Always a starter, never a finisher.
plus.google.com
plus.google.com
However, my father didn't decide that a bridge was required, nor did he choose the ideal location for the bridge based on urban planning and geographic surveys. And let's be clear — he's not going to be out in the rain, assembling raw materials into a structure either. His job would start with the design and continue with the project plan, and possibly end as a consultant or one of a team of over-seers. He's not finishing the bridge, but his role was necessary to get the project from where it was to where it needed to be when someone else would take over.
Technical projects are often the same. I'm generalizing, but you see a lot of supporting evidence which suggests that you have your visionary, your architect, your builder and your "last 10%"-ers. One person can be all of these things, but almost never all at once on the same project.
What I learned when I came of age was that I am a Starter. I have good ideas and the ability to rally others to a cause. I've evolved the ability to network and communicate. I've forgiven myself for not being a Finisher, because there are lots of people that hate starting and love to finish. There are loads of people who will never start and hate finishing, but they are the core team during the middle.
I suggest that you stop seeing your inclinations as a problem and start thanking your lucky stars that you have a regular flow of potentially great ideas. The main skill you need to develop is your ability to kill off the bad ones early so that you can focus your passion and evangelism on the winners.
Chances are, if you got bored it wasn't going to turn out well anyhow. Listen to what your subconscious is trying to tell you.
I think the idea of a person who does things from start to finish his highly romanticized and a lot less comon than whwat you might think. It's great for you to have the abilities to, but I don't think it's a reality to most.
I agree with most of this post, but I disagree with this sentence. It's very, very easy to trick yourself into believing that a great idea that you're working on is not actually interesting. The problem is that you've been working with the idea so much that you no longer are seeing the thing you're making with fresh eyes.
I know this because it's happened to me over and over again. My most salient example was when I was working on a game a few years ago. I got a month (this was during high school, so development times weren't that long :)) into development and started thinking it was crap, no one was going to like it - things like that. Normally, I would just stop and work on another idea, but this time I did something a bit unusual - I posted the game and asked for feedback from the game community. This was the turning point. They said that it was great, I should keep working on it, and they'd love to play it when it was done.
I finished it. It turned out to be my most successful game, ever. It netted hundreds of thousands of views. It's been on dozens of websites. And to think that I was completely bored and uninterested with it weeks before I finished.
Incidentally, I think this raises a great way of getting good at finishing: show your unfinished work to other people. If it's good, they'll love it, and the self-confidence boost you'll get from that can carry you further. And if they hate it, well, maybe you should be working on something else after all :-)
It's been my repeated experience that most people are unable to tell the difference between a good idea and a total dud. Certainly feedback helps, but I would also suggest that most people are trained from birth to only say things that they believe you want to hear. The people you know are almost unable to give unbiased feedback, and they can't help it. They don't want to disappoint you.
Learning how to effectively find flaws in your own idea (boredom is an ineffective but common approach) is an incredibly valuable skill. A bad idea well-executed is still bad.
The more accurate way to put this is "I am not a Finisher". The argument here is that starting and finishing are two equally valuable skills that are somehow equivalent.
A "Starter" is a fairweather friend. It's easy to start things. Most people like starting things. Note this is different from networking and so forth, which is really a separate skill altogether.
Employers, business partners and investors will look at what you've finished and don't care what you've started. When something is 80% done or when times are tough or it's time to soldier on and run the last mile of the marathon, nobody wants the guy around who says "well, I started, that's my skill but I'm done now, I suggest you find a Finisher".
Not being a Finisher isn't a different skill--it's a character flaw.
My firm is hired to implement concepts as working products. I first help the clients decide whether their idea has legs and help them refine the vision. My team builds out v1 over a period of months, and then we generally hand off to an internal team or another firm that will provide ongoing support. We maintain a pool of excellent resources that excel in maintenance projects but don't have the capacity or interest to be architects.
http://jacquesmattheij.com/The+Starter+the+Architect+the+Deb... was pointed out to me as another recent and good article on the same subject.
Finally, I assure you that successful Starters are excellent networkers and communicators. They have to be, or else the project will never leave the gates.
I'm a starter, but I know about finishing and I think it's a good skill to learn.
The ability to look at a vaguely specified problem and say "Okay, here's how we're going to attack it, and here's what we need to build to have something that works" is a very valuable skillset, and not everyone has it.
Now, remember that "finished" is not the same as "launched". Usually, my responsibilities continue up to the point where we can get a product into the hands of users and train the people who'll be maintaining it after me. But there's a fairly large role for maintenance programmers, people who are responsible for little tweaks even though the system is mostly working as desired, and if you're a Starter, there's no reason for you to do that work yourself.
I have had a similar position.
In both scenarios you see the same pattern: once things get off the ground, the co-dependency relaxes because the starter can always hire finishers, but not vice versa. Look at who you hear more about: Jobs or Woz? Gates or Allen? There's definitely a difference in their levels of success, and definitely in their personalities. (Not saying it's the only factors, but certainly important.)
Starter & Finisher are just different ways of saying that you need engineers who can build the foundations and get the project in a good prototype/working state. Yet, you will need engineers with a different skill set who are meticulous, product driven, detail oriented (however you want to phrase it) to carry it to the finish line.
I'd say both the original 80% team, and the remaining 20% team do about the same amount of work.
Now, just to "finish" my point, I'd say the 80% team definitely finishes their portion. They still have to get it in a state that is demoable and 100% functional.
However, I respectfully insist that I have made a successful career of being a Starter.
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 with a little technique. Tell no one about your ideas. Not a SINGLE person. Instead, imagine their faces when they actually see it. If you spend four months working on a project in secrecy and then become tempted to move on to something else that you're working on, you'll quickly notice that the burst of endorphins you get as you enumerate the features of your killer app is mostly absent. Suddenly, you realize that you're four months out and now you have to start from scratch before you can talk about how amazing your project is. If you can't help but talk about your projects, then become a hermit (that's what I did).
Besides, nobody knows what people want. Who would have guessed that the world needed another site to post and comment on photos? Would you validate that idea? Yet Pinterest thrives. Just do it, then tell people.
Additionally, if I'm able to get that burst of endorphins from people just by telling them what I've started, then I no longer have a strong enough reason to build up a list of things I've finished.
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 need finishing so I don't have to be the starter and I can focus on taking projects across the line.
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.
I decided to stick with it with the idea for two reasons:
(1) I'm tired of thinking on behalf of the market and would actually like to see what the market has to say for a change (this same principle worked pretty well in my love life, too, FWIW); and
(2) I could reuse some of the code for my other projects (true).
This weekend I started working on the first front-end use case after dealing with back-end stuff for the past 2 months off and on while simultaneously working an 8/hour day short-term contract with a 1.5 hour commute, on top of finding a new long-term contract after my previous project was cancelled, and even breaking up a relationship so I could stay focused. After feeling particularly exhausted from working non-stop like this and thinking I probably need to stop for a bit, I suddenly hit a point where I cracked up laughing at how awesome this thing that I was building was going to be, and I realised: I have GOT to follow this through, if only to see the look on people's faces it'll be worth it.
Creating things that make people laugh or look twice has always been something I've enjoyed, and if anything is going to motivate me, it'll be acknowledging this. The nice thing is that that is my raw personality, and I don't need anybody to tell me to stick with it, because I know I'm just expressing something inside of me that will connect with someone.
Curious what the distribution of those two opposite problems is like! Among creative types, it seems that the "stuck with it too long" problem is more prevalent in certain areas, like writing or filmmaking, but not as prevalent among hackers. I suppose one compensation for it being so common for hackers to fall into the "100 unfinished projects" trap is that it's less common to find hackers who fall into the trap of, "I stuck with the first idea I ever got for 20 years because I thought it was my One Big Idea".
Film and novels derive their quality from their plots. Plots transcend time. Although the tools involved in creating a movie or book may change (improved camera systems), the tools don't impact the plot much. Therefore, a book written thirty years ago can have the same quality as a book written today.
The quality of an application is unable to transcend time. Sure, the idea of creating a website to connect people might, but the quality of an application isn't usually based on the idea, it's based on the implementation. Implementations cannot transcend time; that's why technological masterpieces don't exist. A programmer who locks himself in his room and starts working on "the next Facebook" now won't be very successful in thirty years: when he launches, the whole technological landscape will have changed.
Programmers rarely work on something for too long, because they understand that their products are dependent on technology, which changes over time. What is amazing today is not amazing ten years from now.
The way to feed the habit is with success. To experience successes, I have found:
- first minimize your goals. The less to do, the faster to succeed. The fastest way to finish a feature is by removing it from the plan.
- work on one project, maximum two. Any more and you will always jump from a project when it gets hard or to the "not fun part".
The problem is 'feeling productive' and 'being productive' are different things, its very easy to be working weekends and nights on your project, its very hard to realise that the chances are the work you are doing wont make a difference to anyone, most importantly yourself.
The second part I agree with, when someone does give a shit what you are working on, 1. You will take the time to make it better, 2. You have already solved the problem of a busy but ineffectual work cycle, move your motivation from 'the next best thing that will be awesome' to 'something that someone other than me cares about right now'
The best way I could recommend to do this is to look at all your projects that are on your plate, pick the one that will take the shortest amount of time for other people to start using and caring, release it tomorrow even if it sucks, start pushing it out to everyone you know, get some feedback and get into a cycle of working off peoples feedback
First, indentify if you are stuck. Create metrics if needed ("if I don't advance this cuantitative variable in a week, then I'm officially stuck").
Second, when you are officially stuck, you need to make a formal and conscious decision to stop fully or keep going. Your current projects should have this 2 posible states: Stoped (with an optional of "until X happens") or Running.
PS: You also need to formally determine where the finishing line is. Otherwise, you'll never finish.
I never thought of doing this, but seems like a brilliant idea!
If your projects are really worth something, then it really shouldn't be difficult for you to "sell" the idea to potential co-founders on an equity, or part equity, part financial basis. If you cannot even sell it to developers or business people, then the idea is probably not worth pursuing and you should stop immediately, not weeks or months later.
On a side note, if you are spending 4 to 8 months on just design, you are probably doing it wrong. You really need to meet some smart people, work with them, and learn about each others' working habits. Developers won't blindly follow someone who can only design, and bring zero business sense into a venture. You either need to up your skills, get some more funding, find people who can fill all the holes that you can't do, or come up with better ideas.
Most importantly, you do need to learn from your mistakes, or learn how not to repeat the things that have failed you in the past. If you can't get past these relatively simple hurdles and make the same mistake over and over and over again, then you really should just get a job where you are assigned to do only one thing instead - and maybe learn to be happy with that.
Once it's out in the world and providing some modicum of value to me and others, I can start deriving joy from fixing that one thing or adding that other small feature that's keeping me from being able to do X.
Case in point: http://www.viainstapaper.com. I wanted to be able to see what people were sharing from Instapaper. I came up with the idea around 11PM on Valentine's Day, and spent an hour prototyping the Twitter search stuff in Ruby. The next afternoon, I slapped a Rails frontend on it, and called it 'launched'[1]. Over the next couple days, I found myself getting annoyed by missing features or nasty bugs, so I'd fix those. Once this subsided, I announced it to the world, and it's been pretty much running on autopilot since.
I wouldn't say it's set the world on fire, but it's gotten me the attention of Marco Arment, Max Linsky (proprietor of Longform.org), and a handful of other people whose opinions I greatly respect.
[1] Hooray again for Heroku, Ruby, Rails, Bootstrap, and all of the other infrastructure that makes it possible to build something like this in just a few hours.
This year had to be different. I needed something to show for my time. I became a finisher.
To make this change I did 3 things:
1) Reduce the scope on any new product ideas. Simple is best. I will only allow myself a month to work on something. If I am working longer than that and have nothing I can publicly show then the scope has probably buried me and nothing will ever be released.
2) Say Fk it and quietly release the project. Quietly because it isn't 100% finished. There are little problems here and there. I would like to spend weeks tweaking a feature but if I do it without releasing anything I will get bored and start a new idea. Once released I can iterate, improve and add functionality.
3) Tell everyone what I working on as I am doing it. This means I need something to show at the end of it or I will look silly. I then tell people in order of technical expertise about its release. Tech savvy people understand the concept of a beta and even an alpha. Others... not so much.
So far its working. I have already released something this year. Its still a bit iffy but it is improving each week. I am becoming a finisher.
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.
I have concluded differently, however, based on the following lesson I have learned repeatedly in all areas of life: until you do something, you often don't realize all the potential outcomes available. You can easily sit there today and think "ah but how the hell am I going to get customers?" and then choose never to work on your idea. That's OK - if you have something better to work on (where better = some other idea where positive, realistic evaluations of the "viable business" preconditions have been met and the total score beats the score of the current idea you're evaluating).
But if you don't have something better it's STILL a good plan to start working on your idea because (a) you'll learn something (b) you'll probably be (pleasantly) surprised, either because a solution will materialize that you didn't expect (are you really that brilliant and omnipotent that you can predict all outcomes?), OR because it will lead you to thinking of a new idea that doesn't have the same problem (how many successful start-ups switched ideas half-way through implementation?).
For instance, you might end up building product X that generates you 100,000 users but doesn't make much money, even though it doesn't cost much to run. But in the process of building X, you come up with idea Y, which turns out to be a great idea according to the preconditions but only if you have 10,000 users... ah but look, you can probably advertise Y on X and suddenly you're likely to have the users you need for Y to take off. By working on a problem, you unconsciously and implicitly start exploring related problem spaces. By not working on a problem... you can't solve it, or related problems you might not even have noticed yet.
http://add-adhd.lifetips.com/tip/81525/adult-add-adhd/adult-...
While it may be true that most people with ADHD don't finish things, it also true that most people who don't finish things don't have any disorder at all. They just don't finish things.
I made a mistake in that it says 9 in 10 go untreated not undiagnosed, though certainly the majority of those untreated are also undiagnosed.
Personally, I'd question why you're willing to challenge a psychiatric disorder like that when you'd never be willing to challenge someone that said "wow, sounds like you might have slipped a disc, you should get that checked out". While undoubtedly there are instances of mistaken diagnosis with ADHD, many objections to the diagnosis have more to do with the viewers confusion between symptoms and moral character.
I'm not challenging the disorder itself. I'm challenging a culture that's happy to jump to clinical diagnoses. There are a wide variety of traits people may possess that can easily fall into a variety of clinical diagnoses but are completely normal. Your original comment was very well balanced, but the 9 in 10 undiagnosed statistic struck me as a wild statistic that had no basis.
I understand the confusion between symptoms and moral character, but I'd prefer a more conservative stance on diagnoses when it comes to a condition with boundaries that aren't black and white.
http://www.ted.com/talks/derek_sivers_keep_your_goals_to_you...
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.
Incessantly talking about what you're going to do before you've done anything isn't admirable in my books.
Maybe restraining yourself from this might make you work towards having something more substantial that you can then in turn "show off".
I'd say "Don't tell people what you are working on until you start it."
It started by instead of rushing headfirst, instead recording ideas into a text file. It quickly became apparent that revisiting something written mere weeks earlier would reveal it as total crap, uninteresting, or the wrong approach or similar. That file is now just under 1000 lines, only 3 of which are probably worth revisiting later. It also seems the act of recording an idea has a similar sense of reward that comes with working on it.
Another rule is to mercilessly cull anything half started in a fit of excitement: my ~/src shrank from something like 100 directories to just over 30 right now, and half of those are 3rd party. Lose half a night's sleep coding some crap? Recognize it's undirected crap, and rm it first thing in the morning. The effect of this is less wasted work, more stuff getting recorded and enduring review, less distraction and less temptation in future to mkdir super_foo_project ; vim a.c.
I also promised myself to only work on an idea after finishing the previous. Presently my last "big" idea started in 2008 and only needs a few weeks' dedication to finish. In the meantime tens of weekend projects remain unstarted, as they rightly should. When I finally gain the discipline to finish that project, I'll be in much better shape to execute in future.
It's important to think of some projects as pure experiments. That their intentional end result was always going to be the information that you learned. Which does feel 'unfinished', don't be hard on yourself for trying & learning through experiments.
Unfinished projects that are far from the real end state you had in mind, need to be addressed. If you often find yourself generally falling out of love with a project after a few weeks work there will be a reason why. It's usually that you a frustrated that you can't achieve the next objective on your own. Note down the obstacle you are facing and what it would take to resolve it. You can keep in mind what's needed, actively work towards it over time instead of feeling bad about it.
We are so often reminded that time is limited that we are conditioned to thinking that we need to build & complete things rapidly and that if we don't, it's a failure.
It's not always possible to just keep pushing forward. You often need things to happen outside of your control. Allow your projects time to wait for what's needed & for situations to change. Revisit them regularly & know what the next step looks like.
Unless you make this post disappear somehow it will hurt in the future. Or help if you learn from this - now.
Recognize that the way you finish matters more than its beginning. Spend time considering that.
Find someone much like you, but ready to change. It cancels the guilt, offers empathy.
Submit to regular, voluntary accountability. Be brutally honest.
Got new ideas? Write them down in the moment of inspiration. Writing it down cancels urge.
Once success is established with its reward, pattern is broken.
Always choose what is right at every step.
I have a great partner in music who is very creative but has trouble finishing things. The two of us make a great team. But, there will be times where I get mad and make him do some finish work. Just because I like finishing things doesn't mean I never have any creative ideas and want to do all the boring, dull cleanup work all the time!
http://plus.google.com/Daniel_Meade/Always_a_starter_never_a...
Think of the collective brainpower on here, surely someone will be able to point him to a solution. Or the consensus should tell him that the problem he is facing has no known solution.
He wrote the entire post without even hinting at the idea. Is he afraid that we will find some flaw with it?
I lacked focus and once I shut off everything I realized that I didn't really need to know all that stuff, it cluttered my mind. With my projects, once I hit the first wall I prefered to start a new project or do something different than spending some time on fixing my problem with the other project.
so what helped for me? I tried to create an environment at home where I could focus: there is only 1 book on the nightstand and I'd rather not read one night because I'm not in the mood for this particular book than starting a new one as I once did.
I plan my meals for 1 week with the supplies I have and I only go shopping once a week, this prevents me from coming home, not knowing what to eat, losing time and energy on something trivial because once I had a problem with one project I suddenly found myself shopping at the supermarket in order to try out a new recipe I just read about on some forum.
So I just sit there and do my stuff and it has worked wonders. I write down which parts I want to have finished by the end of the week and even if I don't meet my goals I'm still going to bed satisfied because I know I couldn't have done better that day and I'm eager to get out of bed on sunday because I know exactly the night before what I will be working on the next day. And interesting enough, once I finished some small projects I suddenly was able to dismiss 90% of my ideas as not worth doing
The only book I've read on this subject is "self discipline in 10 days" and it helped me with getting back my focus. Once I snap out of my workflow and my mind starts wandering I use my "inner voice" to remind me that I have to focus and it works :)
You see, ADHD - or more specifically, ADHD/PI [1] - is commonly overlooked, with only 10% formally diagnosed [2]. ADHD/PI is sorta special because you're not the kid shouting out in class or having problems sitting still. To the average person, you'd just be suffering from depression or lack of sleep, etc. Cycles of started projects with nothing to show for is definitely a symptom of ADHD/PI, but of course, not a formal diagnosis.
Imposter's Syndrome [3] is something I think most ADHD/PI suffers can sympathize with. When we look at others execute tasks, we can say, "Ya, I could do that. I understand how that works." Execution is a whole other matter. Programming/Design is such an attractive gamut for someone with ADHD/PI because there is always something new to learn, or a better way of doing it, but the incredible need to execute can only be seen far, far away.
ADHD/PI doesn't represent a huge percentage of the population in general. But in our circles, I believe the percentage to be quite high. Anecdotally, 1/3 in the arts/marketing/web have strongly associated symptoms of ADHD/PI. Let me be clear: I am not suggesting that as much as 1/3 of people working in these fields have ADHD or ADHD/PI. Just that, in a sea of introverted people - how many are actually suffering with attention deficits and not knowing?
My over-arching point here is - it's important to get diagnosed. Even if you choose not to take prescription medication to treat it, at least you'll have awareness. And with that, you can identify with yourself a lot better.
EDIT: ADHD/PI is so different from what people would consider traditional ADHD symptoms that it has been suggested it should be considered a completely separate condition [4].
[1] http://en.wikipedia.org/wiki/ADHD_predominantly_inattentive
[2] http://en.wikipedia.org/wiki/Adult_attention_deficit_hyperac...
[3] http://en.wikipedia.org/wiki/Impostor_syndrome
[4] http://onlinelibrary.wiley.com/doi/10.1093/clipsy.8.4.489/ab...
The best idea is to build something you want yourself. The next best type of idea is something you know you will be unable to rest until what sits in your mind becomes reality.
Second, if you're going to do something that requires expertise you don't have, then you need to have a plan to deal with that from day one. Either you're going to get someone to help (with equity, perhaps, if this is a startup), or you develop the expertise yourself. Don't put six months into something thinking the solution for this part will fall from the sky.
Planning. That's it, in a nutshell. Planning is the key step to finishing any project, personal or professional.
"There is always another part of the project you could be working on - even if it's mindnumbingly boring (like adding i18n)."
That, to me, sounds like a poor suggestion for this kind of problem. Anything that doesn't get you traction with your project, so that any users start yabbering for tweaks and progress to keep you motivated, are likely to be a mistake.
If the problem is that you're a front end developer running up against back end problems, then you need to be spotting this well in advance or else you're wasting time.
How would it work? Would you wake up, and have _one_ hour to produce something? Would it be related to your project? Writing a blog post about your project? Or is that beating around the bush, and actually not producing anything worthwhile?
Does the thing that you produce, have to mean anything? Or does it only have to mean something to you?
I only ask, because I'm exactly like this guy, and I only want to better myself.
Producer mode is tougher to get into, breaking the ice with an easy task in the morning is quite useful.
- writing that uncomfortable email that's been lingering on your todo list - begin to write your next blog post - not a coder myself, but I would assume that this all applies to writing code / fixing/finding bugs, too.
On a related note, the last thing you do before you sleep can also have a very positive effect on your next day's productivity. I find that going to through / defining the top 3 goals for the day after helps me structure my work and be more motivated to pick up directly on those todos right after I get up.
After a while, when you can see that you're making clear progress towards a goal its easier to slip in to the producer mindset.
What's hard to get past in the beginning of learning to program is that you're going to spend 80% of your time googling, 15% debugging code, and 5% writing code. It can feel really unsatisfying to spend 2 hours googling a problem you're having and the solution taking 3 minutes to implement.
For me the joy is in figuring out how I would construct stuff, once everything is figured out... the joy is gone. The last step, actually making it, is almost never reached.
If you are a thinker/creative and not a doer, you need to align yourself with a doer, in order to make great things happen.
But at the end of the day it's simply: just do it.
And keep talking. Be loud. Let people know what you're doing.
One done thing begets another thing to do.