"Build one to throw away" is going into my vocabulary. I have a project right now that feels just like your example

This is the first time I hear a more senior engineer speak about this topic and I'm very happy that I am not alone. I agree it's easier for me to experiment with existing code before going ahead with reading books. This is quite similar to how children learn - for example, kids speak a language before they begin to learn it. They don't know nouns, pronouns, or verbs but speak the language anyway.

This advice is so invaluable to me. When I join a large project with new technology stack, I always have a strong feeling of imposter syndrome. Your tips help me resist the temptation of understanding every little detail before I could actually make some contribution. Thanks for sharing the great insights, John!

I wholeheartedly agree with the points you've made. It's _really_ helpful to just get something down and iterate on it after. Oftentimes I've found that the code I write in the first draft - many of the snippets I can just copy paste into the second draft, which speeds things up a ton. In these sorts of situations where you're feeling the pressure to deliver, or are feeling overwhelmed by the task ahead of you, I find it's very easy to get stuck doing the same thing. You start reading your big books thinking "Oh yeah, this'll be great!" and you get half way through and you think "The first half wasn't great but maybe the second half will be. It'd be a waste to give up now!" By the time you reach the end you realize that the entire book didn't teach you what you wanted to know, but you kept on pushing ahead down the same path anyways. I've always found that learning has an ROI, and as you're learning, you can ask yourself "What's my ROI for this learning material?" It took me a while to learn this, but just because you think something is "good" or " well regarded" (e.g., a highly rated programming book) doesn't mean it will help you learn what you're wanting to learn in that moment. If you're reading a section in a book that teaches you about X but you want to learn about Y, skip it and go to the next section! If you find that you actually do need to know X in order to learn about Y, you can always go back :)

underrated channel, thank you

Absolute GOLD this channel is, thank you so much

These videos and the insights you share are just gold, thank you 😊

More sr's need to talk about problems they face, for new people to know how to tackle them so we are more prepared.

I'm interested in joining or starting a peak performance group for software developers to be the best versions of themselves, and I don't necessarily mean technical skills, I mean more focused soft skills; a group that helps you productively steer conversations within your job; something like going through the book "Crucial Conversations" with a specific emphasis on applying the principles to software development. The group would practice difficult conversations and brainstorm on the best ways to handle them. Members would bring real life situations to the group and discuss it. People would role play - for example one person playing the role of trying to get their PR approved, and another person playing the role of an engineer who refuses to approve. It would be fun.

Good advice. Beyond a few technologies that I'm confident will be in my long-term toolkit, I no longer try to learn new technologies for the sake of learning them. I simply set a goal and learn whatever I need to learn to accomplish the goal.

I’m glad to know I was on the right track with how I am approaching an existing code base at my internship. You gave me SO many freaking nuggets of wisdom in this video and quelled a lot of my uncertainties about how I should approach things. Fantastic video!

This is great content

Thank you so much. It's very inspiring. I've actually been suffering from imposter syndrome (at least I think I have) as an English teacher, having had a lot of stress and failures in my life. Admittedly though, most were avoidable, but I think it's the guilt and shame that gets you. I am aspiring to become a programmer, and have just submitted an application to a university in computer science, so this advice is very welcome by me. Therefore, I'm sure that I'll be referring to it and your other videos in the future. Cheers.

Hi John. Great video as always. I am wondering if you can make a video on learning how to talk about past experiences. As a newer "engineer" (inflated title), I feel as though I am not very good about talking to recruiters about what I do at work. Agreeably, as time goes on, I have more and more to talk about but the level of abstraction I need to use for confidentiality is hard to manage still. I respect my employer and feel an obligation to "do no harm"; however, simply stating that CRUD is involved in my day to day feels rather... bleh. How do I logically explain tech stack, infrastructure, and my role in the project without overstepping?

Amazing video!!! As a software engineer at early stage startup, is system design skills needed? Shall I learn about full stack, or infra related work is also needed?? Thanks in advance!