Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How to stay focused?
56 points by mantas on June 1, 2009 | hide | past | favorite | 28 comments
Hello, I'm trying to work on my own startup for a while. I sometimes do some Ruby and Javascript contracting to burn trough my savings a little slower (ping me if you're looking for a part-time UI guy).

I've started to work on my current idea more than a month ago. But I'm going forward REALLY slowly. And, mostly, because I cant focus. I waste a lot of time on 'hacking here and there' or writing some small utility for myself.

Do you have any ideas how to stay focused on my main project? How do you get rid of hacking on side-projects too much?




You have to organize the world so that you get a series of small successes. And be prepared to take any success as a success.

Make it easier for yourself to accomplish things. If you can remove parts of your task list (punt for now or remove entirely) it can help -- a long todo list is demoralizing. I find that people generally try to build very large systems; this the enemy of productivity.

Choose a design that will allow you to arrive at as minimal a system as possible as quickly as possible, such that the system still retains conceptual integrity (that is to say, it is whole.) Then, afterwards, each time you sit down and do a bit of work, you'll have added a function or whatever instead of slogging along towards your first working system, which could be quite distant.

Finally, don't thrash when the working isn't happening. Instead, go goof off or go for a jog. This really helps. You can't work all the time, and if you've been pushing too hard your productivity gets diminished rapidly.


> Finally, don't thrash when the working isn't happening. Instead, go goof off or go for a jog.

Very true. Boils down to better time management overall. You're just as productive and a lot happier if you make work time and fun time separate, and you can be very generous with the fun. What you want to cut is "I intend to work but do something else instead" time.


You have got this down to a science, haven't you.


I don't feel very productive. Most of what I wrote is about doing things. Right now I'm at a company. Different skillset.


Use a revision control system, force yourself to commit only changes to one feature at a time. This restriction helps you to avoid wandering into other things, as it would take extra work to manage the unrelated changes.

"Release" frequently; if you don't have any customers, just pretend that you need to package something up. For instance, aim for a new build every day, and maintain release notes describing your changes. If you haven't been doing anything worthy of a new build each day, you quickly realize that you're losing focus and not moving the project forward.


very true. As a noob github user I find my commits to be very "ugly". Git encourages you to write a short descriptive sentence of what you did. For example "added validation checks to users class".

Well the way I code is to jump around all over the place and make little updates here and there. The commit messages end up appearing on files that have absolutely nothing to do with the commit. It's a constant reminder of how to be more structured and orderly. And also to value your time better, since you want to package up and send the damned commit already, you just have to get it done.

Works for me!


Actually, one of the benefits of Git over, say, Subversion, is that it's much easier to hack away on multiple things, and then arrange a series of sensible, self-contained commits from your messy working directory.

It's not necessarily a great way to work at all times, but it's a handy facility to have. Personally I use it most in the early, somewhat experimental stages of a new feature or project, when I find it useful to mentally separate experimental hacking with organised committing.

For most things, though, I try to focus on one thing at a time, and here Git's quick-'n'-easy branching and merging helps out. Whenever I start something new, even if it's just fixing a minor bug, I'll create a new branch just for that work, often naming it after the ticket number in our issue tracking system. Then your being in that branch is a constant reminder of what you're supposed to be working on.

Ryan Tomayko has written a good article on these aspects of Git here: http://tomayko.com/writings/the-thing-about-git


Have you tried using 'git add --patch'? It will let you commit isolated changes.


I had this very problem and what I did was use the Emergent Task Timer. Now, I know this sounds like lifehacker fluff, but it really worked for me. I used this:

http://davidseah.com/tools/ett/alpha/

Save it to your desktop and what you do is this, write 4-5 tasks you want to complete, and make sure you can hear the beep every 15 mins.

What I do is work on something, if I hear the beep and I'm still working, I keep going. If I hear the beep and I'm not working on said task, I go in to ETT and write what I did over the past 15-30-45-60 minutes. Make sure to put an entry for "IM", "Email", "Telephone","Bathroom" and "Food".

What happened is that when I started using it, I realized I only did about 2-3 hours of productive work a day. It took me a few months to push that up to about 7-8 in an 8-10 hour work day, but you get there by keeping track of how much actual work you do in a day.

Slimtimer.com also works well to this effect. Basically, just take the time to count where every minute goes. You'll soon identify where your focus is going instead of your project and be able to fix it.

Closing IM was key for me. :)


Try tracking how you use your time. Go make a grid with hours between 7am and 1am for Sunday - Saturday. Print this. Then write down what you do. I do this to hold myself accountable (I do not use it for planning). I find doing this keeps me on track and lets the little successes build on each other.


Go make a grid with hours between 7am and 1am for Sunday - Saturday

You don't even need to be that labor-intensive - the Emergent Task Timer works great.

http://davidseah.com/blog/the-printable-ceo-iii-emergent-tas... [links to PDFs are at the bottom]


Use RescueTime instead of tracking by hand: http://bit.ly/itYfb


Or stuff to do:

http://stufftodo.dedasys.com

Very different approach, my code is free/open source.


Actually, I AM building a time tracking app :)


Find a partner. For me at least, having someone else to work with is quite motivating.


pomodoro technique ?

http://www.pomodorotechnique.com/


+1 for this. The Pomodoro technique usually helps me when morale is low. You can always commit to a 25 minute push.

If you want to try it you should also check out my open source client, http://code.google.com/p/pomodairo/ =)


I looked at the Pomdoro site, and I'm intrigued. I don't understand something, though. How does it work with programming?

First of all, programming tasks defy time planning, as the next unplanned time-sinking bug or unforeseen difficulty always waits just around the corner.

Second, when you are in the zone, a timer going off every 25 minutes will just cause aggravation.


You can look at it as an agile process. You don't model your whole project at once, but when you start a Pomodoro you commit to working focused for 25 minutes. When the time is up you can prioritize differently or make a push on an unplanned item.

Also, I totally agree on your in-the-zone statement. I currently only use Pomodoro when I am having a slow day and I don't want to let the procrastination get the best of me. When I am in the zone I don't need Pomodoro to help me! =)


nice app - i also use timer-applet for nice Gnome integration on the taskbar


Nice app :) Thanks!


2 things: My natural style of coding is to work on multiple aspects of my project rather than concentrate on one aspect. Maybe this does make me less productive, but what usually happens is I get burnt out constantly thinking about the same problem so much so that I start to avoid working to solve it! Secondly when you say "slow", relative to what? When you are developing a system from the ground up, working it out conceptually takes tons of time, probably much more than actually coding at first.

I am pretty sure I code at a snail's pace, and 60% of my time is spent working the problem out conceptually. Yes I think the process is very SLOW, but I have accepted that the cost is the cost.

In other words, don't be so sure these problems are caused by your inability to focus. Maybe the problems are just problems, and slow or not, you need to get them done.


I felt the same when working on my startup, and something that helped me was to re-think what was required for my first release. Often it seems that everything you've spec'd out is required, but if you really think about it, you should be able to leave some things for subsequent releases.

Once you've culled some features like this, it's much easier to get excited and stay focused on that first release, as it will seem so much closer than before.


I can sort of relate since I'm in the same boat with my startup. The key for me was to set some goals for each week, tell my friends about them (to help keep me honest) and then to simply get cracking. Beyond that, I'd suggest that keeping focused can be as simple as calling yourself out for BS'ing. :)

As for part-time UI work, drop me a line -- I may have some stuff for you: paul.singh [at] philtro.com


Go full time on your idea. Or at least make some commitment so that there is a monthly burn(say a hosted server or a github account at the minimum). Nothing like pressure to keep one focused. This is from my own experience.


Rethink your idea. Maybe you are not 100% sure what you want, and jumping left-and-right instead of facing it.

Once you clear up and the path is found everything will go smooth.

Pragmatically, put yourself one question: What will go into the first release?


Make it a game: http://bit.ly/iGxMB


One word: ADDERRALL




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: