I wouldn't say the primary takeaway from this post is to remind programmers to be humble. It's a takeaway, yes. But humility comes and goes, and reminders often

I wouldn't say the primary takeaway from this post is to remind programmers to be humble. It's a takeaway, yes. But humility comes and goes, and reminders often take the form of bugs in your code that you didn't expect. I would argue the post is primarily about complexity, and in school you probably haven't seen how complex software can get because most projects have to be started and finished within two to three months. Once you start working, you'll quickly discover that the complexity of existing systems can be overwhelming, but this is normal. After 3-6 months working on a complex codebase, ideally with a team to help you, you'll have some idea of how the complex system works, and even if that idea is wrong (in many, many places), it will help guide future changes to the system. The point then, of reminding programmers to have humility, is less about hearsay on the internet and more about the need for tools and languages to make life easier for the individual programmer trying to read the code, then plan, make and deploy changes to a live system. If you're lucky, you'll feel like the system makes sense but changes too quickly. If you're unlucky, the system will make little sense and it'll be entirely your job to fix it or put up with it. Usually, hopefully, there's a middle-ground, where the system works well enough you don't have to make changes, but you're probably not entirely satisfied with it either. Humility can also be the reminder that just because a system looks broken (to you) doesn't mean it needs fixing right this second. If you can spare the time, it's almost always better to try and understand an existing system's quirks before you set out to redesign it and end up re-implementing some of the same quirks yourself. I'll echo mentions elsewhere in this thread and suggest John Ousterhout's A Philosophy of Software Design as a good book on the subject of complexity and API design, but to newcomers to the field, I'll leave the warning that it doesn't cover TDD as much as it could and it also doesn't cover modern Scrum/Agile practices and how development fits in with product design and company goals. But I still highly recommend it.