Let’s talk about strong and weak opinions before jumping to how exactly they damage your code review. I just need some contrast here.

Consider this scenario:

Sofia is reviewing a new feature that Arthur has implemented. She notices similarities between some new functions and existing code in another module.

“We should get rid of this duplication,” she decides and requests changes with a comment.

Sofia’s stance is clear — she’s calling for action. Arthur might have his reasons for the duplication, or maybe Sofia has overlooked something and the code from another module isn’t that similar. Either way, this opens up a conversation to agree on the best course of action because in most teams, it would be considered inappropriate for Arthur to dismiss this comment and proceed with the merge.

Requesting a change or asking a question is a direct way to express a strong opinion. Anything that would require an action would do.

Now, consider a different situation:

Jack is looking over Arthur’s code and spots several functions doing the same thing. He sees potential for improvement but also knows Arthur has put a lot of effort into this feature, and it’s functioning well.

With this in mind, Jack approves the pull request but adds a note: “These functions seem similar; I would consider combining them.”

The key distinction here is Jack’s approach—he didn’t request changes; he approved the pull request and added a comment. He might think he’s pointed out a potential improvement, but in reality, he’s shifted a reviewer’s responsibility onto the author. Now, it’s up to Arthur what to do.

Arthur sees an approved pull request and some mumbling about what Jack would consider but at this point who really cares what Jack would consider. The feature is good to go and the change is approved.

This exemplifies what I call a weak opinion—a remark that doesn’t require action, allowing it to be easily disregarded. The reviewer feels good for offering input, and the author is free to proceed with the merge.

Obviously, there is always an option to withhold an opinion:

Marcus has finished reviewing Arthur’s code and feels uncertain. Could the code be better? Probably. But that’s true for most code, right?
Marcus thinks about leaving some comments but wonders if they’d be helpful. Arthur probably knows about those issues and chose not to fix them because of the tight deadline. Why bring up the obvious?

Thinking his input won’t add value, Marcus approves the change without comments.

Reviewers might hold back for various reasons, such as doubting their feedback will lead to positive change or assuming the author is already aware of the issues and made a conscious decision. However, this can be more detrimental as it deprives the author of potentially valuable insights that could help to improve the code.

To recap:

• A strong opinion requires an action and is difficult to overlook.
• A weak opinion merely provides information and can be ignored.
• A withheld opinion is the absence of feedback when a reviewer has something to contribute.

Roles in code review

In the code review process, we have two key roles: the author and the reviewer.

Their shared goal is to find the most suitable solution, but they approach it from different angles, which is precisely what adds value to code reviews.

The author is deeply familiar with the problem, its significance, constraints (including deadlines), and the code they’ve written. This deep involvement comes with certain risks:

• The author might prioritize the problem’s urgency over other aspects due to its recency and their personal responsibility for resolving it.
• Being so close to their own work, the author may struggle to evaluate the solution objectively.

A reviewer is supposed to be in a better position to balance things out because they aren’t familiar with this new code, not affected by the time spent deep in the solution mode, and probably less attached to the problem than to a pre-existing state of the system.

Challenge of being a reviewer

The role of a reviewer isn’t something that comes naturally to engineers. We’re wired to write code and solve problems – that’s our comfort zone, where we spend most of our time.

But were you ever taught how to review code? If so, you’re one of the lucky few. For most of us, code review just became another responsibility. The assumption was simple: if you can write code, you can surely comment on someone else’s. But it’s not that straightforward.

The difference between writing code and reviewing it is like the difference between playing the game and coaching. The game is the same, but the skills are different, and they need to be learned. Being a star player doesn’t automatically make you a great coach.

Therefore, reviewers often fall back into an author’s mindset.

What does an author want? A fast, smooth review, a second set of eyes to confirm everything’s okay, maybe a bug caught here or there. And that’s what they end up giving — quick checks instead of deep dives into the code that could reveal inefficiencies and provide constructive feedback to enhance both the codebase and the author’s skills.

Where weak opinions come in

From a reviewer's perspecitve, realizing the code could be improved and staying silent doesn’t feel right. Yet, it’s equally uncomfortable to ask a colleague to rework a substantial portion of their code or to dedicate additional time to address issues you’ve identified.

Leaving a non-blocking comment that points out the problem without demanding action might seem like a way to avoid difficult conversations.

However, this approach can be misleading — it makes you think you’ve contributed to enhancing the codebase when, in fact, you’ve passed the responsibility to the author. It’s a soft touch that can lead to hard issues down the line. True improvement comes from facing these challenges head-on, not from sidestepping them.

Strong yet supportive

Strong opinion does not mean harsh. This isn’t about tearing down code that doesn’t match up to your expectations. Your real mission is to foster positive change, not just to flag errors or show off your expertise.

A good piece of advice I once received was to assume missing important context.

It will be true more often than not because as a reviewer, you’re not privy to every detail of the author’s challenges, their objectives, or why they chose one path over another. And even if you think you’ve got the full picture, you can’t possibly know every solution out there to be certain your suggestion is the best and should be implemented.

That said, assuming missing important context it’s not just about acknowledging that you might not have all the answers — it’s also about showing that you’re open to learning and considering different approaches, not pushing for something you came up with.

Start with yourself

If you’re on the fence about making a comment, think about the ripple effect. What if every commit had the same issue?

Imagine every pull request with functions taking three screens, similar to the one you're approving right now. Or more of those clever bitwise operations. Or complex calculations with no tests to prove they're correct.

It might seem like an overstatement, but it’s the reality. We often mirror the style of the existing code for consistency. We copy-paste code blocks. We gauge what’s acceptable based on what’s made it through reviews before.

So, if you’re sure there’s room for improvement, don’t hold back — suggest an action and make it explicit. Sometimes, that action might just be a question for the author to explain their reasoning, which could sway your perspective.

Remember, not every comment has to lead to a change.

Help others

When you’re in the thick of a code review, you might spot weak opinions left by others.

In such cases, you can play a crucial role.

By adding your own insights and explicitly requesting an action, you can transform these weak opinions into strong, actionable items. Whether it’s through asking probing questions or even rejecting a pull request that someone else has approved, your input can significantly enhance the review process.

Interpret non-blocking comments to your code

Non-blocking comments are often seen as optional, merely providing information or sharing a reviewer’s thoughts.

But now you can see that’s not always the case. A comment like “by the way, this function you implemented already exists in the library we use” isn’t just a passing remark. It’s a hint from the reviewer aimed at preventing cluttering the codebase with redundant code.

When you come across such comments, consider the broader implications, similar to when you are the reviewer. If every commit introduced similar issues, how would that affect the codebase over time? Again – once a commit is merged, it becomes a part of the standard others will follow, potentially leading to a pattern that could be detrimental to the project’s health. So, treat these comments with the seriousness they deserve —t hey’re not just side notes; they’re signposts for maintaining standards.

All projects face unexpected issues.

Ideally, when this happens, the team comes together, figures out what’s going wrong, and adjusts their plan. Maybe they set a new deadline. Or, they may even decide to drop the project if the problem’s too big and it’s smarter to focus on something else.

But things don’t always work out so neatly. Sometimes, a team runs into trouble and just keeps on going the same old way. No one stops to rethink the strategy or suggest a new timeline. Everyone just keeps on with their tasks by inertia.

Then, one issue leads to another, and before you know it, you’re used to the chaos. And that’s when you miss a big deadline and find yourself in a mess because it’s not the first project that’s been delayed.

Let’s talk about why these things happen and how we can stop them before they begin.

Starting with a simple example — and it’s not about coding. Say you’ve got to cut 5 sweet potatoes (I always struggle with those). You grab your knife, not realising it’s a bit blunt, and get to work.

You pick the first potato, and it’s tougher than you expected. But maybe it’s just a tough one. You try another, and nope, it’s definitely the knife. By the time you’re halfway through the third, you know you made a mistake.

Now, the wise would pause and sharpen the knife. Not me. I’m thinking, “I’m over halfway already — I can handle these last two potatoes.” I don’t even consider that it is my darn knife, I will be using it again at some point and I’ll have to sharpen it eventually. I regret not checking it earlier, but hey, two more potatoes, right?

The best time to plant a tree sharpen the knife was twenty years ago.
The second best time is today.

– Chinese proverb (not sure, I saw it on Instagram)

For those who can’t connect with the sweet potato tale, here’s a different scene.

Your colleague picks a task. A small one, supposed to be done in a day. The next day, they show up at the standup meeting, admitting they got stuck and spent a day trying to figure it out. They should’ve asked for help, but it’s only clear now in hindsight. Thankfully, they’re back on track now.

Another day goes by, and at the next check-in, the task’s still not done — hit by a couple more surprises. In retrospect, teaming up with someone the day before would’ve been smart, but they kept thinking the end was in sight, so they didn’t ask. Had they known the struggle ahead, they’d have reached out for sure.

The following day, the task’s still hanging. Almost finished, then bam — a strange edge-case causes a memory leak that eats up hours. They ponder getting help but figure it’ll take longer to bring someone up to speed than to fix it alone. Looking back, it wasn’t as quick as they thought, but the time’s already spent. The team offers to help, but they decline — it’s nearly done, just some unit tests and docs to go. This time, they’re sure they’ve got it right.

In both scenarios from above:

• The first hiccup seemed like a one-off.
• Upon realizing their error, there was regret for not adjusting course.
• Yet, future actions remained unchanged, either because the mistake was deemed a one-off or it felt too late for corrections.

This pattern can unfold over any timescale—from minutes (like with those potatoes) to days (like that small task) to even weeks and months. Here’s a story of my own.

Some time ago, my team took a small project. It was low-risk, a perfect fit for one or two people.

We quickly settled on a strategy, broke it down into tasks, and dove into coding. But as we hit the 80% mark, we realized it was far more complex than anticipated. And complex projects demand a different playbook: thorough design reviews, risk assessments, and heightened scrutiny—none of which we had done.

We had two paths. One was to hit pause on development, draft a design proposal, arrange a review, gather feedback, and then either proceed (if the feedback was minor) or scrap everything and start anew (if the review demanded it). The other path was to keep on going as we were.

You can probably guess—I opted for no change, convinced our initial plan was solid and that second-guessing it would be a waste of time. I also figured we’d already encountered enough issues to have uncovered them all. No more surprises, right? Lol.

To cut a long story short, it took a few more unexpected twists (and sprints) before we circled back, documented everything, and brought more hands on deck.

You might have lived through something similar—like that time someone skipped writing tests for a new feature. Then it crashed production, and everyone thought, “a test would’ve caught that.” You fix it but skip the tests again, thinking, why bother when you’ve just checked it manually?

It’s rather a common issue:

• We should’ve documented it, but I’ve already explained it in a call, and it’s unlikely anyone will ask again soon.
• We should’ve automated that deployment, but I’ve done it manually this time, and we don’t update this product often.
• We should’ve seen that dependency coming, but now that we’ve found it, surely it was the only one.

So, what’s the game plan to combat this inertia?

Set the expectations

Imagine you're setting off on a drive with no map and no clue how long it will take. You pick a direction, hoping the road itself will be your guide.

But what if you make a wrong turn?

You might pass a landmark you weren’t meant to see, or notice that the distance to your destination isn’t decreasing on the road signs. Or perhaps the setting sun raises a red flag because, even though you didn’t know the exact duration, you certainly didn’t expect to be on the road all day.

Discovering mistakes like this can be a slow and costly process.

That’s where expectations come into play. And I’m not just talking about the big-picture journey, but also the smaller, interim milestones along the way, and when they’re supposed to happen.
Sure, you might wonder if a detailed roadmap is necessary with all the risks and uncertainties involved. But at the very least, you should have an idea of what the next leg of the trip looks like and when you expect to reach it.

It’s not about micromanaging every step; it’s about having enough foresight to recognise if you’re off course and need to adjust your trajectory.

Schedule the check points

Having a roadmap is one thing, but what's the point if you never check it?

Imagine you’re working on something, heads down, deep in the zone. You’ve got your code, you're progressing, all looks good. But if you never stop to ask, “Are we still on track?” you might miss the signs that you’re going off course.

To prevent it, begin your day by outlining what you aim to achieve and how long you expect it to take. Then, set the rules on when you’re going to assess the progress. If you expect something to take two hours – put a timer to assess your work. Are you meeting your own expectations? If something’s taking longer than anticipated, it’s a prompt to reassess and consider adjustments.

This is exactly why many teams have stand-ups or some other form of checkin-in with each other. “How’s it going?” “Hit any roadblocks?” “Need a hand with anything?” – this is exactly how we make sure we’re still on track to meet our expectations and the right questions are being asked.

Act upon surprises

Every surprise, every deviation from what you expected, is a piece of new information. This new information should prompt you to update your knowledge and reassess your actions.

Think of it this way: you set an expectation that performing certain actions (X) over a period (T) will give you a result (Y):

X × T = Y

You follow through with your plan for the allotted time, but Y doesn’t materialize. This is where the learning opportunity lies—you’ve just discovered that X × T ≠ Y.

If you continue doing X as if nothing has happened, you’re throwing this learning opportunity away.

Before deciding on your next steps, you need to understand exactly what happened:

• Did you carry out all the actions you planned?
• Did you dedicate the amount of time you had allocated?
• How does the result you’ve achieved compare to what you expected?

Let’s take an example: suppose there’s a bug in your software that needs fixing, but you can’t figure out how to replicate it. You have a vague idea of which part of the program might be responsible, but you’re not certain what triggers the it. You decide to try out some common scenarios to see if any replicate the issue. It’s a lot of work, but you expect that by tomorrow you’ll either find the cause or rule out your theories.

Tomorrow arrives, and you aren’t there yet.

Per the algorithm above, you review your actions and realize you didn’t stick to the plan. You tested a few scenarios, got sidetracked by a minor bug and fixed it, updated some outdated documentation while testing another scenario, and helped a colleague with a code review. In the end, you only completed a fraction of your original plan (X₁), along with other tasks that didn’t contribute to solving the main issue.

You also notice that you didn’t spend the entire day on the task. Between the work mentioned above (T₁), you attended four meetings, responded to questions on Slack, and installed a mandatory MacOS update.

Looking at the scenarios you tested, you see you’ve only covered about a quarter of what you intended (¼ Y).

In essence, you did X₁ * T₁, where X₁ and T₁ are only subsets of initially planned X and T. With that, it comes with no surprise that you didn’t achieve Y.

This is the critical moment when inertia can take hold.

You might think the plan is still sound and you’re on the right track. Yesterday was just a bad day, and you didn’t put in the effort you intended. But today, you assure yourself, will be different—you’ll stick to the plan and identify the bug by day’s end.

However, it’s important to question what will make today more successful than yesterday. Weren’t you just as committed to the plan as you are today? Didn’t you intend to spend the whole day on the bug?

So, what will you do differently this time? How will you safeguard the time allocated for bug hunting? How will you stay focused and avoid distractions? If you still have three-quarters of the scenarios left to test, you’ll need to find a way to accomplish three times as much as yesterday. And if you’re not planning any adjustments, perhaps it’s time to reconsider your estimates.

Create a safe atmosphere

Safe atmosphere is essential because without it, the strategies we’ve discussed are unworkable. People must feel free to make mistakes and admit when they’re wrong.

In all places I worked, it was always okay to admit not knowing something, ask for help, or acknowledge a misstep. But I know that not all environments are like this. In places where blame is common, people might conceal their errors, perhaps by padding their estimates to create a buffer for unseen issues. This approach might work for self-detected errors, but it falls apart when others point out the mistakes, leading to defensiveness rather than constructive dialogue.

There’s a wealth of advice for leaders on fostering a safe environment. You’re likely familiar with the basics:

• Begin from admitting your own mistakes and knowledge gaps.
• Practice blameless conversations.
• Help people to see the value in feedback and how it helps them reach their goals, fostering a willingness to adjust.

But what if you’re not in a position to shape your team’s culture?

It’s a tough spot, but there are still ways to course-correct openly without casting it in a negative light. One method is to explicitly plan for problems.

Say you’re assigned a task you expect to complete in a day. If that day passes without progress, asking for help can be scary in a blame-heavy atmosphere. It’s easier if you’ve set the stage for assistance by initially stating you’ll assess the problem and involve others if it’s more complex than anticipated. The same goes for larger projects – schedule regular assessments with the intention of refining your approach if you find a better one.

Does this change the reality of the situation? Not really. But it reframes adjustments from being the result of failure to being an integral part of the plan. If the chosen approach doesn’t pan out, that’s precisely why you planned the assessment.

Help others out of the progress trap

When you’re deep in work, it’s hard to realise you might be off track. You’re in the thick of it—solving problems, slaying dragons, and pushing forward. It all happens so gradually, it feels like progress. But remember, just because you’re moving doesn’t mean you’re heading in the right direction.

The first principle is that you must not fool yourself—and you are the easiest person to fool.

– Richard Feynman (but I also saw it on Instagram)

We set expectations and checkpoints to help us assess our progress and spot when we’re going astray. But it’s this very act of planning and assessment that can be uncomfortable. It’s easier to avoid asking the tough questions and to keep on ‘progressing.’ To jump into coding without a plan, because then, anything you do seems like progress. Or to make a plan but never really check your results against it, because “plans are useless, planning is indispensable.”

If you notice teammates falling into this trap, step in with some helpful questions:

• “When do you expect to finish X?”
• “Now that we’ve had this setback, do you think X will still be done by Y date?”
• “What’s the goal for today?”

And don’t forget to share your own plans and progress. It helps set a standard and encourages everyone to think about whether they’re really moving forward, not just moving.

Final words: know when to stick to the plan

While it’s important to be agile and responsive, there’s also benefits in holding steady with your plan. Constantly changing directions can be just as counterproductive as not changing at all. It’s about finding that sweet spot.

You’ll face problems and delays; that’s inevitable. The key is to know which issues are just bumps in the road and which ones signal a need for a real change in plans. And that’s not easy.

Why? Because it all rests on how solid your estimates are. If you’ve got a good handle on your timeline, you can tell whether a new problem is something you’ve already accounted for in your plan. If it is, then keep calm and carry on.

But estimating is a task in itself. We start off optimistic, get a reality check, and then swing to overly cautious. To get better at it, consider these steps:

1. Estimate with probabilities: outline the best, worst, and most likely scenarios. This helps you stay grounded and prepares you for potential issues.
2. Review after completion: once you finish a task, compare the outcome with your estimate. This reflection helps improve your future predictions.
3. Respect the history: don’t ignore your past performance. It’s the most reliable data you have. Aim to do better, sure, but base your plans on what you’ve actually achieved before.

Remember, planning and doing are different modes of thinking. You need a wide lens for planning and a narrow one for doing. That means you’re not always in the best position to question the plan when you’re in the middle of the work.

The good news? If you’ve set clear expectations, checkpoints, a plan for surprises, and fostered a safe environment, you’ve built a strong defence against unnecessary changes. Stick to the plan, adjust when you must, and keep moving forward.

Imagine you have a colleague named Boris. And Boris has a problem: he's been working on a new feature for five days, but now it's all falling apart. The application starts up, runs for a few minutes, and then shuts down with some weird error message and a huge stack trace.

Boris tries googling the error, but no luck. It looks like it's related to one of the microservices the application uses, and it's too specific for anyone outside the company to know. So he copies the error and posts it in a team chat, asking if anyone knows what it means.

You see the question, but you have no idea.

What would you do?

While you're thinking, let me tell you what most people would do: nothing. And that's totally reasonable: they saw the question, they don't know the answer, and they don't want to spam the chat, so they just carry on with what they were doing before. One person does it, then another, and then a few more. Soon, everyone has seen the question and hasn't said anything.

But Boris is completely unaware of this. Maybe people are just busy and he needs to wait a little longer?

So he waits, until someone posts something else in the chat - another unrelated question – and gets a few responses. Now Boris has to wonder if people would see his question when they open the chat.

The best thing to do in this situation would be to say "I don't know" or react with a "🤷‍♀️" to keep the chat from getting too noisy.

This lets Boris (and others) know that they don't need to wait for an answer from you, and it can help bring more attention to the problem, potentially leading to a quicker resolution. Or at least, Boris won't have to wait unnecessarily.

Even though this isn't the biggest problem you may have (it’s not like Boris is going to wait for an answer for eight months while the company goes bankrupt because he can't complete the feature), being blocked is annoying. "I don't know" may not solve the problem, but it's a step in the right direction.

The more influential you are, the more valuable your "I don't know" is.

Boris might think "Even the tech lead who wrote a half of all code doesn't know this error," and feel a little better about being stuck.
A recently hired junior might think "Wow, it's okay to admit you don't have an answer," with the sense of uplift.
And someone who was hesitant to speak up without a definite answer, might suggest a couple of things to try since nobody else has any ideas.

You organise a meeting to agree on use-cases for a new feature. It is going well, and then a colleague asks which database you plan to use.

You’re preparing a response (because you haven’t decided yet), but someone suggests MongoDB.

“But why not PostgreSQL?” another person counters. “We have a similar service, and it only needs one instance of PostgreSQL – I wonder why the same configuration wouldn’t work for you”.

It surprises a few people. ”One instance?! What is your load?”

“It’s not high at the moment. We may need to consider adding more capacity as we grow, but I think three or four instances will be enough”.

“Have you ever questioned why we have so many databases in the same company?”

And now you understand that the meeting went off-track.

How do you prevent it?

Should you ignore the question about databases?
Or stop on the MongoDB suggestion?
Or cut off the PostgreSQL-guy? And if yes, why him?

And what if their points are not as irrelevant as you think?

Here is a list of tips to help you keep meetings on track.

At the beginning of the meeting...

• ... explicitly state the goals.
  Sometimes, people are unaware of the goals – an additional reminder will not harm. Plus, it will help you return the meeting on track later; you’ll need to remind everyone what you’re trying to achieve.
• ... make people aware of time constraints.
  We have 60 minutes, and I need about 40 for the presentation – the rest is for the discussion and Q&A – something like that is enough to make everyone conscious of time.
• ... share what exactly you plan to cover.
  When people know the order of topics, they won’t interrupt with questions you plan to handle later.

During the meeting...

• ... watch out for side conversations.
  Irrelevant questions are usually not a problem because you choose how much time to spend answering them. Irrelevant comments are fine either – you can acknowledge it and follow up later.
  Most of the time waste is caused by side conversations – when several people are engaged in a dialogue about something that does not contribute to the goal. But yes, they usually start from irrelevant questions or irrelevant comments.
• ... timebox side conversations.
  It is hard to assess whether a conversation goes off-track or someone just needs more time to make a point. Decide how much time you should wait before stopping it.
• ... treat irrelevant conversations equally no matter how they start.
  It is common to say something like “it is probably irrelevant but …” before making a point that is indeed irrelevant. If you have limited time and something does not contribute to the discussion – stop it.

After the meeting...

• ... follow up on what was left undiscussed.
  Irrelevant ≠ not valuable. You may need to stop some conversations during the meeting, but people still have ideas worth discussing. Reach out to the people whose comments or questions didn’t get proper attention for a follow-up conversation.

Jackson is a go-to person when it comes to MongoDB.

You have a problem — you go to Jackson. He’s an expert. Of course, you can go to anyone else – it’s a free world. You can go to Molly if you want. But you know what Molly would recommend, don’t you? She’ll tell you to ask Jackson, that overworked guy with a giant todo list.

Let’s talk about what to do if you ended up being a Jackson and need a way out.

What kind of a bottleneck are you?

There are two different kinds of overworked Jacksons: knowledge bottlenecks and expertise bottlenecks.

Knowledge bottlenecks are the ones who answer questions.

“Who owns Payment API?”
”Which database has client emails?”
”When is our next release?”

If you're one of those, write documentation. Sorry for such trivial advice, but boring problems need boring solutions.

It's worth writing docs even if people don't read them. Sounds stupid, but it will serve as your second brain from where you can quickly copy answers.

Watch out for an urge to share your screen and demonstrate something. It's always better to record a video (or a gif) and share it instead – this way, you will be able to reuse it later.

That was all about knowledge bottlenecks.

Expertise bottlenecks are trickier. They don't just answer questions — they solve problems.

“This program crashes for Netherlands users.”
”My DB query is slow.”
”Our photo gallery page leaks memory.”

This situation is much more complicated because you need more experts to share the load. But unfortunately, there are no books or tutorials you could give to somebody and turn them into an expert – they need to build the expertise themselves. And it takes time.

But how to accelerate the process?

Limited opportunities

If someone wants to learn how to play the guitar, they need to practice playing the guitar. Likewise, if one wants to learn how to fix memory leaks, they need to fix memory leaks.

The tricky part is there are much more opportunities to play the guitar than memory leaks to fix. They don't happen every day.

Zoom out now and look where you ended up: people call you whenever a challenging problem arises because nobody else has a similar experience. And nobody else has a similar experience because you solve all the challenging problems. A chicken and egg situation.

Growing new experts

The naive advice would be to stop doing what you're doing so that others can practice and build necessary expertise in time. But, unfortunately, it's overly utopian – a few companies have the luxury of accumulating unsolved problems while their best specialist sits idle and waits for new experts to emerge.

But I'm not saying it's impossible – there is a way to grow new experts without slowing down the process. Here it is:

1. Pick one successor to mentor.
   Learning opportunities are scarce resource, so resist the temptation to pick more than one.
2. Redirect all requests to this person.
   Need help? Ping Nelson, he knows this stuff.
3. Be available for this person.
   Answer all their questions as soon as possible, pair program or pair debug when necessary.

It works because:

1. The company will not slow down in critical situations – if the time is tight, the mentoree can ask you for help.
2. You can tune your involvement depending on the circumstances to manage risks and guide the learning.
3. This person starts earning credibility from day one, solving real problems with your invisible help.

In the beginning, be prepared to play broken telephone answering proxied questions:

It may look like a waste of time, but it's far from it. Yes, the future expert acts as a proxy, but they learn about the domain. Even if it's a proxy, it's a caching proxy:

As their experience grows, they will start asking more complex questions:

This is the point where you can return to your expert's duties, which you now can split with another person:

Last week, I joined a meetup organized by Skills Matter to talk about work/life balance, Personal SLA and how one can apply best practices from Tech in your daily life.

I hope you find this video useful.

Just remember:

Molly had a very smart boss.

Once, they had a system outage in the middle of the night, which nobody could solve until they called Molly. She logged in, scanned through all the changes from the day before, read the logs, did her own tests, and found the culprit – some expired certificates on one of their production clusters.

When the boss saw it the following day, he gathered everyone in one place and praised her in front of the others.
"Thanks to Molly, the outage persisted for only 45 minutes. She was quick, accurate, and she did the exact things I would do in this situation.
I had numerous incidents like this in my life, you know. And now it almost feels easy — I see the symptoms, and the root cause becomes apparent. But even with all this experience, I'm not sure I could have done it faster than Molly."

And everyone clapped him because he was very smart and humble, and they knew he would have found these expired certificates much quicker.

Another time, the whole team were brainstorming how to reduce the latency of their API.

Molly knew one or two things about it and proposed to cache frequently used data in Redis.

"I think it can be a huge success," the boss commented. "It's great that you mentioned that because I've been analyzing Redis myself and was just about to create the task to begin using it. Do you guys all agree about giving it a try?"

And everyone nodded because he was very smart and always had excellent and well-thought-out ideas.

"Actually," the boss pointed to Molly, "considering you also proposed Redis, why wouldn't you create tasks yourself?"

And everyone found it to be a good idea because wise leaders delegate work to their people.

Later that day, Molly called her old friend. He was a manager in another company, and she knew they were hiring.

"Is it what, my birthday?" her friend laughed. "But how is your team gonna take it?"

She paused for a second. "I'll miss them... but they don't need me much anyway. I don't think anything will change".

Molly was right – nothing has changed with her departure.

She had a chance to see this for herself a year later when she met her former boss.

"We just talked about you yesterday! There was a huge outage because of some expired certificates — put us down for 12 hours! I remember you were good at fixing those..."

Molly was startled but chose to switch to something more positive. "Those certificates are always tricky, don't even remind me… So how's the cool stuff, huh? API?"

"A bit slow as always, you know. But we plan to fix it soon — I think if we can implement some sort of a cache, or perhaps find an open-source thing."

"Like Redis," Molly suggested.

"Exactly! You know, I've been looking at it myself recently — my favourite option so far!"

Alright, let's begin: nested functions are functions defined inside other functions (promised and delivered). You saw them in many forms, like this one:

Here, the function multiply is defined inside its parent, pow, although it does not have to be this way.

Or does it? If nothing else uses multiply, are there any reasons to move it out?

This topic regularly ignites lengthy bike-shedding conversations regardless of the programming language (stack overflow about python, reddit about swift), so I want to jump in and list some more pros and cons which you can apply for your needs.

Why you should not use nested function

Nested functions reduce readability

The bigger a function is, the harder it is to read it.
Look at this example:

By defining three additional functions inside showNews, you make the reader's job harder: they have to scan all of them before reaching the part with actual logic.

It might be much shorter:

The reader still can jump to any functions to see how they work, but now it's optional.

Nested functions influence future growth

One may argue that not all nested functions affect readability.

In the previous example, you had three big helpers — pretty bad. What if there was only one?

Does having loadNews inside the primary function cause any harm? After all, it is just several extra lines.

The danger of this approach shows itself when someone needs to add more functionality. You should not be surprised when your colleagues follow the same style and add other nested functions next to the existing one. After all, they just follow the rules you defined as an author.

All it takes to degrade a good codebase is one example of a poor pattern and people's intent to maintain the code style.

Check the article about "Reckless Reuse" for more examples of how code becomes unmaintainable without anyone noticing.

When nested functions are good

Now you may have an idea that all nested functions are evil and should be avoided by any means.

This is not true.

In some cases, they bring some benefits that can outweigh the disadvantages.

Sometimes you do not want others to use your functions

Yes, functions are meant to be reused. But you may not want it, e.g. if a function handles your particular case but is not suitable for everyone:

There are many cases in which isEqual returns an unexpected result:

But it may be the exact behaviour you need.

In this case, it will be safer to define this function inside saveNews so that nobody has to deal with its peculiarities.

Sometimes you need access to an outer scope

Many languages give nested functions access to the variables from the parent scope and even allow to modify them. You may need to explicitly declare such variables (Python) or capture them by reference (C++), but the benefits are the same:

In this case, the alternative would be passing all arguments to handleError every time we call it, using Function.prototype.bind or wrapping it into a factory. While I prefer different things depending on the situation, I see why somebody may use nested functions here.

Some implementation details are helpful

From the reader's point of view, there are few things worse than jumping between functions to understand how the whole thing works.

Try to understand this piece:

The functions onSuccess and onError do not only hide implementation details but also obscure their purpose. You know something happens, but you don't know what exactly.

In this case, it would be better to define onSuccess and onError within the primary function so that the reader knows what is happening without leaving it:

Two things to note here:

• Implementation details are still hidden: you know what is happening but not how
• Try to avoid situations like this by better naming and defining better APIs. The downsides of nested functions are still there.

So, what to do?

I usually try to avoid nested functions because they make their parents bigger and, as a result, harder to read. Even if a nested function is concise and the impact is negligible, it can potentially become a slippery slope and serve as a bad example for adding similar ones.

But, as you can see, there are some situations when going this path does worth the downsides.

I hope that now you can defend any side in this holy war and justify the style you prefer. Happy coding!

You work on a Big Improvement: rewrite backend on Go, move services to AWS, change a task tracker — something that affects multiple people's day-to-day work.

And then the initiative faces a pushback.

How much it hurts depends on when you encounter it: rejected proposals feel more bearable than having to throw away the nearly finished work you've been doing for months.

How to prevent it?

I have repeatedly found myself on both sides of the fence — as a proponent of innovations and as a member of the sceptical camp. Now, I am pretty sure that Big Improvement's future entirely depends on its author: how they prioritise different kinds of work, address concerns and adapt to feedback.

Let's figure out how to deal with yours

For the purpose of this article, I assume that:
1) you did your homework and know that your company will benefit from this initiative
2) you are open to feedback and ready to adjust if needed

Why technical initiatives fail

Ask yourself: why would anybody reject a good initiative? Assuming nobody is malicious, the answer is obvious – they do not think it is good. But why?

There are many possible reasons:

Some of them are more frequent than others, and I want to highlight these three as the most common:

1. People do not believe you can reach promised goals
2. People tried what you built and did not like it
3. People disagree that the problem is worth solving

Let's see how you can prepare to face each of them.

Reason 1: People do not believe you can reach promised goals

Imagine a medieval kingdom that has been terrorised by a gigantic dragon for centuries. The dragon mercilessly burns the fields with the best crops, devours cattle, and kidnaps the most beautiful (by dragon standards) princesses.

You, a foreign knight, come in armour and on a white horse and ask for thirty armed men and two bags of gold to finish off the dragon forever – something that many have tried to do, but no one has yet succeeded.

What do you expect to hear back?

How it may sound to you

Why do you think it would be more performant and easier to maintain? Are you sure? I'm not sure...

– Carina

What the root cause is

The longer a problem exists, the harder it is to believe that somebody can solve it.

Especially if there were many unsuccessful attempts in the past.

Psychologists call this effect "Learned helplessness" and suggest that it can spread like a virus, infecting individuals, teams and organisations. Collectives that catch it become inert and pessimistic — it requires enormous effort to overcome the dominant belief that nothing can be done.

How to deal with it

Scepticism is contagious. Therefore, it is easier to prevent it than change many people's mind. But you cannot do it with bare arguments.

Instead, you can benefit from applying some principles of the hypothetico-deductive method:

1. First of all, you agree on a definition of the problem with those who already tried to tackle it
2. Then, you propose your idea – something that should solve the problem
3. Together, you deduce the list of consequences: what would the solved problem look like.
   The list may be pretty long, so it is worth focusing on the riskiest cases: if the hypothesis is incorrect, you want to know it as soon as possible
4. And finally, you agree on the list of experiments that may help you to disprove the consequences and fail fast

If it looks too abstract, let me bring a more concrete example:

In the example above, we propose using Rust to solve existing performance problems.
Instead of reasoning whether it would work or not, we identify parts of the system with higher chances of performance problems, agree on how failure would look like and design the experiments that may reveal the shortcomings.

Even though it may sound straightforward, it is common to see two other approaches which do not end up well:

• a proposal faces reasonable scepticism and does not get through not being backed by solid evidence
• engineers either do not identify or do not prioritise risky cases and then have to throw away a large amount of work

But anyway, it was a pretty easy one – time for the more interesting case!

Reason 2: People tried what you built and did not like it

This happens a little bit later, when you think you built something good enough for others to use.

You prepare a polished demo that fulfils all expectations and makes everyone's hands hurt because of incessant applause:

But when others start using it... well, this happens:

How it may sound to you

I like the old way better.
Yes, I needed to change the code in five places.
Yes, the code was hard to test.
Yes, it was less performant.
But at least I could get it working because I knew what to do.
Now, I have no idea what's going on, and it all keeps breaking!
Can you de-engineer it back?

— Marcus, the early adopter

What the root cause is

There are several possible causes, and in most cases, they occur together:

• Not enough documentation
  Writing docs is never the top priority during a turbulent time of building something new
• Unexpected bugs
  After the flawless announcement, people may develop high expectations and forget that this is only the first version
• Unfinished implementation
  It may be frustrating for early adopters to start working with the new thing and then stumble upon a blocker
• Rosy retrospection
  In psychology, rosy retrospection is the tendency to recall the past more positively than the present (even when the facts suggest the opposite)

How to deal with it

Ensure that people have the best possible experience working with a new system from day one.

It would be ideal if you provide:

• Documentation with exhaustive examples
• A list of known bugs and the current state of the roadmap to manage expectations before people start using it
• Support during development so that you can answer questions as they arise and unblock people

If it is impossible to do all of this because you don't have many resources, I would recommend keeping other people away from this version until it meets all criteria. The quality of the first impression means much more than time.

You may have valid reasons not to wait, e.g. when other engineers want to start building something else on top of your system while it is in development. All situations are different, but my suggestion for this case would be to pair with them until they have necessary context.

Reason 3: People disagree that the problem is worth solving

Imagine yourself in a group of bright scientists trying to invent powerful yet affordable quantum computers.

At some point, your experiments pay off, and you find the way to manufacture inexpensive quantum chips –– with them, even smartphones would vastly outperform existing supercomputers from the IBM labs.

However, there is one minor drawback. Its architecture is absolutely incompatible with what we have nowadays, making most of our computer science knowledge redundant. Needless to say, some developers may find having to learn all from the beginning a little unfortunate.

To say the least.

How it may sound to you

What do you mean by 'automated releases'? All you need to do is to log in to the production machine, download new code and run three commands – I can tell you which ones.
You call it a problem just because you were not here 12 years ago!

– Dr Nicolas Peter, PhD

What the root cause is

To discuss the root cause, we need to consider two separate cohorts:

• Those who are used to the current way of doing things
• Those who somehow benefit from it

The first group's reasoning is pretty obvious (just make the transition smooth for them); therefore, I will focus on the second one.

Nobody introduces inefficient systems on purpose. At least, these situations are pretty rare.
Quite the opposite – people usually have good intentions:

• They see a big problem (same as you!)
• They implement a solution (similar to your Big Improvement!)
• They become experts in it.

In time, the solution loses its appeal: it does not satisfy new requirements, there are open source analogues which do the same, and so on. It is time to replace it with something better, but it will imply throwing away all hard-earned knowledge, taking off an expert hat and having to learn something new.

Besides, the experts know the current version like the back of their hands and see all arguments as exaggerated.

How to deal with it

The traditional way of constructing an argument almost guarantees resistance. This is what I call a traditional way:

• You state the problem
• You demonstrate evidence of why this problem is vast and needs solving
• You describe how bright the future would be if you solved this problem
• You explain how you are going to do it

For all its factuality, this approach is devoid of any compassion: you go to the people who built the thing, to the people who use the thing, and to the people who have become experts in the thing and tell them not only that the thing is terrible, but that it has become a huge problem and needs to be replaced immediately.

The alternative approach acknowledges the history of an existing system and focuses on what changed since it was initially created. This can help build a foundation for productive collaboration with the current group of experts and get them on board.

This list of questions can help have a constructive conversation with the experts:

• What were the initial goals of the system?
• Does the system still satisfy all its initial requirements?
• Which parts of the system are you (the expert) not happy with?
• Which parts of the system have degraded in time due to technical debt and negligence?
• Have we received new requirements that the system does not meet?
• How can we make it right together?

This approach allows you to join forces with knowledgeable people to find out much more about current and potential use cases, identify hidden problems, and not repeat old mistakes. Experts, in turn, can retain and update their experience after replacing the existing system. Win-win.

One final tip

Rejection can be painful. Fear of rejection is real.

You may want to avoid this by not letting anyone into your plans until everything is perfect.

Do not fall into this trap because building what nobody needs is much worse than facing a pushback.

Instead, be wise in driving your initiative because its future depends on you: how you identify stakeholders, prioritise different kinds of work and adapt to feedback.

Credits for the cover photo go to Matt Ridley (photo from Unsplash)

Thursday, September 3

"Our interview process is pretty standard. You will have five rounds: three technical, one with HR and the final one – with a hiring manager, each lasting between 40-60 minutes" Anna says on the phone. The script is open on her laptop, but she does not need it — if you recite the same speech ten times a day, text remembers itself. "The first round will be focused on algorithms and data structures, so be prepared to answer questions about time complexity and ..."

"Are you serious?" Jeremy laughs, interrupting the recruiter.

"I'm sorry?" Anna asks with undisguised surprise after a short pause.

"Of course you are! Do your engineers spend time on calculating complexity? No, they reconfigure Kubernetes and move buttons around. That is exactly why you desperately need programmers — because nobody wants to waste their time on your seven rounds".

"Five rounds," Anna corrects reflexively, but the candidate has already hanged up.

Friday, September 4

"And then I tell her: go get another idiot to write code on a whiteboard," Jeremy laughed.

"For real?" Dave almost chokes on beer. "And she?"

"No clue, mate. I've already spent my time listening to how agile they are, that was enough".

Dave recently changed a job and had a completely different story: nobody asked him to reverse linked lists or calculate Big O of made up algorithms. All he got to do was prepare a take-home coding challenge and solve a few problems onsite, all of which were similar to what a programmer might face in their day-to-day work. That leaves Jeremy enough faith that sane companies exist.

"By the way, do you need more developers?"

Monday, September 7

From: hr@catsandchickens.io
To: jeremythewizard@gmail.com
Subject: Coding test

Hi Jeremy,
Thanks for showing interest in our FrontEnd Engineer position at Cats and Chickens!
The first part of our process is a test project that will allow you to demonstrate your coding skills and knowledge of Javascript, CSS and one of the most popular frameworks.
To maximise the efficiency, we ask that you complete the project within 10 days. We understand that you may have a tight schedule, so please let us know if you need some extra time. You will receive a separate email with the details from one of our engineers – they will also be available for you should you need any assistance. Most of our candidates spend 15-20 hours working on a project, but it is totally up to you — there are no minimal or maximum requirements to meet.
I would like to thank you in advance for dedicating time to complete this project!

Wishing you all the best,
Nathan.

Wednesday, September 23

"Rahul, you were looking at his homework project, how was it?" Nathan asks, starting a pre-brief meeting before the onsite interview.

"It existed."

"Sweet, anything else?"

"It was big."

"Perfect."

Sophia, a developer who is about to interview for the first time, looks at Rahul in disbelief. "Didn't you review the code?"

"I was about to", he says and gives a conspiratorial wink. "But then I got an urgent task and had to reconfigure Kubernetes".

Nathan perks up as if remembering something. "You are new, right? What do you plan to ask?"

Sophia prepared a couple of problems, one of which was to merge two sorted arrays. It is a decent warm-up question with numerous potential follow-ups, but Nathan does not seem to like it.

"We do not ask algorithms — only real-world problems engineers face every day. Sorry, but the market dictates new requirements."

"Don't worry, we can rephrase the question to make it work. How about this?.." Rahul pauses for a few moments to formulate a new task. "Our website uses five different APIs to fetch products, all of them ordered by price. Ask the candidate to show them in one list with the cheapest ones at the top."

"Do you mean merging elements from five sorted arrays?"

"Not elements – products. And not arrays – API responses, that's important!" Rahul replies. "And one more thing – never say the word complexity, candidates hate it."

"What should I do then?" Sophia still looks puzzled.

"Ask how it scales."

Credits for the cover photo go to Mark Rabe.

The most common advice about refactoring is to cover old code with tests before changing anything. This is a good suggestion — we cannot modify code if we do not have a way to validate its correctness, and tests are the best way of gaining confidence.
However, it is easier said than done. The code you need to refactor is likely to be different from the samples you saw in the unit test tutorials which usually look like this:

If the code consisted solely of single-purpose pure functions, you wouldn't need to refactor it at all. Most of the time, to-be-refactored code is hard to understand, not to mention writing tests for it. It is usually full of giant functions that do dozens of different things at the same time, implicit state manipulations, and hard-to-trace callbacks.
How to preserve a behaviour when changing a shape of code?

Let's refactor something!

Here is a piece of old code which I would like to change:

The primary purpose of this code is to render the profile page for a given user, but it does a couple of other things:

• It sends stats when somebody requests a profile and when the page is rendered
• It caches previously constructed pages for up to one hour (3600000 milliseconds) to reduce the database load

We want to preserve this behaviour, which means we need resilient tests for it.

Resilient tests?

You want to write tests which will survive code refactoring. It is extremely unpleasant if you spend time writing them, then you change code and all your tests need to be fixed.

To demonstrate the problem, I will show how we can test that stats are being sent correctly:

Check again the piece of code that sends those stats:

You can see several issues with this code:

1. renderProfile has to know how to send stats — if we are to change it in the future, we will need to adjust this function
2. We do not handle errors — nothing catches if a request fails
3. All events are sent independently – it would be better to send stats in batches to reduce the number of requests

A right approach would be to put stats-related functionality to the separate module and then use it in the main one:

If we run tests right now, they will fail because renderUserProfile does not send requests directly, it calls stats.trackUserRequest instead.

Using console.log to strengthen tests during refactoring

When everything is hugely volatile, we may want to temporary sprinkle logs in important logical pieces:

On the next step, write tests asserting that correct data was logged:

Then, make sure that those logs go to the right places during refactoring:

When refactoring is done, remove all useless logs and replace them with proper assertions in tests:

This simple trick will help you keep your tests green during refactoring no matter how much code you modify. Using this method, you can test very complex logic, such as caching:

Final words

It is troublesome when you cannot rely on your tests when you need them the most. But it is much worse when your tests are green and code works incorrectly.

Use this method only as a temporary strengthening for tests during refactoring and replace all occurrences of console.log with the proper assertions as soon as you can.

Happy refactoring!

The layout of Mr Meyer's office is more suitable for questioning than for productive conversation: a massive high-backed chair that looks more like a throne, a long desk intended to separate the host from guests, and odd portraits of old long-bearded men looking shrewdly at anyone who has to report to the boss.
Today, that honourable duty goes to Simon and Andy. Not that any of them are happy about this great opportunity, in part because of the office's oppressive atmosphere, but mainly because of the reason they are there.

Mr Mayer represents "Chips Industrial", the company that outsources development to the firm where Simon and Andy work. After the recent release, their flagship product's revenue fell by 15% due to a software bug, the nature of which they were trying to explain for ten minutes.

"Once again, what was that release for?" Mr Meyer asks.

Simon, the project manager, is the one to answer: "We added a new feature to the application, so users could find products by a bar-code".

"And why did the money go down?"

"Unfortunately, this change had an accidental and undesirable effect — all payments from PayPal stopped coming, and we have a fairly large set of PayPal users, hence the drop in revenue".

"Undesirable effect," Mr Meyer repeats slowly and then pauses.

Andy, the developer, breaks silence: "We've already reverted this feature, and all metrics are back to normal. Now, we're working on a fix and then we'll re-land the change".

"Oh, thank you!" Mr Meyer exclaims. "Why am I asking this when I must praise you two! We paid for two months of work so you could release the feature, drop money and heroically revert it. Why the hell did you have to break PayPal, bar-codes must have nothing to do with PayPal?!"

"They don't," Andy agrees. "But we had to change the database, and we noticed some inefficiencies in the schema: unused tables, meaningless foreign keys, even typos in column names. As we worked on a migration script, we just followed the Boy Scout rule and did a cleanup".

"But why?", Mr Meyer looks puzzled and annoyed at the same time.

"One renamed field was still used by the payment system, and we missed it".

"That's not what I ask," Mr Meyer interrupts. "Why to touch something unrelated to the feature? To me it looks like somebody in your company sabotaged the project".

"No-no-no!" Simon hastily waves his hands in response to this accusation. "Nobody tried to sabotage anything. Moreover, all our people worked to do their best to improve the codebase. Yes, accidents do happen sometimes, and we were prepared to quickly revert the feature and recover the database. As for your initial question, it is an industry's common practice to continuously improve parts that need improvement".

"The Boy Scout rule — always leave the campground cleaner than you found it," Andy adds.

"Okay," Mr Mayer says and starts furiously typing something on his keyboard. Clack-clack-clack click clack-clack. Andy and Simon are at a loss to guess what he is up to, but they do not dare ask. After two minutes of laud clacking and clicking, he turns his laptop over to Simon: "Read it to me".

The project manager comes to the screen, close enough to read from an excel spreadsheet. "Product designers — one," he begins and then looks blankly at the owner of the office.

"The list of people who work on this project. For whose work I pay," Mr Meyer explains slowly and distinctly. "Continue".

"Project manager – one. Senior developers — two. Junior developers — one. QA engineers — two," Simon finished reading. "I'm not sure I understand..."

"Where are Boy Scouts? Where? Do I pay for Boy Scouts?!" Mr Meyer breaks into a scream. "Are you a Boy Scout?"

Simon shakes his head.

"You?" Mr Meyer looks at Andy, but he cannot find what to answer. He opens the mouth to explain the nature of the boy scout rule and why it is reasonable for developers to use it, but Simon intervenes before he can start:

"We are sorry, Mr Meyer, that was totally unacceptable. We are working hard to re-release the feature without the problematic cleanup, and we will make sure similar problems won't happen again."

"You meant to add a new feature, not to break payments!"

"That is fair".

"Why not to do your freaking clean up after the feature? We advertised it to users — can you imagine how busy our support is right now?!"

"I understand, Mr Meyer, that was an oversight on our side, and we will do our best," Simon continues, seeing that despite heated atmosphere, Mr Meyer looks a bit calmer. "It won't take too long — end of the week the latest".

After a long stare at Simon, Mr Meyer sinks into a chair. He nods silently as if coming to a conclusion in his inner dialogue. Then he purses his lips and points to the door, much to Andy and Simon's relief.

"And keep an eye on your damn Boy Scouts!"

I put it straight – you do not need to have any prior knowledge about the codebase to start doing code reviews.

This article is going to be about why all new developers should review code, and how to get the most out of it. If you do not need any convincing or guidance, you may rather watch how I win a fight with my cat.

"New developers" in this context are not only people who have just started a career but also experienced developers working with the unfamiliar codebase.

Benefits of doing code reviews

First of all, it is going to speed up your onboarding. Right now, your learning is limited by the number of tasks you are directly involved in — you learn from your own successes and mistakes.

Reviewing other solutions is a quick way to get around this limit. You can get to know various parts of code without touching them personally and see what works and what does not for different types of problems.

On the other hand, your feedback will be beneficial to the team because you have a crucial trait that no one else has — fresh eyes with no prior context.
As writers cannot edit their own texts, programmers rarely can judge their code. We know too much about why it is written this way, and the more people share the same understanding, the harder it is to have an unbiased opinion. While you have limited knowledge, you are the only person who can give a fresh view and challenge what others take for granted.

How to approach code reviews

1. Do not be afraid

All teams I worked with had a high demand for code reviews, which is quite common in the industry. Therefore, do not be afraid of starting — nobody will mind having one more pair of eyes available.

It is quite common to fear not catching a bug or merging code that would need some improvements. A workaround is simple — do not approve a pull request if you are not sure. Leave your comments, ask questions, and ping somebody else for a final verdict.

2. Understand the problem

Before looking closely at the code, familiarize yourself with the problem:

• What is the definition of done?
• Is it complete?
• Would you add anything else?
• How would you test it?

Think about all possible use-cases the author may need to implement. Then, either remember them or write them down — this is going to be handy soon.

3. Draft your own solution

Remember, we are not reading code yet :-)

To get the most from this learning opportunity, think about how you would approach this task:

• How to structure data?
• Where to put logic?
• Is there anything in the codebase you should reuse? If unknown, how would you search for it?
• Who is more knowledgeable in this area to advise you if you were the one picking this task?

Once again, write it down or keep in your memory — up to you.

4. Prove that the problem is solved fully

Now it is the time to start looking at implementation but only at a high-level. Focus on what rather than how.

Sometimes, clear and correct code does a wrong job:

• An author may misread or misinterpret requirements
• They may implement some parts and forget the others

Look at the list of possible use-cases you prepared earlier:

• Are all of them handled?
  If not, ask whether they need to be — it is safe to assume that you are the one who misunderstood the problem.
• Are there any cases you did not consider?
  If the author implemented something you did not even think about, it is excellent — you already learned something new!

5. Compare your solution with the pull request.

Now you know how you would approach this problem, but how did the author solve it?

Find differences between both approaches and try to understand the pros and cons of each. The best way to do it is to ask questions:

• Why was it preferred to put X and Y to the same database table, rather than keeping them separately?
• Why was the primary logic put to module A, while module B has similar pieces that might be collocated?

This way is how you learn the most — not by reading the code and checking it for correctness, but by exercising your skills and validating proposed solutions.

6. Ask questions about code.

When you get the answers to all high-level questions, it is time to zoom in and look deeply at code:

• Is it easy to understand or something needs further clarification?
  Questions from new developers often mean that the code is not as self-explanatory as it could be. The author may consider adding comments or restructuring obscure fragments.
• Are there ways to improve the code?
  Even though you're new to the project, you can read and write code, right? Leave a suggestion when you see a room for improvement — after all, it can only help.

People frequently ask where is that line between giving useful comments and nitpicking. Is it appropriate to ask to rename a variable or to chase a negligible performance improvement?

As for me, everything is alright as soon as you communicate what is essential and what is not. I always prefix minor comments with the words 'minor' or 'nit', so the author knows which are ok to ignore.

Come back later

If the pull request was not immediately merged — make sure you check it for new comments later.

Someone may reject it despite your approval; someone may add fruitful comments — this is just another piece of context that is never superfluous.

Does your project have an enormous module called something-manager or something-controller that grew beyond any possible limits and became completely unmaintainable? How many do you have?

Usually, code smells are the results of deliberate actions:

We had a tight deadline and agreed to ship overcomplicated and unreadable code. We never prioritized writing tests, and now we little confidence in changing old logic.

Large modules are a different story. They do not happen overnight, and I'm yet to see a person suggesting to put a ton of random methods to one pile and call this pile GlobalManager or Utils. It is never a choice, but rather the result of many good intentions: small enough to attract attention, but still dangerous to cause harm.

Evolution of one module

Let me start from an oversimplified fictional example.
Imagine that you work on a piece of software for college students and their teachers.
First of all, we need to allow teachers to see all assignments that a particular student has. Let's write a module for it!

This is what we need to do:

• Check that a user is a teacher and hence has necessary permissions
• Get all we need from the database
• Format the result and show it to the user

A work in progress, but nothing terrible is happening so far.

Time goes, and teachers request another feature: they also want to see which books their students have. Sounds like a weird request, but we can live with that.

For this feature, we can reuse several functions we wrote before (getRole, formatResult and showContent). All we need to do is to add this small change:

At some point later, we get another request, but it is not about teachers anymore — students also want to keep track of their books to know what they need to return to the library.
This one is even easier to implement:

tiny function that reuses previously implemented capabilities — easy choice, easy code review.
But now students have one more request: they need more information about their books, i.e. the date when it should be returned. Something that formatResult cannot do. Luckily, we are programmers and can make them happy:

Job is done!
The last piece of news for this example: teachers decided that the strange case about seeing students' books was redundant, and there is no real situation for which it would be needed.
Who does not like removing code, huh?

Boiling frogs

We must be proud because we maximized code reuse and iteratively supported new use cases with minimal code changes. All commits were concise and sensible, at least at first glance.

However, it is worth checking the module once again — not only the changes but full content:

Two different types of content for two different types of users. Not much overlap.

What's much worse is that this module is prone to unlimited expansion. Every small change related to students, teachers, books or assignments is justifiable until at some time we wake up with a module so big that the only thing left to do is teach it how to make coffee. Fortunately, the water is already boiling.

Why it happens

Several factors are contributing to this process.

We, developers, love reusing code. It saves us a lot of effort — can you imagine the world where we had to write everything from scratch?

At the same time, we do not like changing old code. Sometimes it is hard, sometimes it is unsafe, sometimes it just makes us think.

Code that we can reuse — investment.
Code that we have to change — legacy.

That leads to the thinking pattern which I call Reckless Reuse:

How to avoid

To prevent Reckless Reuse, keep in mind the original purpose of a module you intend to change:

In our example, we could move the functions getRole and showContent outside of the module that serves teachers, so we still can reuse them from other places of the application without having to grow the teachers' module.

Unfortunately, it is never enough to just do it yourself – all collaborators should adopt the same practices. There are a couple of tricks that can help you with that:

• Invest in proper naming.
  Make sure the names of your files reflect their purposes. If naming is hard, it may mean that you try to call something that should never exist.
• Write comments about the goals of your modules.
  If the name alone is not explanatory, consider adding a paragraph or two about which set of problems a given module is supposed to solve.

It should help you to notice when modules start doing something beyond their initial scope. Even when a change is small and reasonable, it will raise questions when somebody adds the method trackAttendance into the module book-data-provider.

Surrounded by faster pacers

In this part, we will talk about problems that may occur when you feel that a lot of people in your team are much more productive than you.
In many cases, it doesn't lead to any problems – people happily work together and achieve great results. But sometimes their mutual influence can be destructive, and people would feel demotivated and discouraged.

Several symptoms are indicating that you're affected by faster pacers:

• You feel guilty seeing that colleagues have achieved more than you
• You are afraid of taking challenging tasks which can make you stuck for a while
• You feel like you have to work longer hours to keep up with others

Daily standups or any other form of sync with colleagues is the perfect time to diagnose this problem:

• Are you nervous about sharing your progress?
• Do those meetings make you feel like you have not done enough?
• Do you find it challenging to describe your results and plans?

If any of these describes you, a closer look is needed.

Five actions to solve the problem

The most popular advice I heard in this situation is to take it easy. It is normal to have somebody more productive than you, left alone the fact that nobody can be a top performer in all situations.

Even though I fully understand the reasoning behind this suggestion, I do not think it is helpful. If somebody is nervous about attending standups, you cannot fix it by suggesting not to worry.

Instead, you can face this problem, find out the reasons and prepare an improvement plan, even if the problem exists only in your imagination. Then, it's going to be up to you whether to follow this plan or not, but at least you will take matters into your own hands – that alone can be sufficient to address most of the symptoms.

Let's talk about the five things which you can do to get out of this unpleasant situation.

Action one: demystify top performers

no two writers are the same, like snowflakes and fingerprints. No one will ever write in just the way that you do, or in just the way that anyone else does. Because of this fact, there is no real competition between writers. <...> Writing is a matter strictly of developing oneself. You compete only with yourself. You develop yourself by writing.

– John McPhee

In time, everyone develops their areas of expertise. No matter how broad or narrow they are, one is the same — people are much more productive when their job overlaps with those areas.

Before bringing up your own expertise, I would recommend you you to think about your more productive colleagues. Every time they do something great, ask yourself what helped them to achieve those results.

Something that could sound self-deprecating at first:

Mark finished this giant feature for a week. That one would take more than a month for me!

Can be rephrased and cleansed of magic:

Mark finished this giant feature in a week because he's been building similar ones for the past three years.
He did more than ten last year – now he's extremely good at it.

Now you can see that Mark's fast pace didn't appear overnight – it required years of deliberate practice. Moreover, you know that doing more things in this area can help you to close this gap.

That is not the only way of reframing achievements. It could be something like this:

Mark finished it in a week because he wrote the whole system since the beginning and he knows every line of code by heart.

or even this:

... because he did not have the internet at home and spent all his free time working in the office.

No matter the situation, your goal should be to stop seeing people as just productive and start noticed the reasons behind their results. Most of the time, those reasons are ordinary and achievable by anybody.

Action two: find your comfort zone

Simply put, there are three types of activities:

• Something you enjoy the most
• Something you are good at
• Most important things for the company at the moment

The intersection of all three circles is your niche in the team, but finding and expanding your niche deserves a separate article. For this topic, I will focus only on the comfort zone (highlighted in green).

Everybody has ups and downs, and you will have many periods of not being at your best.
One of the smartest things you can do is to prepare something that can give you a little boost when needed — a type of work you like to be doing or an area where you can be very productive.

If you do not have a comfort zone right now — build one:

• Familiarize yourself with plans of your team.
• Pick an area which will require work in the future.
• Start building expertise there to capitalize on it when the time comes.

Action three: define expectations and track achievements

The easiest way to not meet expectations is is to have no expectations at all. No matter what you achieve, you can always find a room for improvement.

The simplest way of coping with that is to formulate your goals before you start working towards them. I find daily plans most precise and helpful for this purpose; here is one of my recent ones:

The expectations were clear and realistic, but I ended up not finishing half of what I planned to do.

Was it a problem? No, because I knew that I had done more important things instead, and there was absolutely no reason to feel sad about my initial plan.

Action four: keep expectations reasonable

Sometimes results are noticeably small in comparison to goals:

While this is a call to think about what can be improved, I would recommend checking your expectations for feasibility first.

There is a simple exercise to figure out if you are unrealistic in your estimations:

• Take some tasks your team plans to work on and imagine how much time each of them would take for you. Can you complete a particular task one day? In a week? Or maybe you can do five of those in an hour?
• Write it somewhere.
• When other people complete those tasks, check how their results match your estimations.
  Were they working within their niches or tried something new? How did it impact them?

This exercise is also helpful when your plans are unambitious and require correction:

Action five: analyse and improve

Detailed plans can be beneficial even when everything looks good:

Even though the result matched your expectation, a picky perfectionist can find some food for reflection:

I rarely use this method – maybe once every two or three months, but it always helps to take control and find something I can change.

Prove it works

At the beginning of this article, I mentioned that the best way of noticing this problem is to pay attention to your behaviour when you need to share your progress and describe the plans.

Feeling that you have not done enough can contribute to the demotivation, which will prevent you from working at your best, which will cause dissatisfaction of not achieving enough, which will incur even more demotivation, which will further decrease your productivity, which will make it even harder to get out of this loop.

The good news is that the actions above can help you to

• Understand if your expectations are realistic and how to adjust them if they are not
• Find the quick way to get back on track after a period of dissatisfaction
• Figure out what is the exact reason for dissatisfaction and how to improve it

If anything, it doesn't leave too many reasons to worry.