> he thing a programmer should ultimately aim for is to automate themselves out. This is something I ferociously agree and disagree on at the same time. 1. Ye

> he thing a programmer should ultimately aim for is to automate themselves out. This is something I ferociously agree and disagree on at the same time. 1. Yes automating labour inputs is the key to growth. Always has been. That is the point in your favour. 2. But paradoxically once you have automated your labour input you grok no further efficiency gains. Why would you when you've reached '100%' efficiency? This is a bit counterintuitive. Here is a toy example; suppose I manufacture hammers at HammerCo Corp. One day I manage to automate all labour relating to the manufacture of hammers. I am rich and successful as competitors die off. Then suddenly I myself go bankrupt because a new competitor introduces hydraulic or pneumatic hammers onto the marketplace in which I had my niche. I have no expertise to counter the move and cannot defend against it. You don't comprehend you were in a local maxima. When a worker closely observes a technological process he or she is involved in they might notice details (or going the other way, general rules) that would not be noticed by causal observers. This leads to creative insight that coupled with capital can allow the invention of new designs and ultimately technologies. I guess the same thing is true of programming. If you abstract too much (something we've been doing for some time now with frameworks/libraries etc) you lose the thread. I'm sure somebody else has thought of this before and given it a name. > Plus the majority of software businesses have arranged themselves around making some use of fresh, mediocre coding talent, so going too deep and too specialized can make you less hireable!. So many people get institutionalized into mediocrity. If they don't get you at school, they'll get you at work. Very few people manage to escape those traps.