Ask HN: How do you stay focused while programming/working?

While not pseudocode per se - my offline coding is predominantly outlining structures and data flows; so how I would structure the application (classes etc - where what code would reside etc). Then I expand from the structure to start moving the data objects themselves around (also giving an overarching structure to the data objects as well), where the flow / control logic starts coming again. Sometimes I'll write a few transformers / mappers there as well if they're needed when sending / fetching data from a few places.

Usually you can speed this up greatly by following the conventions of a framework; for webapps I would design the models/controllers/routes/views, mobile apps would be navigation tree, views (screens), components, and if there's a lot of data, then mappers/reducers etc. So it's usually small descriptions (even one or two words) of what a given class/object/action is doing, where it's coming from and where it's going. I can then expand this to be very specific with fields, routes etc, and what they're all doing.

Having that basic, overall structure done offline means I can approach the coding with purely an implementation mindset and don't have to worry about the "big picture" when doing all the small bits - when you start coding immediately you're on a bit of a discovery path with the big picture, and the implementation details, and changing stuff on the fly etc, which can be rather time consuming / side track into different places and so forth.

Most of what I do is just take data from one place, change it somehow, and present it somewhere else - so it makes the above fairly easy and effective for my work.

It's playing mostly chillstep and slow electronic music with decent or no vocals.

First off, I think there's a myth about productivity. That you are only productive when you are writing code. That's not true.

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.

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.

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.

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.

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.

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.

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.

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.

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."

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.

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.

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?

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.

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.

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.

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.