Our Code Review Culture code — Part one.
At the Reptrak Company we have 5 core values:
Our Core Values
- Be a Pioneer. We are entrepreneurial and constantly creating value.
- Practice Rigor. We focus on quality, precision, and validity in our work.
- Stay Committed. We follow through on commitments to honor our word.
- Be Honest. We’re ethically, fiscally, and environmentally responsible.
- Be Brave.
Let’s focus on the 2 more related to Code Reviews:
- Practice Rigor.
- Be Honest.
Seems like every time we do a Code Review, we need to be driven especially by these 2 values, and also not only at the time of writing this article.
There are as many Code Review Cultures as teams, so in this article, we want to be honest and share with the world our practices, but first, some facts/thoughts about RepTrak.
We are a global company
- We cover 18/24 timezones
- We measure innumerable cultures and backgrounds
- We have diverse relationships to work, and various expectations around relationships to work
- We have boffins — Subject matter experts on topics like diversity, inclusion, and equity — as well as leadership. “a person engaged in scientific or technical research.”
Humor is not globally accessible
How do we create a safe spaces for ubiquitous language, across technologies, teams, and diverse skillsets?
- Diverse backgrounds, media, and cultural heritages mean that we have to allow space across geographies and backgrounds to ask questions, leaning into our value of being Brave.
- What is very funny to you — can be offensive to other people — even with the same background!
Lost in translation problems
A story to illustrate how this happens, from the perspective of one of our team members:
”I had a close friend that was the executive of an international company that was expanding, and he had to visit a ton of countries to build new factories. He always told me ‘the places where I had more problems were the countries where they use the same language, and false friends appear’. Once he visited a factory and the workers demanded in his mother tongue to buy ‘women underwear’, — he thought it was a joke.
Next week the workers went on strike because they needed ‘protection dresses’, or as known in this country ‘women underwear’.
Another example, ‘currar’ in Spanish is ‘to work on’, for an Argentinian will be ‘to steal’, so imagine the reaction when a Spanish team lead told the new Argentinians programmers, here we will ‘steal’ (work) a lot.”
There is no perfect code
Code is always attached to the context in which is developed, which means that code and context should be one and only.
Let’s clarify this idea by showing an example, almost any developer has seen code on how to create the factorial of a number and has introduced to the idea of how to implement a recursive function using this method.
So, which one is more correct? The one that uses recursivity, the one linear? Will depend on the context. Let’s put an extreme example, we need to calculate the factorial of a massive number, but in this case, a good enough approach would fine. (this could be an authentic example if you need to do approaches in quantum physic’s problems).
If you try to use those previous algorithms, the factorial will take forever. In this context, the code will change to approximate Stirling’s formula, or similar approximations
Bad Code is normally generated by Good Programmers in unpleasant situations
We as engineers are super biased about bad code, pointing fingers to a simple culprit: bad programmers.
We need to fight this bias and try to see why bad code happened.
Why does bad code happen to talented programmers?
- Lack of context. Nobody explained why this was critical, what the use-cases were, or how it could be used. Business logic implemented based on poorly defined requirements without fully thinking through the consequences and/or alternatives.
- Human problems. Nobody reads or writes code after 2 hours sleeping the same after 8 hours. If one relative is sick in the hospital, do we expect this person to perform exactly the same?
- Time. We tend to see legacy code as bad implementations but; the reality is best practices changes with time, and all code is written at a specific point in time.
- Lack of experience — in the programming language and trying to use patterns learned in another language that doesn’t correctly fit in the actual context?
- Premature optimization — we do a super performance code for something that doesn’t need to be fast? Or imagine the case where you use Sterling’s formulas from before, for calculating the factorial of numbers that are smaller than 100.
- Egos. A new guy wants to impress their new colleagues and adds mistakes for trying to over-perform?
Considering all of these problems, how can we write better code?
Provide Context — the more the merrier, some strategies:
- Use ubiquitous language and make sure everyone understands it
- Use whiteboards, draw, model a lot in groups. I.e. Bussiness model canvas, Swardley maps, etc.
- Acceptance criteria in your tickets, and also business value+context: Why you are doing this?
- Enforce in agile ceremonies that everyone is on the same page: Simply asking other team members to explain the problem.
- Ensure you fully understand the requirements and impact for stakeholders (users, Engineers, Products, UX, etc.). This is especially important for business-critical logic and complex implementations.
Humans problems
A technology organization can’t solve most of it but at least should try to help with coping, and normally a good manager knows how to handle this, but not only, the rest of the team should feel engaged and available to help on these situations.
Time
So the code worked. Can we improve it? Don’t waste your time justifying, explaining, or criticizing the oldies, only if you have time to battle the tech debt try to fix it, or add a test. The code you pushed today will be tech debt someday soon.
Lack of experience, premature optimization & egos
These kinds of problems normally are on the engineering manager, but as a team, we can help a lot also using techniques like pair programming, especially for new arrivals to the organization.
Remember this
We’re all employed with the same organization: the quality of our code doesn’t reflect on any individual engineer but falls on the shoulders of the engineering department of the organization. It’s not my code, or your code, that gets praised or faulted, but rather one of “that RepTrak product is great” or “that RepTrak product kinda sucks!”
Reviews should always be harder on the problem than on the person. The point is for us to build something great together, not tear each other down.
How is the code review culture at your company?
We’re curious to learn about other code review norms, patterns, principles, and practices. How do you engage with your team around code smells, tech debt, and differences in standards?
