Code review FTW!

A common practice in software projects is peer code review. The general view is that code review helps identifying potential bugs and enforcing a project’s coding standards. While I do not disagree with this, I believe code review can mean much more for a project and its team. Consider code review embraces four regions where your, the reviewer’s, ability to learn and teach crosses technical and domain knowledge.

Teaching + Programming: Code reviews gives you an excellent opportunity to share your programming knowledge with your peers. The goal here is not to show off the latest tricks you learned but to improve the skills of an another developer. You can actively contribute to a person’s growth as a programmer by providing valuable feedback. Coaching novices in a particular technology or introducing people into the specific practices of your project are just two ways of achieving this.

Teaching + Domain: Most software projects built in teams are characterized by a non-trivial domain. A non-trivial domain requires a significant amount of modeling to represents its behavior and attributes in code. Since the modeled behavior and attributes are inseparable of the code it seems more than reasonable for the domain aspect to be included in a code review. The reviewer can play a significant role in overall domain modeling by thinking along.

Learning + Programming: Reviewing code exposes developers to different ways of solving problems. Observing and understanding code written by other programmers is an effective way to ameliorate your coding style and techniques, get to know new libraries and learn patterns. Moreover, it provides inspiration for solving problems yet to come and ideas for improving existing code.

Learning + Domain: The information captured in the code makes it a primary resource for learning about domain concepts and the overall functionality. Code is de facto the most detailed documentation of a software system. Reading it with comprehension extends the understanding of a system beyond the parts one was involved implementing.

Most developers will move between the code review regions as they become better programmers and learn more about certain domains. While some will have the opportunity to learn more often; others will frequently fulfill the teaching role. If a developer is new to the technology used in a project, but an expert in the domain, he might have two roles. In some cases the reviewer will find himself in the four regions at once. The advantage of recognizing these regions is that doing a code review is always valuable regardless of the reviewer’s seniority level.

Expanding your regular code review to the fours regions described above can contribute to your project and team by:

  • making the code the property of all developers in the team – As developers we like to feel at home in a codebase. Reviewing code switches the code ownership from the author to the team and turns it to a common good. It makes the whole team responsible for the code quality and enables any team member to introduce changes. This is also related to shared code (or collective code ownership) in Extreme Programming.

  • gradually improving developers’ programming skills – Peer review will raise the average skill level of a team. Furthermore, it introduces a subtle pressure which motivates developers to write their best code.

  • spreading domain knowledge – Understanding the functionality captured in the code helps spreading the knowledge about the whole system between all team members. It makes the team more confident as a whole, enables any developer to work on any part of the system which as result makes story “cherry-picking” less likely to happen.

  • fostering collective intelligence – The quality a team can achieve together is greater than the sum of what developers could achieve when working alone. Every developer brings different skills to the table and ideally a team achieves programming synergy by picking everyone’s best qualities.

Code review is one of my favorite team building exercises. It is not only about the code but very much about growing into a great team. It is worth mentioning that pair programming can be seen as an extreme form of code review. Depending on the frequency of pairing it can be used as complimentary to code review or as an entire replacement.

| Comments

All companies suck (in some way)

A few days ago I came across a blog post by Ahmet Alp Balkan, “8 months in Microsoft, I learned these”. Even though I have never worked for a company of Microsoft size, Ahmet’s article made me deeply think about all the companies I have worked for since the beginning of my professional career in software industry. I was still a student when I got my first full-time job in a corporation with more than 2500 employees. Afterwards I have worked for a few mid-size companies and I am glad I had the opportunity to taste a few different flavors as it brought me to the realization that:

  • All companies suck in some way – There is no perfect company to work for. There will be always something annoying whether it’s code quality, your colleagues, management, outdated technology or boring projects. The key is to identify the flaws you are able to live with while focusing on those aspects which are essential for your happy work life.

  • Companies can be fixed – You don’t have to accept the status quo. You can improve your company by sharing your ideas with people around you. This is true that it’s easier in small companies but even in those as big as Microsoft you can influence your direct environment. Better code? Introduce peer review. Knowledge sharing? Organize a tech session or write an article on the intranet. Most importantly, talk to your boss. Your manager is not able to read your mind and if you have good reasons he will get this new projector for your team.

  • A company must make a profit – Making a profit to a company is like breathing air to people: necessary but not a goal in itself. During your career you will be asked to cut corners for the sake of profit. Try to make the best out of the circumstances by maintaining high quality standards of your work. If you have luck your company will recognize that letting developers write good code makes them happy and happy employees are good for business.

If there is something you don’t like about your job and/or company there are basically two options. You can learn to accept the way it is or your can change something. And if all fails there is always this third option, set off in search of a company which sucks less.

| Comments

A beautiful adventure

This blog is a new citizen in the never-ending stream of my ventures. Over the years, I have made several attempts to start blogging but I never got through the preliminary hassle. One of the reasons I might stick to it this time is Octopress and hosting on GitHub. This tooling seems to fit my needs and state of mind whereas installing WordPress always aroused in me ambivalent feelings.

I plan to write about software development and related human aspects. Expect some posts about programming and technology in general and stuff I experience while working on software projects. Hopefully some people will find these articles helpful or interesting. Anyhow, I think this is the beginning of a beautiful adventure.