Code Review Is NOT For Catching Bugs

In this follow-up video, we dive deeper into the **true purpose of code review**, challenging the misconception that its main goal is to catch bugs. Instead, we emphasize how code review plays a central role in shaping team culture, accountability, and knowledge sharing.

### Key Takeaways:

- **We see code review as a cultural engine**: It’s a key mechanism for how our team communicates, transfers norms, and builds a shared understanding of quality and standards.
- **We’ve learned that code reviews aren’t about bug-hunting**: Studies—including from Microsoft Research—show that code reviews are not effective at finding bugs, even with multiple reviewers or approval layers.
- **We hold ourselves accountable for our code**: The responsibility for quality and testing lies with the author—not the reviewer. Code review isn’t a safety net for catching functionality issues.
- **We avoid over-reviewing**: Adding more layers of review slows us down without meaningfully reducing bugs. Instead, we focus on meaningful reviews that support learning and alignment.
- **We use code reviews for knowledge and culture transfer**: Through thoughtful feedback and shared context, we reinforce how we build, think, and collaborate—making code review a vital part of team growth.

You Should Be Vulnerable With Your Manager

You are feeling burnt out at work. Should you share this with your manager?

You feel like you are slower than your other teammates and are afraid that you look bad amongst the team. Should you share this with your manager?

Your dog just died, and you are having a really tough time concentrating at work because of this. Should you share this with your manager?

Here are the core points from the lesson:

- Your manager is responsible for your performance at work. Therefore, it's in their best interest to help you resolve anything that is negatively affecting your work performance, even if it's something non-tactical.
- If you are having a deeper issue (e.g. you have imposter syndrome), this is something you should talk with your manager about. You shouldn't expect them to act as a full psychologist, but they should at least be receptive of your problem and lend an understanding ear.
- Venting and complaining are very natural and can act as a therapeutic exercise. Don't be afraid to do this with your manager once you have a good enough relationship.
- This gets easier over time. Once you start being honest and more transparent in your manager meetings, the trust between you two increases, making it smoother to continue being open in the future.

Related resources:

- [\[Masterclass\] What Software Engineers Should Look For In Their Engineering Manager](https://www.jointaro.com/lesson/oeY7ncZhzJ5NO6dij5e7/masterclass-what-software-engineers-should-look-for-in-their-engineering-manager/)
- [\[Course\] Networking Guide: Build Deep Relationships Quickly In Tech](https://www.jointaro.com/course/networking-guide-build-deep-relationships-quickly-in-tech/)

Having The Proper Mentality For Manager 1 on 1s

True or false: Your manager is your superior, so it is on them to ask the right questions and figure out what you need in your 1 on 1 meetings. You just need to show up on time.

Why is the burden on you to set the agenda and overall plan with your manager 1 on 1s?

True or false: It is better for your career growth to view your manager as being a resource for you instead of you being a resource for your manager.

True or false: A good manager 1 on 1 involves you giving status updates and then waiting for instruction on what to do next.

- *Your manager is a resource for you.*
- Don't just see your manager as a source of authority that gives you work. While this is true to some extent, having this mentality really holds back your growth.
- Go into your manager 1 on 1s with a plan on how you can extract the most value from them.
  - This onus is on you to set the agenda for this meeting, so you can get insights from your manager on how to best improve yourself. Let them know about this agenda beforehand, so they can think about how to best help you with each point.
  - Another way of seeing this is how can you make your manager's life easier. By setting the stage for your manager, you lower the barrier for them helping you as they don't need to figure out exactly what your work life looks like and what problems you have.
- A common failure mode for earlier-in-career engineers going into manager 1 on 1s is they go in, give a status update on what they're doing, and wait for more work to be given to them.

Related resources:

- [\[Masterclass\] How To Have Impactful 1 on 1 Meetings](https://www.jointaro.com/lesson/FEK6JZqW2Jg3rdN9yeGn/masterclass-how-to-have-impactful-1-on-1-meetings/)
- [\[Course\] Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)

1 on 1s Are The Time To Be Awkward

Why should you be awkward and even a little bit uncomfortable in 1 on 1 meetings?

True or false: 1 on 1 meetings are great for staying in sync, so status updates are one of the best things you can talk about during them.

Which of the following are good things to talk about in 1 on 1 meetings?

The 1 on 1 meeting is one of the most important usages of time in the workplace. Even the most junior engineer will generally have at least a 1 on 1 meeting series with their engineering manager. However, 1 on 1 meetings are often completely wasted by software engineers - Here's how to avoid that.

Here are the core points from the video:

- 1 on 1 meetings are the most inefficient way to communicate anything that is non-controversial
  - The main culprit here is detailed status updates. If you're using the majority of the time to share these and talk tactics, you are doing 1:1s wrong.
- The most effective way to leverage 1:1s is to talk about things that are *awkward and maybe even make you uncomfortable*. Here are some examples of "awkward" topics:
  - Feedback to improve
  - Emotions (both positive and negative)

Related resources:

- [\[Course\] Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)
- [The Art of the Awkward 1:1](https://medium.com/@mrabkin/the-art-of-the-awkward-1-1-f4e1dcbd1c5c)

2 Ways To 100x Your Productivity That Nobody Does

What are the 2 underutilized but straightforward ways of becoming far more productive?

True or false: Often times you should sacrifice sleep and exercise in order to get more hours, thereby becoming more productive.

Why is it absolutely necessary to get in good sleep and regular exercise no matter what?

- The 2 core pillars of productivity are a consistent, good night's sleep and regular exercise (3-5 times a week).
- "I don't have time for that" is not a real excuse. There are thing you *make* time for. Nobody says they stopped brushing their teeth to become more productive: That is an example of something everyone makes time for. Sleep and exercise are the same way.
- The math doesn't check out for sacrificing these. It doesn't matter if you have more hours in a day from doing this if your rate of getting things done is very low. And it will be low if you are constantly sleep deprived and not physically fit.

How The Best Software Engineers Learn A Tech Stack - The Lego Model

- "The Lego Model" is a way to view the world and understand your learning journey as a software engineer.
  - Technical components (e.g. rendering a list of items) are the individual legos
  - Complete products (e.g. a food delivery app) are the full lego creations
- There are 3 axes to evaluate your legos:
  - **Quantity:** How many you have
  - **Quality:** How good and sturdy your legos are
  - **Commonality:** How "in demand" your legos are (i.e. how many creations they can fit into)
- Most earlier-in-career engineers understand the 1st axis of quantity and incorrectly spend a lot of time learning different tech stacks and frameworks.
- Those same engineers often don't even realize the 2nd and 3rd axes exist:
  - When they learn a component, they will build it out with very low quality.
  - They will learn "flashier" components that aren't even used by most products/companies.

For examples on how to excel at the 2nd and 3rd axes, check out the related resources below!

Related resources:
- [[Masterclass] How To Learn Quickly In Tech](https://www.jointaro.com/lesson/u9ldIvrTvV1wfWExccDR/masterclass-how-to-learn-quickly-in-tech/) - The full video this clip came from
- [This Is How Software Engineers Should Initially Learn](https://link.jointaro.com/iVBpCaB6pAHivhdi6)
- [Building Software For Optimal Learning Example - Login Flow](https://link.jointaro.com/oEkTB3pskKH6JHCX6)

Suppress Your Instincts And Treat All Feedback As A Gift

True or false: If you get a piece of feedback, you should initially assume good intent and that it is correct.

What should be your immediate reaction when you get a piece of constructive feedback?

True or false: If you get feedback that you do not believe is 100% correct, you should just ignore it.

Which of the following are good things you can do when you get a piece of feedback that you genuinely believe is not constructive and is phrased in a harmful way?

True or false: One of the most straightforward ways to grow in tech is to just immediately incorporate every piece of feedback you get.

- **Don't be defensive at all when receiving feedback unless it is entirely incorrect.**
- If you have taken the time to find a supportive team, the vast majority of feedback you receive (95%+) will be correct and have value.
- Feedback is a gift and arguably the greatest gift you can possibly receive for your career. *One of the most common attributes among top performer engineers is that they take and apply feedback extremely well.*
- Have empathy for the feedback giver. They probably feel a bit awkward as they're unsure how you're going to receive the feedback. Make them feel comfortable after they share the feedback by thanking them immediately and earnestly.
- Write down all great feedback you receive and try to convert it into action items:
  - **Example:** "I feel like you could be more active in meetings." -> I will try to say at least 1 thing in every team meeting from now on.
- If you get feedback you genuinely believe is incorrect and hurtful:
  - Talk to your manager if you don't have a good relationship with that person.
  - If you feel comfortable enough to talk with that person directly, have a crucial conversation.

Related resources:
- ["How can I find more opportunities to grow when I'm getting very little real feedback?"](https://link.jointaro.com/TzKmgN5nLnLyXJ5G6)
- ["Everyone's telling me I'm doing great - How do I get actionable, constructive feedback?"](https://link.jointaro.com/ng6MUQy2yUfS8w4e8)
- [Effective Communication Guide - Giving Feedback](https://link.jointaro.com/VsQvnzsnJbbXUQDy6)

Explaining Your Experience In A Meaningful Way On A Resume

Is this a good resume snippet: Worked on the SIVAD system, using Room, AndroidX, Activities, and Java

How do you make the experience portions of your resume stand out?

Is this a good resume snippet: Champion for unit test coverage for Cool Company's iOS app, increasing it by 20% and reducing the amount of new iOS user issues by 10%

What is the main way people struggle with their resumes?

Is this a good resume snippet: Led the JavaScript migration effort with strong communication, architectural, and code quality skills

- The most common way resumes struggle is that they tell instead of show
- Here's an example:
  - **Telling:** Added unit tests to the Android app with JUnit and Java
  - **Showing:** Increased test coverage of the Android app by 80%, which reduced bug tickets from users by 50%
- In a nutshell, don't just say what you did - Adding an adjective like "great" doesn't automatically make your feat impressive. Prove that you did something great by talking about how you did it and the actual result (which is ideally business impact).
- This method of communication is especially important for resumes as their audience is mainly non-technical: Recruiters. They aren't going to understand the more specific tech buzzwords. You need to write things in more "plain English", so that your accomplishments can be understood as impressive by almost anyone.

Related resources:

- [\[Course\] Get More Interviews: Write A Stellar Resume As A Software Engineer](https://www.jointaro.com/course/get-more-interviews-write-a-stellar-resume-as-a-software-engineer/) - By taking the course, you get access to Alex's most recent resume!
- [Your Tech Resume Should Look Boring](https://www.jointaro.com/lesson/WFJYebwJW2rhviTrQrB3/your-tech-resume-should-look-boring/)
- ["What high-impact achievements should a full-stack engineering intern target for a stronger resume?"](https://www.jointaro.com/question/cnEgJuQMKI3G4rqhEkp4/what-high-impact-achievements-should-a-full-stack-engineering-intern-target-for-a-stronger-resume/)

Asking Effective Questions That Get Great Answers Quickly

What are some things you can do to improve your question?

True or false: Ideally, your question takes less time to answer than it took for you to ask the question.

What is the core operating principle behind asking and answering questions?

True or false: In order to be polite, you should preface your question with a simple greeting like "Hello". After the potential answerer responds, then you can ask your question.

Why do you need to attach a lot of context and be as specific as possible asking questions in tech?

- **Core principle**: Questions are an exchange of time. You put some time to write your question and the answerers take some time to respond. Your goal is to make the amount of time necessary to answer your question smaller than the amount of time you spent asking it.
- Have empathy for the people answering the question. Thank them pre-emptively!
- Avoid leading "hi". Just ask them your question directly!
- Google your question and go through the initial results prior to asking your question. Inline that context in your question.
- Attach as much relevant context as possible. You want to prevent back-and-forth where answerers need to ask you questions to clarify your initial question.

Related resources:
- [Bad Question vs. Good Question Example](https://link.jointaro.com/fiY293kj2ewPwMqB8)
- ["How do you overcome the fear of asking stupid questions / bothering people when you need help?"](https://link.jointaro.com/37FJnTAX1BN2e5wt6)

The #1 Thing To Remember With Meetings

Which is the core principle you have to remember with meetings?

True or false: It is safer to just keep attending a meeting series, even if you are not clear exactly what value you are getting from it.

You have a meeting series where there is always action, but there is usually an awkward portion at the end where people run out of topics. What should you do?

True or false: When in doubt of a meeting's value prop, just delete it. You can always bring it back later.

You have a 1 on 1 meeting series, and by the time of the meeting, you feel like there are a lot of issues that you two are getting to too late. What should you do?

Software engineering is a inherently collaborative exercise, so every tech company is going to have meetings. The tricky part as a engineer is figuring out how to use them effectively: Navigating meetings incorrectly leads to mountains of wasted time.

Here are the key points from the video:

- Meetings are *extremely* expensive as it's the most valuable resource people have: Time.
  - This is why you need to be very aware of how productive meetings are for you. Don't just go to them blindly because you are on the meeting invite - This is a common failure mode for earlier-in-career engineers.
- If a meeting has value but isn't fully efficient, consider lowering the frequency or length of the meeting.
- Reflect on the value of every meeting, especially team meetings since they suck up the most time.
- *Lean towards deleting meetings or not attending them* - If you're unsure what value you got from a meeting, there's a good chance the meeting isn't actually helping you.
  - You can always run an "experiment" here. Remove the meeting from your calendar for a week and see if anything breaks - If the lack of alignment gets bad, you can put the meeting back.

Related resources:

- [\[Course\] Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)
- ["How can I be more active in meetings and earn the respect of senior engineers?"](https://www.jointaro.com/question/RtISfsqipLWBhZxvyl69/how-can-i-be-more-active-in-meetings-and-earn-the-respect-of-senior-engineers/)
- ["I have anxiety when speaking up in meetings - how do I overcome this?"](https://www.jointaro.com/question/T1eEbbVZo1fuvbhCDXST/i-have-anxiety-when-speaking-up-in-meetings-how-do-i-overcome-this/)

The #1 Thing You Need To Know About Promotion In Tech

True or false: To get to very senior engineering levels, you need to write thousands of lines of code per day.

Why is output not as important for promotion?

- *Promotion is about behavior, not output*
- Raw output doesn't scale. You only have so many hours in a day, and your hands can only physically type so many lines of code per minute.
- Senior engineers can have 10x to 100x the impact of a junior engineer. In order for them to do this, they need to add deeper types of value to the business.
- That deeper type of value comes from behaving in a fundamentally different way to more junior levels. In particular, engineers at these very senior levels add multiplicative value instead of additive value. An example of this is a senior engineer empowering many others to write code instead of just writing the code themselves.

Related resources:
- [[Taro Top 10] Time Management And Productivity](https://www.jointaro.com/playlist/5WA87nbbYJWLnQ60D826/)
- [[Masterclass] How To Get Promoted Faster In Tech](https://www.jointaro.com/lesson/W730BOdrfAIXAEVd8HUf/masterclass-how-to-get-promoted-faster-in-tech/?playlistId=eZOEUatYEe7BBAZByuha) - The full video where this clip is from
- ["How to improve at multi tasking at work?"](https://www.jointaro.com/question/ION8KZHyA8fNWOpHDhZI/how-to-improve-at-multi-tasking-at-work/)

Tech Career Growth Videos

Our instructional videos provide software engineers with insights needed for career growth. Masterclasses go incredibly in-depth on a specific tech topic while case studies are real examples from established engineering leaders.