Interesting comment, "start your day as a producer". I've seen this around before, but I'm not sure what it means.
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.
It doesn't really matter what you start producing, it's that it (hopefully) sets the tone for the rest of the day. If you can do something that relates to your project, that's even better.
The first things you do in the morning seem to 'set the tone' for the rest of the day. E. g., have you ever noticed how the first song you listen to often sticks with you for hours?
So instead of firing up HN or Reddit right after you woke up, start your day with something that requires your output - this doesn't have to be an essay, but could be as quick as:
- 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.
No, what you produce doesn't have to mean anything. I remember one week I decided I wanted to write real-time tic tac toe in using socket.io and node.js. I did it. It was those small projects that let me start tackling bigger and bigger projects.
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.
Just like eating bad food and watching TV, being productive is a habit. Get in the habit and you'll find yourself up early on weekends working on your projects.
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".
I think this is the opposite of the solution, the problem isnt doesnt sound like motivation to work, as mentioned they are always working on and excited by 'the next big thing', Its certainly something I relate to.
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
I don't consider "working on something I never released" as being productive though. In my original post when I was talking about habitually being productive I meant habitually shipping & following through on projects till completion, not just habitually working on 'a' project without finishing.
It could be more useful outside of SEO purposes, though. Pretty links allow people to guess the content of a page by looking at the browser's status bar when the link is hovered. It becomes especially important if the link text itself is not descriptive enough ("click here").
Thanks for your input here, your comment is actually very helpful. I realise that if I don't learn from it now, the post could come back to haunt me. But that's just it, it holds me accountable, which is the motivation I need to sort it out.
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.
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 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.
Thanks Pete, that's a great analogy. And your sentence "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" really hits home, you're absolutely right. Thank 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.
> 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 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 :-)
I accept that I should have arrived at a less-lazy way of describing the feeling I get when I am able to detach myself from a pet-favourite idea long enough to see its flaws.
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.
Absolutely agree with this advice. It's how I fixed my last unfinished project - launching something completely broken and having people tell you they liked what they saw but could you please fix that one little thing, is a great way to get motivated to fix that thing.
> What I learned when I came of age was that I am a Starter.
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.
You're welcome to your opinion, but I respectfully disagree. Frankly, I wouldn't be employed if anything you said was absolutely true.
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.
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 not talking about you or your company, but a lot of Starters are excellent bullshitters. They have an idea that is the equivalent of "Lets go to the moon" and leave it to others to build a Saturn V rocket. The latter of course is just an implementation detail.
That's a separate problem from that of the OP. We're getting into definitions here, but I wouldn't call your bullshitting Starter a Starter at all. They're just a bullshitter. A Starter worthy of the name should at least draw up some detailed blueprints for the Saturn V. :)
Then they have to finish at least the detailed blueprints, which I imagine is quite a big project in itself. In the end, you'll need someone to finish the 'start'.
I'm a starter, but I know about finishing and I think it's a good skill to learn.
That's not entirely true. I get called on all the time, within my department at Google, to start things. Usually I'm explicitly forbidden from finishing them (even when I want to), either because they're "good enough" unfinished or because they can be handed off to other people who are not good at starting things.
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 think that your job sounds like a prototyper, which to say that your mandate is to develop to a level where others can rebuild it with a point of reference. Hence you're a starter and a finisher.
Are you suggesting that the same people need to start and finish? Was Steve Jobs a starter and a finisher? If so do you really believe he could have built the hardware and finished the technical aspects of the project? Or is he a clever starter who found a good finisher - Steve Wozniak? Do you think Woz is both starter and finisher? Based on what I've read in iWoz and Apple Confidential, I think they had two very distinct personalities -- which could be summarized as "Starter" and "Finisher", and were co-dependent. Same thing for Bill Gates & Paul Allen. I would say there are some cross cutting concerns here: (starter vs finisher) vs (technical vs business minded).
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.)
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.
To be fair, in my experience there are always the engineers who build the first 80% of something, but then a separate set of engineers who build the last 20%. Of course the original 80% remain part of the team, but they usually take on different supporting roles for managing it.
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.
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.
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.
I think you're all missing the obvious solution. He should tell all of us what he is working on and where he is stuck.
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?
The problem comes down to programming, I decided to leave it from the post as the post is more about the situation. I know I'm not alone with this problem, and any non-specific advise offered to me from writing this post may also help others.
You're on a good path when you acknowledge the problem. Overconfidence bias makes us take impossible challenges. Put the big project on hold and do a few small projects with good ROI. And try to partition the big project into smaller ones.
Two things. First, plan out your milestones ahead of time. It's a lot easier to keep your enthusiasm up if you break the project down into smaller projects and just concentrate on the next milestone.
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.
Consider looking into the symptoms and characteristics of adult ADHD, especially if you ever had episodes of hyperactivity as a child. It's probably not what's going on, but frequently switching jobs (projects) can be a flag. 9 out of 10 adults with it are undiagnosed, and treatment is very effective.
Do you think you could provide some links or references? When I read your comment, I immediately thing of overdiagnosing condition these days. I only ask because I Think a lot of people in my generation (I guess that's Gen Y?) jump to the "ADHD" or genuinely think they have something wrong with them, when they are completely normal.
Having lots of unfinished projects is common with people with ADHD. We tend to get over the initial excitement of starting something new and lose interest. In order to be actually diagnosed with ADHD you would have to be affected in other ways that seriously impact your life, but this is one "trait cluster" that a lot of people with ADHD share.
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.
This post gives me an opportunity to highlight the major beef I have with the "ideas don't matter, execution is everything" crowd. It's simply false. The idea, and the vision of the world the idea leads to, are what can get you through these moments. If you are working on a project that you don't truly, deeply care about for some reason, you will throw in the towel early. This is part of the reason I'm skeptical the recent YC experiment to bring on idealess founders -- to me, if you're unable to show that you can be passionate about an idea (faking it doesn't count) you're unlikely to find one that will get you through these cloudy days.
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.
i had a similar problem: I worked on several projects parallel, had sheet after sheet with notes of "awesome" ideas, was interested in everything, read photography-blogs to recipe-sites, listened to podcasts and so on.
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 :)
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.
I think there is merit in your argument; having something more tangible than an idea means a lot more, especially when the op sounds like he is quite open with his ideas and willing to express that initial excitement.
Maybe restraining yourself from this might make you work towards having something more substantial that you can then in turn "show off".
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 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).
Your idea has already achieved validation from you, short of that your work validates itself by existing in a functional state.
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.
I found this "little" technique is immensely powerful. I've found that talking to people about everything I'm currently working on (as opposed to what I've completed) deflates my excitement a little bit about what I'm working on. After a few rounds of this, I no longer want to finish what I've started!
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'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 need finishing so I don't have to be the starter and I can focus on taking projects across the line.
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.
This is what happens to me a lot, and I've done exactly what you've suggested with my most recent project. A few days ago I read about OMGPOP and Draw Something and realised it was a clone of a game I used to play 5/6 years ago, and started thinking "shit I should be building a better THAT!" and started self-doubting my side-project: it's too ambitious and nobody has ever built anything like it before, have I got enough savings to pay for the processing that's required, will anybody actually even use this thing (whereas people are obviously making $$$ from Draw Something), and then will it even make money, etc.
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.
Here's how I overcame it - I put my own money on the line. I hired artists and writers for my recent project, even though I was easily capable of doing it myself. If you pay a grand out of pocket though suddenly it keeps things in perspective. You can tell yourself, "If I move on from this then I'll have just thrown that money away." It's more motivating than you think.
I suffer from this too (approaching 30 now), however in recent years it's improved.
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 somehow interesting to me how often this comes up on HN. It's also a problem I tend to have. But if you had asked me 10 years ago based on what I'd casually heard outside of tech, it was much more common for me to encounter and worry about the exact opposite failure case in creative projects: not the person who has 30 half-finished novels, but the person who's spent 30 years writing their Masterpiece Novel that is probably not going to be a masterpiece, but nobody can convince them that they really should be trying out other things instead of sticking with this one project to the bitter end. Basically, not enough experimentation and bouncing around between projects, and too much unwavering fixation on one Big Project that they've tied their ego to.
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".
I think the person with 30 unfinished books and the person spending 30 years on their novel are really just flavors of the same thing - inability to finish a job. They're both re-starting and revising over and over again. I would guess that if the 30-year novel ever gets completed, it probably bears little resemblance to the original draft. There's probably various reasons that could apply to either case - perfectionism, lack of attention span, unable to commit on decisions, self doubt, etc.
It's partially because the technology industry moves, while the film or book industry doesn't.
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.
You must finish something at the beginning and end of the day. Make sure you divide tasks in a way that your first and last tasks does not last for long.
98 comments
[ 4.1 ms ] story [ 166 ms ] threadHow 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.
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
http://plus.google.com/Daniel_Meade/Always_a_starter_never_a...
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.
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!
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.
http://www.humblepied.com/jessica-hische/
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.
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.
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?
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.
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.
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.
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 :)
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."
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.
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.
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.
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.