Code reviews shape your digital journey, a reviewer’s perspective

Code reviews should play an important role in successfully enabling your Digital Product delivery

Alexandru

Alexandru

Community Manager at Softvision
Alexandru chose Softvision in order to complete and enrich his digital journey towards a professional career with high-profile enterprise projects developed to the highest quality standards, being amongst the first colleagues hired in the Bucharest office four years ago.

During his collaboration with Softvision, he leveraged his decade of software development experience and contributed to many successful projects.
Alex is a public speaker for brand awareness at various national technical events and has contributed extensively to the Enterprise NET community staffing globally.
Alexandru

Latest posts by Alexandru

Reviewing pull requests properly or performing code reviews, in general, is one of the most satisfying experience a seasoned developer can have… if done right.

At Softvision, as a developer, I was blessed with the opportunity to fine tune this ability and see it evolve and impact projects, clients and fellow developers for the better. Let me tell you my take on the whole process, if I may.

Let me start by first sidestepping a little ☺

The code review process usually implies:

  • Looking objectively at someone else’s code base;
  • Scanning for erroneous use of design patterns;
  • Quantifying the overall quality of the code (the amount of code debt or code smell);
  • An exhaustive look at the code(also known as Over 9000) if I’m part of the team that wrote the codebase or high-level look if I’m an external reviewer trying to ascertain if a certain project is going in the right direction or not;

This give or take, close to the textbook definition of a review except it needs a more personal touch, a human touch, so in essence, a code review process should also highlight the following in my opinion:

  • Emphasize good code or implementations, good use of design patterns;
  • Humanize bad code, code that needs improvements by presenting an explanation of the “perceived” issue, an example of the “perceived” better implementation as well as a mandatory call for discussion in order to better understand the context under which the code was written and determine if “perceived” equals “actual”; (To all the developers who had to insert code debt, hours before the release, Yes! I’m looking at you! I tell you it’s fine! It’s fine as long as you do the wrong thing for the right reason with the intent of fixing it later. Our clients are depending on us, for quality solutions, yes, but also solutions that work and sometimes mistakes are made, but we must soldier on, our clients are depending on us)
  • Your overall technical experience, let me explain, each time you review someone else’s code you are applying all your experience to better that code, to better the submitters coding skills;

Getting back on track after this “small” side step, or explanation, the reasons why I think that code reviews shape your digital journey through technology, the reasons why you should be involved in the code review process in your project/company are:

  • Improved code quality: by pitching in, you will improve code quality and indirectly improve the skills of the entire team
  • Improved communication: By discussing and understanding the context under which the code was written you will unknowingly create natural communication channels with all the team members based on a common drive: to better the entire team’s tech skills
  • Lessons in empathy: by learning to understand the project context, the team, the skillset of the team, by placing yourself in the shoes of the submitter, you will perform the review with empathy, thus highlighting what is good and also what needs to improve with a collaborative and friendly tone

You will be exposed to the opportunity to mentor others on best practices and at the same time improve your own knowledge. I find nothing more rewarding than teaching and mentoring others, shining a light on best practices, giving back to the community as others have done so for me in the past(remember – you are the sum of all your past experiences and interactions with developers, Team leads, managers and other “influencers”)

  • Don’t overcommit, if you’re not confident you will be able to look at the code with fresh eyes and finish on time, have the power to say no. If I have a doubt I will be able to give my 110% on reviewing someone else’s code, I will pass the opportunity, rather than not deliver at the high level of quality that is expected of us, by our peers, who rely on our help;
  • Baby steps, perform code reviews in chunks of files(a few files at a time), code lines(100-400 lines at a time), call them review “sessions” if you want, so that you can benefit from maximum attention span and focus;
  • Write good comments, clear, short, concise; Where you are harsh, call for a follow-up discussion to better explain your reasoning;
  • Get lost in little code issues, small defects BUT focus on the bigger picture – gather all those small code issues and defects in the “miscellaneous” area of the code review, your submitter won’t be affected/annoyed, but your Q&A engineers will appreciate the extra effort in catching those pesky corner cases;

The major don’ts:

  • Nobody’s perfect, nobody will win the “I’m a better developer than you!” fight or the “This is the only way to write good code!” debate, so stop trying to. There is no perfect code, there are only readable & maintainable & reusable code and teams that work in harmony;
  • Don’t get emotional, it’s not you versus them, it’s us together along in a digital journey that positively affects clients, end users and betters the world;
  • Don’t analyze the code and propose total overhaul of the architecture/redesign of the codebase – be mindful of the client’s context and propose those actions that are doable inside the constraints provided (team size, client infrastructure, etc.);
  • Don’t analyze the code through your coding style, code standards or preferred patterns; learn the project-specific coding standards beforehand and judge the code on how it was written given the specs/analysis/developer experience level and context, NOT on how you would have written it;

If I were to pinpoint the moment in my career, where I started to grow exponentially from a technical perspective it would definitely be the moment I started performing and submitting code reviews.

I would love to hear your thoughts on this matter, what has shaped your digital journey?

Never stop learning!

 

 


(1)Read the analysis documents of the specs, pull the code from repo, build the code, run code quality tools, run unit tests, smoke test the functionality.

Share This Article


Alexandru

Alexandru

Community Manager at Softvision
Alexandru chose Softvision in order to complete and enrich his digital journey towards a professional career with high-profile enterprise projects developed to the highest quality standards, being amongst the first colleagues hired in the Bucharest office four years ago.

During his collaboration with Softvision, he leveraged his decade of software development experience and contributed to many successful projects.
Alex is a public speaker for brand awareness at various national technical events and has contributed extensively to the Enterprise NET community staffing globally.
Alexandru

Latest posts by Alexandru