Discipline is all what matters, automatizations are imperfect and temporary tools. Simply put: all abstractions are leaky, all abstractions have trade-off, and

Discipline is all what matters, automatizations are imperfect and temporary tools. Simply put: all abstractions are leaky, all abstractions have trade-off, and you cannot necessarily rely on some abstractions in every context. The GC example that the author uses is a good one: having GC in a language does not magically remove all memory allocation issues. Believing this means you just don't have much experience programming (or you've been very lucky). I've been working mostly with GC languages and we have memory leak every now and then, good luck to fix that without discipline. Embedded software frequently relies on (very) limited compilers and libraries, most of the time there are no GC and until recently there were even no malloc/free for $B things shipped to space: only static arrays and discipline my friend! TCP is another good example: sometimes you need to craft you own congestion management, packet discard rule or what not. ORMs have made my life easier but I've still had to spend days on complex hundreds lines SQL reports. The list goes on. It's not "I had to go through this, you should too" out of frustration. It's because at some point the same kind of issue will appear again, even though the current available abstractions may seem to shield us from it. It might not scale as easy as you wish, yet you need some disciplined seniors to review and teach your juniors. This very article ironically proves it :)