Ask HN: How do you stay motivated when the project gets stale?
23 comments
ToDo lists. I find that when I get bogged down for any reason, if I create a todo list of items that have to get done I'm more likely to do the items on the list. I tend to pick up momentum as I cross items off the list. Make the list a manageable size, finish it off and create a new one.
For product related tasks, getting actual users and feedback from them is a huge motivator as well.
For product related tasks, getting actual users and feedback from them is a huge motivator as well.
I don't think I'd get any work done without my todo lists. Here's what works for me:
- Make the list a manageable size. I find more than 30 or so items overwhelming.
- Never let the list run out. I add new items constantly. The last ten or so items all read 'Expand this item: (some high level feature that can be broken down)'
- Mix easy and hard items. Striking an item off the list is satisfying, so make sure that after a particularly hard item, you can breeze through two or three more.
- If you're encountering a lot of hard items, spend some time expanding then into separate line items.
- At the end of the day, don't give into that temptation to polish off the easy item at the top of the list. Otherwise you'll work your way through a couple more easy items and end up having to start the day at a hard one.
- Have a visible backlog of your completed items. It's satisfying when you feel like you aren't making progress.
- Always attack the list in order. If you find yourself needing to move items around to satisfy dependencies, go right ahead, but if you skip and item because you just don't feel like working on it, at the end of the project you'll have a whole list of items you don't feel like working on.
- Make the list a manageable size. I find more than 30 or so items overwhelming.
- Never let the list run out. I add new items constantly. The last ten or so items all read 'Expand this item: (some high level feature that can be broken down)'
- Mix easy and hard items. Striking an item off the list is satisfying, so make sure that after a particularly hard item, you can breeze through two or three more.
- If you're encountering a lot of hard items, spend some time expanding then into separate line items.
- At the end of the day, don't give into that temptation to polish off the easy item at the top of the list. Otherwise you'll work your way through a couple more easy items and end up having to start the day at a hard one.
- Have a visible backlog of your completed items. It's satisfying when you feel like you aren't making progress.
- Always attack the list in order. If you find yourself needing to move items around to satisfy dependencies, go right ahead, but if you skip and item because you just don't feel like working on it, at the end of the project you'll have a whole list of items you don't feel like working on.
I've found it's one thing to make a ToDo list, but completely another thing to complete the items on it. What I've found is that there are actually (at least) two major things that get in the way of finishing up projects. The first is knowing what you need to do, which a todo list solves. But, all too often I used to stare blankly at the "todo" list, and while it was comforting to know what needed to be done (and actually quite fun to come up with these things), I'd still have the overarching feeling that "it's really going to suck doing these things, and I really don't want to do them."
The way I get over this second hump, the way I actually get myself to do things that I know need to be done, is pretty simple. I sit down and imagine how it's going to feel when I finish doing these easy tasks, and how I'm going to feel when I've conquered this list, and seen my idea through all the way. I know it's going to feel great to finish the things, so why not just do them already? The more I think about it, the more I get excited to go to work.
If your goal of completing your todo list is "I get to feel what it's like to conquer these things, to completely realize this idea or project of mine from beginning to end" as opposed to "I just need to do this drudgery," then you might find yourself being propelled by your own desire to feel good, and you might even have fun doing it.
The way I get over this second hump, the way I actually get myself to do things that I know need to be done, is pretty simple. I sit down and imagine how it's going to feel when I finish doing these easy tasks, and how I'm going to feel when I've conquered this list, and seen my idea through all the way. I know it's going to feel great to finish the things, so why not just do them already? The more I think about it, the more I get excited to go to work.
If your goal of completing your todo list is "I get to feel what it's like to conquer these things, to completely realize this idea or project of mine from beginning to end" as opposed to "I just need to do this drudgery," then you might find yourself being propelled by your own desire to feel good, and you might even have fun doing it.
In response to the above replies, there are good and bad ways to write to-do lists:
http://www.43folders.com/2005/09/12/building-a-smarter-to-do...
http://www.43folders.com/2005/09/13/building-a-smarter-to-do...
http://lifehacker.com/270404/the-art-of-the-doable-to+do-lis...
and my personal spin:
http://vmi.posterous.com/epic-to-dos
http://www.43folders.com/2005/09/12/building-a-smarter-to-do...
http://www.43folders.com/2005/09/13/building-a-smarter-to-do...
http://lifehacker.com/270404/the-art-of-the-doable-to+do-lis...
and my personal spin:
http://vmi.posterous.com/epic-to-dos
Not leaving the polish for the last. I've noticed that it's bugfixes and the final polishing that are the most tedious (everything's done and most of it works).
I now polish, test and debug every bit of the project as I go along. It's very tempting to pinch all the fun parts out of the project right away (the core functionality) and leave the little stuff to the end, but this is gonna leave you with heck of a lot of little things to do after the project's ready.
But once you're already trapped in the little things, it's the todo lists: dividing it all up into as little pieces as possible and going at them one by one. This also forces you to measure how much of it is still to be done - otherwise you feel like every one of those last bits is going to be the last one. And when it isn't, it's going to feel like puke. .. and fixing bugs like this is also prone to create other bugs.
I now polish, test and debug every bit of the project as I go along. It's very tempting to pinch all the fun parts out of the project right away (the core functionality) and leave the little stuff to the end, but this is gonna leave you with heck of a lot of little things to do after the project's ready.
But once you're already trapped in the little things, it's the todo lists: dividing it all up into as little pieces as possible and going at them one by one. This also forces you to measure how much of it is still to be done - otherwise you feel like every one of those last bits is going to be the last one. And when it isn't, it's going to feel like puke. .. and fixing bugs like this is also prone to create other bugs.
I've tried that but found that it's best to polish at the end. Nothing wastes more time than throwing away polished code. I don't fine tune anything until I'm sure I'm going to use that code in production.
You need to internalize a desire to use the finished product. In otherwords, you have to want the finished product.
This is probably a horrible misquote, but I remember a long time ago John Caramack saying that what drove him to fix all those little stupid bugs at the end of a product was the desire to play the finished game.
Others who just wanted to ship it were having a tough time sticking with it since they just liked developing cool tech and wanted to move on to the exploratory phase of the next project.
Now, if it's a clients website you have absolutely no interest in and can't figure out a way to have an interest in (coding for it's own sake), you've got bigger problems :)
This is probably a horrible misquote, but I remember a long time ago John Caramack saying that what drove him to fix all those little stupid bugs at the end of a product was the desire to play the finished game.
Others who just wanted to ship it were having a tough time sticking with it since they just liked developing cool tech and wanted to move on to the exploratory phase of the next project.
Now, if it's a clients website you have absolutely no interest in and can't figure out a way to have an interest in (coding for it's own sake), you've got bigger problems :)
For me, interacting with actual users motivates me to "polish" a project. I can imagine it is very tough if you can't go live. Not launching until things are perfect seems like a problem in and of itself.
When I have issues of this ilk, I look for the next, absolutely concrete, thing I can do that will result in a payment.
My take on this is that finishing up the last 10 percent is what separates the seasoned pro from a newbie developer. Correctly judging, assessing, assembling a view of exactly what is lacking from a project to make a tight release is and making a big list and iteratively finish it off is immensely satisfying for me. here's where actual software for other humans are created, design decisions evaluated and put to the test. Will it hold or require too much glue code, making a big refactoration à future must?
i force myself to like this stage and i like it more and more as i am less motivated by designing systems from ground up since that has become easier over the years, and I am mostly building web apps.
i force myself to like this stage and i like it more and more as i am less motivated by designing systems from ground up since that has become easier over the years, and I am mostly building web apps.
I would like the answer to that question as well... Although I have this problem with my personal projects (that are supposed to be "fun"), not so much professionally.
The problem is that when I get bored with (which might happen very soon, as in, after a few days), it stops being fun... so then your choices are to go on anyway, in which case you're doing drudge work instead of something enjoyable, or move on to a different project, which will likely meet the same fate.
I haven't found a solution for this yet, although I suspect that it might help to have a few other people working on the project as well.
The problem is that when I get bored with (which might happen very soon, as in, after a few days), it stops being fun... so then your choices are to go on anyway, in which case you're doing drudge work instead of something enjoyable, or move on to a different project, which will likely meet the same fate.
I haven't found a solution for this yet, although I suspect that it might help to have a few other people working on the project as well.
There is no easy fix for this. You need to be disciplined enough to keep working when you've done all the fun parts.
The good news is that if you can get better at being disciplined just by practising it, and the rewards are very high, because you become a finisher, and people like and value finishers.
Also, the act of finishing is immensely enjoyable, and is therefore its own reward. With practice your mind will begin to be motivated by that reward, once the little rewards of the early parts of projects have gone.
The good news is that if you can get better at being disciplined just by practising it, and the rewards are very high, because you become a finisher, and people like and value finishers.
Also, the act of finishing is immensely enjoyable, and is therefore its own reward. With practice your mind will begin to be motivated by that reward, once the little rewards of the early parts of projects have gone.
The act of finishing should be enjoyable but what if it's not? Are there any tricks to make yourself be happy about the finish?
Yes. Sit down and imagine how you're going to feel when you are finished. Really try to make yourself believe that you're done. If these are features, imagine using the product with those features in place, and how much it adds to it. If it's design, think about how much better it's going to look when your through with it. If it's performance, think of how your product is now more capable of handling more requests or is faster and lighter-weight feeling. Whatever it is on the todo list, I'm sure there's a good reason it's there.
Now that you've imagined how much these things on your todo list are going to improve whatever it is you're working on, and how awesome it's going to be when those things are in place, why not get to work?
Now that you've imagined how much these things on your todo list are going to improve whatever it is you're working on, and how awesome it's going to be when those things are in place, why not get to work?
I think exline's comment about todo lists is helpful - I find it psychologically satisfying to strike off the last item on a list.
There's extrinsic rewards of the finish, like getting paid, having something to show on your portfolio (depends on the work, obviously), not getting fired, etc.
I quite like getting things I don't enjoy finished because then they're gone, the mental energy devoted to them can be reallocated.
The work is not only the flash of the new shiny. Those pesky issues and small annoying bugs are part of the work. Try to raise your perspective from 'what's new' to 'what's great' and 'what's great' requires focusing on what the client needs rather than on your excitement. Delivering what someone needs will, in the long run, give you more enjoyment than the fun of exploring the unknown.
Deadlines. Find an excuse to set a hard deadline with real consequences up front and stick to it. The results are dramatic.
What I do—and this is definitely easier in a startup where you have a greater ownership stake—is to take pride in efficiency. The number of bugs fixed. The number of tweaks produced.
Having a nice low-friction issue tracking system can help with this. I like Pivotal Tracker.
Having a nice low-friction issue tracking system can help with this. I like Pivotal Tracker.
> The number of bugs fixed. The number of tweaks produced.
possibly even better: the number of bugs not produced
possibly even better: the number of bugs not produced
Well, that is probably something you can't keep track of.
[deleted]
[deleted]
money
Any advice?