When I'm going back to an old complex project, how can I restore my focus and motivation?

Question

I've had a few weeks break from a large and difficult project that I've been working on for two years. The project could be a few weeks from shipping, if I can manage to focus on it.

I've noticed a few things that make it difficult for me to finish it:

1. I'm distracted, I'm thinking about other opportunities, even if the voice of reason tells me I should stick to this one.
2. I somehow lost the motivation to see my application shipped. For the most time I felt like it was going to be an awesome product but now I can't get my confidence back.
3. I left it in the middle of solving a very complex problem. To start coding again I need to have a full picture in my head of what my options are. Neither notes, nor drawings work for me, so I have trouble recreating my mental state from when I abandoned the project.

I feel like my problem is lame, but then I know many people abandon their private projects. I really see a pattern here. But I hope there is some mental trick/exercise that can help me a bit?

Answer 1

I had a similar problem with a large scientific writing project which was "inactive" for 1.5 years and it was very difficult to get back in.
And sure the first step is the most difficult one (for each new attempt to work on such a project).

What helped me:

• read my text and see what's already there
• talk to colleagues which can judge the value of the work
• ask yourself honestly why you want to finish it?
  What in life (yours or others') will change, if you have finished it?
  Is that worth the effort?
  Yes?
  -> Than get started (like Gary R. says: (1) collecting what has to be done and (2) do it!)

Falcon and Gary R. already gave good advice.

I'm not a software developer, so I have no special experience with the milestones of such a project, but I imagine:

you're coding not only for yourself but something which other people also could use?

If this is at least part of your goal/motivation, than you could/should get in contact with the potential users of your software. That might motivate you and also show which features to concentrate on...

Answer 2

1. Quickly jot down what you need to complete before you are ready to release.

2. Scratch off everything that could wait until after release.

3. With the remaining items, sort them by priority.

4. Set aside time to attack each one-at-a-time. When you finish an item, give yourself a reward. It can be as simple as writing a Tweet that you finished one more thing. Whatever makes you feel good about the project.

5. Talk to a friend. If you have a fellow developer that you trust...talk to him/her. If not, join a club and share. Excitement is contagious so know that people will find your work interesting and valuable.

Answer 3

Well, my friend, when you have a dream or a vision of a product, there'll always be the point when dreaming aspiration turns into laborious doing and reality makes your dream fade and clouded.

I'd advice you to recall the spirit of the time when you began your project. Find a way back into it and just overcome the hardships by sheer discipline. Envision your final product, how the users will use it and love it. Get back into it because a refined product is worth it while an unfinished product is of little value. The time invested is already too precious to abandon the project. Tackle the hardest parts first and then have a nice journey towards a polished product. Be proud of your work.

Answer 4

It's rather a tip than an answer to your question, but you may reward yourself for starting first task of this project. That little trick should motivate you to continue working and finish the project.

More info here:

http://lifehacker.com/5839224/reward-yourself-for-starting-difficult-tasks-to-stay-motivated-enough-to-finish-them

Answer 5

I'm a solo developer and have this problem all the time: I develop something, bugfix for a few weeks, hear nothing for a year then they come back and ask for new features meaning I need to get "back into" the project. Some of these are quite sizable projects (for a solo developer), and I've had to develop a way of coping with it...

While working through a project I make these assumptions:

• I may drop the project at any point and not get back onto it for an indefinite period of time.
• If I leave the project without documentating it properly, I'll lose hours or days figuring out where I was before I can actually do work on it.
• I will rarely have opportunity to document it retrospectively to the point I'm confident I could return to it after an indefinite period of time (which for me is the whole point of documentation).

My answer to these problems is to...

• Document very simply in the present tense why each part exists, what it does, and why it does it that way.
• Do this BEFORE I create that part.

The advantages of doing this are:

• Your can pause the project at any point and know it is fully documented.
• If you follow this principle, the documentation is always up-to-date.
• Spelling out "what and why" is an effective way of exposing bad design choices before you make them (have you ever documented something, and as you've written that, thought to yourself: hold on that's dumb, but its too late now...)
• Explaining "what and why" (as well as evaluating against alternatives) is probably more useful in helping you understand the program and appreciate the logic behind it (whether it was designed by someone else, or by yourself in a distant past) than verbosely detailing how it was implemented.

The last point is very important and so easily overlooked: if you don't understand the logic and validation behind the design decisions, or think the logic is flawed, you'll find it hard to stay motivated to work on the project. If you secretly desire to scrap it all and start from scratch, that's a good indication you have this problem. I document my projects not just to remember where I'm at when I get back onto it, but also to ensure I feel positively about it when I do. Do not overlook this aspect of motivation/documentation!

It may help to think of it as documenting as if you were to provide the best handover experience humanely possible to someone who is equally skilled as you, but with no prior knowledge of the project (i.e. you in a few years time).

If you pick up a project which doesn't have this, then buidling up this kind of documentation is a good way to get to grips with the project and to feel positive towards it.

Answer 6

Regain control over the project gradually.

The main problem concerning old projects, as for me, is that you forgot the overall structure and the details. You are stressed because you are not at control, the project isn't in your head.

To overcome this, give yourself some time. Don't create anything new. Learn. Read the documentation, list of tasks, history, wiki and all the meta information you have on the project. At some point you'll feel that now you have a complete understanding of it and you're ready to do something.

Answer 7

A body in motion wants to remain in motion. A body at rest wants to remain at rest.

There is some inertia to every project, but by forcing yourself to go on, you can start to regain a little momentum. The bigger the tasks are, the harder it is to regain that spirit, and the harder it is to stop working on it once you've started. Unfortunately, you will have to slog through it right now.

Hopefully, you should have made notes, have a to do list, maybe some bug list somewhere. Start with doing the little bits first. Maybe do a little design or simply set aside a day/hour/half-week detailing how exactly you plan to get started on this.

For all my personal projects, I often write down a 'design philosophy'. The design philosophy would be some high level vision, detailing what it would look like when it's done and the reason I developed it in the first place. I find it important, because there will be times later in development where you have to make difficult design decisions, and the design philosophy is a good way to stick on the right path. It's also good to help you realize why you should be committed to it.

Answer 8

Lots of good answers here, and I personally use a combination of them.

The most important for me:

1) Momentum is a subconscious motivator
2) Start with tiny improvements 
3) Increase time and scope gradually
4) Momentum will take over and you'll get into "flow".

More details:

1. Lots of advice I've read over the years includes "visualization of happy outcome OR painful consequences". Neither one has motivated me. The only thing that motivates me is progress. So at first, when I know I haven't touched the code in months, I'm at a stand-still. And it's VERY difficult to start. But since I've discovered the key is momentum + progress (no matter how small), the solution for me is to FORCE MYSELF to start. Even though it's "mentally painful".

2. So start by saying to myself: "I'll do only 1 hour today. I'll only review the code and try to understand it a little. I'll make changes to comments only, even if it's just fixing typos." Max 1 hour. The only goal is exploration and fixing typos :)

3. Then every day after that, I increase to 2/3/4/whatever hours and dive a little deeper in the code. Still just learning and poking and experimenting.

4. At certain point, I'll just forget about my time limit and I'll be in the "flow" and the momentum will just come. The motivation will be subconscious: get it fixed and working. No need to tell myself or visualize success/defeat. It just comes naturally.

If it doesn't come right away, just keep using the time limits. Eventually "the code will all be in your head" and you'll make progress naturally.

No amount of self-talk will solve this problem. You have to force yourself to do a little more every day. This is how it works for me.