More About Code Reviews, Impostor Syndrome, and Growing from Code Reviews

Following on from my last post, I saw a co-worker gracefully apply the principles of sound code reviews. It was comforting to see someone else on the same path as me. I observed myself while reading his comments. I didn’t feel attacked or questioned. His tone was curious and thoughtful.

I’ve observed this week that seeing code reviews as a part of engineering work, equal in value to coding and delivery, is starting to influence me. My thinking used to be upon submitting pull requests:


This meets the requirements.
This is as elegant and succinct as I am aware.
This passes tests.


Then, I would feel ashamed when comments come in about did you consider this? Why did you choose that? My internal dialogue became, I should have known this.

But the truth is that I often don’t have the full picture in my head of the entire codebase, or more experience, or the unique insights of another engineer. I only know what I’m operating on right now… if I’m not growing.

It got me thinking about a recent newsletter by The Hybrid Hacker entitled Dealing with Impostor Syndrome in the Engineering World. It was a uncomfortable, unsettling read in that it hit home deeply. I put exceedingly high expectations and requirements on myself to have thought of everything before a code review. And that’s simply impossible.

However, I can start to learn what my coworkers pick up on and ask questions about. Mining that can make me more thoughtful and compel me to improve. Learn more. Explore more. Skill up.

My wish with my new role was that I would get to work with senior engineers, to really level up my game, to sharpen steel against steel. And that has been fulfilled. For that, I’m grateful!

Examining What Is Important To Work On In Software Projects

I observed this week several vectors acting on my thinking. It’s important to focus on the product and the overall mission, as I said last week. That’s the main vector. But then, you look at the active sprint, and you look at what else is left. Low priority tasks left there as low-hanging fruit. Second vector comes in – I want to work on something that is valuable to the team and organization, something that advances the main vector.

So, I look at the backlog and look at the bigger tasks, not prioritized in the current sprint. There are still tickets there, needed to get the release over the finish line. Bigger tasks like API integrations or outstanding features. So, then you weigh up the first two vectors. Something valuable, preferably not low-hanging fruit, and something that advances the product. By my own internal logic, picking up something from the backlog makes sense then.

And this is where internal logic is not not sound, but defies a third important vector team norms and culture. What does the team do? What is accepted in the team? And there, internal logic – even if sound – can come up short with team norms. In some teams, it’s acceptable and encouraged, on some level, to pick up tasks from the backlog. But in others, it’s not if it wasn’t included in the initial sprint planning and not added later during sprint refinement.

There is no actionable method on offer here. Thinking through things, as you navigate a new role and organization, will help you identify the important vectors at play and your own internal logic.

First Week Thoughts

First full week at new role behind me. Really grateful to jump into modern, well-architected, and advanced codebases.

The technologies I’ll be delving into on my own time and getting comfortable with:

1) Formik

2) React-Query

3) Yup schema validation

4) Styled components

5) Advanced TypeScript generics

Two things that I have been doing and practicing, as I navigate the new role:

1) Keeping product-first thinking in selecting tasks to work on. What creates the most value? What does the team need done to get over the launch line? What helps the product the most? This requires a lot of communication and starting to build relationships.

2) Pushing myself out of the comfort zone by picking non-trivial tasks to complete. It may be nice to get a little thing done to get my feet wet, but I learn more about the products and team by working on something a little more complex. Examples include a bug fix or a new feature

Verified by ExactMetrics