Mentoring and Code Reviews

A fellow developer, let’s call him John, approached me recently to ask if I would take on some paid work, essentially helping him to finish off and fix some issues in his first major iOS project. I agreed and subsequently decided that it was outrageous for me to charge for the work and that it was time for me to repay a similar favour someone did for me.

When I started writing Objective-C and Cocoa code after years of developing Windows software it was a steep learning curve because I’d been mostly working with VB. I’d really not done much with C so I was effectively a new developer albeit with a lot of development experience.

A developer called Jonathan Dann, who in those days was yet to work at Sofa or Facebook, spent a few hours going through some code I’d sent him. He gave me a huge number of tips and pointers which were invaluable and he quite rightly said that it was important not to get into bad practices early on of the habits would be harder to break later on. That brief bit of mentoring was incredibly useful and incredibly important.

As I looked at John’s code recently I realised a few of things:

  • The proliferation of blog posts, books, training videos, forums and other resource such as StackOverflow are great. They allow people to get up to speed and create great things very quickly. However if the code they are teaching is not of a very high quality then they will start impart bad habits or, even worse, incorrect techniques, on their students.

When you write code that other people might use or copy do your very best to write clear, well-structured, ‘correct’ code.

  • Code review, mentoring or whatever else you want to call it need not take vast amounts of time. I’d always avoided doing things like this before and, to my deepest shame, only got involved because it promised to earn me some money. In just an hour or two I was able to spot a few core issues and write a list of things for John to look at. The results of those few minutes will, like Jonathan’s do with me, last forever and help cement some fundamental ideas and principles into John’s coding techniques.

Just a few minutes of your time can make a massive difference. Make time for others.

  • It’s not a one-way process. As I looked through John’s code it made me think carefully about the advice I was giving him and making sure that it was right. It made me look at my code and my coding styles much more closely than I normally would and it was a reminder to spend a few moments each time I write some code to review it and polish it if necessary.

You can learn from reviewing someone else’s code because it makes you think really carefully about every word of advice you give and every line of code you change.

  • We’ve not yet done this bit yet but I am looking forward to John’s feedback about my comments. We’ll discuss and debate what I’ve said and I really hope that that his comments will make me realise that I’ve got things wrong or could do things a different way.

As an indie developer I don’t really do code reviews with colleagues so having my own advice questioned and having to justify it is extremely important.

  • Very few of us take anything but the most glowing feedback well, even if it is presented positively. It is natural to be defensive about what we’ve done and actually it would be more worrying if you didn’t care about your work. I applaud John’s bravery in asking me to look at his code and this is something I need to learn from. However it also made me try to make all the feedback I gave in a positive way. If I don’t embarrass, humiliate or upset John then he’s more likely to take note of what I say or challenge me.

Don’t be a dick when you give someone feedback. It’s counter-productive and you don’t look big and clever.