The BEST Software Engineers Avoid This Learning Trap
Вставка
- Опубліковано 24 лип 2024
- 📱 Accelerate your career growth: joinTaro.com
Interview between Grant Sanderson (@3blue1brown) and Sal Khan (@khanacademy): • Sal Khan: Beyond Khan ... . Trying to "master" a codebase is usually NOT what you should do as a software engineer.
➤ Pass your coding interviews (use code Taro for a discount): neetcode.io/pro?
➤ Advanced coding exercises, build-your-own-X (40% off): app.codecrafters.io/join?via=...
💌 Join our mailing list: email.jointaro.com/
➤ Connect with Alex: / alexander-chiou
Hi! I’m Rahul, a software engineer and founder with a passion for teaching.
📹 UA-cam: / rahulpandeyrkp
📝 LinkedIn: / rpandey1234
🐦 Twitter: / rpandey1234
📸 Instagram: / rpandey1234
📂 Github: github.com/rpandey1234/
🎥 My UA-cam Camera Gear - kit.co/rpandey1234/my-youtube...
#TechCareerGrowth
Watch the full interview between Grant and Sal: ua-cam.com/video/SAhKohb5e_w/v-deo.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).
Great point. Always good to have mastery over the fundamentals since they're, well, fundamentals :P
Sometimes knowing what is a fundamental vs something which *can* be glossed over is the hard part.
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.
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
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.
This hit home for me. I’ve struggled with this throughout my career.
Thanks Rahul
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.
Great point 👍🏽
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!
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. 🙏
I love the concept of a jog day, haven't heard that before!
@@RahulPandeyrkp It's probably called differently in different teams/company. It's a day in between the end of a sprint and the start of a new one. It's a day out of the ordinary focussed sprints (which consists of work-specific objectives) intended for non-sprint related tasks e.g. research, learn a new tech, administrative tasks, etc. Hence, it's called a jog day. 😉
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! :)
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.
if you want to know how everything works - I think you'd better be an engineer (software engineer, why not)
@@sergeymatpoc Is there a industry wide licensing process like in the mechanical and civil engineering fields which makes you a certified software engineer?
@@skyhappy in two words - there's no such thing as "licensing process" for artists or creators of any kind. Just because you can't "license" any sort of engineering or other creative field. You can license non-creative fields like plumbing, administering and many other low-level jobs (drivers, electricians, technicians). But engineering is about development, mindset growth, continuous education, social skills and, I'd say, brand development as well.
BTW, there's the least requirement for engineers as well, bachelor's degree for example.
@@sergeymatpoc Not sure if you know - mechanical and civil engineers have widely accepted licensing processes to be called engineers. They do exams and need certain years of experience. A bachelor's degree varies wildly, a random uni is different from MIT.
@@skyhappy could you please provide some examples? I really don't think these engineers require any special certificates to work.
And yes, I told about bachelor degree as a baseline, not against that, but degree doesn't give a real understanding of knowledge level, because, you know, every education is different, and assessment level varies widely.
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.
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!
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
)
Agreed
wow, that a great advice on abstraction as junior engineer i always tend to get lost.
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.
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.
I remember writing emails to open-source engineers who I look up to for help with the anxiety attack I was going through when I tried to work on beginner level issue tickets for various FOSS projects that I really love and care about, and I couldn't even get started since there is just so much code and written in an idiomatic fashion tuned for more experienced developers. But I did learn important lessons from those movements.
I'm sorry you had panic attacks- all engineers have to struggle through imposter syndrome and feeling constantly stuck. Glad you're in a better position now!
great point. thank you!
Mastery is geared toward academia, not industry. That’s my overall outlook
need different levels of each depending on the domain
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
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.
People holding all the knowledge in their head (and not in a wiki or documentation) happens more than it should :/
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. 😪
Let go of that compulsion, you'll get a lot more done in a large codebase
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.
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
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.
very insightful. thanks fr sharing
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 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.
right, mastery learning is absolutely essential for much of education, but is not a pre-requisite for having impact
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.
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.
Facebook (and most other fast moving tech companies) will have leaky abstractions. So it's always a judgement call to understand how much you need to pull back the covers
Basically, trust the API contracts. You'll not fix Stripe's API if it's giving status code 500 from their side.
This is so relatable. Thanks a lot man.
5:52 I need to work on bigger teams. Often, I'm completely on my own.
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
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.
man! this hits close to home!
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.
Thanks Vivek! Also check this video I just made about internships: ua-cam.com/video/o4OQvIkRQrk/v-deo.html
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 UA-cam, so why built a separate app for that. Is there something specific planned that we will be seeing in future?
We're building a Q&A product which we plan to release in the coming weeks
Great one!
Thanks Kunal!!
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.
That strategy makes a lot of sense
This video couldn't have come at a better time. Thanks a lot Rahul for this great video.
Thanks Ajit!
Been there, done that.
Stuff should be marked w.r.t abstraction level.
Thanks for this tip, Sir!
Thanks Rahul. Can you make a video on what to do in first 60 days of joining a new company as a Software Engineer?
on my list!
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.
I like the re-framing of a different type of mastery: not of the code, but of the abstraction patterns.
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 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.
Couldn't agree more
Great point. An engineer should have enough confidence (mastery) in the basics of the language that they could go into any part of the codebase and figure it out with enough time..
Understanding Docker is a bit different though. If every engineer has to deeply understand Docker to get things done, that feels like an issue.
@@shoumikghosal to peel back abstraction layers as and when needed without trying to understand whole mammoth system is the toughest skill to acquire as a software engineer
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!
thanks Irteza!
Thanks, your guidance is quite valuable.
Keep making videos on such topics
thank you!
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.
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.
Great analogy, the math world is enormous
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 😛
same! that's why I wanted to share this perspective, that this is fairly normal
Can make a video on your opinion on TDD and BDD and if there are any other approaches to development? Please?
BDD is new for me, I'll have to understand it myself :P
Did Kahn just imply middle school math is worthless? As someone who did Algebra 1 in 6th grade, I completely agree.
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.
For leetcode I'd suggest mastery. You want to explain in depth how an algorithm or code works.
But what about training a non software engineer to become a software engineer. Is mastery based learning still bad?
in general, bias toward building; that's how software engineers are made
I really like your videos Rahul, I find them very helpful, I see your channel as a prospect for subscription ;)
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.
There's so much value in having experts, no denying that. In fact, even as a junior engineer, I'd rather you become an expert in a relatively small area where I can fully trust you, rather than being mediocre in a bunch of areas.
We talk about that here: link.jointaro.com/N13zVPMrkBJNU9LC7
Valuable content. It makes a lot of sense.
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.
Hey can you please explain what is this IC you are talking about 🙂
@@rj27thug78 I believe IC stands for Individual Contributor which is your normal software engineer. I guess for promotion you have to master the code base and that is something they consider
Why would HR ask that they don't know anything about code
@@skyhappy Typically in any Promotions especially from IC3 to IC4, they look at how much Engineer has Mastery? HR job is to question the manager. They can't evaluate.
HR being very involved in promotion doesn't seem very good to me 🤔 but in general, I'd expect mastery over *something*, but the scope of the mastery may be smaller if the eng is more junior
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.
I have a lecture series about Android dev with Kotlin that might be helpful. And I have one video in particular about transitioning to Kotlin
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
Which company/location?
@@RahulPandeyrkp Microsoft - USA (Remote)
@@ridufly4531 could you start a project with a software engineer who could then refer you?
@@RahulPandeyrkp Seems like a great idea, thanks Rahul.
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!"
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.
Thanks for sharing your perspective. It's definitely not a binary distinction between learning with breadth or depth.
I took it as a suggestion for new engineers trying to get up to speed and productive in a new system as efficiently as possible. But beyond that, I fully agree that senior ICs (and above) really NEED to develop mastery of at least one area. Ideally an area that no one else on the team has already mastered, to help round out the collective expertise that the team has on tap. The trick, of course, is being able to dedicate the necessary time to this before new story assignments force you to switch gears completely.
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.
thanks for the best advice, sir. This gives me a boost.
my pleasure!
Great video. Can relate to it.
"Facebook is the most complicated app in the world"; not really though.
Wait until you see GmsCore, GoogleMaps, UA-cam etc! Entirely different level of complexity :)
What's GMS? The web indexing and search framework?
Great Advice
I think this concept of learning would good to be applied in Computer Science and not Software Engineering
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.
agreed that fundamentals require deep understanding
where do you draw that line between fundamentals and the rest?
@@azamatsarkytbayev9451 Let me tell you where I drew the line for myself.
For me I am interested in android development. So for me fundamentals = kotlin, java, OOP, algorithms.
I learnt Java and Kotlin from UA-cam. I learnt android development from Rahul's course. I learnt algorithms from Stanford university online materials.
(Trust me if I can do it as a graduate from high school in a third world country, you can do it too! I believe in you!)
The rest is like "creating a button in android studio". I don't have it memorized but I can google it and cut and paste some code to make it happen. It's not fundamental CS concepts, but it's easily accessible through the internet and Googling. So whatever would take some research, is not fundamental to me.
I hope that makes sense to you and you can use it as advice for your own software engineering journey.
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.
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.
interviews are unfortunately very different from the day job of software engineers
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
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!!!!!
In general, I advise not to get any credential unless you know that it will lead to better job outcomes. Working at Pinterest and Facebook, having something like a Udacity Nanodegree never made a difference in whether we hired someone or not. But if a company you like says you have a better shot with it, $400 is not too much to spend.
@@RahulPandeyrkp thank you! They offered 70% off. $120 a month. Going to finish the projects they have and apply. Thank you for taking the time to reply! Appreciate it a lot!!!
Hi Rahul,
Is 512 GB SSD & 16 GB RAM ENOUGH FOR ANDROID DEVELOPMENT ? OR NEED I MORE ?
KINDLY HELP
Yep
@@RahulPandeyrkp thanks :)
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 made some futile attempts at reading all the code early on in my career :P
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
Just focus on following good people
@@RahulPandeyrkp yup following people like you :)
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.
Great perspective. At FB there was a big push to having clear code ownership, so if there was a bug or abstraction gap, it would (hopefully) be clear who is the right point of contact.
@@RahulPandeyrkp That is good. We have lost the original authors and inherited the two projects from them. Kind of bad management decisions in place. Also they thought that everyone should be able to do anything anywhere ... naive trend these days in some bigger companies. :-)
I thought I was dumb for not knowing what different parts of the codebase did
Not at all!
Very helpful content ☺️
thank you!!
I am totally Aggry with you Rahul sir
😭 why??
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 (ua-cam.com/video/bZ6pA--F3D4/v-deo.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. (ua-cam.com/video/6nlazL_yhK4/v-deo.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!
That's a very thoughtful analysis. Mastery learning certainly has its place, but that place is not when you start a job.
One way to resolve the tension here is to acknowledge that there's a time for mastery learning, and there's a time for making use of the tools available to you (even if you don't fully understand them).
- If you just bought a Udemy course, presumably you have the time and energy to dive deep into a topic and
"master" it.
- If you just switched to a new job a month ago, I'd argue that your time is best spent landing impact. Focus on squashing bugs, implementing features, and delivering business value. Mastery learning does more harm than good here, I'd wait until you're better situated in the company to start diving deeper into various areas.
@@RahulPandeyrkp Sounds like you think we should have a bias for action, rather than letting some arbitrary goal of "mastery" that stalls us from getting started on tasks.
Rahul's idea is really worth pondering but there's also a contrary view from John Carmack - ua-cam.com/video/YOZnqjHkULc/v-deo.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.
thanks for sharing that video, I have so much respect for John Carmack
@@RahulPandeyrkp Would love to see a video when you need to resist temptation of diving into some unnecessary part of codebase and focusing on priority. Also on situation where you've scoped a project to right extent and didn't let feature creep-in to happen and also as an individual didn't dive deeper into the wrong (maybe interesting) part of project/code/feature.
best video
Collab with Garry tan
I think you are taking things out of context by a very large margin.
How so?