Take the 2-minute tour ×
Personal Productivity Stack Exchange is a question and answer site for people wanting to improve their personal productivity. It's 100% free, no registration required.

Working on a big solo project (~15,000 LOC), I am encountering the following phenomenon:

I seem to work best when I program in short bursts of 10-15 minutes.

Right now I am working on a section which is a complete first time for me architecturally and if I have any architectural issues that emerge when doing the implementation, I seem to be able to best serve these by taking a total break. Then, later, sketching out the ideas on some paper. And when I feel I have sufficient clarity, then going back to code. This iterates until that architectural issue for that section is resolved.

This seems quite counter intuitive: that I can progress more quickly by coding less, and taking more breaks.

I am nearing the end of the sections which are "first times" for me, and about to dive into stuff which I am much more familiar and am wondering if this counter intuitive efficiency will continue. So my question is: even for regular coding of sections one is familiar with, which don't require constant re-clarification of the best architecture, is more progress to be attained by taking more breaks and coding in bursts?

share|improve this question

3 Answers 3

up vote 8 down vote accepted

Different people work best in different ways. The Pomodoro Technique encourages frequent breaks. The bursts are traditionally a little longer than yours, but you can set whatever times you want on the timer. I think by walking around, so I take a lot of "breaks" too.

When working on knowns, I think your span or work between breaks will increase. However, I think you will still take frequent breaks to reset your brain for efficiency. This is fine. Just keep a note of where you are up to. A failing xUnit test is good for this. As is a TODO comment in the code.

share|improve this answer
    
This is a good answer. –  Cris Aug 25 at 8:58

You say it's counter intuitive, but that's where your intuition fails. There is nothing wrong with your approach.

Taking a step back and letting the issue ferment for a while works. That's why you get your best ideas under the shower.

This is especially true when creativity is concerned, which is an aspect of a coder's job.

You also take on a different methodology (not just think without tools but as you say sketching out the ideas on some paper), which is a smart thing to do. It gives you more overview.

You seem to associate LOC and progress a bit too much ("even for regular coding of sections one is familiar with, which don't require constant re-clarification of the best architecture, is more progress to be attained"). Yes, with parts that are more 'regular' you will notice that when you are fully immersed in the construction of your code, you will take less breaks and write more lines of code. But when you're doing that less creativity is required. Creative parts take a different approach, do not translate that as 'being less productive'.


I have years ago adopted the phrase Good programmers are lazy, i.e. they initially seem to do nothing (or at least no coding). They brood on the right approach before hitting the keyboard.

share|improve this answer
    
Personally, I prefer to use paper for any creative 'brainstorm' or 'sketch' or 'outline'. I don't know why, but my creative juices flow so much better on paper than on any other brainstorming or mindmap app. I work in IT too, with an all-digital workflow, so the only paper I deal with is that which I created myself. I don't claim to understand it, but it works for me. –  IT Bear Aug 25 at 22:58
    
Actually my intuition works awesomely and suggests this approach to me. I used the words "seems counter intuitive" to emphasise the contradiction that a less-working-intuitive person may more easily relate to, and highlight the importance of break-taking, if that was unclear to you. Your answer displays a great understanding of this area, very well done. –  Cris Aug 26 at 13:58

You seem to ask three different questions: First is "most effective work habit for coding?" Second is "wondering if counter intuitive effeciency will continue" and third: "is it more effective to code with more breaks or less?"

I work very similarly, when encountering a difficult architectural problem. I am actually glad to see that the pattern is similar with somebody else.

It feels quite normal to require longer breaks when addressing new architectural issue, you need to lay it down, to see it from different angles. I sketch my initial attempts on a paper - a simple class diagram, sequential digram or an activity diagram and think of consequences of different design approaches. Sometimes I consult with design patterns if appropriate. Later on, it shows up, that I did not address some problems and have to redraw the design. It is so much easier to rethink the design, than to refactor existing code.

So I presume these are two very different things to do - to analyze and design and later to code it out. These processes thus can naturally have different steps. Usually I avoid writing code entirely, until I believe that the design I came up with will not have to be changed very much after I start coding.

I presume you will get back to your usual workstyle, when working on code you are familiar with. Think of it in a way that you were workstyle was different, because the type of task you encountered was not a coding task. You don't use a hammer, where a screwdriver is required.

@Pomodoro:

I worked with Pomodoro technique for a longer while, but I realized, that it was only good in the sense that it forced me to stop working from time to time in order to enhance productivity, but very soon I learned to hear my brain craving for pauses - it was more natural to work in the way brain scheduled its breaks, than to have a timer to do it for me.

See what Timeful blog has to say about taking breaks

share|improve this answer
    
Curious - wouldn't it be faster if you just did this on a piece of paper? –  Jan Doggen Aug 27 at 15:27
    
And you are not really answering the question. –  Jan Doggen Aug 27 at 15:29
    
You are right, I was so enthusiastic about answering just the topic question I completely forgot to read the description. Sorry. I will modify my answer. About the paper - depends on the purpose. I actually was working with a paper for approx. a year, while coding, but more and more issues led me to mindmapping. Firstly - papers crumble, often I crossed things off and it was hard to find relevant information. In a mindmap you just remove things and move them around, rewrite, etc. It's just a lot more powerful, I was never as effecient with a paper. And now to address your question.. –  Ev0oD Aug 27 at 15:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.