Most of the work I'm really proud of happens in 1-1.5 week long coding binges, during which I code ~14 hours a day, don't eat well and don't get outside much. During that time my entire being is oriented around the problem. I sleep when I'm too tired to be productive and wake up with the problem spilling out of me.
I usually need a couple of weeks recovery time afterwards during which I'm pretty useless for anything thats not light and fluffy. But that time is 100% worth it. If I could work at that intensity for 1 week out of each month I'd be more productive than I have been at any 9-5 job I've ever had. Well, for a given definition of productivity.
So I guess I like pomodoros - I just think they should be about 1 week in length.
http://psychcentral.com/news/2011/02/09/taking-breaks-found-...
The Pomodoro/25 minute approach your OP is advocating I think requires that you write software a different way. You can't write big source files that reference hundreds of data structures. You can't write modules that require other modules to be structured just-so in order for things to work. You can't throw hundreds of views, models, etc, into a big repo and let them all call each other. You have to spend time constantly creating new interfaces, shuffling responsibilities around, and generally keeping your codebase such that no particular module requires you to reason much about the modules other than its few neighbors.
Frameworks tend to discourage this way of programming, because they want to give you a small set of primitives and have you fit everything into one of those boxes.
But if you can manage it, by avoiding frameworks, learning about all of the component systems available to you, and getting comfortable writing your own middleware, the 25 minute requirement can actually help you, since if you find a problem that you can't wrap your head around in 25 minutes, you know your next task is to move some module boundaries around so that you can get a clearer view of the problem.
Many software teams choose to operate on the bleeding edge of "could a very smart, full-time programmer with a lot of coffee understand what's happening after poking around for a couple hours?" rather than "does this interface create a region of the codebase which can be independently understood?"
- There's the technician skill, where you poke at your react elements and fiddle with CSS until it looks like the mockup the designers gave you. Every 20 minutes you need to trawl through stackoverflow to find the exact way to use flexbox to get the layout you want, or to work around a bug in safari. When you're done you do some refactoring and feel good about it and call it a day.
- And there's the engineering skill, where you scratch your head and read wikipedia & some academic papers until you know what search terms to use. And then you realise that really you want something like an invertible bloom filter, except there's some small % chance it will fail each time you query it so you need a fallback mechanism. Except then you realise that fallback mechanism will have O(n^2) - but if you use a slightly different data structure then it'll become O(nlogn + klogk). But that requires modifications to the bloom filter itself and a funky network protocol, so you write that.
If the only programming you do is the first type, thats fine. Thats where we all start. Thats the majority of work out there. 25 minute pomodoros are probably fine for that. I like pair programming, because I can stay focussed better with a friend. Sometimes I listen to excited music while I work.
But all the work I'm most proud of is the second type. I wrote a streaming incremental compiler for a 2d air pressure based language. I got 90% of the way to making an OT algorithm work for arbitrary JSON structures (including object move), only to realise that it absolutely needs conflict markers so I put it down for awhile. I wrote a nodejs server from scratch thats compatible with google's browserchannel protocol - basically reimplementing TCP in the process. I implemented a PEG parser - and I'm going to need a session like this to add the ability to pass realtime streaming text updates through the parser.
These sorts of things can't be reduced to 25 minute context increments. They just need too much mental state. Maybe once they're done they can be broken down into pieces that you could explain in 25 minute chunks. But figuring out that some particular abstraction is the right one requires fitting the entire system together in your head, so you can turn it around. And thats a spacing out in the shower followed by a day with a whiteboard kind of task.
I guess the way I see it is that large amounts of uninterrupted time doesn't simply make it easier to do hard engineering. It makes it possible. Is that what the book refers to as deep work? If so then I think pomodoros are an anathema to that.
I think if that's true, you should spend your time structuring a back-end such that other people in the organization can take the "technician" stuff off your hands. People who care most about those parts of the codebase. Potentially even non-engineer. Start them in a read-only front end app. It doesn't get you out of the woods, because you still have to support all of those people. But your real job is doing the hard engineering work to create a robust framework which is safe for people to build on top of.
In the long term, you'll spend part of your time basically teaching, and the other part of your time doing that gnarly researchy stuff you love.
And you could eventually opt out of teaching too, if you found someone on your team who likes that work. Then you're just the wizard deep inside the machine making magic happen. Your teammates would probably help. Good people will take as much of the responsibility as they can, since they don't want you as a bottleneck anyway.
And exactly like a real sprint (running very fast) a period of resting is necessary after such an effort, usually longer than the execution time spent.
I've always understood the pomodoro timers as 25 minutes of getting down into the trenches and then taking 5-10 minute breaks to think about whatever you're doing from a high level overview.
About context, this is from Programmers at Work by Susan Lammers, interviewing John Page, author of the PFS productivity suite, famous in the late 80s.
Lammers: Why are programmers so obsessive?
Page: You constantly try to hold the state of the entire system you're working on in your head. If you lose the mental image, it takes a long time to get back into that state. It's like being an air-traffic controller who has nine planes in his mind and knows exactly where they're all going. Distract him by asking him when his shift is over and he loses those planes--the model he had in his head. In programming, a big complicated model is very efficient once you're in the groove. If you get out of it, you've got to work on it quite a while to get back in.
I think a better advice now would be to experiment, and see what suits you best in terms of sustainability, output and fulfilment.
Today I my pomodori were between 25 minutes and an hour. It's home time now, but I feel great due to a large part of the day filled with flow.
Intuitively I'd assume that the context and information in working memory is precisely what enables one to do "deep work". Constantly requiring you to rebuild your in-memory cache feels like it would lead to sub-standard work.
I think you can, but the big risk is that what you produce becomes incomprehensible to anyone without all that context filling their brain, including you next week.
(Not saying I'm in favour of deliberate interruptions, just that this might be an argument for them.)
I used to believe this as well, then I tried 50 minutes, 10 minutes break and I like it way better. Try it for yourself and see which one works best for you!
Also, I never realized how short 25mins actually was. And working like that helps me estimate programming tasks. It used to be that someone would ask, "how long will it take you to do X?" I would always say, "an hour or two". Then I realized how short an hour actually is... only 2 pomodoros... and wow, that went by fast.
If I'm not done with a task, the trick I use for not losing focus between Pomodoros is to leave an easy bug, or purposely break something easy and leave a "//todonext".
I can't remember who, but some famous sculptor used this technique. He would purposely mess up an easy part of his sculpture, so that the next day, he had a "softball" to fix that easily got him back into work mode. (anyone know this phenomenon?)
Someone told me that its 25 minutes because it prevents you from building too much context in your head that prevents you from taking a break at 25 min mark. You can't do creative work if your brain is filled with lot of context. eg: TDD goes really well with pomodoro because you are only thinking about the next test and you can break on failing test so you can pick up right back. Is this a reason for 25 min for Pomodoro?