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>

Explain Like I’m 5: Demystifying Meta’s GenAI Infrastructure

Session led by: [Malik (Mike) Alnakhaleh](https://www.linkedin.com/in/malik-mike-a-32b63818b/)

**Event description**

Dive into the fascinating world of Meta's next-generation artificial intelligence with an event crafted for simplicity and clarity!\
\
Whether you're a software developer, a tech professional, or a bit AI-curious, join us for an illuminating session where complex concepts are made accessible. No PhD required!

### **What You Will Learn:**

- The Backbone of Meta’s GenAI: Unpack the core components and architecture powering Meta's cutting-edge AI, from robust data center hardware to innovative computing networks.
- Scaling AI for Tomorrow: Explore how Meta scales its AI infrastructure to support complex models and vast datasets, ensuring efficiency and sustainability.
- Innovations in AI Deployment: Discover the cutting-edge tools and practices Meta employs to deploy AI applications, from development to production.

### **Who Should Attend:**

- Software developers and engineers seeking to understand the infrastructural demands of AI.
- Professionals interested in AI, machine learning, and data center engineering.
- Anyone curious about how large-scale AI systems are built and used.

Ready to peel back the layers of Meta’s AI infrastructure with the curiosity of a five-year-old?\
\
Secure your spot today and step into the world of tomorrow's AI, exploring the future, one simple explanation at a time.

Taro at YC's Demo Day (Summer 2022)

Demo Day is an event where Y Combinator-funded companies present to a room full of specially selected investors and press. This is our presentation about Taro. 

Since the presentations are only 1 minute long, the goal is not to cover everything (that'd be impossible), but instead to say enough such that investors want to learn more.

We launched Taro Premium earlier in the summer, so a lot of our pitch focused on the traction we found in a short time.

Thank you all for being on this rocket ship with us. If you want to support what we do even more, [consider joining Taro Premium](https://app.jointaro.com/membership). Right now, we're pretty early so, so we can be very hands-on with each new member!

If you're thinking of doing your own startup someday, here's some resources to help with that:
- ["How did you decide to quit your job and make a startup?"](https://www.jointaro.com/lesson/beZzIkLUP28WinNQctlP/how-did-you-decide-to-quit-your-job-and-make-a-startup-9132022/) - In this video, Rahul's cofounder Alex walks through his decision-making process behind starting Taro
- ["Career advancement or building a startup? Which one is harder?" ](https://www.jointaro.com/question/EquWmWjZhqiiujyltreJ/career-advancement-or-building-a-startup-which-one-is-harder/)

Part 5 [RBP] Create Custom Hooks

This lesson explains how to improve the organization and reusability of React components by extracting complex logic, particularly related to data fetching, into custom hooks.

- **Creating Custom Hooks:** Learn the process of creating a custom hook to encapsulate state management and side effects, such as those involved in fetching data and handling loading and error states.
- **Organizing and Reusing Logic:** Understand the benefits of separating concerns by moving complex logic into custom hooks, leading to cleaner and more maintainable components.
- **Improving Code Readability:** Discover how custom hooks can make your code more declarative and easier to understand by abstracting away implementation details and providing a clear interface for interacting with data.

Links:

- Florian’s free web development playlist on YouTube: <https://www.youtube.com/playlist?list=PLrnPJCHvNZuDG6BWjUFVxeWyYlve_SVJO>
- Code link: <https://github.com/codinginflow/react-best-practices/tree/custom-hook/src>

Avoid This Commonly Held Naive Perception Of Managers

Paper Reading Group: Attention Is All You Need

Generative AI, specifically large language models, have taken the world by storm. But they wouldn't exist today without a key paper published by Google Brain: "[Attention Is All You Need](https://arxiv.org/pdf/1706.03762.pdf)." The 10-page paper, published in 2017, introduced the Transformer - a critical innovation in neural networks.

**What's in store?**

- A deep dive and interactive discussion of the paper. We recommend reading (or at least skimming) it first: <https://arxiv.org/pdf/1706.03762.pdf>
- A look at what came before the paper (neural networks, embeddings), and what came after (BERT, GPT-2, and ChatGPT).
- **All software engineers welcome** - no AI/ML background necessary!

**Did you know?**

- The paper's authors have all gone on to found multiple billion-dollar AI companies including Cohere and [Character.ai](http://Character.ai).
- Since 2017, the paper has been cited over 86,000 times.
- The Transformer architecture is the **T** in "GPT".

**Your host:**

[Charlie Guo](https://www.linkedin.com/in/charlierguo/) is a seasoned founder and author with over 15 years of software experience and more than a decade in Silicon Valley. He is an alum of both Stanford and YCombinator, and currently publishes [Artificial Ignorance](https://www.ignorance.ai/about), an AI-focused newsletter for engineers and founders.

**The agenda:**

- Charlie will give a brief background, and then explain the key insights and context from the paper.
- We will open the group to some Q&A and a broader discussion.
- And we'll end with some discussion on which paper to read and review next.

The next paper reading group is on October 15 about [deep reinforcement learning](https://www.jointaro.com/event/paper-reading-group-human-level-control-through-deep-reinforcement-learning-deep-q-network/), led by Sai Bhavanasi.

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

21 Ways to Make Yourself a Better Engineer (From a Senior Engineer at Pinterest)

Join Taro and [**Jordan Cutler**](https://www.linkedin.com/in/jordancutler1/), a Senior Engineer at Pinterest and [**High Growth Engineer**](https://read.highgrowthengineer.com/) author to learn 21 rapid-fire ways to become a better engineer. You'll learn the top underused tips and skills to grow in your career.

We'll cover:

- Career growth
- Influence
- Communication
- Managing up
- Leading projects
- Technical skills
- Productivity

Be ready for practical and actionable advice. No BS included.

Helpful links: 

- [Slides](https://drive.google.com/file/d/1PEgnDJEa4wRw3bjxe22obyfP2qSm9lBB/view?usp=sharing)
- [Jordan on LinkedIn](https://www.linkedin.com/in/jordancutler1/)
- Jordan's newsletter with 68K+ subscribers: [High Growth Engineer](https://read.highgrowthengineer.com/)
- Jordan's course on Taro: [Become The Go-To Expert As A Software Engineer](https://www.jointaro.com/course/become-the-go-to-expert-as-a-software-engineer/)

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

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>

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

Part 4 [RBP] Clean Up Your Fetch Requests

This lesson focuses on preventing race conditions that can occur when making multiple fetch calls in React components, leading to inconsistent UI behavior and a poor user experience.

- **Identifying Race Conditions:** Understand how race conditions happen when asynchronous fetch requests resolve in an unexpected order, particularly with slow or unreliable network connections.
- **Strategies for Avoiding Race Conditions:** Learn how to use tools like SWR or React Query to manage fetch requests and automatically handle race conditions, or implement manual cleanup logic with an "ignore" flag to discard outdated responses.
- **Improving Code Structure:** Discover how to keep your fetch-related code organized and maintainable, especially when dealing with loading and error states, setting the stage for cleaner solutions covered in the next lesson.

Links:

- Florian’s free web development playlist on YouTube: <https://www.youtube.com/playlist?list=PLrnPJCHvNZuDG6BWjUFVxeWyYlve_SVJO>
- Code link: <https://github.com/codinginflow/react-best-practices/blob/fetch-cleanup/src/app/page.tsx>

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

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

What Exactly Is Big Tech?

While many people associate "Big Tech" with the largest household names in the industry, the definition can, and should, be broader. This lesson provides a useful lens for identifying companies that operate like Big Tech, even if they’re not part of the traditional FAANG group.

- **Traditional Big Tech**: Commonly refers to the largest companies by market cap - *Microsoft, Google, Amazon, Apple, and Meta*. Sometimes Netflix is included (as in “FAANG”), but it's structurally different, e.g. Netflix historically had no engineering levels and treated everyone as senior engineers.
- **Critique of the FAANG Acronym**: Netflix is singled out as not entirely representative of "Big Tech" norms, being smaller in scale and structurally more unique than the others.
- **Broader Definition**: Companies with *$50B+ market cap* and *2,500+ engineers*, along with similar performance expectations, leveling systems, and engineering culture as the Big Five, should also be considered Big Tech. This includes companies like *Uber, Airbnb, and Stripe*.
- **Why This Matters**: Focusing only on the top 5–6 companies can be limiting. Many other companies now offer equivalent opportunities in terms of compensation, growth potential, and engineering culture, especially as they reach scale.

This broader perspective is helpful when evaluating job options and team culture - not all Big Tech companies are the usual suspects.

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.

[Timeless Career Advice] What to Learn

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.

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