DEV Community: Xapuu

Code Review Anxiety: Causes, Consequences, and How to Manage It

Xapuu — Wed, 27 Nov 2024 07:27:24 +0000

What is code review, let's check some definitions

"Code review": The act of crucifying your colleagues in public, while showcasing the superior qualities of the reviewer. In cases where the reviewer makes a mistake, he/she must make a ritual suicide out of shame.

Jokes aside the "Code Review" (CR) is an essential step, of the software development for any product with multiple collaborators. During the process, one side (the contributor) provides a code solution to a problem whereas the other (the reviewer) provides feedback, on the submitted solution. Based on the provided feedback, the contributor might need to make extra changes to improve the submitted solution, based on the input from the reviewer.

It looks like a straightforward process, where people help each other to deliver the best solution, but the devil is in the details...

The problem and why code reviews might be stressful

Many developers tend to dislike conflict and let's be honest, many people in IT are introverted. However, participating in code review is inevitable for every developer.

The CR process by design is a type of social interaction and all social interactions by nature can lead to conflict, caused by a clash of opinion.

These social interactions in some cases might lead to something called "Code Review Anxiety" which besides making people feel bad, on a personal level, also impacts their work and might cause some unwanted side effects on company level.

Take this text with a pinch of salt, as there are no concrete metrics and not enough research done on the topic, this article is mostly based on personal experience and whatever exists currently on the web.

Personal impact

Anxiety

The term "Anxiety" as described on Wikipedia is

Anxiety is an emotion that is characterized by an unpleasant state of inner turmoil and includes feelings of dread over anticipated events

As mentioned in the preamble, when there are social interactions there are sure to be conflicts. In the context of CR, these conflicts are related to all change requests, that might occur, so this process builds up on the feeling of "Anxiety" when a new CR is made.
Interestingly, the same anxiety can arise when there’s no feedback at all, such as in a "rubber stamping" culture where code reviews receive quick approval without detailed or no feedback.

In summary, when there are numerous change requests, anxiety builds up from the feeling of being underqualified for your position, or of the fear to not meet certain deadlines, to which the team has committed.
If the change requests suddenly stop, the results are also similar as the developer may feel like their colleagues have simply given up on providing feedback.

Imposter syndrome

While anxiety often arises from specific triggers, such as receiving harsh feedback or tight deadlines, imposter syndrome is a more pervasive feeling of self-doubt. It can cause developers to undervalue their expertise and second-guess decisions, even in the absence of direct criticism, before diving in an example let's check the Wikipedia definition

Impostor syndrome, also known as impostor phenomenon or impostorism, is a psychological experience of intellectual and professional fraudulence. One source defines it as "the subjective experience of perceived self-doubt in one's abilities and accomplishments compared with others, despite evidence to suggest the contrary".

So here once again we might have anxiety, because of the lack of validation for our opinion in the code review process, which can transform even in increased anger levels.
Examples of such situations can be cases where we are being "gaslighted" as review givers or receivers.
As reviewers, our suggestions are being rejected because of reasons that we don't understand or postpone our change suggestion for undefined future refactoring.
In the case where we are being reviewed, the required changes might not make sense for us, but because we are suffering from the "Imposter Syndrom" we just accept and apply them.

In summary, this situation occurs when the other side doesn't communicate well enough their reasoning for giving or accepting change requests, which additionally builds our anxiety in the code review process. If those issues are neglected, they can grow from feeling of anxiety to anger, which will further decrease the willingness of the team member to participate in the process.

In summary, these challenges arise when communication breaks down, and reasoning for accepting or rejecting change requests isn’t well-articulated. This lack of clarity intensifies anxiety, and if left unaddressed, can escalate to frustration and anger. Over time, these emotions may erode the team member’s willingness to actively engage in the review process, impacting both morale and collaboration.

Work related

Avoidance of asking for CR

This issue is a manifestation of the fear of receiving negative feedback, Junior developers might fear negative feedback due to their lack of experience and the need for validation. Senior developers, on the other hand, may worry about making "dumb" mistakes that could undermine their credibility in the company.

This anxiety leads to situations where a simple feature can be over-communicated, overengineered, or over-tested, or in general it goes out of the scope and the expectations for the task, which leads to delivery delays.

Avoidance of giving CR

CR avoidance occurs when developers avoid reviewing others' code whenever possible. While this might not immediately disrupt processes if there are enough reviewers, it has negative consequences:

Harder knowledge transfer - Developers who avoid reviewing others' code often remain unaware of their colleagues' work. This can lead to duplicated code, redundant functionality, and increased difficulty navigating the project due to failed knowledge transfer.
Lower trust levels - People tend to trust more people that they know, rather than people that they haven't communicated with, so the more a developer engages with their colleagues (in a productive way), the more trust he/she will have
CR bottlenecks - When points 1. and 2. are present in a company, usually some more senior or confident developers are doing most of the reviews, which sometimes might lead to delays because the reviewers, for example, are on vacation or have work with higher priority.

Rubber stamping CR-s

Rubber stamping of CR-s is the act of attaching labels like "LGTM", "CR OK" etc., without actually making a detailed review, giving constructive feedback where needed, and often neglecting comments about small "code-smell" issues.

This practice ultimately lowers the overall quality of the project, creates technical debt, and increases the likelihood of bugs slipping through due to a lack of thorough review.

In summary

While code review is an essential part of modern software development, the anxiety and stress it can cause shouldn't be ignored. Developers often face emotional and professional challenges during the process, from imposter syndrome to avoiding feedback altogether. These issues not only affect individuals but can also have a broader impact on team dynamics and project quality.

In the next section, we’ll explore practical ways to reduce code review anxiety, improve collaboration, and foster a healthier review culture.

Strategies for lowering the anxiety

Lead by example

While it may sound like a cliché, "leading by example" is one of the most impactful strategies for fostering a healthy code review culture. As the saying goes, "What goes around, comes around."

The principle is simple: by actively engaging in the code review process with sincerity and professionalism, you set a standard for others to follow. Comprehensive and genuine feedback doesn’t just improve the immediate quality of the code—it also creates a ripple effect, shaping a more collaborative and respectful company culture.

Building this culture takes time at the organizational level, but the personal benefits for those who practice this approach are often immediate. Developers who consistently provide thoughtful and constructive reviews tend to receive better reviews in return. A "good reviewer" earns trust and respect, which naturally encourages others to reciprocate with the same level of effort and attention.

Over time, this cycle reinforces a culture of positive collaboration, creating an environment where constructive feedback becomes the norm rather than the exception.

Add CR criteria

Establishing a public code review checklist and a set of general best practices can be a powerful tool to encourage participation, especially for shy or less experienced developers. By creating a shared understanding of what constitutes "good code," these guidelines empower all team members to provide constructive feedback confidently.

For example:

Naming conventions: If your company has agreed upon specific rules for naming variables, methods, or classes, even a less experienced developer can point out a naming inconsistency made by a senior developer. Since these rules are public and agreed upon, the feedback is more likely to be well-received.
Method sizing: A guideline on method length—e.g., methods should ideally be under a certain number of lines—gives reviewers a clear benchmark. When a method exceeds this limit and can be refactored into smaller, more focused methods, reviewers can suggest improvements based on the agreed standard.
Branch naming or commit message formats: Having predefined conventions for branch names or commit messages ensures uniformity across the team. A reviewer can easily suggest adjustments when these conventions are not followed, again supported by the team-wide agreement.

By providing this framework, you remove much of the subjectivity from code reviews and reduce the likelihood of conflicts arising from personal opinions. This encourages active participation from all team members and helps foster a culture of mutual respect and collaboration.

Automate the process

Further optimization can be achieved by automating these commonly agreed-upon rules. Automation allows developers to validate that their code meets company standards independently, boosting their confidence when requesting reviews. For reviewers, this reduces the time spent identifying common mistakes, such as leftover code or formatting issues, enabling them to focus on providing meaningful feedback where it matters most.

For example, companies can integrate tools such as SonarQube, which measures metrics like:

Complexity: Identifying overly complex methods or classes that may need refactoring.
Code Duplication: Highlighting redundant code to improve maintainability.
Test Coverage: Ensuring sufficient testing is in place to reduce risk.
Code Smells: Detecting potential issues early before they become bugs. By implementing such tools, teams can automate repetitive tasks, streamline the review process, and create a more efficient and productive workflow.

Pre-review Buddy Collaboration System

The "Pre-Review Buddy Collaboration System" is a flexible way to improve the quality of code reviews and foster collaboration. Instead of waiting for feedback during the formal code review process, developers can request a pre-review from someone with domain expertise. This approach not only enhances merge request quality but also creates opportunities for mentorship, knowledge sharing, and team alignment.

Implementation

The implementation of such a system may vary depending on organizational structure, but the prerequisites and workflow generally follow these steps:

1. Create a Domain Expertise Document

To identify the right buddy, maintain a public document that lists team members and their areas of expertise. This directory should include details such as:

PROJECT / Technology	Member 1	Member 2	Member 3
A	Expert	None	Mid
B	Entry	Expert	Mid
C	None	Expert	Mid

This helps ensure the right person is consulted for specific types of changes. For example:

It wouldn’t make sense to involve a backend expert for a frontend-specific review.
Similarly, a developer deeply familiar with Project A might not be the best fit for reviewing the business logic of Project B.

2. Create a Communication Channel

To streamline collaboration and avoid overloading specific team members, establish a dedicated #pre-review-buddy channel in your team’s communication platform (e.g., Slack or Microsoft Teams). This channel allows:

Developers to post requests for assistance, briefly describing the area of work and the type of feedback needed.
Available buddies to respond voluntarily, based on their expertise and current workload.
While direct messages are an option, they can unintentionally lead to overloading certain experts. A public channel helps distribute requests more evenly and encourages a culture of shared responsibility.

3. Conduct a Live Review Session

Once a buddy has agreed to assist, schedule a short live session to review the code collaboratively.

During this session:

The review requester walks through their solution, explaining the thought process and any specific concerns.
The buddy provides feedback, pointing out improvements, and aligns the code with team standards.

This approach benefits both parties:

For the requester: It provides immediate, actionable feedback and insights into what reviewers expect in formal code reviews.
For the buddy: It creates an opportunity to share knowledge and mentor team members, reinforcing a sense of team collaboration.

Guidelines for Effective Pre-Reviews

While the Pre-Review Buddy Collaboration System improves the overall review process, it’s important to follow these guidelines to ensure its success:

Focus on Meaningful Reviews:
Pre-reviews should be reserved for tasks that are complex, impactful, or outside the requester’s comfort zone. Avoid using this process for repetitive or trivial tasks.
Respect Time and Availability:
Review requesters should be mindful of their buddy’s workload and aim to keep live sessions concise and focused.
Encourage Bidirectional Learning:
While pre-reviews primarily benefit the requester, they should also be seen as an opportunity for buddies to refine their feedback skills and gain a broader understanding of the team’s work.

Benefits of the System

Speeds Up Formal Code Reviews:
Pre-reviewed merge requests are often cleaner and require fewer changes, reducing bottlenecks in the review pipeline.
Improves Code Quality:
Knowledge sharing during pre-reviews helps align developers with company standards and best practices, resulting in higher-quality code.
Supports Junior Developers:
Newer team members can gain confidence and learn domain-specific knowledge faster by pairing with more experienced colleagues.
Fosters Collaboration:
This system creates an environment where team members actively support each other, strengthening team cohesion.

Some final thoughts

Thanks for bearing until the end of the article, this text is based on my personal experience and might differ from your personal journey, but I hope it gave the readers some food for though and motivation to fight this issue if they experience it.

Code review anxiety isn’t an issue that can be solved overnight, it’s a personal journey for many developers. However, I think that anyone can make contributions to ease journey for their peers.

Have you experienced code review anxiety? What strategies have worked for you or your team? I’d love to hear from you!

Idempotency

Xapuu — Sat, 15 Jun 2024 17:09:44 +0000

This is a submission for DEV Computer Science Challenge v24.06.12: One Byte Explainer.

Explainer

Idempotent operation is such a function that no matter how many times it is executed it will always produce the same output. For example get methods are idempotent, no matter how many times you fetch a user '/user/1' you will always receive the same user.

Git stash for newbies

Xapuu — Fri, 21 Jan 2022 22:24:53 +0000

Stashing like a pro

Given that we are using git in a perfect world, we as developers have all the time in the world to checkout our new feature branch, complete all our work related to the feature, without having to multitask, without jumping all the time in emergency meetings, hot-fixing stuff and helping out with the issues of our colleagues, but unfortunately, we are not living in such a perfect world.

Often times when we are switching between different tasks, hopping from branch to branch when we had already written some code, and in those situations, we have to save our progress somehow so that we can continue later. Usually, we are creating different "WIP: refactoring stuff" like commits, and not once or twice do such commits stay forever in our git history. This happens especially in situations where we are part of a team, where the collaborators are far from being power git users, and this is the reality, it is not a horror story that happens only in other companies, at least from my perspective I have seen such commits in several different companies during my experience.
So how can we fix this, one way is adopting the not so widespread feature called git-stash in our day-to-day work.
The point of this article will be to explain in plain English how and when to use this feature and hopefully optimize your day-to-day work.

What are stashes

The stashes are a way to store our changes in separate local storage, that can be accessed on-demand whenever the need arises. Let's give a simple example about a use case where the stashes can help you.

Basic use case

For example when we are in a situation where we are debugging some code and we are putting console.log-s or echo-s here and there, usually we don't want to have those in our commits, but our friend Jhon Doe wants us to help him out with debugging something critical in another branch, then we have few options either make commit and switch the branch so we can join his bug hunt or clone the repo in a separate place and then dive in the debugging process.

The option with committing code with log commands and funny commit message is not a desirable one as we already mentioned, but the other option with having a new clone of the repo is obviously an overkill :D, so the best thing we can do is stash our changes like so:

git stash

That's it just like magic all changes that we had made locally are stashed and stored in a separate place, that only exists on our machine in the current git project.

In order to see the changes that we had stashed, are stashed for real we can use the git stash list command, this will show all our current stashes, if you have no previous stashes, the git stash list will show something like the following, where the WIP on {yourBranchName}: hash is the default name that git will assign to your stash if nothing is specified, followed up by the hash of the branch

stash@{0}: WIP on {yourBranchName}: f136dae {the last commit on the branch before stashing}

Whenever you finish your side job, you can just return to your starting branch and re-apply the changes, as simple as just doing

git stash pop

This will re-apply the last stashed changes and remove the code that was stashed from your "secret storage space", keep in mind that the stash is shared between all your branches, so there is the possibility to pop it in the wrong branch.

Keep in mind that if you want to stash files that are not tracked (e.g. file that is newly created in this commit), we should stash them by using the git stash -a command, where -a stands for all.

Bit more complex use case

The basic example above is pretty simple, its purpose is to give you a glimpse of what you can achieve by using stashes, Let's explore a bit more complex examples where we need multiple stashes.

A real example from my experience, for long-living stash, was the need to apply specif for my machines package.json changes, that should never go to the remote git instance because potentially would've messed the default configuration, on which different automation and stuff depend and I needed that configuration for all branches on which I work.

So here is the recipe

git stash push ./package.json -m myMagicConfig

After that, if you list your stash with the git stash list you are supposed to see something like so

stash@{0}: On {branchName}: myMagicConfig

This time we can see our message instead of a hash with the last commit, the other interesting thing that is worth mentioning is the stash@{0} the number in the braces is the index of the stash, the stash storage work just like a stack, so your latest stash will always be with index 0.

In the example that we are going through, the usage of the git stash pop is not the best one, because as we already mentioned the pop command will remove the entry from the stash, which means that we will be able to use it only in one place, so what can we do now? Go go git stash apply to the rescue.

git stash apply {index}

This command will re-apply the changes related to the {index} from the stash, without removing the data itself from the stash.

Bonus

The next command will remove entry staying at specific {index} from your stash

git stash drop {index}

In the cases where you are abusing your stash, have hundreds of references there and you can't find the thing you are looking for, you can combine the git stash list command with grep and search by the message you left in the stash

git stash list | grep {message}

The last goodie is the clear command, which will drop all your stashes

git stash clear

Final notes

You can read the full manual here stash(1)

I hope this article helped you to learn something new, or if you are from the git master race, at least was enjoyable and refreshed some of your git knowledge, please share it with all you think might be needing it and help me raise the global git awareness :D