What's more sad is that nowadays you're expected to have not only breadth of knowledge (sacrificing depth) but to also learn fast. We romanticize speed. We want

What's more sad is that nowadays you're expected to have not only breadth of knowledge (sacrificing depth) but to also learn fast. We romanticize speed. We want the chef who creates quality food in fast food speeds! Something that the author of the article could also touch upon is that, lack of resources was also a boon. I recall reading interviews of great programmers of the yesteryear saying how they would "read the same book twice over to understand deeply" and "sometimes I'd read the same concept from another book to make it really click", one of them being John Carmack! A naive assumption I made after reading statements like those was this: When performing, sometimes you go fast to pressure yourself but under that pressure the odds of delivering quality work is greatly reduced. However, when comprehending something new, you cannot romanticize speed. You almost have to value comprehension and depth. Speed comes as a byproduct of the hours spend understanding. Instead of that we favor speed of questionable learning quality, we tag ourselves "jacks of all trades" because you know enough Next.js to ship the product but not enough to tell what you could have done better or even why we chose to do A over B outside of "the stackoverflow answer told me to". That is, until the client complains. We really misuse the whole "premature optimization is the root of all evil" to "premature readability", "premature anything". Gotta go fast! tl;dr aside from the programming environment, not having access to "quick and dirty" answers to any problem affected everyone's expectations of delivery and performance, and that also played a role in how we learned.