4 ms·
I think the problem is even a little more subtle. The thing a programmer should ultimately aim for is to automate themselves out. But there are two strong disin
by zubat 10y ago
I think the problem is even a little more subtle. The thing a programmer should ultimately aim for is to automate themselves out. But there are two strong disincentives to doing so. One is economic - they don't participate as a stakeholder equally unless they're cofounders.
The other is a disincentive to improve. By this I mean that becoming a better programmer means taking on deeper challenges and solving increasingly obscure concerns and constantly reaching a point where no IRC channel nor Stack Overflow thread can help you. This takes you out of flow. It's not fun to work right up at the limit of your ability, you have no hope of bullshitting through that level of difficulty in crunch mode, and developing those skills alienates other programmers who are not burdened by the demons you have fought. 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 it works out that prevention with good engineering can grow discouraged in favor of all nighters.
- dsfyu404ed 10y ago>It's not fun to work right up at the limit of your ability, you have no hope of bullshitting through that level of difficulty This isn't just for programmers. Pretty much any occupation where you're routinely in a situation where you are responsible for making decisions based on incomplete information or with a large element of chance/luck affecting the outcome will wear you down fairly quickly. President, pope, EMT, infantryman in foxhole, cartel kingpin (and other criminals who make enough money to be "noticed" by authorities) etc., to name a few.
- internaut 10y ago> 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.