5 ms·
While I respect the Pomodoro technique, I found that its focus on 25-minute chunks is largely incompatible with the way I (and many others) program. When it tak
by KingMob 11y ago
While I respect the Pomodoro technique, I found that its focus on 25-minute chunks is largely incompatible with the way I (and many others) program. When it takes 10-15 minutes to load everything up in your brain, that only leaves you a few minutes to actually work before you take a break.
It remind me of the "This Is Why You Shouldn't Interrupt a Programmer" comic: http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/ http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-..., except in this case, you're interrupting yourself.
These days, I use SelfControl to disable access to my distractions all day long to get a ton of stuff done.
- baby 11y agoI don't think the 25 minutes matter that much. I always did 30 minutes, and then if I feel like I wanted more time, I would ignore the alarm. The principle is to give you a small amount of time you have to focus. Then once you did that, everything else seems easier. Pomodoro is not really a time management technique, rather a motivation/anti-procrastination technique. But OP is trying to sell his product so... buzzwords.
- redrummr 11y agoThen start your next pomodoro immediately. That's what I do. If you can do that and not get burned out, that's ideal, especially if you're in the zone. It's also better than increasing your pomodoro time IMO. Since I don't take a break 2-3 sessions at a time sometimes, looking at 10 minutes to go is spurring; when I experimented with 40-minute sessions I hated looking at 35 minutes left on the clock.
- larrywright 11y agoI do a variation of this. Ten minute timers, instead of 25, and then I make sure that whatever task I set for myself is something I can do in 10 minutes. For programming tasks this is often "Finish writing method foo", or "Debug the problem with method bar".
- ahstilde 11y agoHow long are your breaks?
- larrywright 11y agoI don't take a break after every session. I usually try to break for 5-10 minutes once per hour.
- mikekchar 11y agoWhen I temporarily went into teaching (5 years... lol) after a career of programming, I still wanted to write software every day. The only problem was that I only had small pieces of time -- usually 20-30 minutes here or there. It was a kind of enforced pomodoro. Of course, I suffered exactly the same problem that you do, but even worse because it would be hours before I could pick up the code again. My solution was to try to swap out that context to disk :-) I'm back in software again and I've refined my techniques a bit. It's helpful for me because as I get older, I can hold less context in my brain than I used to be able to do anyway. There are 2 main places I store context: tests and TODOs. I'll start with TODOs. I actually use Emacs org mode for TODOs. The best part about Org mode is that it is in a text editor. That means that I interact with it the same way that I interact with any other tool. It is also hierarchical, which means that I can embed TODOs within TODOs. Finally, it is folding, which means that I can ignore large sections of the TODO list, or move sections around with just a few keystrokes. Basically, as I'm programming, whenever I have the thought, "Oh, I have to do this", it goes in the TODO (even if I'm just about to do it). You have to be terse because you don't want it to take more than 1 or 2 seconds to jot down. But terse is OK. I actually have 2 editors open -- one that I'm programming in and one with Org mode. I switch between windows in tmux. This is the fastest way for me, but if you use Emacs normally, then Org Capture might be faster. Every time I finish something, I go back to org mode, mark it DONE and then reorder my TODO list. It only takes about 10 seconds to reorder the TODO list and it's useful time for me to think about what I'm doing. The easier bit for keeping context is tests. As I'm getting near the end of the pomodoro, I make sure that I have a failing test. If everything is passing at the moment, I quickly write a failing test. When I return from the pomodoro, the first thing I do is run the tests. This shows the failing test. At that point, I only concern myself with fixing that test. If you are used to doing TDD, then it usually only takes 30 seconds or a minute to fix the failing test. This is like a bit of a boot loader to get you back into the problem. After the test is finished, I go to the TODO and reorder them. Often it doesn't have to be reordered, but the act of thinking about priorities restores the context for me. Currently, I'm doing some experiments where I am recording myself doing a large kata where I do one pomodoro per day (the ultimate in context killing). I don't have any conclusions yet, but the techniques I describe above seem to be working well. I'm using Asciinema to record myself and it elides portions where you are idle for a certain number of seconds (I have it set to 2 seconds). In other words it removed bits where you are doing nothing for more than 2 seconds. By comparing the actual time spend to the length of the recording, I can see how long I was idle. At the moment, it seems to be averaging about 5 minutes for every 25 minute pomodoro. That doesn't seem to be excessive to me (since I am reading documentation and thinking occasionally).
- mands 11y agoFor coding I find that 45m work with 15m breaks (and a 30m long break) work better as you have enough time to get into a problem, and just enough of a break after to send some emails / browse HN, etc. The overall work ratio is lower (75% vs ~83%) but it's hard to put an qualitative efficiency metric when programming anyway so I'm not so worried. This ratio also worked super well when writing my dissertation - the 5m break never felt like enough of a reward after. (there is also a great Pomodoro extension for Gnome if you're running Linux).