The BEST Software Engineers Avoid This Learning Trap

Hi! I’m Rahul, a software engineer and founder with a passion for teaching.

#TechCareerGrowth

[raghuram_bhogireddy]

This talk hit me hard. I often feel miserable that I couldn't able to get grip on the code base in the initial days. But this talk has changed my perception towards looking at code. Thanks for this great eye opener... 😀

[bobkameron]

Hey this video was great. I currently started my first dev job at Amazon as a career changer and this is definitely relevant. I've found it's just really helpful to have just a general idea/overview of the packages/ services that your team owns, interfaces of dependencies/ clients, etc... then knowing this I can dive deeper into more relevant parts of the codebase fast to make some impact.

However, as a self taught engineer I have found that trying to achieve mastery when learning software fundamentals (DSA, software design/ architecture, etc) is really helpful for interviews and on the job. Like to the point of being able to explain core algorithms or concepts like abstraction, modularity, testing paradigms, etc to someone without a technical background has really helped me triage bugs/ issues faster and communicate them effectively with various stakeholders (devs, QA, PMs, etc).

[HanyunGong]

Both skills are important for software engineering. The ability to abstract helps you navigate through complexity whereas mastery usually leads to sound and robust architecture. mastery is often the pre-requisite for solving a technically challenging problem or bug.

[HL-uwfk]

One trick pony never ends up well, I know so many talented SWE’s that are so much behind in career because they tried to be the best in one thing and every job requires you to know 10 technologies in parallel and it is impossible to get to know them all to the core.. you said it well, agreed!

[Mate-mate]

I think we can apply the same principal to our life as well. Acknowledge that we can’t master everything in this life so leverage other people’s talent and skills to do your job. Also, in order to leverage other people’s skill you need to be good at articulating your problem to other people.

[mockingbird]

Initially, I had panic attacks from not knowing the abstractions as a student. My paranoia would be if I was assigned a ticket as an engineer. I don't know how an internal library is built (for example, fancy operator overloadings in the case of C++, the working mechanism of an API, etc.). I couldn't be able to get the job done (since, most of the time, I don't understand the API codebase itself due to the complexities and abstractions involved *within* that codebase). I would eventually get fired for low performance or fear being seen as a *dumb* guy who doesn't know how the code works by my senior engineers.

It took me too long to let go and learn to work with the abstractions without figuring out every detail of how the API is built.

Thank you for this fantastic video, Rahul! Helped me settle my paranoia a little bit.

[skyhappy]

It's hard being a developer when I want to learn how everything works 😩. I had the same experience with a assignment this past semester. I wasted too much time trying to understand the starter code.

[ggnore]

Man I wish this was talked about more. I've always felt so lost during my work experiences because I felt that I knew nothing about our ecosystem since I didn't understand how every part of our program worked

[aakarshan]

I think mastery still exists.. it just shifted from understanding the whole workings of the codebase to understanding the evolution of codebase towards a specific direction. I feel its like seeing a Turing machine abstraction in every programming language... we don't need to know the implementation of a language to abstract turing computation out of it and develop algorithms which are independent of languages.
Amazing video, especially when you mentioned about not getting overwhelmed by the whole codebase and figuring out meaningful abstractions and building on top of them!

[gauravaws]

This is wonderful advice @Rahul. I've struggled with this forever and this has been one of the sources of my imposter syndrome. I always use to think I need to know everything and was always trying to catch-up. If there is anything that has hurted me more its the mastery mindset. The truth is because of the sheer breadth and depth of everything it is very hard to master anything these days. Thanks for sharing your mental models. I wish I had access to this kind of content when I started out 15 years ago.

[twistedlog]

This hit home for me. I’ve struggled with this throughout my career.
Thanks Rahul

[janzenzarzoso]

Once again, an incredible and useful content Rahul. Thank you for sharing your thoughts! As I was taking down notes it resonated with me when you said that one of the goals of an engineer is to "Get things done". I've been to situations where I went into rabbit hole trying to learn everything and not getting things done. If I may add to your wealth of wisdom here, there are times when you do want to dig a bit deeper on some topic and it depends on your personal goals as well. If you want to be a master of something then I'd say it's a good secondary goal but don't diverge on the primary goal to "get things done" this is why in our company we have a day of research and development we call Jog days to dig in deeper on things you are interested in by not affecting the team's goal.

Thanks Rahul from NZ. 🙏

[hlinc]

Mastery of core concepts is good. But nobody can learn everything. The ability to get things working by leaning on good abstractions is essential, but so as the ability to dive deep through the layers of abstractions at specific points when necessary.

[wadecodez]

The problem you described for large code bases is true, unfortunately, a lot of senior devs have a difficulties explaining this concept to young developers. The problem escalates when the code is old and there are a lack of tests. It's a vicious cycle. Junior devs become overwhelmed then senior devs encourage them to master their skills more as a result the junior devs become more overwhelmed.

[spiritual]

wow, that a great advice on abstraction as junior engineer i always tend to get lost.

[ampersignia]

Many coding bootcamps tout “mastery learning” approach and that sounded important to me as a newbie with no context other than what they say is in the course syllabus. It’s nice to hear the opposite opinion from an experienced SWE or manager/founder.

[Kanal]

In my opinion the key is learning concepts and improving your skill to generally understand new things fast. Tools and code change all the time, principles of good engineering mostly stay the same.

[brunodosreis]

The benefits of mastery rub off on how fast you learn other things. But approaching EVERY endeavor with a mastery mindset is counterproductive.

People who experienced a long mastery journey develop a lot of skills and approaches that people with traditional learning backgrounds have not. As a result they learn more ways than just the “right” way to do something.

On a mastery learning path you are incentivized to look at a roadblock from different perspectives, models and approaches until you find one that helps get past it. After a while this becomes a habit and you are a lot less intimidated by roadblocks in other parts of life as well. It also helps with understanding people: colleagues, superiors, subordinates and competitors.

[HanyunGong]

The ability to abstract indicates mastership.
Knowing how the entire system works in a abstrct manner helps making the right choices when making small changes.
Practically, especically in FB, modules are far from being perfectly encapsulated; knowing just the module you are working on can introduce tech-debt in the long run.

[MADMAX]

This is the biggest mental I have to struggle with.. I HAVE to understand the core fundamentals, and can't live with just adding patches here and there, and hoping everything will work just fine. 😪