Why I đ Code Reviews
⏠Listen to this Story or Read it
I have been a professional iOS developer for almost 5 years now and I can honestly say I have found my passion. One of my favorite parts of being a software developer is that we need to keep an open mind and constantly be learning.
I started iOS development while studying my Masters in Austria. What I did back then was mostly a bunch of little students projects, not really focusing on quality. Then I started working in a startup, as a junior developer. It was a great opportunity. I was the only one working on the project, so for a junior, not that big of a challenge when it came to quality.
After I finished my studies, I moved to Germany and started working full time as an iOS developer. Here, the team was bigger and had processes, standards, a strong focus on building quality software. I found it fascinating.
This is where I first encountered code reviews. I believe this was one of the most important sources for my professional growth and one of the main driving forces in how I nurtured my passion and dedication. I work now as a Senior iOS developer and I attribute great part of my progress to this practice.
Why I think code reviews are great:
You learn the value of constructive criticism
On my first contact with code reviews and pull requests, this was the hardest thing to accept.
To have someone you dont even know in person(some of my colleagues were working remote), say all kind of stuff about your code was tough :). We learn that criticism means you did something bad, you screwed up. And we tend to take it personally, to get offended, to feel not good enough.
This is one attitude each and every one of you team mates needs to get over. To not take criticism personally, but as a suggestion of how to become better and constantly improve.
It took me a long time to get used to the comments. Sometimes, I would get all the way to the end of a feature and the comments would say: âWhy did you do this?â âHow flexible is this?â âCan you draw a diagram of your solution?â
Imagine having to start all over again đ«. Throw away days or week worth of work.
Finally, after a couple of months, I got used to it and I was even able to challenge my colleaguesâ solutions and start finding possible improvements in their pull requests. I had changed. I was getting good at this review stuff :)
After another few months, my remote colleague left the company. The team got a bit smaller since new projects were coming in and we had to split. I had nobody to question my solutions anymore.. It was this moment I realized how important it is to have someone that challenges your code constantly. He was my mentor and I have not even realized it.
After a while, you also start challenging yourself. But this does not always work.. Sometimes youâre tired or just lazy and might decide to take some shortcuts.. Might decide to skip the challenging part altogether.
Thatâs why it is so important to work in a team that is focused on getting the best out of everything, every feature, every line of code.
Embrace the criticism and value the people that challenge you to grow. It will make the greatest difference. I believe this advice applies to everything in life and as long as we can receive feedback and criticism, we will not stop growing.
Cultivate a constructive criticism culture in your team and value it the most. It will bring the greatest benefits
It helps spread knowledge inside the team
Having all the members of the team review the code before it gets merged, helps everyone get familiar with all parts of the project.
Especially for bigger features or modules, team reviews make a lot of difference. Everyone is able to understand the new part of the application, share their concerns, maybe propose improvements and finally agree that this was the best way to implement it.
It is also one of the best ways to help someone new in the team understand how you work.
You get to look back at your code and go âWhat the f**k???â
This is maybe my favorite part. When you open an older project that you wrote and you cant recognize yourself. That is the greatest proof of growth! It is a very nice feeling to realize you made so much progress that you dont even recognize yourself in the things you used to write.
I think this can only be achieved when the team has a strong review culture. We are not able to challenge and second-guess ourself like someone else would. This brings real change, tangible progress.
It is a stepping stone to team-wide standards
Code reviews are also a place where standards discussions start to take place. Everyone has an opinion and everyone in the team is his own individual. But as a team, there is some common ground you can reach, through standards. Everyone agrees and everyone sticks to them.
To define the standards it is not easy. In the begining, you dont even know what you should standardize. Code reviews can provide the basis for that, being a way to communicate the different opinions inside the team.
Naming conventions, formatting, error handling, logging, special cases, comments, documentation. They can all be extracted, step by step with the help of the reviews.
The output will be an uniform, high-quality code base
Once you have a basic set of standards, the code will start to look the same no matter who wrote it. This means, the entire project is easier to read, to understand and to debug.
Since everyone is writing code using the same rules, you will see all code as being written by you. This will improve the way and the amount with which the team understands the project.
Also, with the team questioning every single line of code (more or less :D), you can be sure that the static analysis significantly improves the quality of your application.
You get to learn from your team mates
You are all in one team because you are all awesome. What is even better is that you can complete each other.
There might be something you have not considered or something you happen to have overlooked. Someone in your team can remind you or bring it back to your attention. We all have our blind spots
What do we give back?
Most of the times, there is no such thing as a perfect solution.
So what do we need to sacrifice for all these benefits?
The obvious answer is time. It is an effort to review code, especially if you are doing it right, so it takes time.
Do you see the benefits?
When putting it all in balance, done right, this practice will actually help you save time and money on bugs and technical debt.
I really believe code reviews can make a huge difference in the quality level of an application, which means less bugs, which in turn means less time spending fixing them, which eventually leads to money saved.
Code reviews actually develop an awareness about the validity and quality of our solutions as a team. Even if it is your own review before you finish or if it is the external one, it makes you aware and vigilant in looking for better, quicker, more stable solutions.
It is easier to navigate through the project and maybe even easier to recognize the parts that could be improved.
Thank you for taking the time to read this. Hope you have enjoyed it as much as I enjoy code reviews :). Let me know what you thought about it and donât hesitate to get in touch
If you would like to get personal coaching for improving your iOS development skills and get input from me on your most pressing iOS related issues, I am currently open to coaching other devs. If you are interested, just get in contact . More details here: https://mobiledev.consulting/1x1-expert-coaching/
My goal is to be constantly learning and I believe there is no better way to gain deeper insights than teaching and sharing with others what you know. This is why I want to share my expertise to any mobile developer interested in learning more and getting stronger in their skills.