The cognitive ceiling. Research by Ericsson, Mark, and Newport shows that 3-4 hours is the daily maximum for concentrated effort. Beyond that, diminishing returns.

“Diminishing returns” is not the same as zero returns. You’ll get more coding done if you work eight hours a day than four hours a day. There’s certainly a point where the quality gets so low that the returns are negative (by introducing bugs / technical debt / stuff you have to rewrite the next day), but in my experience 4 hours is not it.

In fact, if the problem is very complicated then it might even take you three hours just to get up to speed with what you were doing the day before.

Idk, I definitely have days where I’m highly productive for more than 4 hours, but I also have days where I work even longer and accomplish nothing. I don’t think a number like that is particularly useful for anything, and only good for micromanagers who need to feel like they can hyper-optimize every single thing.

Interruptions definitely fuck me up though, without fail. Maybe it’s the type of work I tend to do, which generally requires me to keep a lot of context in mind. An analogy I’ve heard that I think works well: It’s like fixing a car, but you have to disassemble the entire dashboard and steering column just to reach the part you need to work on. As you’re doing that, someone asks you pick them up so now you have to reassemble everything to be able to drive the car to pick them up, and then disassemble it all again just to get back to work.

Diagram in the link preview (and also in the article) is a little confusing, because “invaluable” subverts the usual meaning of the “in” prefix, with “invaluable” meaning:

extremely useful; indispensable

Which makes the diagram suggest that deep focus gets good results, but unfocused and distracted work gets the best results.

Data reveal that the median coding time is 52 minutes/day. Meetings consume 11+ hours per week, pushing peak coding to the afternoons when mornings should be prime.

Shit. I knew it was low, but that’s awful.

As an engineering manager, I use all of the approaches described in the article, and a few others.

It does make a tremendous difference both in output of correct solutions, and in team member retention. And team member retention saves big money - having to spend 18 months to train new a subject matter expert every three years is expensive.

The 18 months onboarding every three years (per each pod of five developers) was the average re-training cost on my teams before I mastered these (and a few other) techniques for managing creative engineering talent.

Edit: and for those who say “I’ve heard it takes less than 18 months” - yes, I know. I probably lied to you to protect my own job. Haha. The truth is important, but the full unvarnished truth is not more important to me than my collecting my next paycheck.

I’m on west coast time, and main office is eastern, my day becomes way more productive once east coast ends their day. No interruption and the last 3 hours are such a good floe state

My favorite meeting is my 8am standup that’s scheduled for 30 minutes and averages an hour. It really makes sure I have no energy to do anything else that day. Except it’s every day. And most updates are “no updates” with extra words to make it sound like people are doing stuff.

My experience doesn’t match this in terms of resuming after an interruption. For me at least, most coding doesn’t require that high state of understanding everything in every detail, so an interruption is usually not that big a deal.

It’s helped if the interruption is on my own terms though.

Does that include research time? I sit around pondering solutions, drawing diagrams, planning. When implementing harder solutions, usually 2 hours of actual deep work. But there are days where I wire up the logic and other grunt work, I can do that for 5 to 6 hours.

it would take 4 hours of concentration to just pronounce “Csíkszentmihályi”

Hyperfocus wants a word.

But, saving this anyway.