15 SWE Years In 1.5 Hours [Part 2] - Learning How To Code

In order to become a software engineer, you need to learn how to code. This lesson teaches you:

- The optimal way to use tutorials
- Why tutorials can easily start *hurting* your learning progression
- The dubious value of books when it comes to learning how to code
- An incredibly effective and altruistic way to truly learn technical material

Follow the advice here to understand any new codebase fast: ["What is the effective way to understand new repository in order to make the required changes in that repo?"](https://www.jointaro.com/question/KoxB3UU2zWC9pdYU6Rx0/what-is-the-effective-way-to-understand-new-repository-in-order-to-make-the-required-changes-in-that-repo/)

How To NOT Learn A Codebase

The biggest mistake engineers make when going into a new codebase is to excessively read through the code and documentation. This is a horrible way to learn. 

The problem is exacerbated because the supporting documentation of the code is usually out-of-date: the docs can't keep up in a fast-moving tech company.

Instead, just dig in and start coding!

- Break things
- Add all the print statements ever
- Get the debugger working
- Run the code and see what happens

The key takeaway is that you should **get your hands on the keyboard** (even if it's uncomfortable).

The Common Misconception With Help

When you're new, there's an overwhelming amount of information to absorb. You should plan to ask many, many questions, which means it's important to have the right framing of that interaction.

Obligatory Confucious quote:

> The man who asks a question is a fool for a minute, the man who does not ask is a fool for life

Myth #1:

- **Myth**: Asking for help is a sign of weakness ❌
- **Reality**: You’re expected to ask questions to gain knowledge and foster interaction ✅

Myth #2: 

- **Myth**: Everyone knows so much more than me, I’ll waste their time ❌
- **Reality**: Each person’s knowledge is incomplete ✅

Instead of thinking that building expertise in something is difficult or impossible, realize that **you can become more knowledgeable than anyone** as long as you narrow the scope appropriately. (e.g. "In one afternoon, I can go understand more about the flags to configure **git log** compared to anyone on my team of 10 people.")

Being New Is A Superpower

Instead of treating your newness as a liability, view it as a superpower.

- Nobody wants to be mean to the new person, so you have the perfect excuse to request resources aggressively.
- You can observe problems with the codebase, processes, or tools that tenured employees have learned to tolerate.
- You can connect the dots between different teams or ideas that would be harder for people entrenched in their roles.

Approach your onboarding with the urgency that "**You will never have fresh eyes again**."

As the most clueless person, if you revamp a resource (wiki, code, etc) to be easy to understand for yourself, you are making it easy for **everyone** to understand.

Level Up Your Code Quality As A Software Engineer [Part 26] - Side Projects & Open-Source

You don't need to work at some fancy FAANG company to learn how to write truly good, high-quality code. Code quality is something that can be improved upon outside of your job and even if you don't have a job! This lesson will teach you:

- The power of **side projects** and **open-source contributions** when it comes to leveling up your technical skills
- How to build side projects that get a ton of users so you can maximize your learning (and your resume strength 💪)
- How to make meaningful open-source contributions that can even get the attention of Big Tech companies

To dig deeper into this topic, go through this thread: ["How to Learn/Practice Clean Code, particularly by oneself?"](https://www.jointaro.com/question/6DcTkiS9UJhDkQz1HIAL/how-to-learnpractice-clean-code-particularly-by-oneself/)

Level Up Your Code Quality As A Software Engineer [Part 16] - One Diff, One Thesis

One of the biggest and easiest ways to level up your code doesn't even lie in the code itself and is about how you split it up when submitting it for code review instead. This lesson will teach you:

- The most common way low-performing software engineers mess up their code when submitting it for review
- Why championing the concept of "One Diff, One Thesis" massively boosts your productivity alongside your code quality
- How to tell whether your pull request follows the principal of "One Diff, One Thesis" or should be broken up into smaller pull requests instead
- How to split up your technical task or project into chunks, so you can map out its pieces to a series of pull requests following "One Diff, One Thesis". We do this with an in-depth example further digging into the login flow

Did You Just Get Laid Off? This Is How You Should Think About It

Getting laid off is rough and a huge blow to your mental state. This video covers how to have the proper mentality if you are laid off, so you can bounce back.

Here are the core points:
- **Being laid off is not a reflection of who you are** - Who gets cuts in a mass layoff is effectively random, and incredible software engineers will get hit by them all the time. *There is absolutely nothing wrong with you if you get laid off.* Don't let some out-of-touch tech executive's bad decision determine your self-worth.
- **You *will* recover** - This is especially true in the tech industry where severance packages tend to be quite competitive, even generous. Use the time to really process what happened, find peace, and figure out your next move. The silver lining of being laid off is that the door has started opening to your next opportunity: You just need to walk through it.

Related resources:
- ["Aftermath of layoffs?"](https://www.jointaro.com/question/7Gav09HFuLlGDlM749UY/aftermath-of-layoffs/)
- ["How open should we be to recruiters about employment status?"](https://www.jointaro.com/question/Lo8W7fMRFbcwUQ9WyTVF/how-open-should-we-be-to-recruiters-about-employment-status/)

System Design Series: Taro Playlists [Part 3] - Defining The Requirements

You can [find the full system design doc here](https://docs.google.com/document/d/15WaM8Ojan82g0m2mtz6kC2Hiyj0Q6VbjfqRmVNDI3qw/edit?usp=sharing) - Feel free to use it as a template for when you're designing systems at your job!

The concrete details are covered in the doc linked above, so this summary will focus on the "meta" context behind this part and additional commentary:

- It's very important for engineers to clearly understand the requirements of the product as they need to build them.
  - A common failure mode is that the proposed requirements aren't technically feasible. It's important for engineers to call this out as early as possible, which is why it's a valuable exercise for them to really lay out in the requirements in their system design doc and overall process.
  - Very senior product managers may give broad strokes in terms of what the product should do. Another reason why this exercise helps engineers is that it's actually up to them to convert the high-level points from their PM into very concrete features and requirements.
- "Jobs to be done" is a mental framework championed by Kevin Systrom, the co-founder and initial CEO of Instagram. The idea is that every product is "employed" by users to do a certain "job" in their life. This is a very important thing to understand about a product and clarifying this serves as an intermediary step towards creating concrete requirements.
- Something that's missing from this document are designs - This is because Taro has no dedicated design support at this stage. At a more mature company (which you almost certainly work at as the viewer), you would have designs at this stage in the document (it can be its own section). For front-end products, you need to put pixels on screen at the end of the day, so it's crucial for engineers to have designs to really understand the requirements and provide concrete feedback.

Effective Communication Guide [Part 6] - Communicating In A Remote World

- What is lost in a remote work environment when it comes to communication?
  - **Volume:** A lot of ad-hoc communication ("water cooler chats") can't happen anymore.
  - **Depth of presence:** When you're on a video call, it's mainly just your face that's visible. In an in-person meeting, especially 1 on 1 meetings, your entire body is visible, which lets you express a lot more via your body language.
- **If you're comfortable, have video on during calls** - Use your facial expressions to really show that you're listening and truly hearing what the other person or people have to say.
- **Book 1 on 1s very aggressively** - 1 on 1 meetings are the core building block behind strong relationships. In an in-person environment, you will build relationships naturally through other means like team lunch, but since those are lost in a remote environment, you need to lean on 1 on 1s far more.
- **Get really good at technical writing** - In a remote world, especially with teams distributed across multiple time zones, a lot more communication has to happen asynchronously.
  - Project updates are very important in particular. It's much harder to stay aligned when everyone is apart.
  - If you aren't already, try to write a project update for your work every 2 weeks or more.

[Masterclass] Understanding And Optimizing Your Pay In Tech

Related resources:
- ["If my main goal is compensation, would it be wise to learn blockchain tech since it will potentially be the tech of the next couple decades?"](https://www.jointaro.com/question/tyS6MzzADqBzt10802Mh/if-my-main-goal-is-compensation-would-it-be-wise-to-learn-blockchain-tech-since-it-will-potentially-be-the-tech-of-the-next-couple-decades/)
- ["How do people in Big Tech deal with constantly fluctuating Stock Prices from their company?"](https://www.jointaro.com/question/JhEDkJl8AexlsL4IXBOH/how-do-people-in-big-tech-deal-with-constantly-fluctuating-stock-prices-from-their-company/)
- [[Taro Top 10] Pay Negotiation](https://www.jointaro.com/playlist/uyWSc5q79zFw2Ei7w59d/)
- [Presentation Slides](https://docs.google.com/presentation/d/1MdJrfT-wBDI6p-3z2_4rNY8IJwlvj1X7n3E5bmYajFU/edit?usp=sharing)

Quick Tips To Get Higher Quality Code Reviews Faster

In this segment, we focus on how to **ramp up effectively and build trust through proactive code review habits**. By learning from past diffs, referencing previous work, and anticipating reviewer questions, we strengthen both our code and our relationships with teammates.

### Key Takeaways:

- **We study past code reviews to ramp up faster**: Reviewing recent diffs helps us identify codebase hotspots and learn how experienced teammates structure context, write test plans, and address feedback.
- **We reference prior diffs to preempt questions**: When making similar changes, we compare our approach to earlier ones (especially from tech leads) and explain why we took a different route—saving reviewers from needing to ask.
- **We proactively comment on our own code**: By flagging areas we’re unsure about and inviting feedback up front (e.g., naming choices or design alternatives), we guide reviewers toward the most relevant parts and show that we care about quality and collaboration.
- **We show respect for reviewer input**: Code review isn’t just about getting approval—it’s about listening. Ignoring thoughtful feedback undermines trust. We strive to acknowledge and incorporate suggestions to create a positive, team-first review culture.
- **We demonstrate maturity through initiative**: These habits—referencing historical context, asking for help, and valuing reviewer input—aren’t just tactical. They signal leadership and self-awareness, accelerating our growth and reputation on the team.

What The Optimal Discussion On Code Review Looks Like

In this video, we explore the **spectrum of code review discussions**, highlighting what kinds of conversations are appropriate—and which are not—for an effective and healthy code review process. We emphasize that great code reviews live in the middle: technical, constructive, and context-rich.

### Key Takeaways:

- **We avoid extremes on the code review spectrum**: Debates about architecture or product behavior should happen *before* the code is written. On the other end, trivial nitpicks like formatting should be automated with linters—not left to human reviewers.
- **We aim for meaningful middle-ground discussions**: The best code reviews focus on topics like naming clarity, input assumptions, and logic validation—things that improve understanding and code quality without being overly granular.
- **We talk about testing and future-proofing**: We use code review to validate testing strategies and anticipate how upcoming features or changes might interact with the current code—enabling forward-thinking design.
- **We reduce unnecessary friction with agreed standards**: By aligning on style conventions and automating formatting checks, we free up our code reviews to focus on higher-order thinking and shared learning.
- **We use code review to transfer experience and context**: A reviewer’s knowledge of future plans or broader system behavior adds lasting value. These discussions aren’t just about code—they’re how we build team wisdom.

Manager 1 on 1s Are A Litmus Test For Seniority

True or false: In tech, operating at senior levels means that you are driving more, if not most, of the conversation in your manager 1 on 1s.

Why do senior employees tend to drive more of the conversation in manager 1 on 1 meetings?

One-on-one meetings evolve as career levels advance. A key sign of professional growth is taking ownership of these conversations and using them to drive impact.

- **Initiative reflects seniority**: If recent one-on-ones are led primarily by a manager with direction and feedback, it's likely an early-career dynamic. As experience grows, the expectation shifts toward independently setting priorities.
- **Ownership of agenda is critical**: A senior-level contributor brings a clear agenda to one-on-ones, proactively using the time to align on strategy, surface blockers, or present ideas—not just receive instructions.
- **Setting direction is the goal**: Defining one’s own work and outlining what to focus on next are hallmarks of operating at a senior level. The more someone guides the conversation, the more they demonstrate leadership and self-management.

20 Years Of Fighting Procrastination [Part 3] - Build A System

Most people rely on fluctuating willpower to be productive—but the most effective creators use systems. Here are the core points from the lesson:

- Systems make good behavior automatic by reducing cognitive load and accounting for natural fluctuations in willpower, energy, and focus
- Structure your day around your strengths—use mornings for disciplined deep work, afternoons for accountability-based tasks, and evenings for creative exploration
- Focus on generating artifacts like notes, calendar blocks, or test plans to capture progress, clarify your thinking, and preserve valuable context
- Habit stacking and predefined triggers make consistent output easier and help you avoid relying on short-term motivation or memory

Master The DSA Interview [Part 2] - The Key To Truly Learning DSA

One of the biggest mistakes software engineers make is memorizing content instead of actually understanding the concepts. This lesson teaches you:

- How to learn data structures and algorithms properly instead of merely doing rote memorizations
- What it looks like to truly master a data structures and algorithms problem, shown with an in-depth example
- Common patterns to remember with data structures and algorithms

Ace Your Tech Interview As A Software Engineer [Part 6] - Having The Right Mentality

A lot of software engineers actually have all the necessary skills to pass the interview - They just choke when the time finally comes. Why is that? Well, let's dive into why. This video teaches you:

- The terrible unhealthy mentality software engineers often have going into tough tech interviews, particularly with top companies like FAANG
- What mentality you should have instead to unlock your full potential and why it's hard to ascend to this level of mental clarity
- How having the right mentality greatly improves your interview performance, far more than any amount of preparation ever can

Level Up Your Code Quality As A Software Engineer [Part 17] - Share The Context

Software engineers often have this flaw where they assume that everyone somehow automatically knows what they're doing and the nuances of the spare they're operating within. This often extends to their published pull requests. This lesson will teach you:

- The ingredients behind a high-quality context section on a pull request
- A simple tactic to greatly expedite your pull requests, build respect amongst your team, and get better feedback (hint: It's not just your teammates who can review your code)
- Exactly what a stellar context section looks like with an incredibly detailed, broken down example. This is a trademark sign of high-performing mid-level and senior software engineers

[Masterclass] How To Stop Writing Messy Code As A Software Engineer

It's 10x easier to write messy code instead of good, clean code. The hard part is that unless you have good role models, it's extremely difficult to learn how to write quality code. If you're a software engineer going through this struggle, this masterclass is for you.

Here are the core points from the video:
- **There's no such thing as objectively "clean" code** - A lot of engineers treat code quality as something to "solve" where after they learn the best tech stack/database/framework, they can just plug that in everywhere and win. That's simply not how software works. The reason why writing truly great code is hard is because it's all about the context and nuance. Code that's good in one codebase can be horrible in another.
- **It's all about the user experience (UX)** - At the end of the day, the end-user doesn't care about your code quality. Most end-users have never read a single line of code in their life. The end-user simply wants a good UX, which means that if you need to write code that's a little messy to uphold good UX, you should do that.
- **Feel the pain of your bad code** - True learning comes from struggle, and if you really want to stop writing messy code, you need to see your own code break and struggle. Go outside of the happy flow and dogfood your own products and features aggressively. Read your old code every once in a while and see how horrible it was - If you groan then, that's a good sign of growth.
- **Break down your tasks** - A marquee trait of bad software engineers is that they jump straight into the coding, write a gigantic messy commit, and get demolished in code review. To prevent that, proactively decompose your tasks into smaller ones where each one is ideally 1-3 commits or a few days of work. This lets you come up with an actual plan for the task and invite your teammates' feedback at an earlier stage in development (i.e. before you write much or any code). For an in-depth guide on software decomposition, check out the discussion here: ["How do I make software less overwhelming?"](https://www.jointaro.com/question/YseMPDw538jhyS1MWlTs/how-do-i-make-software-less-overwhelming/)
- **Write clean pull requests (PRs)** - It doesn't matter if the code in your PR is bad as long as it's "dressed" well and optimized for your teammates to leave good feedback (which will make your code good!). Write atomic commits, have a real PR title, attach a thorough context section + test plan, and proactively call out tricky areas. Learn how to do all that with the following video and its related resources: [One Diff, One Thesis - What Every Code Review Should Be Like](https://www.jointaro.com/lesson/3NAbmgiaY3IpvayNIoVl/one-diff-one-thesis-what-every-code-review-should-be-like/)

Related resources:
- ["How to Learn/Practice Clean Code, particularly by oneself?"](https://www.jointaro.com/question/6DcTkiS9UJhDkQz1HIAL/how-to-learnpractice-clean-code-particularly-by-oneself/)
- ["How to upskill effectively, especially with the software design aspect?"](https://www.jointaro.com/question/JALOyWIOCo7UXIMLlUz3/how-to-upskill-effectively-especially-with-the-software-design-aspect/)
- [[Masterclass] How To Write Better Code Faster As A Software Engineer](https://www.jointaro.com/lesson/iYpRj8XfyzCSaTYnce3y/masterclass-how-to-write-better-code-faster-as-a-software-engineer/)
- [[Masterclass] How To Do Amazing Code Review](https://www.jointaro.com/lesson/rhRFh49oouaUDhWUvkQb/masterclass-how-to-do-amazing-code-review/)
- [Presentation slides](https://docs.google.com/presentation/d/106NsN9Z9QNvZR_-LMaiVu2rT8Kro_4YwXS44j-rNLXk/edit?usp=sharing)

How One Of FAANG's Biggest Upsides Becomes A Terrible Downside - Peer Pressure

A big reason engineers go to FAANG is to learn from the brilliant talent there. However, this benefit is very much a double-edged sword.

Here are the core points from the video:
- **Big Tech is very competitive** - You will be compared to your peers, many of whom will be better and more productive than you are. Most Big Tech companies make this competition explicit by having stack ranking where the bottom 5-15% of engineers are fired or PIPed every performance cycle. This means that if you're not superior to enough of your peers, your job is in danger.
- There are many side effects to this environment:
  - **Imposter syndrome** - Imposter syndrome is rampant at Big Tech where everyone is so insanely smart and hard-working.
  - **Anxiety and fear** - Being a low performer at Big Tech sucks and is almost always extremely stressful. A lot of engineers here spend a ton of time worrying about being at the bottom.
  - **Poor work-life balance** - You will be pushed by your peers to excel. Many of them will also be overachievers who work late, pushing you to do the same.

Related resources:
- ["How does Stack Ranking work (at FAANG) and how can I be proactive at a base level?"](https://www.jointaro.com/question/lScy3l2NPIrWvRuHOjcF/how-does-stack-ranking-work-at-faang-and-how-can-i-be-proactive-at-a-base-level/)
- ["How do you deal with zero-sum situations where one's success comes at the expense of another?"](https://www.jointaro.com/question/wDZ2LC0AzujhbOOBs43m/how-do-you-deal-with-zero-sum-situations-where-ones-success-comes-at-the-expense-of-another/)
- ["How do you push back against a PIP when it doesn't feel fully justified?"](https://www.jointaro.com/question/4fLz0VmshEouTzQl2Iuc/how-do-you-push-back-against-a-pip-when-it-doesnt-feel-fully-justified/)

How To Find A Tech Company That's Less Likely To Do Layoffs

In a bull market like the one from 2014 - 2021, everyone's a genius. While you could work more or less anywhere before and get a couple solid years of career growth, that's not the case anymore. This video covers how you can choose a company that's less likely to do a mass layoff.

Here are the core points:
- **Prioritize profitable companies** - If the company is publicly traded, this is shared in every earnings reports and is easily Googled (i.e. "Is company X profitable?"). A good business needs more money coming in than going out, and companies with fundamentals like these will always be rewarded.
- **Make sure the company is hiring carefully** - The easiest way for a tech company to take on too many costs is by hiring people it doesn't need. If the interview process is too easy or the company is trying to 10x its headcount every year, that's generally a bad sign.
- **Leverage your network** - We all have people who are much smarter than we are within our network, and this is very prevalent in the tech industry. If the best and brightest in your network (i.e. those who really do their homework before accepting an offer) are going to specific companies, there's a good chance those companies have real legs.

Related resources:
- ["Insensitive to talk about applying to a company which has suffered from layoffs?"](https://www.jointaro.com/question/LH6CCgWMUAVEAHKDDUWc/insensitive-to-talk-about-applying-to-a-company-which-has-suffered-from-layoffs/)
- ["Staying motivated among lay-offs?"](https://www.jointaro.com/question/EEMkoCSNPzdRToTHjuSb/staying-motivated-among-lay-offs/)

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.