Read Your Teammate's Latest Code, Every Day
Some seemingly simple practices can greatly improve the productivity of software teams. The practice discussed in this article can reduce bugs, improve design decisions, broaden a developer’s skills, increase team motivation, and strengthen team bonds. It may sound like a bold claim, but it’s something I see frequently in high-performing software teams.
The “secret”? Spend a few minutes reading the code that your colleagues pushed today. That’s it. It doesn’t have to be long time (perhaps around ten minutes), and you don’t need to read every line. The key is to stay up to speed with how your codebase is really changing every day (not just what’s mentioned in the daily stand-up or scrum!).
When you make this small investment every day, the benefits accumulate over time. When the whole team does it, the effects multiply and it becomes like a superpower. This isn’t meant to replace your team’s daily stand-up meeting / scrum / rollcall etc., but it does augment and enhance those meetings. In fact, a popular time to read the team’s latest code is shortly before the daily meeting.
This article describes the benefits of encouraging this practice within your team. Hopefully you can experience the benefits too!
Develop Broader Skills
Picture the scenario: a colleague goes on holiday and the moment they step out of the door, their well-tested thoroughly-reviewed code somehow breaks and causes a major outage in the production system. Customers are angry, managers are incredulous, teammates are worried, you are stressed. You have to identify the source of the problem, and either fix the bug or back-out the offending change. Now.
This task will be far easier if you have read your colleague’s code before. Investing a little time each day familiarizing yourself with how everything “fits together” gives you a far better chance of quickly finding and fixing problems when under enormous pressure.
Being able to step up and solve these emergencies will also make you a highly valued member of the team (protip: it’s best if you’re not also the cause of those emergencies 😊 ).
Accelerate Learning
When junior developers read senior developer’s code, they get real-world examples of coding best practices. When I was a junior developer, seeing how senior team members solved problems, structured their code, practiced “defensive programming”, documented gotchas, worked incrementally, etc. was a huge benefit. What’s more, I got these lessons every day, and it didn’t require any time investment from the senior developers.
When I eventually became one of the senior developers, I noticed that there was a strong correlation between whether a junior developer took the time to read their teammate’s code, and how quickly their skills improved. And as a senior developer, I’m still learning and still pick up new techniques or knowledge from reading colleague’s code.
Efficient Mentorship
It’s important for senior developers to take a quick read of a junior developer’s daily commits. They can easily spot if the junior developers are struggling or have misunderstood some aspect of their task. Its far more effective to give some minor guidance early on, rather than have the junior go too far down the wrong track (or maybe not even make any progress at all!).
Of course, making mistakes is part of learning. The senior developer may choose to let the junior explore the problem for a while, but that should be a conscious choice. The important thing is that the senior developer stays aware of progress. Simply reading the junior’s daily commits is an easy (and unintrusive) way to do this.
“Micro” Code Reviews
Peer code reviews are an important part of developing robust software. A excellent complement to “traditional” code reviews is the “micro code review”. This is a faster, more lightweight and informal approach, where teammates offer each other brief ad-hoc feedback on their daily commits.
This is meant to complement, not replace, traditional code reviews. Importantly, nitpicking must be avoided! It’s all about creating an environment where everyone takes a quick look for bugs / slip-ups / oversights in each other’s latest code.
Some examples might be:
- I found this documentation a little unclear. How about adding […]
- There might be an “off-by-one” error in that loop
- Did you know there’s a library function for that?
- It looks like the code might not handle scenario X
In other words: any feedback is brief, specific, and constructive.
(As with all code reviews, the feedback should be delivered sensitively and with forethought. Be mindful of whether the code is “work in progress”, or the author is under a lot of pressure to hit a deadline!).
No More “Hidden Work”
Unfortunately, it’s common for developers to work very hard on fixing a difficult bug, firefighting an emergency, or performing a boring task, and that hard work goes unnoticed by their colleagues. This is sometimes called hidden work. It can be even more of a problem with remote or distributed teams.
The effects of hidden work are all negative. The person may feel demoralized because their efforts are unacknowledged and seemingly unappreciated. The other team members might wonder why their colleague is behind schedule on another task. Management might not realise how much effort the person has put in, or that a problem exists which is regularly draining engineering resources.
All of these things conspire to rob the team of motivation and even reduce trust within the team. Not a good outcome if you want to ship high quality software on time.
Stronger Team Bonds
Knowing some details of your colleague’s work always sparks interesting conversations and enables collaboration. I’ve seen many great ideas come from casual conversations that started “hey, I had a thought about that thing you’re working on”.
It can even help you understand how your teammates might be feeling. E.g. one teammate may be happy to have completed an important refactor (tell them “well done” and celebrate their achievement!) while another teammate may be stressed because they have been stuck on a bug for two days (maybe take extra care not to interrupt them, or alternatively, see if you can help out?). These insights into how your colleague’s daily work is progressing can really help the smooth running of the team.
Happier Developers!
All of the benefits mentioned above contribute to a making developers happier. When a developer feels that their skills are constantly improving, their work is recognized and appreciated, they can rely on their teammates, and they have positive collaborations, this might just be a dream working environment :)
Hi, I'm Patrick
I'm lucky enough to have been part of some amazing software teams. From developing some of the core software inside Sony's PlayStation consoles (as part of Sony PlayStation's Advanced Technology Group), to developing and running algorithmic trading systems in a multi-billion dollar hedge fund.
My goal is to help software teams produce the best software possible, and enjoy themselves while they're doing it.
My experiences have taught me a lot about what makes high-performance software teams work. I hope that by sharing and discussing these insights, we can all help each other produce better software :)