Become A Debugging Master [Part 13] - Create A Real Fix

Quick fixes are tempting, but true engineering excellence comes from addressing the real problem. Here are the core points from the lesson:

- A surface-level fix, like returning null to avoid an exception, hides the real issue and often leads to worse problems later
- Always stress-test your fix, check nearby features, and invite feedback instead of hoping a band-aid fix is “good enough”
- If you must land a short-term patch, clearly document it and create a task for a proper fix to maintain team trust
- Use the “Five Whys” method to dig deep into the root cause rather than stopping at the first obvious error

The “Do No Harm” Principle In Coding

In this segment, we discuss the principle of **"Do No Harm"**—a foundational mindset for writing safe, reliable code. While it's great to break large features into smaller diffs, it's essential that each individual diff **stands alone** as non-destructive and does not degrade the product or infrastructure if applied independently.

### Key Takeaways:

- **We ensure every diff is safe in isolation**: Even in stacked diffs, each change must not break functionality or expose incomplete features. Every diff should be self-contained and ideally improve (or at least preserve) the integrity of the codebase.
- **We avoid relying on future diffs to patch behavior**: It's risky to land an unstable or unfinished diff assuming a follow-up will fix it. If that follow-up is delayed or rolled back (e.g., due to a production issue), the earlier diff could introduce bugs or break the app.
- **We use feature gates wisely and early**: When launching features behind flags, we gate the feature at the very beginning—not in later diffs—to avoid exposing half-baked functionality in production.
- **We’re cautious with shared infrastructure**: If a diff touches a shared module or critical system, we proactively reach out to other teams to confirm our changes won’t unintentionally break their workflows or apps.
- **We understand our code lives in a larger system**: Like parts of a giant elephant, changes in one place can affect parts we can’t see. Practicing empathy and caution helps us prevent cascading issues in complex, multi-team environments.

The “Do No Harm” principle reminds us that good engineering isn’t just about adding features—it’s about protecting trust, stability, and the broader system our code lives in.

Break Into Tech And Become A Software Engineer [Part 20] - Demystifying Resume Selection

In this lesson, Brian shares insights from his experience as an engineering manager, explaining how resumes are sorted into "no," "maybe," and "yes" piles during the hiring process.

This lesson covers:

- Why resumes with a skills mismatch or unclear roles are put into the "no" pile, and how to avoid this by clearly presenting your relevant experience and skills
- The challenge of standing out from the crowded "maybe" pile, where many passionate junior developers end up due to generic projects and experiences
- Tips for increasing your chances of landing in the "yes" pile by demonstrating experience, showcasing personality, and experimenting with different resume approaches to see what resonates with employers

If you need extra help breaking into tech, join Brian's exclusive, cohort-based bootcamp (just 10 students per batch). Use this special link for $800 off: <https://www.parsity.io/taro>

Connect with Brian on LinkedIn: <https://www.linkedin.com/in/brianjenney/>

Asking Great Questions [Part 16] - Attaching The Code

Code is heavy, especially when viewed outside the context of an IDE or code review platform like GitHub. It's critical to keep this in mind when you're asking questions about your code. This lesson teaches you:

- The most common failure mode when it comes to attaching code to questions
- What it means to gracefully attach code to your question, explained with an in-depth example
- A trick you can use to share a lot of code without overwhelming your question

To learn how to isolate relevant code, take our debugging masterclass: [\[Masterclass\] How To Become A Debugging Master And Fix Issues Faster](https://www.jointaro.com/lesson/ioR6WzamAIUTpySLAr7o/masterclass-how-to-become-a-debugging-master-and-fix-issues-faster/)

Asking Great Questions [Part 22] - Learn To Fish

Getting the answer to your question isn't enough: If you want to respect the person who helped you, make sure to follow through on the end-to-end learning. This lesson teaches you:

- A common mistake engineers make when getting an answer that's too shallow
- What engineers should do to follow-up on an answer and get full value
- Why it's better to potentially annoy your helper with more questions now instead of later
- The difference between knowledge and mastery, why the latter is so critical for your career, and how asking great questions is intrinsically tied to mastery-building

Tech Lead Blueprint 16/17 - Chaos And Tech Debt

Connect with Lalit on LinkedIn: <https://www.linkedin.com/in/lalitkundu/>

Don't Forget: Code Review Is Public And Has Huge Consequences

In this final segment, we emphasize how **code review is not just a technical exercise—it’s a public, cultural signal**. Especially for tech leads and senior engineers, the way feedback is delivered in code review has real consequences for team morale, inclusion, and career development.

### Key Takeaways:

- **We treat code review as a public cultural forum**: Comments are visible to others on the team and can impact how engineers—especially juniors or new hires—are perceived. Feedback that embarrasses someone publicly can harm confidence and even affect performance reviews.
- **We avoid harsh criticism in public threads**: If we’re truly concerned about someone’s patterns (e.g., lack of testing mindset or carelessness), we give that feedback in private, not in a code review. We follow the rule: *Praise in public, critique in private.*
- **We understand the leadership signal we send**: As tech leads, our tone sets the bar. If we leave demoralizing or curt comments, we implicitly encourage others to do the same—fostering a negative or toxic culture.
- **We handle serious feedback face-to-face**: When needed, we schedule a quick 15-minute conversation to deliver constructive criticism with nuance and care—ensuring it’s received in the spirit of growth, not shame.
- **We use code reviews to build people up, not tear them down**: Every interaction is a chance to create a safer, stronger engineering culture. We remember that what we say—and how we say it—has lasting impact.

Ultimately, we believe that **code review is leadership in action**—and great leaders use it to uplift their teams, not diminish them.

Master The Art of Successful Negotiations: Unlock Your Full Potential

A practical negotiation workshop led by Nadav Klein, professor at INSEAD and instructor at Minerva Project. 

Nadav discussed the importance of negotiation skills in both professional and personal life, emphasizing the need to understand human behavior and the mechanics of negotiations. He highlighted the significance of practice -- the more you do it, the better you become!

It's important to identify zero-sum issues vs cooperative issues in negotiations. You should **strive to find ways to cooperate and create win-win situations by understanding and prioritizing the differences in what each party wants**. Critical to this is to bridge the information gaps and understand how we evaluate ourselves vs how others evaluate us.

- [Connect with Nadav on LinkedIn](https://www.linkedin.com/in/nadavklein/)

More resources on negotiations:
- [The #1 Rule Of Negotiation - How To Avoid Giving A Number](https://www.jointaro.com/lesson/4T3wTorG47wPzSqVmAOx/the-1-rule-of-negotiation-how-to-avoid-giving-a-number/)
- [[Case Study] How To Land 18 FAANG+ Offers With Steven Zhang (Airtable, USDR, Tableau)](https://www.jointaro.com/lesson/gGkO4pLeFq1ctRM9tSBF/case-study-how-to-land-18-faang-offers-with-steven-zhang-airtable-usdr-tableau/)
- [3 Quick, Powerful Negotiation Tips](https://www.jointaro.com/lesson/8VeEnbxdbPKsZbTcCFm5/3-quick-powerful-negotiation-tips/)

Become A Debugging Master [Part 11] - The 2 Styles Of Bug Searching

When you’re stuck on a tough bug, how you approach it can make a huge difference in how quickly you find the root cause. Here are the core points from the lesson:

- Top-down debugging starts from the full application and removes pieces to isolate the bug, while bottom-up starts with a clean slate and adds code until the bug appears
- Bottom-up debugging can dramatically speed up iteration and discovery in large, complex codebases, even if it requires more upfront effort
- A key mindset is to “move the ball forward” by adding logs, setting alerts, or gathering information that will help your future self debug faster
- Forming clear written updates or questions based on your debugging history allows you to get much higher-quality help from others

Tech Lead Blueprint 15/17 - Low Performers

Ship & Grow 500k+ User Side Projects [Part 19] - Managing Your Project

If you're just starting off with side projects, especially if you're a junior engineer, it can easily get overwhelming. This lesson teaches you:

- The important thing to never forget about side projects
- The 1 project management tool you absolutely should *not* use to manage a side project
- The 1 simple, organic tool that is probably best to manage your side project and keep track of open tasks
- How to organize your side project with decomposition, shown with an example

Come Up With 500k+ User Project Ideas [Part 13] - Look For Gaps

You have found some competitors that you want to beat with your side project. Now how do you do that? This lesson teaches you:

- How adding efficiency and reducing clicks can be extremely compelling
- General basic UI/UX (user interface/user experience) improvements you can make for a product
- A simple way you can level up an application without doing anything (everybody hates ads)

Become An Open Source Master [Part 23] - Be Like Water

It's hard to play well with others when we're very stubborn. Instead, "*be like water*":

- Adapt our contributions to fit the project's philosophy and guidelines.
- Observe and learn from other successful pull requests in the project.
- Be patient and work with the maintainers to get our changes approved.

The viral bad pull request mentioned: <https://github.com/A11yance/axobject-query/pull/354> 

The full process of making a contribution in a big, scary project: [Fixing a Bug in Google Chrome as a First-Time Contributor](https://cprimozic.net/blog/fixing-a-bug-in-google-chrome/)

Connect with James:

- GitHub: <https://github.com/jamesgpearce>
- Twitter (X): <https://twitter.com/jamespearce>

How To Prepare To Leave Big Tech For A Startup

If you’re like [Rahul](https://www.jointaro.com/profile/tTjEXHcTZEYDGh8oUFU2Dy5VFVG2/), you were intent on leaving the bubble of Big Tech to pursue the startup life for a long time. If you have 6 months or 1 year left working in an established company, what can you do in anticipation of your startup journey?

One of the best things you can do is validate the idea of your startup with a side hustle. **Be careful that you’re not using company time or resources or you may later get sued.**

Generally, there are 3 types of projects an engineer can work on: 
1. A project purely for learning, to try out some technology or framework that may have come out recently. 
2. A small business. Also known as an indie business, a micro-Saas, or even something as simple as selling a digital product like an eBook. 
3. A VC scale startup. **This should be reserved for very few companies.** When you take venture capital money, they are looking for a massive return on investment, something like 50x or 100x. That means you’ll be accountable for strenuous growth targets.

Whichever path you choose, go in with your eyes wide open about what your motivations are and whether you’d be happy signing up for the likely outcome. 

An input into the decision about *when* to leave the Big Tech life is to look for some indication of commitment for the customers you’re serving. Are your customers offering you their time, money, or reputation for your product? That’s a promising sign. 

Another reason to leave is that you feel that there’s a narrow period of time when your idea could succeed, e.g. new regulation or a groundbreaking technology.

------

Connect with [Eric on LinkedIn](https://www.linkedin.com/in/ericbahn/)

Engineer Your Ideal Tech Career [Part 17] - Closing Thoughts

Wrapping up the course, [Sophie](https://www.linkedin.com/in/sophienovati/) shares her motivations behind helping people achieve their most ideal and ambitious career outcomes and some ways to connect further.

We hope you leave this course with a crystal clear vision of what brings you excitement as an engineer and how to take that next step to get there.

Thanks for watching!

Looking for mentorship from tech’s top engineers + personalized job hunt assistance and interview prep? [Formation.dev](http://Formation.dev) can provide you unlimited career coaching, technical mentorship, personalized practice, and mock interviews. Join us here: <https://formation.dev/partners/taro>

Worksheet: [Formation - Coding Your Career](https://firebasestorage.googleapis.com/v0/b/tech-career-growth.appspot.com/o/courses%2Fslides%2FFormation%20Career%20Direction%20Worksheet.pdf?alt=media&token=f6344b78-529a-411e-a449-7a34a8d55fc8)

Break Into Tech And Become A Software Engineer [Part 12] - Pick A Platform

In this lesson, Brian emphasizes the value of choosing the right platform for writing online, with a strong recommendation for LinkedIn.

This lesson covers:

- Why LinkedIn is a great platform for building a professional presence, with less anonymity and trolling compared to platforms like X or TikTok
- The advantage of standing out on LinkedIn, where recruiters and employers are more active, making it easier to connect with professionals
- How while platforms like X and TikTok offer cutting-edge tech content, LinkedIn provides a safer environment to network with verified professionals and receive genuine feedback

If you need extra help breaking into tech, join Brian's exclusive, cohort-based bootcamp (just 10 students per batch). Use this special link for $800 off: <https://www.parsity.io/taro>

Connect with Brian on LinkedIn: <https://www.linkedin.com/in/brianjenney/>

Clear Communication For SWEs [Part 9] - Problem-Solution-Benefit

In this video, I explain the Problem-Solution-Benefit framework, focusing on identifying a problem, proposing a solution, and highlighting the benefits. This framework is crucial for gaining stakeholder buy-in. I provide examples and steps on how to apply it effectively.

Connect with me on LinkedIn: <https://www.linkedin.com/in/ryan-wiens/>

Build Deep Relationships Quickly In Tech [Part 20] - Everyday Is Networking Day

Networking doesn't need to be hard. In fact, it should be easy. This lesson teaches you:

- What networking should feel like when you're doing it properly
- Why networking shouldn't feel like a hard, conscious, extra effort
- Ways to make networking seem more natural
- One of the most common mistakes engineers (and introverts in general) make when it comes to networking and maintaining relationships

Building A Metrics Map

In this lesson, we explore **practical techniques** for identifying the input metrics that matter most. Through methods like **metrics mapping** and **customer experience mapping**, we gain a clearer, more quantitative view of what drives our business forward—especially from the customer’s perspective.

### Key Takeaways:

- **We prioritize input metrics and customer interactions**: Too often, businesses rely heavily on output metrics. We recommend looking deeper into input metrics—particularly those tied to customer behavior and experience.
- **Metrics Mapping helps us discover drivers of key metrics**: We start with a business goal or known metric, then recursively ask what drives it and how we can measure those drivers. This technique reveals a broad and useful set of input metrics.
- **The process is recursive and comprehensive**: We drill down from each metric or goal until we can’t go any further, building an extensive network of quantifiable drivers. Repeating metrics across branches is fine—what matters is completeness.
- **The end goal is a flat, exhaustive list of metrics**: While the mapping exercise may begin as a hierarchy, we ultimately compile all the discovered metrics into a single, non-hierarchical list for practical use and monitoring.
- **Finding input metrics is an ongoing process**: This isn’t a one-time task. We continuously revisit and expand our metric set as our business, goals, and customer needs evolve.

To dive deeper into Input Metrics Mastery and learn more from Bill and Colin, follow these links:

- Take the full course at their website: <https://workingbackwards.com/>
- Buy the book: <https://www.amazon.com/Working-Backwards-Insights-Stories-Secrets/dp/1250267595>
- Bill's LinkedIn: <https://www.linkedin.com/in/bill-carr/>
- Colin's LinkedIn: <https://www.linkedin.com/in/colinbryar/>

Maximize Your Equity And Benefits In Tech [Part 3] - Foundational Tax Concepts

Understanding how taxes work is key to making smart decisions about equity compensation—here are the core points from the lesson:

- Gross income is reduced by payroll taxes and deductions to determine adjusted gross income (AGI) and taxable income, which drives your federal tax liability
- Long-term capital gains (assets held over a year) receive lower federal tax rates than ordinary income, often saving high earners significant amounts
- State tax treatment varies—most states don’t offer preferential rates for long-term gains, and some, like Massachusetts, penalize short-term gains more heavily
- Investment losses can offset gains and up to $3,000 of ordinary income per year, but “wash sale” rules can disallow losses if you repurchase too soon
- The Alternative Minimum Tax (AMT) may kick in if you're using lots of deductions or exercising incentive stock options, so it’s important to model this in advance

Next steps with Andy:

- [Connect with Andy on LinkedIn](https://www.linkedin.com/in/andymoranio)
- [Leave feedback and/or sign up for Andy’s newsletter](https://subscribepage.io/taroequitycourse)
- [Schedule a consultation](http://adastrafp.com/contact-us/)

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.