For every kind of work, we need a certain period of concentration time, meaning that a window of time is necessary to start, work on it, and finish a given task.
The concentration time for software development labor is long, I believe the same thing happens with other creative labors related to arts, design, and writing for example.
It takes time to get into the flow.
And when you are in the flow, productivity bursts, and time passes at a different pace.
It is rare to accomplish programming tasks within a 30 min time frame.
A manager’s calendar can have 15 min meetings, and 30 min tasks all day long and that is okay, I can say that from experience because that’s what I did in the last 5 years.
A programmer calendar can not have small time boxes all day long; they still can have 15-30 min meetings, but to be productive at programming sessions, they need hours.
I can also say this from experience because that’s what I did in the 10 years prior.
I was able to spot this thing since I’m back programming nowadays after a 5 years break doing management labor.
There is no best or the worst, it’s just different.
The flow-breaking or context-switching problem
If a programmer needs hours for a productive programming session, it means he needs hours without interruptions.
If you throw an interruption on a programmer when he is in the flow, it’s hard to measure the time you made him lose.
The time can be the same, but the amount of work he can deliver in that period of time isn’t.
It’s not like: “hey! help me here with this 30min thing and I’ll give you 30min more to finish your task there” it doesn’t work like that.
It can explain why one person can deliver a lot of work in one day and somehow can not reproduce it the next day.
If we could measure the time that person stayed in the flow, maybe we could find a correlation, but who knows?
What I know is that flow-breaking and context-switching are productive killers.
Final takeaways
So what? Do not talk with programmers. Is that the solution?
I don’t think so, interruptions must be avoided, but in the real world, it just happens.
It can be an external interruption or a self-interruption, it will occur anyway and I won’t pretend I have a solution for that.
But here goes a reminder for us developers that we should set up our schedule according to our productivity expectations for a given day or week.
We can’t always control our own schedule, but it is up to us to draw a line that marks the concentration-time required to accomplish a given task.
You can’t expect to deliver a ton of work with quality if running on a very granular calendar. Right?
Image credits: https://unsplash.com/@icons8