Maybe you misread the article - the obsession here is with "speedup", which is not the same as productivity.
The author gives the example that instead of simply doing more X, being faster can enable you do Y instead of X (where Y might be only working half-days). Very much "work smart not hard", which is where a lot of grind-y productivity stuff lands.
You can still be hyper-productive without killing yourself in the process. Also, some people actually like to do these things.
Keep in mind that there is a point where relaxation turns you into a worthless bum, and constantly analyzing things before you act will mean you struggle to learn which paths don't work in reality.
nothing is more frustrating for me that to have a goal, and a path, but be unable to get there because of .. issues. i know thats programming and working in an organization
but if it is going to take me a year to deliver an X, I probably wouldn't choose to do it. a month, hell yes. the worst - pulling the trigger on X assuming it will take a month + delta and have it take a year.
there's also the reward and momentum factor. if i keep getting nice wins i get pulled into doing more interesting work. if its going to be another 6 weeks before i can see any demonstrable progress... i'm actually going to go alot slower and be tempted to just forget the whole thing.
some of us are actually in it to _do stuff_....not just show up at standups and collect a check. honestly though maybe i have less to show for wanting to dig into real work.
another important context here is that Jamie is driven by a desire to make programming more useful and accessible to people. the fact that he's trying to quantify that is quite interesting and relevant to that goal.
so .. put in your 40 hours and have a life. there are other people with differnt goals.
edit- sorry temporal, it doesn't sound like it , but i'm really agreeing with you
I agree and I would say that choosing to work on the right things is much more important than being a fast programmer. Sometimes you need to spend more time thinking about a problem, do a bit of a "market study", or gather more data. Too many startups out there are solutions looking for a problem. On a smaller scale, as an individual programmer, it's easy to get caught into yak shaving or trying to optimize the wrong thing.
> choosing to work on the right things is much more important than being a fast programmer
Choosing to work on the right things is completely orthogonal to being fast though.
> Sometimes you need to spend more time thinking about a problem, do a bit of a "market study", or gather more data.
You can do this even if you are a fast coder. Only difference is how long it takes to test things, build MVP's and show them to potential users. MVP's are a great way to better understand what to build or do market studies, so I don't see why this goes against being fast.
