5 ms·
Finish The Projects You’ve Started
- evanrmurphy 17y agoI 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.
- wheels 17y agoI 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 17y agoThe 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.
- martythemaniak 17y agoI'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.
- huwshimi 17y agoPeople 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.
- zackattack 17y agoThis site is great
- Tichy 17y agoI 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 17y ago> 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?
- wedesoft 17y agoTest 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.
- vlisivka 17y agoProgramming 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).