I don't understand this perspective, but I hear it often.
The way I see it productivity should always be measured against the actual result and how long it took, not a mere impression based on how much of that time was spent in front of the keyboard.
I'm willing to bet John Carmack has thrown away the vast majority of the code he's ever written. Everything I've read about him seems to indicate he's a "hands on"/"external thinker" kinda guy which would be why he was so dedicated to keeping track of his time according to this story. Not everyone has that need. It actually sounds exhausting and pitiable.
Was it really productivity being witnessed, or just a man desperate to get back to his computer so he can play around with the code some more? Some of us do most of our problem solving when we're away from the computer living our lives. Sometimes I don't have an answer until the pressure is off and the clock says 5PM. A tide of relaxation often drags in the answer that was just past my reach 15 minutes earlier.
Writing code is not typing. It's thinking. We all do it differently. I prefer a beer and a nap. All that really matters is that you don't stop thinking about the problem.
Your perspective isn't mutually exclusive with the one in the article.
I take the article, and the Carmack stories, as an argument to be scrupulously honest with yourself about when you're fucking around. If you do your best thinking taking a shower or a 20 minute walk in the sun, that's fine, because you're working, not fucking around.
But if you're browsing facebook, not thinking about the problem, and telling yourself it's part of your process, you might be in denial.
> If you do your best thinking taking a shower or a 20 minute walk in the sun, that's fine, because you're working, not fucking around.
This ignores all the evidence that stepping away and doing something entirely unrelated can lead to a breakthrough from a fresh perspective. Sometimes that's because you thought about the problem elsewhere, but sometimes that's because you've allowed the set of contextual assumptions you've made about the problem to unwind and be released but not thinking about it at all, which is what provides that fresh perspective.
I have literally spent ten hours on a problem and left for the day completely demoralized about it, only to come back in fresh the next morning after having not thought about it (literally having no chance to think about it in some case, given I have a family and obligations), only to sit down the next day, spend ten minutes reviewing where I was at, have a possible solution five minutes later, and an implementation that works 15-30 after that.
The belief that you need to be working on a problem to make progress in it is a trap. Now, avoiding it because you don't want to deal with it? Yes, that might be denial, but for anything that requires creativity, progress is often not linear, and expecting it to be is just ignoring the reality of how our minds work to chase an ideal that doesn't work.
If you track your pace hiking one thing you discover is that a non-trivial break almost never pays off (presuming you're past a certain baseline fitness level). Unless you get lost.
I recently discovered I spent days cranking out unpleasant repetitive code when I should have used a different data model that would have allowed me to write a trivial generic solution.
I suppose this is an area where no heuristic is anywhere as good as having the experience to know the right answer in your specific situation.
No sorry I'm saying something else. Regardless of what you're doing, yes even browsing Facebook, what matters is that the code was delivered on time or faster and doesn't suck. The typing of the code is trivial.
In that case I think you might be straw-manning the message of the article.
It's about being honest with yourself about how your practices relate to your actual productivity versus your potential productivity. Of course at the end of the day only the output matters, and if you're super productive by browsing facebook 4 hours a day and focusing the other 4, good for you.
The article asks: Are you selling yourself short by doing that?
It's possible the answer is no, and that you simply need to work that way.
But it's far more likely that you are selling yourself short. Most people surfing facebook for 4 hours a day are not productive geniuses with an idiosyncratic process. They really are just fucking around.
> I think you might be straw-manning the message of the article.
Yes? First sentence was that I don't understand this perspective.
> Are you selling yourself short by doing that?
I think finding progress is more important than what is literally being done. Activity and productivity are very loosely correlated in knowledge work. If that person scrolling facebook decides to switch careers to online marketing or bring those skills into running their own business, it definitely wasn't a waste of time.
> Most people surfing facebook for 4 hours a day are not productive geniuses with an idiosyncratic process. They really are just fucking around.
I don't know anyone working in tech that's this dumb and lazy. The post is about writing software, not menial work. If someone is bored by tech work or doesn't see the value in it then they don't understand it. They deserve to fuck around and get fired.
I think a lot of people really struggle with metrics and evaluation. We've gotten used to algorithms and mathematical expressions but I don't think many have internalized meaning and the actual information that they convey. All metrics are guides, not absolute objective signals. People hear Goodhart's Law and think about how metrics can be abused, but the real lesson here is that metrics are only guides. The abuse only happens because they become absolute measures rather than only a part.
It may take one person all day to produce 50 lines of code and another 500, but we can't differentiate these people by the metric of time, number of lines, nor the number of commits. Even bug and error metrics don't complete the story. Those 50 lines could be more critical, more complex, and have higher impact.
Realistically, we need to embrace the chaos. Everything is fuzzy and messy, and that's actually okay. That's how life and the universe actually are. Metrics are good guides to this chaos and help us navigate these complex landscapes, but they all have a limitations, which if we aren't aware of can lead to disaster. You need to be aware of the uncertainty and limitations of your metrics. I see a lot of HN/STEM like people argue passionately for meritocracies, but have yet to see one of these people account for the limitations of the measures they so passionately advocate for. The irony of this being that this takes us further away from that meritocratic goal and actually increases the noise in the system. To make a system more meritocratic you have to embrace the noise in the system.
The way I see it productivity should always be measured against the actual result and how long it took, not a mere impression based on how much of that time was spent in front of the keyboard.
I'm willing to bet John Carmack has thrown away the vast majority of the code he's ever written. Everything I've read about him seems to indicate he's a "hands on"/"external thinker" kinda guy which would be why he was so dedicated to keeping track of his time according to this story. Not everyone has that need. It actually sounds exhausting and pitiable.
Was it really productivity being witnessed, or just a man desperate to get back to his computer so he can play around with the code some more? Some of us do most of our problem solving when we're away from the computer living our lives. Sometimes I don't have an answer until the pressure is off and the clock says 5PM. A tide of relaxation often drags in the answer that was just past my reach 15 minutes earlier.
Writing code is not typing. It's thinking. We all do it differently. I prefer a beer and a nap. All that really matters is that you don't stop thinking about the problem.