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
Now you've interrupted I will lose 40 minutes. Lol.
Also it's not whats I'd call true code like what a C programmer would do, it's a enterprise 3d CAD modeller that has a variety of built in programming automation tools/language, visual rules.
So its solving geometry issues, component interaction, and interpart constraints via formulae and code so that the varied consumer parameters (they may alter) don't destroy the model dependencies, and they still get a product assembly output.
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.
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.
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.
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 still sugar coating it....
I was in a pretty intense training program, like up to 110hrs/week actively studying on top of normal military bullshit.
No matter who you are or what you're doing, you can't spend that much time actively focusing on stuff. After a certain point there's not only zero gain, but continuing to try and push through it just protracts any refractory period till you can be productive again.
We went thru it with everyone knowing it wasn't productive, because they wanted us stressed the fuck out to make sure when we were stressed the fuck out we could still function.
But it's absolutely insane for employers to do it. The only logical reason is intentionally causing burnout when there's a steady supply of new employees that can be hired for cheaper...
Which is how this all comes back to why "crunch time" is the norm with programming.
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.
I feel like with neurodivergent types it balances out to around that anyways. Yes, I may spend 3 days hyper focused on a task 10 hours a day, but the rest of the week or month it's might just be 10 minutes a day I can focus lol.
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.
19 Comments
BCsven@lemmy.ca · 39 pts · 202d
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
PlutoniumAcid@lemmy.world · -27 pts · 202d
*flow
I hope you code better than you spell, friend.
NotANick@lemmy.world · 34 pts · 202d
I don't think the simplest of typos on a QWERTY keyboard justifies a correction and snark, does it?
BCsven@lemmy.ca · 8 pts · 201d
Its fine , I got a chuckle out of it. That's inevitable for me on mobile without my glasses on.
Alexstarfire@lemmy.world · 3 pts · 201d
New to the internet?
BCsven@lemmy.ca · 3 pts · 201d
Now you've interrupted I will lose 40 minutes. Lol.
Also it's not whats I'd call true code like what a C programmer would do, it's a enterprise 3d CAD modeller that has a variety of built in programming automation tools/language, visual rules. So its solving geometry issues, component interaction, and interpart constraints via formulae and code so that the varied consumer parameters (they may alter) don't destroy the model dependencies, and they still get a product assembly output.
entwine@programming.dev · 20 pts · 201d
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.
pinball_wizard@lemmy.zip · 16 pts · 201d
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.
tias@discuss.tchncs.de · 11 pts · 200d
"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.
givesomefucks@lemmy.world · 9 pts · 202d
"Diminishing returns" is still sugar coating it....
I was in a pretty intense training program, like up to 110hrs/week actively studying on top of normal military bullshit.
No matter who you are or what you're doing, you can't spend that much time actively focusing on stuff. After a certain point there's not only zero gain, but continuing to try and push through it just protracts any refractory period till you can be productive again.
We went thru it with everyone knowing it wasn't productive, because they wanted us stressed the fuck out to make sure when we were stressed the fuck out we could still function.
But it's absolutely insane for employers to do it. The only logical reason is intentionally causing burnout when there's a steady supply of new employees that can be hired for cheaper...
Which is how this all comes back to why "crunch time" is the norm with programming.
nullPointer@programming.dev · 8 pts · 202d
it would take 4 hours of concentration to just pronounce "Csíkszentmihályi"
whatsgoingdom@rollenspiel.forum · 5 pts · 201d
Easy, his name is pronounced like: chicks sent me high.
kambusha@sh.itjust.works · 5 pts · 202d
Bless you
FishFace@piefed.social · 6 pts · 201d
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.
Cryxtalix@programming.dev · 5 pts · 201d
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.
MonkderVierte@lemmy.zip · 4 pts · 201d
Hyperfocus wants a word.
But, saving this anyway.
nullroot@lemmy.world · 6 pts · 201d
I feel like with neurodivergent types it balances out to around that anyways. Yes, I may spend 3 days hyper focused on a task 10 hours a day, but the rest of the week or month it's might just be 10 minutes a day I can focus lol.
bold_omi@lemmy.today · 1 pts · 179d
Bullshit. I program for much longer periods.
Hazzard@lemmy.zip · 1 pts · 201d
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:
Which makes the diagram suggest that deep focus gets good results, but unfocused and distracted work gets the best results.