Everyone doing software engineering understands the importance of code reviews, and there is an almost unlimited number of articles that talk about code reviews best practices and how to perform them.
Today I want to share with you a different angle on the topic, discussing how we use code reviews at ZEISS not only to improve the quality of our codebase over time but also to build stronger teams, improve cross-team collaboration and promote learning through mentoring.
A few words on quality
The primary purpose of the code review is to make sure the overall code health and quality of ZEISS’s codebase is improving over time. In order to achieve this, we created a strong change review process, which relies on the senior engineers on the role of code reviewers to own the CL (change list) and balance the trade-offs between the feature sets and the engineering rules on the code.
As a general rule, reviewers should favor approving the CL once the code is in a state where it suffices its purpose, it’s properly documented and improves the overall code health.
Code health or code quality can be relative to each project or team, depending on their specific needs and programming language in use, however, there are some concepts which apply during the code review phase which includes:
- The code is well designed
- The code suffices its purpose
- There are no broken UIs
- The code is easy to follow and understand
- The changes are tested
- The code follows proper naming conventions
- The code is properly commented
- The code follows the style guide
- The code is properly documented
Tooling
Whenever possible we make use of tools that help us validate a number of items before the CR reaches the reviewer. Tools can help us automate the validation of coding style (with tools like eslint), test coverage and test results, naming conventions, etc.
Mentoring
Code reviews are like knowledge exchange sessions, and they can be an important part of teaching developers best practices, or something new about a language, a framework, or general software engineering principles.
During this session, the reviewer will comment over all the findings identified from his/her experience with 3 different types of comments:
- Necessary changes
- Suggested changes
- Informative
Necessary changes
Enforceable changes are changes that are mandatory to resolve in order for the reviewer to approve the code. Though we encourage reviewers to be flexible with personal preferences, we do follow the rule “Technical facts and data overrule opinions and personal preferences”.
Enforceable changes are those which guarantee our code health and quality.
Suggested changes
These are comments that are placed by the reviewer to suggest an alternative solution for a given problem or suggestions for a different way to accomplish the same. If there are no big reasons to rewrite the code, the reviewee can opt to do the changes or to keep the code as-is.
Informative
These are comments which do not require resolution, they are of informative character, and they are used just to provide additional information among the parts. A good example could be a summary of the reviewer’s thoughts over the CL. They provide a path for more generic feedback which can help to build the relationship between the parts.
In any case, all comments are intended to be constructive feedback, and a way to transfer knowledge between the reviewer and the reviewee, or vice-versa. There are some rules any comment should follow to be effective for this purpose:
- Be kind
- Explain your reasoning
- Enable the reviewee to solve the problem by just pointing out the issues with the code rather than giving an explicit solution
- If the code is hard to follow, kindly ask to simplify the code rather than explaining the code to you
Building stronger teams
At ZEISS, we have a strong team culture. Teams are empowered, autonomous and fully functional units. To maintain them productive we make sure there is respect and trust among team members, but also, that they have fun while working on the projects.
Code reviews as discussed play a crucial role in supporting the individual developer’s growth and learning, but it also helps build better relationships and trust. And this is true not only for my own team members but also for people among different teams in the organization.
As we covered before in our microservices / microfrontends architecture, each team project is connected to the overall Digital Customer Companion (portal.zeiss.com), and we often use common services or libraries that every team can upgrade. Thus it can be very hard to keep up with the changes to a popular service when it can be altered by multiple teams.
Code reviews help us to keep it under control, and keeping everyone informed of what is occurring. As code reviews that happen in the form of a PR (pull request) are not limited only to members of my own team, reviewers who are interested in a particular service, a library, or a microfrontend can review the code of any team as long as it follows the guidelines.
But it is often the case that the engineer creating the PR will assign it to specific people from their own team, and from other teams that are experts on that particular area or code repository. This creates a balance and accountability cross teams that help increase the code quality and bring teams together.
There’s a lot to talk about how our teams perform to deliver the quality products ZEISS is known for but would be the subject of its own article.
Conclusion
Code reviews are at the heart of our performance and quality, they are not an annoyance in the process but rather an opportunity to learn and build better code.
Fun fact: this blog post has been subjected to
a cross-team code“post” review.
Thanks for reading!
Three critical factors to consider when you work as software engineer in digital B2B
A well-oiled machine, where all parts (competencies) work perfectly together and incremental software solutions with great user experience and business value are delivered to our customers daily. That´s what digital transformation – or rather say business transformation in the digital age is all about. Right?
Textbook solutions are available everywhere, even on the internet. What to do, how to do it, what competencies you need? Here it is: Just describe the vision of the digital product to be developed. Move on and develop the product with the user and/or customer. Get a great DPO with business know-how, get an agile coach, add some leading designers (UX, UI and maybe even DT initially) and then we get our great engineers on board. Some backend experts, some frontend experts and add a solution architect. You build on leading, cloud first infrastructure and work in a DevOps mindset. Done!!
Yes – in theory it is easy.
At least for us at the ZEISS Digital Innovation Partners, this is not the case! It is not easy. It is hard work to bring leading digital solutions to B2B customers. Why?
Developing Digital in a B2B world
Well first, we are not only talking about a new “Digital Solution” we are talking about a business and cultural transformation. Second, we need to develop and build up complementary competencies to design, develop and scale digital solutions. And third we need to learn how to collaborate across ZEISS, across x-functional teams and at best in dedicated swarm teams within ZEISS and with external partners and/or customers.
All three elements are true for many competence areas, but especially also for software engineers. In addition to being excellent in your respective area (Frontend, Backend, SW-architect, infrastructure, …) or coding languages/framework (React, Angular, JavaScript, Node.js, Scala, .NET, …), it is important, to become good or even great in the following three areas:
1. Understand customers’ needs – our digital solutions are for their success
Have you ever developed a great App, or written some awesome lines of code and in the end, nobody used it? Do you know how that feels? For me personally, an innovation is only an innovation if it reaches customers and enables them to be successful. What is an App worth that finally cannot be used by customers because of API-issues or specific requirements nobody took into consideration – not you, not the DPO. How does that feel after many nightshifts? So what? Go out!
Understand the customer and the user of our software and digital solutions. Understand in which surrounding, under which circumstances our customers will use the solution. Really understand what the core challenges and the underlying needs of our customers are (empathize). Sometimes an .xls-file is more helpful than a fully fletched AI-Chat-Bot. Sometimes a .pptx-document is better than a complicated dashboard which is updated every 3 ms. But sometimes a well architected digital solution, using the latest tech, the latest frameworks and all of that deployed and improved in DevOps-mode is the right thing to do. There is no good or bad – there is only good for what and bad for what. Let’s understand our end-customers! Or as my design-friends would say: “The onus is on us”
2. Listen well, collaborate and deliver as a team – we win together, and we lose together
Talk less and listen more. We as technically trained people and especially the breach of software engineers does not like marketing talk. Let´s get down to the real stuff, let´s talk complicated and complex challenges. Let´s only focus on content and challenging issues. Let´s solve the problem – done. Everything is logical. Right? No – wrong.
We are all humans with different trainings, different feelings and different way of discussing. We need to learn how to listen well, listen to other competence areas and discuss topics of business and design. We need to come to a basic understanding of the way of working of other competence areas and just accept that colleagues think, work and behave differently. This is neither good or bad – just different.
We might even have to learn some new vocabulary: What is a business case – no worries, nothing complicated but important in the business world. Wireframes we need for our frontend experts, but what are the differences between desirability, usefulness and usability? Why is the sales person talking about leads and order intake or the service person talking about MTTR? These competencies are equally important. Why? In order for the digital solution to be relevant for the customer, the whole chain needs to work and we need to work and deliver as a team.
In our circumstances, we are part of a great and globally leading tech company in the B2B world with more than >170 years successful history. Our customers expect us to deliver great, leading and serviced products and not “show-cars” or untested “PoCs”. For that we need to be professionals and convince for example our sales colleagues of the value of the digital solution. They have known some of the customers most of their professional life. What happens, if sales do not understand or trust the digital solution? How will they talk about the solution in front of customers?
Designing, developing, deploying and continuously improving digital solutions is a team sport. If you want to win a championship in basketball and your point guard scores 39 points and at the same time defense regularly breaks down – well, try again. If you develop a great frontend but the backend cannot pull the right data to be displayed to our customers or the service organization is not ready to answer business questions regarding the digital solution, we will not have success with our solution. This is a call for team collaboration. Working in a team with different competencies always requires tradeoffs and a team spirit.
Respective tools can boost collaboration and even agility and create transparency throughout the team, but the mindset to collaborate and to work as a team needs to be ingrained in every member of the team. We for example collaborate across all functions via Microsoft Teams. It works quite well, increases the sharing attitude and transparency. A recent project called PreciseUI, which enabled the handover between design and engineering successfully would have never been developed at high quality by engineering or design in a separate approach.
Collaboration as a Team requires respect for everyone’s competencies. Digital is like a horizontal force of nature – acting across all functions and competencies. The upcoming challenges are too big, too interwoven and too complex to be solved by only one person
3. Continuous learning – Build your T-Shape
Understanding the customer and working in a team does – for sure – not free us from our core responsibility as a professional software engineer – writing code that helps our customers to be successful.
In today´s world, where everybody is just a message away, where knowledge is shared widely, where new services are developed and offered by individuals and even by some of the most valuable companies on the planet, we need to be continuously learning to be successful and to stay up to speed. This is a mindset and a very valuable investment.
There are many opportunities to continue to learn. Learning from colleagues, from blogs, from official trainings, from tech-talks, meetups, during hackathons or by just watching some video. Learning and applying the learnings in a continuous manner is crucial to be successful in the long run.
In addition, I personally strongly value a T-Shape profile. Having a good overview of what is happening in the tech world, what coding languages and approaches are good for what and having a basic understanding of the most relevant competencies, such as Frontend, Backend, architecture and infrastructure lets you understand the big picture. At the same time, you really need a core competence to build on and to develop further.
In my experience, moving to a generalist too early, could leave you with: Check of all traits – master of none. One key question to ask is always: Why and what for would colleagues ping me or even call me?
Conclusion
Today’s tech world is also about sharing. This is a start and is meant to give an overview about the environment we work and live in. We will continue our journey of sharing and collaboration.
