3 ms·

5 minute pomodoros sound like a horrible idea. The pomodoro technique is supposed to employ half-hour blocks. You should try the pomotodo iOS app. It takes care

by Kinnard 11y ago

5 minute pomodoros sound like a horrible idea. The pomodoro technique is supposed to employ half-hour blocks. You should try the pomotodo iOS app. It takes care of a lot of the overhead and keeps track of all the data for you: https://pomotodo.com/ https://pomotodo.com/

mikekchar 11y ago
In fairness, I did say it was a crazy idea. I can certainly understand that it sounds like a horrible idea, but I think you might have missed the bit where I said it was working fantastically well. ;-) I have done 25+5 minute pomodoros many, many times. It is a good technique. In many ways the 5 minute pomodoros are not that much different. You could treat it as normal pomodoro with a timer going off every 5 minutes. What the 5 minutes timer gives you, though, is a sanity check about what you are doing. Because you have to write down what you have accomplished, if you feel you have accomplished nothing in that time, it gives you a quick way to change gears. The main advantage I have been getting from this is in difficult problems. I'll spend 5 minutes assessing the situation and then realize that I'm not really any further along (i.e., it's going to take me 20-30 minutes just to figure out what to do). So I start to think, "Is there anything I could do in 5 minutes that will give me a place to start?" It's tempting just to read code for half an hour, or step through with a debugger, or whatever. The "what can I do in 5 minutes", limits you to selecting partial solutions and decomposing your problem from there. This has improved my productivity quite a bit. Similarly, I have often looked at something and thought "I'll just refactor that quickly". Then the 5 minute timer beeps and I'm forced to think, "Is this really a fast refactor? Can I get it done in the next pomodoro? Was it really a necessary refactor?" Sometimes the answer is "no", which saves me a lot of time chasing things that are unnecessary. Sometimes I'm pairing with my partner and we disagree on approach. After 5 minutes, we're forced to write in our log "We were arguing". But the next pomodoro we just say, "Let's pick one and see what it looks like." Even doing it twice is often a lot faster than continuing arguing. Also when pairing, it is good to swap the keyboard frequently. 25 minutes is too long in my experience. What often happens is that the person who is stronger will dominate because they can write a lot of code in 25 minutes. Then they switch and the next person ends up playing catch up for their 25 minutes at the keyboard. Rinse and repeat. 5 minutes is not enough time to dominate the design. Also, it is easy for the navigator to stay focussed for that period of time and not wander off to check Facebook, etc. Ping pong is also another technique which is good for this problem. Org mode in emacs also works very well. The interface is exceptionally efficient. The nice thing is that it stores everything in text files. We can check in those text files into the project. Since we check in code every 4 or 5 pomodoros, the diff in the commit shows the changes to the TODOs and a list of things you did to make those TODOs change. If you review these commit by commit, you can also see where we planned to do something and then changed our mind. This last bit is especially useful because I live in Japan and my colleagues live in the UK. We pair together in the UK morning. My colleague will then solo code (or pair with someone local) in the UK afternoon. I will pick it up in my morning and we will meet again in my evening (UK morning). I call this "relay programming". By looking at the journal in each commit, I can easily see what my colleagues did and what they were thinking. It takes all of about 10 minutes to catch up completely and to be able to carry on effectively. It might not fit your programming style, but if you are doing XP style programming, I would recommend giving it a try. It has worked quite well for me.

by Kinnard 11y ago

mikekchar 11y ago

In fairness, I did say it was a crazy idea. I can certainly understand that it sounds like a horrible idea, but I think you might have missed the bit where I said it was working fantastically well. ;-) I have done 25+5 minute pomodoros many, many times. It is a good technique. In many ways the 5 minute pomodoros are not that much different. You could treat it as normal pomodoro with a timer going off every 5 minutes. What the 5 minutes timer gives you, though, is a sanity check about what you are doing. Because you have to write down what you have accomplished, if you feel you have accomplished nothing in that time, it gives you a quick way to change gears. The main advantage I have been getting from this is in difficult problems. I'll spend 5 minutes assessing the situation and then realize that I'm not really any further along (i.e., it's going to take me 20-30 minutes just to figure out what to do). So I start to think, "Is there anything I could do in 5 minutes that will give me a place to start?" It's tempting just to read code for half an hour, or step through with a debugger, or whatever. The "what can I do in 5 minutes", limits you to selecting partial solutions and decomposing your problem from there. This has improved my productivity quite a bit. Similarly, I have often looked at something and thought "I'll just refactor that quickly". Then the 5 minute timer beeps and I'm forced to think, "Is this really a fast refactor? Can I get it done in the next pomodoro? Was it really a necessary refactor?" Sometimes the answer is "no", which saves me a lot of time chasing things that are unnecessary. Sometimes I'm pairing with my partner and we disagree on approach. After 5 minutes, we're forced to write in our log "We were arguing". But the next pomodoro we just say, "Let's pick one and see what it looks like." Even doing it twice is often a lot faster than continuing arguing. Also when pairing, it is good to swap the keyboard frequently. 25 minutes is too long in my experience. What often happens is that the person who is stronger will dominate because they can write a lot of code in 25 minutes. Then they switch and the next person ends up playing catch up for their 25 minutes at the keyboard. Rinse and repeat. 5 minutes is not enough time to dominate the design. Also, it is easy for the navigator to stay focussed for that period of time and not wander off to check Facebook, etc. Ping pong is also another technique which is good for this problem. Org mode in emacs also works very well. The interface is exceptionally efficient. The nice thing is that it stores everything in text files. We can check in those text files into the project. Since we check in code every 4 or 5 pomodoros, the diff in the commit shows the changes to the TODOs and a list of things you did to make those TODOs change. If you review these commit by commit, you can also see where we planned to do something and then changed our mind. This last bit is especially useful because I live in Japan and my colleagues live in the UK. We pair together in the UK morning. My colleague will then solo code (or pair with someone local) in the UK afternoon. I will pick it up in my morning and we will meet again in my evening (UK morning). I call this "relay programming". By looking at the journal in each commit, I can easily see what my colleagues did and what they were thinking. It takes all of about 10 minutes to catch up completely and to be able to carry on effectively. It might not fit your programming style, but if you are doing XP style programming, I would recommend giving it a try. It has worked quite well for me.