Cross platform code reviews

2 minute read

Code reviews are nothing new in the developer world. In our team, we work according to the git flow principle, meaning we use one or two historical branches and use other short-lived branches during our sprint to work on features, bugs and releases. Once the work is done the developer creates a pull request on Github and assigns another one to review the code.

Given that we have 3 platforms and only 3 developers, each of us owns one platform to develop for fulltime. When we review code this usually is from another platform, one we do not necessarily technically master. So we look at code more from a logical point a view which has a few benefits. First off, we all need to write readable code. Otherwise you get a lot of questions about how or why you wrote something. This effectively eliminates smart ass coding where developers compete to write as much logic on one line. You know what I’m talking about, we all do it. Secondly, we learn a lot more from each other than initially thought. Three platforms also implies 3 different cultures and customs. We see the good and bad practices and can take ideas or guide each other into new, uncharted territories. And last but not least, we get a lot more knowledge about the code within the team. Everyone has a pretty good idea how it all fits together and we help out one another when it comes to handling smaller tasks or fixing bugs when we can.

It’s also funny as we have fulltime Java developers looking at Objective C and C# or any of the other combinations between developers and code, which creates the setup for good jokes at times. But more importantly, we grew as a team and became a lot more mature when it comes to doing things the right way. No-one can get away with half baked solutions, which is basically what we are currently still fighting to get rid off. If you have the opportunity to try it, I suggest to give it a go. And if you are afraid this will increase the bug count, you have another problem to tackle first. Either you fail to trust a perfectly capable team, or you hired the wrong people. In which case you should first work on that and then proceed with this. Every sprint we learn new things from each other and it would be awesome if we could inspire other people to do the same.

Leave a Comment