[Timeless Career Advice] Promos and Relationships

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.

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>

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

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

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

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>

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

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 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 Effectively Do Big Tech Engineers Perform In Startups?

In this lesson we talk about how engineers from big tech companies perform when transitioning to startups, and what hiring managers should look for when bringing in FAANG talent.

- **The sweet spot is 2-6 years of big tech experience** — engineers in this range bring the best of both worlds: they've been screened for talent and learned strong software engineering fundamentals at top companies, but haven't spent so long there that they've become rigid in their thinking or problem-framing approaches that may not apply in a startup environment.
- **Very senior big tech hires often struggle with the transition** — engineers who've spent many years at large companies can develop highly specific ways of doing things that don't translate well to startup constraints, making cultural and operational fit more challenging despite their technical depth.
- **Big tech experience becomes an asset when there's a specific scaling need** — senior hires excel when the startup has a concrete problem that matches their domain expertise, such as building infrastructure for massive consumer scale or managing rapidly exploding engineering teams, where their direct experience from companies like Facebook becomes immediately applicable.

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.

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.

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

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

[Timeless Career Advice] What to Learn

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

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>

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