Learning A New Codebase? Here's How To Figure Out What Matters

- Learn how to blame the code (i.e. know who wrote each line of code)
- A lot of people don't realize that when it comes to big companies, there are huge swaths of the codebase where nobody really knows how they work
- When absorbing the codebase on a new team/stack, go through the various classes/files in your ecosystem, and use blame to understand the hotspots, the code that's been changed frequently and recently by people. Don't just try to understand the entire codebase straight up.
  - Use the test plans of connected commits/code reviews to better understand how to run the code and what it does
  - Maintain the system: This is another reason why *you* should have great test plans on your diffs/commits, so you can keep your team's codebase well-documented and easy to learn

Efficiency Tips for Engineers (From An AI Researcher/Stanford PhD/Ex-Meta Engineer)

[**Mo Tiwari**](https://www.linkedin.com/in/motiwari/) is an AI researcher, Stanford PhD, Facebook Software Engineer, DRW finance quant, and Caltech Math + Physics major 😳 🤯

The secret to his prodigious career: **ruthless efficiency**. Mo is able to achieve more per unit time than most of his peers.

This talk covers both behaviors and tactics to improve your ability to get things done. Sample topics:

- How and when to process email to minimize disruption.
- Best practices for calendar invites and scheduling
- Keyboard shortcuts that Mo uses dozens of times/day to save time

Download the slides here: <https://drive.google.com/file/d/1HET2AgDGeXA7Guhfq0IjaU53wY5AlsOE/view?usp=sharing>

Connect with Mo on LinkedIn: <https://www.linkedin.com/in/motiwari/>

Take the productivity course: [\[Course\] Maximize Your Productivity As A Software Engineer](https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/)

Making The BEST Case For Yourself In Performance Review: The Self Review

- Your self-review is the most important feedback for you come performance review season: Ignore the weirdness you may feel hyping yourself up and take it very seriously.
- The onus for representing yourself well falls mainly on you, not your manager or peers. Nobody knows you better than you. It's your job to make sure that none of your awesome achievements fall through the cracks.
- Start your self-review early and refine it across several iterations with your manager.
- Use [your brag journal](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/brag-journal/) to seed the self-review.
- Show the impact. Attach links to proof as much as you can (e.g. linking a dashboard with positive metrics to show that the project you launched added business value).

Related resources:

- ["How can I most effectively talk about my projects?"](https://www.jointaro.com/question/c0CDYi5VCRXz0gHHLiGP/how-can-i-most-effectively-talk-about-my-projects/)
- ["How to figure out what the most important projects are?"](https://www.jointaro.com/question/CgCPA60bDDHoOteN7Lmb/how-to-figure-out-what-the-most-important-projects-are/)

Don't Learn Code In This Way - How Software Engineers Waste Time

So many software engineers mess up when they're trying to learn code by bringing over a bad habit from school: Studying. This is simply not how software works, and this video's here to explain why.

Here are the core points:
- **Reading code and documentation is ineffective** - You can't purely read your way towards a good understanding of a codebase; it will get you 10-15% of the way tops. Software is fundamentally about doing - The actual learning begins when you jump in and start playing with the code. On top of all this, it's much better to get a high-level understanding of the codebase by asking your teammates for it instead of trying to infer it yourself from raw reading.
- **Documentation gets worse the better the company is** - Good software companies are fast-moving. This is a big reason why FAANG is successful: They are able to still move quickly despite their immense size. Because of this, documentation is rarely kept up to date due to how fast the codebase evolves. In fact, excessive reading of documentation may actively harm you if it contains legacy patterns that aren't accepted at your company anymore.

This clip is from our masterclass on how to succeed at a new team or company as a software engineer. You can watch it here: [[Masterclass] How To Succeed At A New Team Or Company As A Software Engineer](https://www.jointaro.com/lesson/n384HdJuDgulSHbHQLnf/masterclass-how-to-succeed-at-a-new-team-or-company-as-a-software-engineer/)

So now that you know how NOT to learn a codebase, here's some resources on how to actually learn a codebase:
- [How To Learn A New Codebase Fast](https://www.jointaro.com/lesson/DX27hiXPJ4G7Czk2mwLL/how-to-learn-a-new-codebase-fast/)
- [Learning A New Codebase? Here's How To Figure Out What Matters](https://www.jointaro.com/lesson/dQXKZNqivtoByEHV9V17/learning-a-new-codebase-heres-how-to-figure-out-what-matters/)
- ["How can I learn a large codebase fast as an intern?"](https://www.jointaro.com/question/F2rJZgdUBxdGZilFTR6k/how-can-i-learn-a-large-codebase-fast-as-an-intern/)

How To Learn A New Codebase Fast

What is the best way to learn a codebase?

True or false: In software, experimenting and making changes is cheap, so a great way to learn is by trying a lot of things and seeing what happens, even if you do not fully understand the overall codebase yet.

Why is structured learning like tutorials and courses not effective for actually learning a codebase?

True or false: Before you jump into a codebase, you should ideally get a certificate in that tech stack before working with it.

Which of these is a good way to learn a codebase with your first code changes within it?

True or false: Breaking something locally is an effective way to learn a codebase.

- The best way to learn a new codebase is to learn by doing.
- Don't get paralyzed reading documentation or getting a certificate before jumping into a codebase.
- Start tinkering ASAP. It doesn't matter if you don't fully understand the codebase - Just do small changes like deleting a line or flipping a variable and then see what happens after you build the code.
- Alex's standard: Put out a commit/pull request for a new codebase within 2 days.
- You want to get code into review as soon as possible, because the feedback you get on your pull request is where the real learning happens. Don't worry about the quality; it's going to be bad in the beginning like with any newbie - The important thing is that you submit something out there into the world so your teammates can tell you how to get better.

Related resources:
- [How To Figure Out Which Parts Of A Codebase Matter](https://link.jointaro.com/PdpWBjAzU7NVTamf6)
- [Learning A New Codebase Fast As An Intern](https://link.jointaro.com/SMaLvqCVeoH9MmvV7)

Make Sure To Do This To Get Full Credit For Your Work

On top of doing the work, what else do you need to do in order to get full credit for what you are doing?

True or false: It is bad to give more public status updates for your project as it will come across as looking for attention.

Why should you not feel icky when you are properly broadcasting the status of your project?

Core points:
- *You don't get credit automatically for doing good work, especially if you work in a large company.*
- It is vital that you bring visibility to your work and claim credit for jobs well done in project updates, meetings, and other more public avenues.
- You may feel "icky" for sharing status updates - Don't! If your work is truly important, than it's worth sharing about and keeping the team in the loop. If you don't feel like your work is important, then you have a separate problem you need to address.
- Use project updates to thank others! Treat it as a mechanism to build social capital.

Related resources on how to write concise, impressive project updates:
- ["How can a painfully introverted person increase their visibility and promote themselves?"](https://link.jointaro.com/3XHsUifABjyN3Tq98) - From a SWE intern at Google
- ["How to get more visibility on work?"](https://link.jointaro.com/aQUHxnsNAJVcRgth6) - From a junior engineer [E3] at Meta

[Masterclass] How To Come Up With 100k+ Users App Ideas You Can Build For Free

Start with a simple side project and keep iterating on it to separate your side project from the rest.

Related resources:
- [[Masterclass] How To Build And Grow Tech Products To 500k+ Users For Free](https://www.jointaro.com/lesson/OEuX0KMhcnNSTJ50Voee/masterclass-how-to-build-and-grow-tech-products-to-500k-users-for-free/)
- [How Alex Made An App That Got 80k+ Users In 1 Month](https://www.jointaro.com/lesson/GlSjjLhuUdHt5drq3l5F/how-alex-made-an-app-that-got-80k-users-in-1-month/)
- ["Finding a mobile app idea - How to do it?"](https://www.jointaro.com/question/KJ4VXh6rUhKbWeiJoRDe/finding-a-mobile-app-idea-how-to-do-it/)
- ["What are some of the side income or passive income sources you can suggest?"](https://www.jointaro.com/question/URhejS9m02tEFM9WLZsd/what-are-some-of-the-side-income-or-passive-income-sources-you-can-suggest/)
- [Presentation Slides](https://docs.google.com/presentation/d/1ai8lxU1B-bH35iiSFf5hvk6NjAHpUyF2rshjyDipvaY/edit?usp=sharing)

System Design Series: Taro Playlists [Part 2] - Sharing The Context

Core points from the video:

- Weak organizations will have product and engineering be incredibly siloed. It is far more effective when product managers and engineers work very closely together. Meta in particular has seen a lot of success by having this harmonious culture.
  - This means that software engineers should also understand why they are building something and not purely be responsible for implementation.
  - Software engineers should have an opinion on the product and work with their PMs to optimize vision and direction.
- A master spec should also have the context behind the "why" of a product and not only contain technical details.
  - The product details will often live in a separate document called a PRD (Product Requirements Document). In this scenario, you should link it in your technical spec and maybe have a paragraph summary of its contents as well.
- Capture any existing context that will affect how you build your system. This will often means that there's components that are already around in your company's ecosystem that you need to build on top of - This scenario is extremely common when building projects in Big Tech.
- Attach visual aides if you can (images, videos, gifs): It makes it far easier for project stakeholders to grok the information.
- **Context behind Taro playlists:**
  - One of the most requested feature within Taro
  - Think of it as being similar to YouTube playlists
  - We have already shipped a read-only version of playlists

For the full system design doc, you can get it by [becoming a Taro Premium member](https://www.jointaro.com/membership).

DSA Crash Course [Part 1] - Course Welcome

Welcome to our crash course for data structures and algorithms! This incredibly in-depth course will help you master core data structures and algorithms concepts, even if you're a complete beginner with the topic. This course is exactly for you if:

- You want to be efficient with your study time
- You don't enjoy solely grinding LeetCode because it's slow and frustrating
- You want to actually understand the concepts instead of merely memorizing patterns

This course is special because it's carefully engineered to be a smooth and effective ride:

- Problems are specifically chosen to be a progressive sequence, building on top of one another
- The overall difficulty of the problems you'll solve will gradually increase
- You will be able to visualize the underlying data structures and algorithms with animated explanations
- Learn the implementation with concrete code walkthroughs

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

Strategies To Stop Procrastination

Procrastination: We all become masters of it in school, and for almost all of it, this terrible habit will continue long into our careers. This video covers how you can combat procrastination and maximize your work productivity.

Here are the key points from the video:

- Break down your overall goal into smaller pieces and strive to do just 1-2 pieces of it per day.
- Write things down! Clarity leads to action.
- After every week, reflect on how you spent your time.
- Find an accountability partner. Pair with someone else and commit to sharing progress updates with one another every single day. This social pressure will motivate you to do work as you don't want to be the person going into that meeting with no progress.
- Introspect and ask yourself if you're truly excited about the thing you're doing. If you're not, you might need to find that true passion.

Related resources:

- [\[Masterclass\] How To Manage Your Time Optimally In Tech And Achieve More Results](https://www.jointaro.com/lesson/rnX9EKpzc43TgGW9MozG/how-to-manage-your-time-optimally-in-tech-and-achieve-more-results-792021/) 
- [A Powerful Tool For Software Engineer Productivity - Focus Blocks](https://www.jointaro.com/lesson/uGdn2AiDfn3B07FkpIVR/a-powerful-tool-for-software-engineer-productivity-focus-blocks/)
- ["How do I optimize my sacred hour at work?"](https://www.jointaro.com/question/l8dzUVTu99CahofQsYAi/how-do-i-optimize-my-sacred-hour-at-work/)

How To Build Work Relationships Faster - Giving Deeper Thanks

If you want to build work relationships efficiently and effectively network in general, it's vital to master the art of giving thanks and showing gratitude.

Here are the core points from the video:
- **Giving thanks is a skill** - Don't just send a cookie-cutter 1 sentence thanks over DM after someone helps you: It's very soulless and takes you almost 0 time to write. Helping someone out with their work performance is one of the most high-impact ways you can add value to their lives; you should respond in kind when you receive this help. Some basic tactics to "level up" your thanks is to send a heartfelt paragraph and to thank them in person, either through a video call or actually in-person if you're physically coworking.
- **Thank teammates via their manager** - This is especially true at a high-performance tech company like FAANG where so much of the engineering culture revolves around performance review. If someone goes above and beyond helping you, make sure to let their manager know. If they're a recurring helper, you can even tell their manager that you deeply believe that this altruistic behavior should be rewarded in their performance review: When the helper hears this from their manager, they will *really* value you as a teammate and know that their efforts have truly been rewarded.
- **Thank publicly** - This adds more weight to your gratitude and also acts as an artifact to help out the other person during performance review.
- **Recurring thanks** - There's no reason why you can't thank someone multiple times for the same thing. Alex had a mentee who was really good at doing this: They would be very thankful on the initial unblock, and after the full project finished, they would thank the helper again (i.e. *"I just shipped this project, and it wouldn't have been possible if you didn't help me on X"*).

Related resources:
- [Effective Communication Guide [Part 3.1] - The Power Of Thanks](https://www.jointaro.com/lesson/noWZaoGWlrYQxX2Vhigd/effective-communication-guide-part-31-the-power-of-thanks/)
- [Don't Waste Your 1 on 1s. Build The Relationship](https://www.jointaro.com/lesson/wcFrGc53iHzbWh0Ssw1j/dont-waste-your-1-on-1s-build-the-relationship/)

Once You Get This, You Will Be Able To Fix Any Software Bug

The foundation for debugging and just getting software as a whole is understanding the end-to-end flow. This is a mental framework that can be applied to any language and any stack, even if you have never worked on it before.

For most of you, you're working with something like this:

1. The client sends an API call to the back-end
2. The server receives the request and parses out the model
3. The server queries the database for the appropriate data
4. The server returns the data in a formatted JSON response
5. The client receives the response and parses it
6. The client translates the models into UI and renders it

Once you figure out what steps are necessary for the flow you're debugging, you can systematically go through them one-by-one until you identify which one is breaking.

Related resources:

- [\[Case Study\] Solving A Multi-Million $$ Instagram Bug](https://www.jointaro.com/lesson/WYk4J05iBqOuPtD0CYKX/case-study-solving-a-multi-million-dollardollar-instagram-bug/)
- ["How can I become more independent and better at unblocking myself with tricky technical issues?"](https://www.jointaro.com/question/QhqQQGrDgFjZbqohpKe0/how-can-i-become-more-independent-and-better-at-unblocking-myself-with-tricky-technical-issues/)
- ["How can I root cause bugs faster?"](https://www.jointaro.com/question/PSv7aYI70VwaDsoRgMyW/how-can-i-root-cause-bugs-faster/)

[Case Study] Becoming A Tech Lead Again In Just 1 Month After Joining Robinhood From Meta

- The expectations for an L5+ (senior+ at a FAANG or similar company) engineer are high. You won't get 12 months or even 6 months to fully onboard: You need to start having huge impact and showing your depth within 1-2 months.
- After starting, Alex told his managers that he was happy to offload any responsibilities they had so they could focus on higher-level issues and expand their scope. As a tech lead, you need to view your manager as a partner, not just a boss. "Treat me as a resource."
- The project that Alex was first put on was to make settings more server-driven within Robinhood
- The most impactful thing to do was to add color to the project:
  - Stabilize and then drive the workstream meetings
  - Create a thorough tech spec
  - Align XFN to figure out how to treat each settings section properly, especially in places where there were inconsistencies
- How Alex added his depth:
  - Wrote a 5+ page Android spec for his portion
  - Manually audited all of settings and compiled a detailed spreadsheet of inconsistencies to fully capture impact
  - Thorough data analysis spec, doing complicated SQL queries himself
  - Mentored an L4 engineer in the process, giving them L5 scope
- Recap (how you can incorporate the learnings here into your work):
  - Earn trust quickly: Be "aggressively" nice. Find out how you can add value to others and be very sincere and upfront about it.
  - Fill in the gaps: View your projects holistically and figure out what's missing to move the project forward. This will often times be "less flashy" non-coding work.
  - Bring people together: Don't be paralyzed by your lack of knowledge. Especially if you're new to a company, you will be clueless in a lot of scenarios. If you're in a cutting edge company like Meta/Robinhood, there will be a smart person(s) somewhere out there with the answer: You just need to bring them together in a healthy way.
  - Go deep: There's far more to a senior engineer than their ability to code. If you're a new L5+ engineer, even the tenured L3/L4s at the company will code circles around you in the beginning. If you're an L5+ engineer, figure out what behaviors and fundamentals you have that more junior engineers don't and show those as much as you can. This generally involves shipping software in a much more holistic way.

Related resources:
- [Presentation slides](https://docs.google.com/presentation/d/1j5Lj_IGrtCRUpobj0f8k9egrBAej9apzikGp_V_iTCk/edit?usp=sharing)

Use Code Review Feedback For Hypergrowth - Meta Prodigy Engineer Story

As a junior software engineer, one of the main ways you're going to grow is through feedback on your code review. Because of this, it's vital that you get the maximum value from code review feedback.

Here are the core points from the video:
- **Respond quickly and with appreciation** - Be thankful of good code review feedback, and try to respond to code review comments within 1 to 4 hours. Don't be defensive when it comes to code review feedback.
- **Don't make the same mistake twice** - Take the time to really understand and absorb the feedback: Don't just make the suggested change. If you don't understand the principles behind some feedback on your code, just ask! [Here's our in-depth advice on how to really not forget code review feedback](https://link.jointaro.com/7wjo6DcDcJmxDVYB9).
- **Alex's mentee prodigy story** - Alex had a Meta mentee who was able to grow from junior [E3] to senior [E5] in just 2 years. A big part of this was their incredible code velocity:
  - This mentee really nailed learning from code review feedback. Their initial commits were a bit messy, but they quickly got to a point where they stopped making mistakes.
  - They were also very meticulous about their pull request quality. They always had very thorough summaries alongside very complete test plans. For more complicated commits, they would have up to 5 videos walking through every case.
  - After 1 half, this engineer was writing almost 500 commits a half, making them the #1 code committer in the entire organization. This was largely because their stellar code quality and code review learning allowed them to land their pull requests on the very first try 90%+ of the time.

This highlight is from our masterclass on "How To Write Better Code Faster As A Software Engineer". [Click here to watch it.](https://link.jointaro.com/v6zEgUfQTxoSj33Z7)

Related resources:
- [Quick Tips To Get Higher Quality Code Reviews Faster](https://link.jointaro.com/dE4U41RAVtZKLhxJ7)
- [Avoid These Junior Engineer Mistakes With Code Review](https://link.jointaro.com/agkYrLH8uuCv4UcPA)
- [Code Review MUST Be Fast, Otherwise The Team Is Unhealthy](https://link.jointaro.com/oxK55E1bkX8nMeNGA)

How Big Tech Judges Interview Performance Differently

What is the main extra axis that Big Tech companies will grade interview candidates on?

As long as you get a correct, optimal solution, that is enough to pass a Big Tech interview round.

Why is communication so important in Big Tech companies?

True or false: Big Tech companies don't really care about what specific technologies and programming languages you have worked with.

What's the core high-level asset Big Tech interviewers look for?

- At a lot of companies, you can just get the right solution and pass. This will often not be the case with Big Tech interviews.
- Communication is much more important at Big Tech companies as there's more stakeholders on everything
- Try not to be silent for 5+ minutes at a time during the interview. Regularly be explaining your thought process
- Massive companies like Meta and Microsoft will have very custom technology, so it doesn't really matter what you're currently experienced in
  - Because of this, Big Tech companies generally let you code in whatever language you want
- It's possible to get the sub-optimal solution or a slightly incomplete solution and still pass the interview if your communication is very strong

Related resources:
- [[Masterclass] How To Ace Your Big Tech Interview - Data Structures And Algorithms](https://www.jointaro.com/lesson/V4sTACzfOh22nMVcUV3w/masterclass-how-to-ace-your-big-tech-interview-data-structures-and-algorithms/) - The video this clip was taken from
- [Alex's Guide To Effective Communication](https://www.jointaro.com/playlist/hVdLQQzfslaYarLSCmmy/)
- [[Masterclass] How To Ace Your Big Tech Interview - System Design](https://www.jointaro.com/lesson/J3I9fTW9ulr6T9KjxpqY/masterclass-how-to-ace-your-big-tech-interview-system-design/)
- [How Alex Got Into Meta With 0 Prior LeetCode Experience](https://www.jointaro.com/lesson/ZYiTbN21FsqFxFdpwt5a/how-alex-got-into-meta-with-0-prior-leetcode-experience/)

Creating A Portfolio That Makes Recruiters Come To You

Building a personal portfolio looks nice and feels good, but it *rarely* helps engineers find jobs. In this video, we cover how you can truly stand out as a software engineer and make the jobs come to you (instead of the other way around).

Here are the core points:
- Building a portfolio website can be a nice exercise, but don't spend too much time on it. *Don't expect to get any inbound recruiter reach outs due to your portfolio site*. There is no real central repository of them that recruiters browse.
- In terms of what recruiters do browse, it's primarily LinkedIn. If you have this portfolio energy, it's much better spent polishing your LinkedIn profile instead.
- At the end of the day, a portfolio website is resume++. This means that your foundation is still your resume: Make sure your resume is *extremely* sharp before you even consider building a portfolio website.
- Alex found a lot of success having his Google Play developer page be a portfolio as it hosted real, verifiable products on it. Since his side projects got millions of installs combined, he's gotten reach outs from top companies like Uber, Square, and Instacart through his Google Play developer email.

Related resources:
- ["What technologies or stacks should I create a project to add in my resume for entry level software jobs?"](https://www.jointaro.com/question/c0DiG5ureLbkZ1mKD9Rf/what-technologies-or-stacks-should-i-create-a-project-to-add-in-my-resume-for-entry-level-software-jobs/)
- ["I want to land a job in a big tech as a SWE - How to do it?"](https://www.jointaro.com/question/MWJfUBnnUr8CKYFCO8bp/i-want-to-land-a-job-in-a-big-tech-as-a-swe-how-to-do-it/)
- ["Can Github stars grab big tech recruiters' attention?"](https://www.jointaro.com/question/XaUn4XuIBMSmrr5fcHIT/can-github-stars-grab-big-tech-recruiters-attention/)

Junior Engineers, Avoid This Fake Growth Trap

What's the main change in expectations when growing into senior engineering levels?

True or false: Hustling (i.e. working extremely hard) is a common, healthy way to get promoted.

Why is it bad if you are able to get promoted to senior levels through sheer ultra-hard work and very high raw productivity?

- A lot of earlier-in-career engineers believe that being a better software engineer is all about coding: If you can write more good code faster, then you are growing.
- This is generally mostly true in the beginning, but then it quickly becomes a toxic way of perceiving growth.
- You will hit walls. There are only so many hours in a day, and you can only type so many lines of code per hour.
- As a senior engineer, you need to focus on multiplicative and deeper behaviors.
- If you are able to have the impact of a senior engineer but are working extremely long hours, you are essentially "faking" the appearance of a senior engineer. This working model is not sustainable, and once you burn out, it's a terrible situation for everyone.

How To Properly Learn To Code As A Software Engineer - Do The Simple Thing First

Software engineers are obsessed with using the most modern framework in pursuit of the best code. Ironically, this dogma leads to them writing terrible code.

Here's the core points:

- **Do the simple thing first** - When picking up a stack, use the most basic framework. If possible, don't use a framework at all. By starting with the primitive setup, you will understand its limitations. This means that when you move up to modern frameworks and libraries, you will truly understand the problems they are trying to solve, allowing them to use them properly.
- **You can't "cheat" advanced code understanding** - You can't jump straight to the cutting-edge tech. These abstractions are powerful for a reason: They are naturally complex and require a deep understanding of the overall stack to use. When you try to "skip to the end", you will write bad code. The most terrible code comes from more junior software engineers trying to be smart prematurely with "modern architecture".

Related resources:

- [\[Course\] Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)
- [\[Course\] System Design Masterclass: Shipping Real Features To Production](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

[Masterclass] How To Manage Your Time Optimally In Tech And Achieve More Results

Ever wondered what separates software engineers at FAANG and top startups from the rest? One of the big reasons is their ability to manage their time well to supercharge their productivity. At the end of the day, how hard you work and how naturally talented you may be aren't relevant if you aren't able to use your time efficiently.

Here are our Top 5 points from this masterclass (in no particular order):
- **Focus on just 1 thing** - Have a goal for every single work day. Make it more concrete by writing it down. Humans are naturally bad at multi-tasking; narrowing everything on your plate to a single task brings clarity which leads to action.
- **Break things down** - By decomposing big projects into smaller and smaller sub-tasks, you are making it more digestible and actionable. This is an especially important skill for more senior engineers and tech leads as they will need to take in huge problems and split them up into smaller chunks to delegate to others. How good a software engineer is at this is a key attribute of their seniority.
- **Move your phone out of arm's reach** - Modern-day smart phones are great, but they are also super-effective distraction machines. Relying on raw self-will to resist checking your phone every 5 minutes is overrated and often ineffective. Introduce that extra friction.
- **Find an accountability partner** - Humans are a social species, so we naturally don't want to let others down. Peer pressure is some of the most effective pressure there is and finding someone who you care about and is counting on you is often more powerful than any collection of time management tactics (including the ones in this masterclass).
- **Get consistent sleep and exercise** - Software engineers in particular will claim that they "don't have enough time" to do these. Sacrificing sleep and exercise is the classic mistake of getting a short-term gain with huge sacrifices in long-term value. These 2 things are activities you *make* time for. Get ~8 hours of sleep each day and do ~30 minutes of exercise 3-5 times a week. After a few weeks/month, you will see a huge boost in your energy and mental clarity from doing these.

Related resources:
- [Strategies To Stop Procrastination](https://www.jointaro.com/lesson/90PJpQEWVdVK47yh6IiB/strategies-to-stop-procrastination/)
- ["How do I optimize my sacred hour at work?"](https://www.jointaro.com/question/l8dzUVTu99CahofQsYAi/how-do-i-optimize-my-sacred-hour-at-work/)
- [Presentation Slides](https://docs.google.com/presentation/d/1MCEx7X592VfvdWlFi4JrhSffiDIeNyc1FsqDJMy8hvI/edit?usp=sharing)

How To Earn Respect Fast - Senior Engineer Onboarding Story

Even if you're onboarding, you can earn respect amongst your team. In fact, you should feel empowered to earn this respect despite being new, especially if you're a senior software engineer.

Here are the core points from the video:
- **Help junior engineers** - This is one of the most effective ways to earn respect on a team as a more experienced engineer. The junior engineers may be more fluent in the code than you are, but if you're a senior+ engineer, there is a reason you have this level: You have certain fundamentals and instincts that are applicable everywhere that junior engineers don't really have.
- **Show your depth** - You won't win with velocity and output when you're new. However, you can win with depth and quality as that's largely a function of your effort and time. If you're a more experienced engineer, think about how you can go deeper into something than everyone else on the team.
- **Alex's senior engineer onboarding story** - Here's how a senior Android engineer quickly made a splash after joining Alex's team back at Instagram.
  - They saw a junior engineer struggling with a very complex text layout bug with the Instagram Android app.
  - They volunteered to help with this bug, even though they didn't have to.
  - After many failed debugging attempts, *they slowly extracted the relevant code line by line into an entirely separate Android app to identify the breaking line*. This was a brilliant tactic that nobody else on the team even remotely considered.
  - This combination of goodwill and extreme software engineering depth earned them a mountain of respect pretty much immediately.

This clip is from our masterclass on how to succeed at a new team or company as a software engineer. [Click here to watch the full thing.](https://link.jointaro.com/9sJzfDeH3JdWzZRg9)

Related resources:
- ["How can I quickly gain respect among my team as a senior engineer?"](https://link.jointaro.com/i9j4dtohx2bXc2Sq8)
- ["How do you network effectively within a company?"](https://link.jointaro.com/Hr1nr53D7sfQAEv3A)

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.