Ask HN: Staying focused on your project | Hacker News Reader

Ask HN: Staying focused on your project

55 pointstmaly41 comments

What tools or techniques do you use to maximize your focus on your project when you are working on it?

Lately I've been doing something a bit crazy: 5 minute pomodoros. I use org mode to maintain a TODO list of things I am planning (granularity of around 10 minutes each). I then work on them in order. At the end of a 5 minute pomodoro, I write down in log what I have done in that 5 minutes (it's got to be a quick one liner).

Obviously sometimes you don't want to break every 5 minutes, so my pomodoros actually seem to average about 9 minutes. However, the forced reflection after 5 minutes makes me think: am I doing the right thing, should I change direction, am I just staring off into space, etc. The writing down what I have done makes me realize that time is passing (which is hard for me). I try to make sure I have something to write down that isn't "continue with the previous thing". The TODO list helps me focus. Every once in a while I spend a whole pomodoro updating the TODO and planning what's coming up next. If I'm pairing, the end of the pomodoro is where we hand over the keyboard.

So far it has been going spectacularly well, but it's hard to sustain for a whole day. Make sure to take breaks ;-)

I learned about the pomodoro stuff (I do the 25 with 5s that is the default in a lot of places)

I'm pretty impressed by how well it seemed to work off the bat

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/

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.

I go to the coffeeshop with paper and pens only. Then I try to kill the ideas around what I'm working on right then and there, using a UX-centric focus. I've realized that my personality centers this paper design process, and works best if I try not to consider too many implementation decisions at this stage. The result should be something approximating a functional spec, with features and their rationale, asset lists, wireframes, etc. - a document that describes something that "should" already exist. The coffeeshop time is when I am most allowed to space out, enjoy the moment, doodle some things. What I'm really doing is batching together all the biggest emotional decisions of the day so that my remaining work is smoothed out - it's all execution without having to stop and decide.

Upon my return I turn the indicated design into Trello cards. When I want to do labor I look at the cards and pick one. Speed and terseness is essential for my retaining focus - having the paper design prevents me from compromising quality as I try to take shortcuts. If I get too much into storytelling while sitting at the computer, I may romanticize what I'm doing instead of doing it. If I have to send emails for business I try to keep a short timetable of a few minutes each; likewise with code. When I get tempted to narrate future work in my code, I deliberately make the comment barebones - a list of titles, for example, just enough to be a reminder. The cost of filling in the gaps in the comment could go to finishing the feature. If I need an additional level of documentation, that signals that I should go back to the paper design and the cards.

This is only most possible with solo work and a high level of familiarity with everything I'm doing. If I have to learn, then I have to go through a different process of playing and practicing before I can proceed so rigidly. And with team projects things are necessarily different.

A possible alternative for folks who like the idea of pen & paper, but also wish they could keep digital copies & not have to keep sheets of paper around - take a look at the Galaxy Tab A S-Pen models (or the Galaxy Note 10). I find it still puts me in the same mental mode as pen & paper, but with the added benefit of syncing my handwritten notes to Evernote so I can refer to them everywhere. I used to keep a clipboard full of paper handwritten notes, this has eliminated the clutter for me. I take my tablet a lot to coffee shops as well for planning & deeper thinking.

Taking a break from technology can be useful in itself though.

I've been working on an open-source project on GitHub for more than a year. It's not the kind of project that will ever bring me income obviously and it's not a success story, but I can relate to many of the challenges involved in building any kind of project.

The first problem is what happens after the novelty is gone. The Pareto principle applies, the last 20% of work needed to be done being the hardest. And we tend to start working on something, satisfy our initial urge and then move on. Well, a year and a half later I'm still working on it, even though I've had pauses that lasted for weeks or even months. For me the recipe is finding something that is worth solving. And given that my library was born out of necessities at work, plus a couple of users that started using my library, I felt enough responsibility to proceed. My library also has competition, but every time I've looked at the competition, I remember the very good reasons I've had for starting my own thing. And I'm now marching towards a 1.0 release that will be in good shape and provide API stability for some time. But now I'm feeling the second problem - how to market it, how to scale the development process and so on. I know that I've got something good on my hands, but I don't know how to convince others.

But the biggest problem is that this project is a love child. My problem won't be that I lack the motivation or focus to work on it, because I do, finding the focus necessary is effortless when you really want to work on something. No, my problem will be to let go of this project if the alternatives will evolve to be better.

Back to your question, for immediate advice - I'm the kind of individual for which time management techniques never helped, ever, as my problems are usually of inspiration and finding the necessary motivation. On motivation, having a child to feed surely helps :-)

But I can say that when I'm getting in "the zone" I'm 10 times more productive and when I get there, I tend to stay there for as much as possible, as getting in that zone is hard. And that means I stop my IM, I put my phone on silent (with my wife added as an exception) and I play music. Music helps me a lot, because I need background noise to keep my mind from wondering off. Also, I try to have a healthy sleep cycle and weekends are always for fun and relaxation. Rules like that can keep you from burning out.

>>> I've had pauses that lasted for weeks or even months. For me the recipe is finding something that is worth solving.

I can totally relate to that. Sometimes I feel that ok, this project is much more complicated than I expected, or maybe it's not that interesting really. Should I abandon it?

So I try to honestly answer to myself, am I just being lazy right now, or is it for real? I find it quite important to distinguish between these two.

If you are just feeling a bit lazy, just try to fix some simple bug, or update readme, something small like that. It can do wonders. Usually, opening the IDE and starting to write the first line of code is the hardest part :) even if you can't be bothered to do anything that night, that's cool. Don't be too harsh on yourself.

But sometimes, you genuinely lose interest in the project. In that case, I think it's fine to just quit (assuming it's a side project which isn't bringing any income and it never will, that kind of stuff). There's no point to push yourself too hard, it's too likely that the product will end up being a bit crappy since you've lost the interest, and you won't have much fun (which often is the top priority) either.

I try to (since it's not always possible) to have a list of small tasks, which normally would take me 30 minutes or less.

It's much easier to get distracted when you only have these huge ugly tasks where you have no idea where to start from. Which leads to the importance of splitting big tasks into many smaller subtasks.

i find writing / fixing tests is a good way to get started on something.

the subtasks usually become apparent very soon.

A work log page each day with a list of todos, notes, progress log, etc. in a personal wiki like MoinMoin. I use this more often than third-party sites like Wunderlist because I can use it with nothing more than Markdown in an offline text editor if needed. If it is a project I am having trouble staying focused on, then I also use the Pomodoro technique (https://en.wikipedia.org/wiki/Pomodoro_Technique). I tend to use a longer than usual Pomodoro amount of time, usually 45 minutes, then a 5-10 minute break, then 5 minutes to refocus before diving back in.

> A work log page each day with a list of todos, notes, progress log, etc. in a personal wiki like MoinMoin.

For people working on Windows I recommend using OneNote. It can work like a wiki but you can also put your blocks of text in a multi-column fashion instead of the usual single-column text. In this way you can quickly see a bigger picture of your project.

This is going to sound a bit weird but try treating yourself as the client.

Use some kind of issue management / agile tool online.

Track your time and then bill yourself weekly or monthly.

I can recommend Pivotal Tracker or Trello and Harvest app. Both are free for personal / small usage.

You will start to appreciate how much you have achieved, which features to prioritise and how much value (financially) you have put into your project.

Love the idea. I use KanbanFlow: http://kanbanflow.com because it combines Kanban with time tracking and a bunch of other features.

Loads of coffee, stomach not too full, sleep well at night, listening to music, disable all IM programs and e-mail clients. Attacking a problem that captivates me to get started. Sometimes it helps to leave a bug that you know how to fix in the program so the next morning you have an easy thing to get started.

Im sorry if this comes off the wrong way but- constantly realising this is the only thing between me, and achieving a decent house/life for my family.

Every time i feel tired, i force myself to realise what my life was, what it is now, and how much better it could be

Seconded. Free will is a real thing, but are you willing to use it?

I understand completely. I use that same idea for motivation.

There are two techniques/strategies I have used to become more productive. Both strategies revolve around the idea of not becoming distracted.

1. Stop "planning" everything and start "doing" things. I believe planning is a great way to procrastinate because you convince yourself you are being productive when you are not. Instead, I try to minimize my planning and keep things moving.

I stopped using planning tools such as Trello or other Kanban systems because they are so heavy and in the browser it makes it easy to get distracted and surf the web but also, those tools suck you in and you soon start 'planning' a lot of details instead of actually doing work.

I replaced my task manager with a simple command line tool I made myself (https://goo.gl/YF6Wsk). I am not sure if it would help anyone else but I use it every day. The premise of the tool is simple, minimize the time I spend outside of my editor. If I have to log tasks I do it and jump right back in my editor.

2. The Pomodoro Technique has helped me "get in the zone" because the technique makes you focus right off the bat.

I make sure that I have a high-level development course plotted out so I have a sense of progress from a bird's eye view, but I also keep a very granular todo list for my day-to-day things so that way I never fall into the "what do I do next" + feeling overwhelmed mindset.

Also, try to stay off distracting websites like HN, Reddit, 4chan, etc. On that note, gotta go!

   1. Decouple dev from analysis; work on only 1.
   2. Analysis at night with pencil & paper.
   3. Don't go to sleep without specific morning plan.
   4. Dev starts first thing in the morning.
   5. Always focus on WHAT to build, never HOW.
   6. NO INTERNET in same room as dev computer.
   7. Start with the data; the process will follow.
   8. 3 3-hour dev sessions per day.
   9. 1 2-hour analysis/review/refactor session at night.
  10. It's a marathon, not a sprint.
  11. Apparent failures are OK. May lead to something great.
  12. Take care of myself (diet, exercise).
  13. When I'm not working, I'm not working.
  14. Never forget WHY I'm building something.
  15. Weekly & monthly project plans, frequently revised.
  16. Happy dance whenever something really cool works 1st time.

> 8. 3 3-hour dev sessions per day.

> 9. 1 2-hour analysis/review/refactor session at night.

> 10. It's a marathon, not a sprint.

Ummmm....

Nice recipe for burnout. 11h per day is not sustainable, not healthy and hurtful to whatever you are trying to do.

I think that it's manageable, esp. if you are doing breaks for meals/exercise/etc. and getting enough sleep, even moreso if this is not an every day of the week plan (two days on, one or more off, for instance). Without any data on frequency or what this person is working on, you really can't make a blanket statement like that.

    NO INTERNET in same room as dev computer.

That one doesn't seem like a good idea, better work on impulse control if one can't stop himself from checking his facebook every 2 minutes than shooting yourself in the foot by cutting off an invaluable tool like internet.

It's like turning off the heating to avoid sleep-deprived developers falling asleep: a short term solution that doesn't solve the root of the issue.

I can relate to a "no easy internet" rule. It is possible to download a lot of important information (godoc, cppreference, perl man pages) so that internet interaction is minimised.

It is possible to plan what needs to be looked up. If you have to move room to look things up that sounds about perfect to me.

All projects have the stuff that's exciting and fun, and all the other stuff that's boring and dull, but needs to be done. I try and handle some of that boring dull stuff early when I have lots of energy, and try and save more of exciting stuff for later.

I've had trouble launching things when I've left that boring stuff till the end, and boy does it drag on getting that stuff done.

I've recently added a repeating popup reminder to my Mac - it pops up a dialog box every 30 minutes that says "Are you wasting time?". The answer is allowed to be "yes" sometimes - I need breaks - but the point is to make sure it's a conscious choice, and that 30 minutes of browsing or playing games doesn't turn into 2 hours.

How did you enable a popup to appear every thirty minutes on OSX?

You can use `osascript` to show a popup. Depending on which shell you're using, it would look something like this:

    for i in {1..4}; do
      sleep $(expr 60 \* 30)
      osascript -e 'tell app "System Events" to display dialog "Are you wasting time?"'
    done

Or just put the osascript line in your crontab?

You could do notifications via hammerspoon. It's probably overkill, but you could probably work in a custom active window time monitoring system.

I have the same problem and some of the techniques might help you: http://bookofhook.blogspot.com/2013/03/smart-guy-productivit...

(But my biggest problem is getting work done when I'm not interested in it anymore).

I am trying to use OKR in my projects. They help me to stay focused in what I need to do and see progresses every quarter. I am using WeekDone for tracking them.

Moreover, using Todoist for keeping track of my todo's, Quip for my documents and Trello as my default board.

Agree that taking breaks from technology and staying offline is very helpful to keep me focused.

Talk to users. When I know someone who's waiting for me to complete the next improvement, focus happens more naturally.

I stop answering emails and phone calls. I ignore anyone ringing the doorbell. Anyone of the above can result in an action event that creates a time-consuming task. (I've found that every time a neighbor comes by its almost certain to cost me money.)

I have a busy button on my phone, but I still get people walking in my office to bother me about trivial things. Sometimes I have to pull a Tim Ferris on them

I'm reading The Willpower Instinct (http://www.amazon.com/The-Willpower-Instinct-Self-Control-Ma...).

what do you like most about the book so far?

Reply on news.ycombinator.com