I read that back when it was first published, believed it, and built a few teams using it's philosophy. I've also been at a few big companies that haven't followed it's direction. In my experience it doesn't work unless you have a small team and a small company and even then you are often left with fickle programmers who leave when the next fad comes along because your company can't justify rewriting its systems with the latest fad tech.
Wouldn't you say lisp was the opposite of a fad at the time when PG wrote that article?
It's been a long time since I read it, but in Microserfs, the classic "VC" or "Money" guy describes how you can drive around the Valley on a Sunday and predict the success of companies by how many cars there are in the parking lots.
Most conventional wisdom these days is that if you have to work 80-90+ hour mega weeks you're doing it wrong, but I think that the analogy might be that if the team is using an interesting technology stack, there's a higher chance the engineers there are of higher caliber (as they're interested in pushing themselves to use a newer technology.)
"but I think that the analogy might be that if the team is using an interesting technology stack, there's a higher chance the engineers there are of higher caliber"
My experience doesn't support this for a few reasons. One of the main reasons is what I alluded to before, the people interested in "interesting" tech stacks are fadish, even if the tech isn't. In 2-3 years, your "interesting" tech stack becomes "uninteresting" or worse, a bad idea. I remember when java was "interesting" then it was php, then python, then ruby on rails, then scala, clojure, haskel, then backbone, then node.js, then angular, then react, then go and rust, then ....
