
Finish The Projects You’ve Started - yannis
http://www.happiness-project.com/happiness_project/2010/02/finish-the-projects-youve-started-or-call-an-end-to-them.html
======
wheels
I whole-heartedly disagree. Starting things is my litmus-test for deciding if
I'm going to take them further.

Examples:

• My usual way to pick a next book to read is to start reading 5. Whichever
one pulls me in the most wins.

• When sorting though startup ideas _many_ of them were for things I'd
prototyped / researched in the past, including the one that became Directed
Edge.

Unfinished projects leave _positive_ pressure for me to go back and do things
at some point in my life. Starting in on something is the best way to learn
its dimensions. There's this _pleasant_ queue of things that I'd like to
finish up in life at some point before kicking the bucket, and I suspect it
will only continue to get longer.

I'm not saying, "don't be a finisher" – but the important thing seems to
finishing _many_ projects, not _all_ of them.

~~~
jsharpe
The message is not that you must finish all of your projects, but that you
must decide whether you will finish them or not. If you decide to finish them,
then just do it! If not, then store it away somewhere out of sight. If you
want to go back to it, you can always pull it out again.

Unfinished projects create clutter, and for me (and a lot of people I know)
clutter depresses me and makes me less productive. I'd rather have unfinished
things filed away somewhere, than out in the open getting in the way of my
active projects.

------
evanrmurphy
I think people should also stress out less about unfinished projects. Lots of
failures and to-be-continued's (successes a plus too, obviously) is a sign
that someone has lots of projects. More power to you if you can get closure on
the projects that stagnated, but the merit is debatable if this effort takes
time away from pursuing more promising ones.

------
Tichy
I don't see the advice in this article. Surely, for any project, you either
finish it, or you don't. There is no other choice.

The only thing that seems possible is to decide for some projects to quit
trying to finish them and erase them from the mind. But the article offers no
help in deciding when to draw that line. Just because a project takes longer
than expected? I don't think that would be very useful.

It seems to me the advice here just mounts more pressure on projects. Now it's
not only "I should finish it", but also "I should decide if I finish it or
not" - merely letting them stay in some corner won't do anymore.

~~~
vlisivka
> I don't see the advice in this article. Surely, for any project, you either
> finish it, or you don't. There is no other choice.

Outsource? Delegation? Give away to community?

------
huwshimi
People often ask me how to learn more about building web apps and I give
similar advice (although I only talk about finishing projects, not culling
them).

So many of us have a lot of ideas. We get excited about some and start
building them. But not many get to the stage where they could go live. And of
those we launch not many get maintained.

Without launching an app it is hard to get the breadth experience that having
a working, live, active web app. You are forced to learn about marketing,
design, taking payments, feedback, user interactions and so much more. So I
encourage people to take a project they like and not only launch but maintain
it. This obviously requires having a decent idea to begin with, but that is
just part of the challenge.

------
wedesoft
Test of time: Once I read an article on a game developers website. The article
suggested to let an idea for a bigger project rest for some time (e.g. two
months). If you are still enthusiastic about it, then it's more likely that
you have the motivation to pull it off.

------
martythemaniak
I've started 4 projects in the last 4 months and am not more than 25% done on
any of them. I wish I could concentrate better so I can spend more time on
them, I really wanna see at least one make it.

------
vlisivka
Programming has low ROI(Return Of Investment) very often. Try to improve your
ROI, i.e. code small, reusable parts, then assemble big projects from these
small parts.

For example:

    
    
      * you can write code generator instead of code;
      * you can write (small) library first, then use it in your programs;
      * you can prepare templates and wizard program, which automates creation of typical code;
      * (for Linux) you can prepare package, which is easy to install.
    

General rule: try to save your future time, even when you need to sacrifice
some today time for that.

Just for example, every command line program needs option parsing. Write
template for typical option parsing routine, keep it in separate directory,
improve it over time, write generator, which will just substitute program
name. Even if your project will fail, you will still have this small piece
done, and it will save some of your time at every new project.

(Sorry for my English).

------
zackattack
This site is great

