Live data from Hacker News

Always a starter, never a finisher.

plus.google.com

71–80 of 99 posts

Re: Always a starter, never a finisher.

#71
post #32

Don't tell people what you are working on before you finish it. http://www.ted.com/talks/derek_sivers_keep_your_goals_to_you...

I cannot disagree more. Opening up my ideas to ridicule and critique has been the best thing I've ever done. I don't waste time on the bad ideas, people get behind the good ones, and people see that I'm always doing something. I don't have to deal with the "what happened to that project you were working on" question much because my standard answer is "Boy was that a good learning experience! I showed it to X, Y, and Z and they gave me great feedback and inspired a bunch of new ideas that are more interesting. Take a look!"

Sure, I don't finish everything, but the important bit is that the things I fail to finish are less good than the things I do finish. This is the "fail fast" mantra in a slightly larger nutshell.

Re: Always a starter, never a finisher.

#73

As is probably common for most HNers, technically feasible ideas pop into my head daily. My mind leisurely constructs state and class diagrams while I'm taking a shower, by the time I dry off, my gameified crowdsourcing quant-bot seems like the most amazing idea ever. But what about my MMO and a dozen other half formed projects each with their own litter of bastard experimental branches? I was able to end this cycle…

I've found that that deflation comes from trying to live up to the expectations you've shared with others, rather than letting your project grow organically in isolation. I am a person who suffers from extreme shame for not being a finisher. When I grew up my dad used drill over and over "you need to finish things" and instead I just got worse and worse at starting things. I'd actually like to find projects now that…

I've found that that deflation comes from trying to live up to the expectations you've shared with others, rather than letting your project grow organically in isolation.

Very true! You know that this feature just needs to be dumped if the project has any hope of progressing, but you are now beholden to the image of your project before the constraints of reality set in. This is why every project with a high profile debut ends up missing part of the highly touted killer features.

Re: Always a starter, never a finisher.

#75
post #60

My father is an engineer, and he always taught me that there's no such thing as a good job half completed. The problem with his perspective is that it is uni-dimensional, and with good reason: if you half-build a bridge, people are going to be sad. He's an engineer and he's got to finish the bridge. However, my father didn't decide that a bridge was required, nor did he choose the ideal location for the bridge based…

I'm sorry, but you're kidding yourself if you think there's a lot of value in being an "idea man", or if you think that there aren't people who have both great ideas and the ability to see them through to completion.

I think it's amusing that you didn't finish reading my comment. Or perhaps you disagree that one person starts and finishes a complex project on a regular basis, I'm not sure.

However, I respectfully insist that I have made a successful career of being a Starter.

Re: Always a starter, never a finisher.

#77
I had the same problem for about four or five years in my early 20's.

I got really sick of being poor, that changed my behavior drastically. I had to start finishing things and making money off of them to improve my quality of life.

Fear of freezing to death and starvation are extraordinarily motivating.

Re: Always a starter, never a finisher.

#78
post #32

Don't tell people what you are working on before you finish it. http://www.ted.com/talks/derek_sivers_keep_your_goals_to_you...

I cannot disagree more. Opening up my ideas to ridicule and critique has been the best thing I've ever done. I don't waste time on the bad ideas, people get behind the good ones, and people see that I'm always doing something . I don't have to deal with the "what happened to that project you were working on" question much because my standard answer is "Boy was that a good learning experience! I showed it to X, Y, and…

I'm not advocating working on projects in secret. Once you have something even slightly ready, by all means share it.

Incessantly talking about what you're going to do before you've done anything isn't admirable in my books.

Re: Always a starter, never a finisher.

#79

My father is an engineer, and he always taught me that there's no such thing as a good job half completed. The problem with his perspective is that it is uni-dimensional, and with good reason: if you half-build a bridge, people are going to be sad. He's an engineer and he's got to finish the bridge. However, my father didn't decide that a bridge was required, nor did he choose the ideal location for the bridge based…

I am a closer, I finish things. I come in and make projects complete. I hit deadlines, I pay the bills, I write documentation, I do whatever it takes. I am the guy who makes everyone look good.

There is a 90/10 rule, 10% of the project is 90% of the effort. That 10% of the project is always at the end. I come in and slog through that last 10%. I'd much rather start new projects every day and hand my half-assed spaghetti code off to someone else to clarify and reduce into something maintainable. Unless you have worked through the project from beginning to end, some other poor schmuck probably rewrote all of your shit code from the beginning when you got distracted by your caffeine induced ADD and wandered away. Classifying yourself as a starter makes you about as useful to a software development team as an 'idea guy' is. Be a starter, but be a finisher too.

As you can tell, I'm bitter and grizzled and unhappy. But working on a good idea and not finishing it is about as useful to a software development team as masturbating all morning instead of coding. Successful software development is entirely about execution. Finishing is execution. I would go so far as to say that a good engineer is always finishing, whether at the beginning of the project or the end.

Re: Always a starter, never a finisher.

#80
The problem is following a "maximizing" strategy, instead of a "satisficing" strategy.

Maximizing means you do things based on what seems like the best possible path. Satisficing is focusing on the minimum requirements to reach your goal.

Never finishing seems to be a combination of maximizing when you don't need to bother, and also failing to identify the true requirements for you. In order for you to start a successful venture, there are a surprisingly large number of fixed requirements:

1) You need a product that people care about

2) That you can charge for

3) With a viable customer acquisition strategy

4) Where 2) × 3) = enough to support you

5) It needs to be something you can actually implement

6) That you can stay excited about for many years

The problem is that maximizers will start maximizing on some handful of these. Often they'll take #5 super seriously and start trying to execute perfectly on their vision, do great design, etc, etc.

But then at some point along the way they start to realize that even if they maximize on that axis, they haven't satisfied one of the core requirements. Indeed, the can't satisfy one of the core requirements. It's a depressing realization, and the only option is to jettison the idea and move on to something else.

Which leads me to my somewhat unexpected conclusion, that the solution to never finishing may well be not starting. Which isn't to say that you should twiddle your thumbs and not build stuff. Building stuff is a critical skill that you need to practice.

But just treat your projects like side projects. Don't start running off and thinking you're going to actually start a company until you have a project that you really think can hit all six requirements.

And don't try to maximize any of them. The important thing is to get all six cooking at an acceptable level.

Post reply on HN