Become An Open Source Master [Part 18] - What Are The Most Important Modules?

We need to identify the important modules in an open source project. We should understand the configuration items, hot functions, and utility classes. Additionally, we should figure out how the data flows through the project, including its structure, storage, and APIs.

Connect with James:

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

You stayed calm. They still didn’t trust you.

You said nothing was wrong.\
But they felt something was off.

Here we explore what happens when teams can’t read you—and start reading into you.\
Not because you did anything wrong.\
But because silence always fills itself.

**Want to go deeper?**

- Explore more tools and courses at [**Taha’s Method**](https://www.tahasmethod.com/) — from interview prep to leadership development.

- Follow me on [**LinkedIn**](https://www.linkedin.com/in/tahahussain/) and subscribe to my weekly newsletter, [**The Conscious Leader**](https://tahahussain.substack.com/), for more lessons like these.

- Get 30% off [**Top Tech Leader**](https://bit.ly/tarotopleader) with code **ILOVETARO** (exclusive for Taro members).

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/>

Become An Open Source Master [Part 19] - What Opinions Do The Authors Have?

Be aware of the human element in open-source projects. We should understand and follow the project's coding style, including linting and formatting preferences. If the project lacks a style guide or linting rules, we can offer to help create them, but we should always do so with the approval of the original maintainers.

Connect with James:

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

Build Deep Relationships Quickly In Tech [Part 6] - You're Going To Get Burned

Networking isn't all sunshine and roses - You're going to go through a lot of pain as well. This lesson teaches you:

- Why many relationships fall apart
- Why you shouldn't let a failed relationship turn you off networking forever
- A tactical, mathematical framework to minimize risk and maximize upside when it comes to networking
- How to identify if a relationship isn't going anywhere and should be cut off

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.

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

How To Be An Effective Tech Lead [Part 16] - Be Visible

While you need to lead with selflessness and put the team first as a tech lead, this doesn't mean that you can't be selfish at all. As a tech lead, it's critical for you to get proper credit as well. This lesson teaches you:

- The main tool you have to boost your visibility and prove your depth of contributions
- How to be visible in general

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/)

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.

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)

[Timeless Career Advice] What to Learn

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)

Gilad’s Take On Management

In this video, we explore the core responsibility of managers and define what great management truly entails. The speaker provides a clear, actionable definition of management and unpacks each part of it to guide us toward becoming more impactful leaders.

- We learn that **the essence of management is to create a positive and sustainable change in the organization’s performance**, a definition we are encouraged to internalize and apply.
- We embrace the idea that management is a **creative, proactive discipline**, not just a reactive one—our actions should be intentional and forward-looking.
- We are reminded that our impact must be **positive** and **lasting**, focusing on growing people and systems that perform well even in our absence.
- We are taught to focus on **creating deltas**, meaning our value lies in the improvement we drive, not in maintaining the status quo.
- We expand our view beyond just our teams, recognizing that **great managers influence the broader organization**, constantly looking for opportunities to elevate overall performance.

If you want to learn more from Gilad, he shares free leadership advice daily on [LinkedIn](https://www.linkedin.com/in/giladnaor/?utm_source=taro&utm_medium=course&utm_campaign=cta) and weekly on the[ δeltas newsletter](https://posts.managementdeltas.com/?utm_source=taro&utm_medium=course&utm_campaign=cta)

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>

Clear Communication For SWEs [Part 8] - The STAR Method 🌟

In this video, I explain the STAR method, breaking down its components - Situation, Task, Action, and Result. I highlight the benefits of using this structured approach in job interviews, performance reviews, and presentations.

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

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/)

Tech Lead Blueprint 16/17 - Chaos And Tech Debt

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

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

DSA Crash Course [Part 82] - Summing Squares Walkthrough

In this lesson, Alvin walks through the python implementation for the *summing_squares* problem.

Code along and test your work in the following editor workspace: <https://structy.net/problems/summing-squares?language=py>

If you need additional support taking these DSA skills and actually applying them, take [**Alvin's**](https://www.linkedin.com/in/alvin-zablan-b73a92117/) *complete* data structures and algorithms course on [**Structy**](https://structy.net/?utm_source=taro). You can try out the concepts yourself in their interactive code editor and learn advanced DSA patterns like stack exhaustive recursion.

Use [**this link to get 20% off**](https://structy.net/purchase?promo_code=taro20) the entire Structy DSA learning experience.

Follow Alvin on LinkedIn: [**https://www.linkedin.com/in/alvin-zablan-b73a92117/**](https://www.linkedin.com/in/alvin-zablan-b73a92117/)

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.