Development Process, Technical Leadership

3 Simple Code Review Guidelines

facebooktwitterlinkedinmailfacebooktwitterlinkedinmail

I have recently expressed my aversion to code review platforms. Assuming I managed to convince you, the next valid discussion point would be: if we’re not using a tool, how can we ensure the code reviews are effective and efficient? We could spend all night discussing the details of various approaches. While they always need to be aligned to a particular team and project, here is a shortlist of the main guidelines that proved to be beneficial in multiple projects for my teams.

Do it together. I’m a strong supporter of performing your code reviews in pairs. I believe you can get the most value with the least effort when both developers (code author and the reviewer) are looking at the same screen, talking to each other: asking questions, explaining, advising. The pairs should not be fixed, otherwise you will limit knowledge sharing and increase the risk of conflicts in the team.

Do it early. ‘Early’ meaning: as soon as your current task is coded, or even during its implementation (if it’s complex). The earlier you get a second opinion, the easier it is to change the code. While it might sound ‘unfair’ to ask an ‘innocent’ person to drop their work and review your code, my experience is that it actually improves the flow within the team. Try it and see for yourself.

Do it often. Daily code reviews can be very helpful in case of fast-moving teams that are building new systems. For maintenance-oriented teams you can adjust the period to fit the need. My preference is to keep the sessions under half an hour, so if they tend to overrun often, it may be a sign that they are not performed frequently enough.

FAQ

How can we ensure that code reviews are not missed in this approach?

Make them a part of your Definition of Done. If it’s enforced properly, developers will have to perform them before moving on to another task (the concept of Kanban WIP limits can be helpful here). A development task without a code review should never really be considered ‘Done’, as some reviews can result in significant changes to their implementation.

What if all code reviews are performed by the manager/ lead in our team?

If you’re that manager – stop it. You won’t keep up with doing it properly, and you’re taking other benefits off your team members. Coach your developers in reviewing each other’s code and offer your help whenever needed. Leading an inexperienced team can be more challenging of course and requires exploring additional techniques, but avoid putting yourself as the only reviewer – your goal should be to have a self-driven team, and that’s an important part of it.

What to do in case of distributed teams?

That’s simple nowadays – use a phone and screen sharing (yes, both audio and visuals – that’s very important). If your team is distributed, you should already have this figured out anyway. As with many other practices, avoid separate locations to be an excuse for limiting communication within the team. It’s not the same as with face to face reviews, but try getting as close to that as you can.

But we’re already doing pair programming…

In that case you should already be getting most of the benefits described here – assuming you’re applying the practice properly (I may write about it one day, too). I would still recommend to occasionally bring in a 3rd developer to have a fresh look at the critical pieces of the code, but in general your team is in a much better situation already.

Summary

At the end of the day, it’s important that you promote a culture of close collaboration and open discussion in the team, and the way code reviews are performed can have a significant impact on this matter. If people avoid discussing with each other and hide behind a tool, that’s going to cause more and more problems in the long-term. Instead, follow a light but strict approach of frequent, short reviews performed in pairs, giving an early and direct feedback about the code changes.

Please feel free to describe your approach to code reviews in the comments.

facebooktwitterlinkedinmailfacebooktwitterlinkedinmail
Standard
Development Process, Technical Leadership

Code Review Systems Are Harming Your Team

facebooktwitterlinkedinmailfacebooktwitterlinkedinmail

Code reviews should be an essential practice in every software development team. As an industry, we are long past the discussions about whether to perform them at all, focusing on implementing them in the most effective way instead. As with many popular practices, some companies offer tooling that promises to lower or even eliminate the hard parts of it. You can tell from the title that I’m not a huge fan of those.

Problems with Code Review Systems

To be clear, I am writing here about systems that support offline (or ‘asynchronous’) code reviews. You send the code changes to another team member through the system and get their approval or suggestions back after some time. They are meant to save time by eliminating the need to meet and chase people, but they actually harm your development process in multiple ways.

Decreased knowledge sharing. Besides identifying code issues, another benefit of code reviews is an opportunity to share knowledge and experience between team members. And it works in both ways – the reviewer and the code author can give each other additional insight into a specific part of the system, technology, business domain, and more. It’s not something that would normally be entered in code review comments, many such things come up during a conversation between developers.

Communication issues. Teach your people to avoid talking to each other and you’re asking for big trouble. Giving ‘code advice’ is a very delicate matter, it’s easy to offend someone just by using the wrong tone of voice, and it’s even more difficult to control such effects in writing. Developers usually approach this in one of two ways: some avoid the possible confrontation by giving ‘standard’ comments, and others just directly write their opinion, not caring about how it will be interpreted. As you can guess, both ways cause problems.

fight photo

Lower job satisfaction. Many developers actually enjoy showcasing their work when they feel it was done really well – it’s like showing our precious baby to friends. Having it reviewed by someone offline is not really the same thing. You don’t hear the reaction or see the look on their faces while you guide them through your brilliant solution…

Less pressure for quality. I believe that most people (not just developers) do a better job when they actually have to show and explain the results to someone else. We all want to appear smart (or at least avoid humiliation), and we are often willing to give extra effort for that. Again, it’s a stronger effect when you do that in person.

Interruptions. Do you think you’re limiting the interruptions in your team by queuing the code reviews in a tool? Think again. What you are actually doing is replacing a small interruption with a larger one. In most cases, it’s just more difficult to shift your mind from one coding task to another, than from coding to reviewing (and back).

For instance, imagine a developer finishing a coding assignment. He puts the task into Pending Review status in the system and starts development of another feature, shifting his focus to a different problem. Then, after a few hours (or even days), he receives a list of required fixes from the reviewer. He goes back to the previous feature, possibly interrupting the new task. How much time will he lose to switch back to the original context? How many little details has he already forgotten about? How many issues it will cause? What is his motivation to change a feature he has already (mentally) closed?

The Good Kind of Tools

Having stated the above, I definitely support and encourage utilization of static code analysis tools, like FxCop and StyleCop for .NET developers. I believe such tools should be an important step in every mature build process. They give you multiple benefits without any significant drawbacks, and require only constant (i.e. independent of project size) time to set up.

Another scenario is audit documentation, e.g. PCI. It’s easier to keep code review evidence for such purpose in a system rather than on separate forms, but it should only be used as a means to document code reviews that were performed, rather than as a replacement for them.

Summary

For every automation opportunity you need to carefully review both sides of the picture. While ‘offline’ code review systems can save you some time in the short term, the long term results will vary from some missed opportunities at best, to significant communication and quality issues at worst. I’m not saying ‘don’t use them at all’, but if you decide to utilize such platform then make sure it’s not used for all reviews, and it’s not an excuse to avoid direct communication and important discussions within the team.

At this point, a valid question would be: if we avoid using code review systems, how can we make our review sessions effective? That’s going to be the topic of my next article.

facebooktwitterlinkedinmailfacebooktwitterlinkedinmail
Standard
Links

Leadership Links Mashup #1

facebooktwitterlinkedinmailfacebooktwitterlinkedinmail

Every single day I read at least a few articles about topics which I want to grow in. When I was working as a software developer, I used to follow a number of technical blogs and websites. I found it to be a simple and effective source of programming knowledge – a great complement to books and practical exercise. Just spend an hour per day while queuing or commuting, and you soon become the ‘go-to’ person for your colleagues when they need an advice on which tool or method can be used to solve a particular problem.

In a manager’s role this approach was still very useful to me, and I naturally started looking for similar resources about leadership and related soft skills. While there’s plenty of such content on the web, it was very difficult to spot the really valuable articles among all the feel good/dream big/be yourself mumbo jumbo.

So after spending a lot of time myself, I decided to make it easier for others and publish a regular selection of the most interesting links I have encountered recently. I don’t want to commit to any particular frequency at this point, I will just post them each time I collect an interesting bunch. They will cover both general leadership skills, as well as topics specific to software development management.

Below you can find the first selection. Enjoy!

facebooktwitterlinkedinmailfacebooktwitterlinkedinmail
Standard
Management, Technical Leadership

Why You Should Become a Technical Leader (Or Not)

facebooktwitterlinkedinmailfacebooktwitterlinkedinmail

For most software developers, there comes a moment in their careers when they ponder next steps. Should I continue in my current role, gaining more and more experience and eventually building more complex and challenging applications? Or should I follow a different career path, more focused on managing teams? What factors should you take into account when making such decision? Here are the ones that I consider to be the most important.

manager photo

Job Satisfaction

In general, are you enjoying your current role? It might seem obvious to answer ‘No’, as you otherwise wouldn’t be considering a career change, but think about it for a bit longer. Is your lack of satisfaction really caused by the role, or maybe it’s because of your current project, assignments, the people you’re working with or some other factor that can be changed?

When was the last time that you felt good about your job? When were you last excited about your next day at the office? What is different from then to now? Before you make a serious career decision, try to recreate that situation and see if you can feel the energy once again. You could discuss such options with your manager or coworkers, consider moving to another project or volunteer for additional tasks – depending on what made you happy the previous time. You should also consider other technical paths, like becoming a trainer or possibly an architect.

Once you are confident that this type of challenge is needed, a manager’s job can be extremely satisfying – if approached well. While you no longer have direct control over the results, it’s a great experience to see how your efforts bring benefits in the long term. Helping your team members grow and achieve their own goals is another source of fulfillment. There’s also a lot of room for creativity: team building, strategic planning, making decisions that shape your projects or even the whole company – all of that can turn out to be a wonderful journey.

Personal Growth

Leading a team requires applying more soft skills than technical work. Qualities and abilities such as:

  • Confidence
  • Effective listening
  • Delivering feedback
  • Building trust
  • Communication
  • Time management
  • Negotiation
  • Conflict resolution
  • Building engagement

are important for all employees, but need to be used to a much larger extent by a leader. So if you want to be good at this job, you are forced to improve on them. As a side effect, you can become a better person and enhance your behaviors in other areas of your life. If you approach it correctly, it can help you improve relationships with your family and friends, deal with personal problems more effectively, and so on.

Future Career

Have you ever thought about what you want to do in your 40’s? What are your long-term career goals, what type of job would you like to perform? If you intentionally want to continue in a programmer’s role, eventually getting onto more and more advanced projects – that’s perfectly fine. However, many software developers don’t even think about it now, which I see as a big mistake.

road photo

Some people have well-defined goals for their future, for example they would like to become a CIO, or even run a software company. If you belong to that group, becoming a technical leader is definitely a good step towards that goal, and will allow you to start gathering the required experience. Even if you want to run your own start-up, such practice can serve as a great foundation.

In general, performing a team leader’s role allows you to verify if a manager’s career is something you actually want to pursue in the future, without dumping all of your technical duties now.

Summary

The right motivation is everything in a manager’s job. Without it, you won’t be able to accept the increased amount of stress and effort, lack of direct control over results, additional (huge) amount of learning, and all the other factors that are required to perform well in this role. Make sure this is really what you want and need for your career and life, and don’t let it become an escape from your current work problems.

facebooktwitterlinkedinmailfacebooktwitterlinkedinmail
Standard