I don't know if this will help you at all, but perhaps it will.<p>First off, I think there's a myth about productivity. That you are only productive when you are writing code. That's not true.<p>The way I work is that I need to have a fully formed idea of the solution to a problem before I start writing code. That doesn't mean it's the correct solution. But I have to start with an idea of how I'm going to solve the problem.<p>Sometimes that takes 10 seconds, if it's a new feature. Sometimes it takes 10 days if it's a bug I don't understand. Sometimes it's 10 hours for a totally new project. Could be anything. But I always start with documenting things in my way: offline. Your notebook and a good pen are your friends.<p>I do my best thinking at this state away from the computer and away from code. I do it best walking around. Once I think I know how to solve the problem (usually wrong for larger projects and bugs; usually right for new features in an existing project), write down what you intend to do on paper. I know Project Management tools exist for this task, but they don't have the same connection for me as physically writing something down.<p>As I'm doing that writing, I'll realize a lot of things that are bad about this approach and correct myself. And then my brain will start to organize tasks and group them. While I'm going through this exercise, I will set checkpoints for myself. If it's a ticket for a bug that needs to get fixed today, well, maybe I'll get lucky, and it's one and done. Other times, not so much.<p>I also try to organize my work segments vs. my thinking segments around my meeting schedules. Because even when my day is broken up by meetings, I'm still probably thinking about my problem.<p>Building in your checkpoints by planning your work this way has been very helpful for me, not because I need to check facebook or twitter or HN, but because it represents tangible progress.<p>But if you actually look at my workflow, it's a constant iteration of think a lot, followed by pounding out some code for a few minutes. Sometimes that ratio is very small on the code side, and sometimes it's quite large on the code side.<p>Without making comments as some other people have about medical or mental problems, I would suggest this: that there's a lot to be gained from working in very small chunks and that if you're worried about momentum, perhaps that's the problem you should be trying to address. Momentum is a tremendously overloaded word, and you shouldn't be trying to evaluate yourself based on your ability to obtain or maintain it.<p>I have a fairly similar pattern to what you are talking about. Solve a thing; then think about the next thing; then solve that. No one has ever complained about my productivity. On the contrary, people sometimes wonder how I can get so much done when I spend so little time "working."<p>Different people work in different ways, and I don't think that's a thing to worry about. I've really never very much experienced what people call the zone in programming. I certainly do as a musician when I'm practicing my violin. My girlfriend hates when I practice violin because I absolutely cannot be taken out of that mental space.<p>As a developer, I don't care about the context switch or the momentum or focus. I can go back and forth. No big deal. So I can understand why this can be problematic. But it might not be.<p>Questions to ask: are you being told that you aren't productive enough? Are you feeling like you aren't doing good enough work? Or enough good work? Where is this criticism coming from? Is it external or internal? Why do you want to change your patterns?<p>One of the things that technology companies need to realize is that there are more ways to be productive than just by being in your chair.<p>I'm my most productive when I'm not writing code. I'm my most productive when I'm solving the problem. And then the code is just a translation of what I've figured out.<p>When I follow this path, I find that my thoughts are more often wrong than right, and I don't have to worry about getting up and thinking or rewarding until I've fixed my thinking about the problem and proven it to myself through code and tests. And when I get into that mindset, I can't stop until I've corrected myself and crossed everything off the list in my notebook.<p>Take that for what's it's worth. I'm just one person. And I could be wrong about all of this. But I think I understand a little of what you're talking about, and this is how I deal with it.