Watch the full interview between Grant and Sal: kzfaq.info/get/bejne/iaeYftKZx5vJj6s.html Check out Taro, the app I'm developing to upskill software engineers: jointaro.com/

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

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

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.

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!

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.

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.

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

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.

Mastery is geared toward academia, not industry. That’s my overall outlook

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.

I’m facing a similar issue and I’m so glad that you’re shedding light on this important topic. I have felt stuck due to the onus of knowing enough to make an impact. Downloaded the app. Really looking forward to it. Thank you for taking on this great endeavor of helping the community and all the best Rahul and team Taro! :)

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

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!

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.

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

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.

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

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

great point. thank you!

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.

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.

agreed, although depending on the role, level of abstraction one is working at, diving deep to achieve mastery might make sense (like optimising some very inner details to improve performance of a service )

very insightful. thanks fr sharing

This is so relatable. Thanks a lot man.

Rahul as always, thank you so much for this video. I joined a financial company (AMEX,VISA,MasterCard) on the software side. So much dependency code-base between teams, intertwined. I gave up truly understand how it works honestly, I just master 2-3 repos that are relevant to the task that are assigned to me :) Sometimes when i want to understand something i need to get access to the specific repo and contact the person from the team etc. To add on, certain companies are people centric in terms of knowledge, where documentations are not up-to-date, so is extremely hard to understand the in and outs quickly without working for long in the company.

man! this hits close to home!

Oh my! I run into burnout just because of lack of mastery. And I didn’t know it was that until I watched the video

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.

Great one!

Did Kahn just imply middle school math is worthless? As someone who did Algebra 1 in 6th grade, I completely agree.

Basically, trust the API contracts. You'll not fix Stripe's API if it's giving status code 500 from their side.

I think in some parts I resonate with your opinions and some part I don't. Abstraction is more of mandatory skills now days where you need to ok with not knowing some part of codebase. But mastery learning is more about trying to learn and getting better at your craft. Sal refers to example of achieving 80/100 and then slowing trying to understand where you lack and then get 90/100 and so on.

Thanks for this tip, Sir!

Fantastic advice that will serve you well. I'd just add one caveat to temper Rahul's take. Don't fall into a second trap, which might be to think that mastery is bad in all scenarios, outside of software engineering. And don't use Rahul's advice as an excuse for not reviewing something that you know you should. The practice of achieving mastery in one area (that last 20% is full of plateaus and takes FOREVER) is the keystone of human civilization and can be a source of real personal fulfilment.

6:40 I have a counter point. What if we dive into project, ask for feedback but then learn the changes made is all wrong or testing is expensive? Teams will find any reason to pip or demote these days

I have downloaded the Taro app. But I am not getting what you're trying to build as it only contains videos which can be uploaded on KZfaq, so why built a separate app for that. Is there something specific planned that we will be seeing in future?

5:52 I need to work on bigger teams. Often, I'm completely on my own.

Sir You don’t even know how helpful you are I have joined Booz Allen hamilton 4 months ago as backend engineer and I have been trying to master codebase written in Java but unfortunately I always get things done late and I even use my weekend sometimes to finish task.my life has been miserable and I feel like I am not getting impact. Most of my colleagues are moving pretty. I don’t really think about abstraction to just trust the api and build things in top of it. I always want to understand how the API was built instead of understanding how API works and then just trust it and build things in top of it. I think you recommandation is valid. I just need to focus on a specific section I am working in the codebase and become really good at it. Thanks so much

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.

Ok, so as a software engineer, who decided, have to do BSc in computer science now from a university, who's admission requirement is to know pre-cal, I had to go to khan academy and start my maths from Algebra, cause I forgot all that. But, I am/will be breezing through it, as I already did that before, just that I forgot it. Also, the concept, that I should not get overwhelmed when joining new company is really good. For most part, when I joined a new company, I cared about my work only, but soon, I got very overwhelmed that I had to quit my job after some months :( But yeah, that was a learning lesson for me. Thanks 4 the video

Thanks Rahul. Can you make a video on what to do in first 60 days of joining a new company as a Software Engineer?

This video couldn't have come at a better time. Thanks a lot Rahul for this great video.

Great Advice

I am a big fan of mastery learning. But I now do see a flaw. I am on my first internship right now and have been facing similar problem. Great content.

Valuable content. It makes a lot of sense.

Mastery of coding/ computer language/ tools and mastery of a code-base are two different things. The former is necessary and the latter is not.

I really like your videos Rahul, I find them very helpful, I see your channel as a prospect for subscription ;)

Been there, done that. Stuff should be marked w.r.t abstraction level.

Thanks for the reminder to not to be a perfectionist. I agree totally. It hurt me big time in many phases of my career to not start until I understood everything 😛

Pareto the shit out of everything. Mastery learning is not the right way because with 20% of the knowledge you get 80% of the results. This applies to most industries. Mastery learning is just a manifestation of human instinct for perfectionism

I get the gist; however don't you think it's helpful to rather than avoid mastery and force trust, it'd be must better to master the abstraction techniques (layering, design patterns, rollback frameworks, microservice architectures) used widely and cultivate that trust? It then becomes a skill of zooming in and out and knowing what to make a BlackBox.

Thanks, your guidance is quite valuable. Keep making videos on such topics

As a self taught coder, this was a key lesson that I was "lazy" enough to adopt early on. Whenever I approached something new I'd ask myself 2 questions 1) is this interesting and 2) is this critical? Generally speaking I'd prioritize mastery of those that fit both criteria 1st and abstraction for all other combinations. Many things are interesting and so you want to dive in but unless it's critical for a project you're working on, you won't have enough of a working knowledge to truly master it so no need to waste the effort. Of its critical but not interesting, chances are you can partner with someone who can say yes to both questions and deliver that component of the work.

Mastery learning is not different from traditional learning. Rather, it builds up on the foundation laid out by traditional learning. Mastery learning goes beyond the traditional learning and only beyond. You have to understand the subject with traditional learning, but, instead of just going on and leaving the "20%" of the content unclear, you should, then, use mastery learning to catch up with the 20%. Mastery learning does not require you to understand everything right from the beginning; that's just a wrong way of learning anyway because you are not going to learning anything there. For example, in learning physics, mastery leanring asks you to explain how electronegativity is related to reaction, but it will not require you to know how an atom has charge in the first place.

This is the best channel for engineers who are already in a big tech company. I love the app as well. Please keep uploading, Rahul!

Better than an elephant a Country analogy makes more sense, say a country like the US has different states each are managed by different teams but all combined contribute to the country.

I disagree with the point that it's completely inapplicable. We an apply mastery learning to some parts like the fundamentals. Aka. we should know our programming language well enough to code in it. We should learn data structures and algorithms and master them to land a job and like such. Like that. Fundamentals I think are good. In terms of the code base I think I completely agree. I recently got a friend and we worked on a coding project together. He did his part well and I did my part well. We didn't need to know each other's code in order to make a good final product.

Staring at the hindquarters of the elephant... "hmmm, aha, I see! This opening here is where food goes! This is where the system accepts input! Oh wow! Somebody get this thing a mint!"

But what about training a non software engineer to become a software engineer. Is mastery based learning still bad?

Now is Leetcode better treated as traditional or mastery learning? I argue it's probably mastery, though I'd like to hear what others think.

thanks for the best advice, sir. This gives me a boost.

In your second anecdote about facebook you're bringing up the point that you couldn't get something done until you got some guidance, which is somewhat contradictory to the point of the video. You're saying that someone who understands the bigger picture (and has "mastered" that portion of code) guided you through it. Actually come to think of it, your first anecdote is a moot point as well, since if you probably went back and re-read some of the boilerplate of the assignment you'd probably understand more of it, much like Sal Khan described. I posit that an engineer that cares about leveling up as an independent contributor (becoming senior engineer etc) will care about mastery learning, whereas an engineer that cares more about the bigger picture (becoming manager, cto) will be satisfied by traditional learning. I think your advice is to prescriptive and biased for a managerial career track, and I think there's a false dichotomy between the two learning types, and a good engineer will employ both.

Even in mathematics, mastery pertains more to academic learning. The parallel in sofware would be mastery of computer science. Math doesn't have something like an engineered codebase. Maybe the closest thing is a proof crafted by a mathematician.

Can make a video on your opinion on TDD and BDD and if there are any other approaches to development? Please?

Man can you make a video for people who are in different fields and is trying be a SWE, but has no coding experience, how to approach it? Like from ground level. I am in a customer success role in big tech and want to switch into Swe

Hey Rahul, quick question. Do you think Udacity nanodegree is worth it? I know a lot abt Android. Done ur projects from course but they have extra projects to do. I can do them in a month, which will be $400. Worth it? What do you think? Thanks so much for your time!!!!!

Great video. Can relate to it. "Facebook is the most complicated app in the world"; not really though. Wait until you see GmsCore, GoogleMaps, KZfaq etc! Entirely different level of complexity :)

5:10 gonna play devils advocate and say but true understanding(mastery) helps to create the innovative solutions, and long term memory for the subject. What was learned for compiler im sure was still useful in its own way even if it was less hands on development time. Also companies appreciate solutions that specialists and mastery provides.

Hi Rahul, Is 512 GB SSD & 16 GB RAM ENOUGH FOR ANDROID DEVELOPMENT ? OR NEED I MORE ? KINDLY HELP

I think mastery learning is important in software engineering. I disagree with your interpretation that mastery learning implies trying to see the whole elephant. In my mind mastery learning implies seeing some of elephant with totally clarity. To put it another way mastering reading does not imply you must read everything. It means you must be able to read the language. If you have a surface level understanding of a topic, say docker, you’re gonna be screwed trying to debug a pipeline.

Hi there Rahul great content love your videos. I had a request can you make a video on how would the transition of a java android developer be to an kotlin android developer.

What is the job market for fresher like people less than 2 year of work experience..?? Do you get high paying job if you are not from faang

Very helpful content ☺️

Unfortunately, interviews are making us to do exactly Mastery in every topic. And if you don't know some particular themes well (those use can learn in 30 minutes with Google search) you may be rejected just because "it shows your understanding and knowledge", ignoring all the rest you know and able. Just my personal pain, never mind.

Here is my 2 cents: 1. Engineers at IC3 level r given feedback to master the code base so that they can be considered for IC4 level. I have seen umpteen number of times including HR questioning that as they do not have the mastery how can they be at IC4.

I think this concept of learning would good to be applied in Computer Science and not Software Engineering

Man, if I went and tried to read all the code in all the services my team owns, I would never get any work done lol

I am totally Aggry with you Rahul sir

I feel like this is a more obscure example, whereas the skill of learning how to program in the first place is more comparable to what Khan is actually talking about. In that case, you absolutely should master the fundamentals of programming before tackling more advanced problems.

I thought I was dumb for not knowing what different parts of the codebase did

best video

It is ideal if you can trust the surrounding code and just need to care about your part to implement. Sadly, there are projects messed up so badly that you can't trust all layers from the gui to the database ... and there is some bug to fix and no-one knows what it should exactly do. In such case, you can choose between burning out mastering the nightmare app or quit the job (which I did, after going through nightmare first). That is the scenario where you can't really apply the point of this video, because nothing will work. On the other hand, if it is suitable to master the application, and be author of a lot of code in it, it can save a ton of time in general and you can quite well estimate time needed and need less time int the end. If I am not master of the app, I would rather always double or tripple the estimates, depends on how good or bad the app is written. Also fixing the bugs may require you to master some parts of the app... otherwise you will not find the root cause and doing ugly hacky fixes are first steps to hell (they may still not work or break randomly again or make others not to believe your code - loosing additional time) But I agree that it is good to distinguish between mastery of the app and the programming language.

You know I find this worldview to be quite interesting, as it is in opposition to the idea that you should try to become a master at your craft. You can see in this talk (kzfaq.info/get/bejne/mMBmo6RekqyXdGg.html) how Jonathan Blow feels that by abstracting away everything, we're losing the ability as a civilization, to have strong control over low level implementation. I understand that when there are deadlines and stuff, we have to triage. But if the general advice given to software devs is to not think about low level details, and in fact not attempt to gain mastery by attempting to understand stuff that's outside of your immediate domain of responsibility, what do you think that leads to, on a larger scale. Also I find it funny that even though you advise us not to worry about mastery, you clearly have internalized the habit of trying to master your craft, as mentioned by your college experiences. So even though you think its best not to strive for mastery, do you think it is precisely this habit, that has made you an excellent engineer? Here's another youtuber, Hussain Nasser, that appears to be an excellent engineer (to me at least), that holds an opposing viewpoint. (kzfaq.info/get/bejne/bNSclN19xN_Me2g.html) He is literally saying that what has made him a great engineer, is his desire to eliminate all blackboxes, and understand everything he uses. I know its a bit much to ask, but as a self-taught dev who pretty much only has youtube channels like these to guide myself in the right direction, I would love to hear your thoughts!

Rahul's idea is really worth pondering but there's also a contrary view from John Carmack - kzfaq.info/get/bejne/j7WKodSbrdG5fJc.html I believe figuring out which abstractions are worth diving deeper into (like common ones like scheduling logic, async programming model under the hood, and so on) is an art to gain productivity. In contrast, some business logic or huge apps can be abstracted by just understanding relevant or conflicting feature-set logic. But in this case, one needs to know the next likely bottleneck in your application, and understand design tenents driving certain software choices but doesn't need to read and understand the whole codebase.

Collab with Garry tan

I think you are taking things out of context by a very large margin.