As programmers, why we never finish our projects | Hacker News Reader

As programmers, why we never finish our projects

programmer-hek.blogspot.com

45 pointsalphydan19 comments

One thing I've learned over many years [of discarded projects] is that if you don't put effort into completing it, it'll never get finished. The problem isn't a lack of talent or vision. It's not an inability to finish a project. It's a problem of discipline and focus. Discipline is the ability to do what needs to be done, regardless of your want to do it. The further I go through life, the more I understand is achieved in life because of relentless self discipline and focus than because of raw talent. Talent and vision are only 2/3 of the equation... without discipline, nothing gets done.

This is why most real entrepreneurs aren't afraid to share their ideas and get it in front of people, while most developers go into "stealth mode" afraid someone will steal their idea. Entrepreneurs know that without execution, your idea is worthless... and execution is equal parts talent, vision and discipline. Take any one of those 3 pieces away and just like the fire triangle, your idea dies.

>Brag until you Fail

>Share your idea, it’ll validate (or invalidate it), shape it and most importantly, commit you to it. We don’t want to let people down and we do want to save face, so tell people what you’re working on.

I'm not sure if I agree with this last point. Studies have consistently shown that discussing a goal with others reduces your motivation to actually meet the goal[0]. I've found this to be true in my own experience with side projects. I'll spend a few days excitedly discussing the details of some idea with my friends online, and then never end up finishing the project.

Social pressure does work, but it's likely better for more definite goals. You could tell your friend "You know, I think I'll run that marathon with you next month," and be obligated to prepare for it. However, side projects are mostly self-motivated and there's no use sharing all your excitement with friends instead of working on something tangible to show.

[0]: http://www.newsweek.com/does-announcing-your-goals-help-you-...

Over my quota, so can't read the NW article, but your point matches my experience strongly.

I think of it as a delayed gratification problem. There's a bunch of gratification that comes from building something cool, and having people around you appreciate it. If you can get a lot of that based on just the idea of the thing, then you've got much less motivation to actually build it.

If you're going to get 1000 plaudits for finishing, that might keep you going through 10 ergos of work. But if you cash in 800 plaudits right off, now you're faced with 10 ergos of work for only 200 plaudits: and that's an exchange rate it is difficult to justify.

A similar thing happens with releasing little and often, for the same reason. It is massively motivating, until the 4th or 5th release, then you hit the wall of rapidly diminishing returns.

>>Brag until you Fail

AKA "How to lose friends and annoy everybody"

I used to have incomplete projects, but now I set goals and work on the project until that goal is met.

I've worked with many other programmers on side projects and many times, unless someone is getting paid, they get bored and lose interest when they have to start working on something that's not cool or interesting.

I learned the hard way that these are also the same types of developers I don't want to start a company with.

Same here. My barrier for "starting" a project is much higher than it used to be. I might think about a project, or bounce the idea off some friends. However, if I commit to starting something, I finish it. I usually have some sort of deadline, but will finish the project regardless of whether I think it's still worth pursuing after I've started.

I think having this "barrier to entry" is important. When I have an idea, I tend to let it sit and re-evaluate after the "lust" stage has died down. Often times, I realize perhaps it wasn't as cool as I thought. If something is still nagging at your days later, perhaps it's a good candidate to evaluate.

Regarding your last point, I think also what a lot of developers struggle from (myself included) is project ADD. Having discipline to scope something out, set sane (and near) deadlines and focus only on that is important to seeing it through to completion. Good work on developing that discipline.

This has been common in my experience as well, I have many unfinished projects in my past but not so many from recent years. I have also seen many indie game devs struggle to translate their passion into an alternative to a job because they just don't treat it like one.

I've got quite a few projects that aren't "finished" because there are additional features I'd like to add some day. However, they are "done" in that they currently work for me. For these applications I just use them as-is, adding a feature whenever inspiration strikes.

I had one open source library that gained some traction, which I lost interest in. Luckily for me, another took over to finish it.

I've had the same problem. Not just programming projects but also blog posts, articles, music tracks, and even a novel that I want to launch, but somehow, seem stuck at 90% complete.

I was actually thinking of launching a platform to help people get the last 10% done. Often, people have the entire thing figured out but lack the confidence or the expertise to go live. Perhaps if an expert was to look over the project when it was about 90% done, you would feel more confident about launching.

Either way, the demands of someone looking for help before launching, vs. someone who wants something built from scratch are very different. I thought a dedicated platform for the former would help.

That's actually a really good idea. A lot of times people have big dreams for projects they really enjoy, but little knowledge and expertise in those areas, and so they aren't confident enough to see it through to the end. I myself have a website trading business that is in this state.

That's great, but I think this is even more accomplished than a majority of developers. The majority of developers have a wild or fun sounding idea and pursue it for a few days (guilty of this myself). Most likely, the "fun" part only constitutes a minority of overall functionality, and I find it's generally the non-fun stuff that demotivates people to not finish (e.g., billing, setting up a web site, user management, etc.) The key has to be to either determine if those things are critical, or somehow fit them in before you're left with nothing other than a pile of non-fun stuff.

My editor ozette is like that (http://www.github.com/marssaxman/ozette/). I wouldn't call it "done", or suggest that anyone else use it, because there are a dozen unresolved bugs and maybe half a dozen unfinished or unimplemented features that seem important - but it's done enough that I spend all day every day using it to make a living. I fix bugs when they annoy me enough to justify the time spent, and I add features when I have time and inclination in my off hours. I suppose I assume that it will be "done" when I've fixed all the known bugs and implemented all the features I had intended before I began working on it, but it seems likely that I could spend my entire career using this tool and still manage to retire before "finishing" it, which suggests that "done" is not a very useful idea here.

Because programming gives us very easy means of getting something on the screen (just write a line of text and computer will execute it; magic!) but makes it very hard to accomplish anything (due to extreme indirection AKA „Yak Shaving“ and archaic computer-centered text-based „tools“). Also because we generally lack culture of Developing things (i.e. understanding that production and polishing of things takes 95% of effort which takes enormous amounts of perseverance, focus and discipline).

But what we all fail to ask is how much of a return on our investment does that 95% of effort get? Would something with 20% of the work give us 80% of an ROI? You have to pick your battles. Of course, something that looks slick and professional makes us feel a lot of pride - yeah, that's right I did that, doesn't it look slick? Isn't the UX amazing?... but did we spend 80% of our time attempting to increase our ROI by only 20%? If so, we're concentrating our efforts in the wrong place. It's really easy to get sucked into making something look perfect, but you always have to have an eye on the goal. [Does the extra work I'm putting into this increase or decrease ROI? Is it costing the company more to pay me to fix this bug than it's going to yield in income?]

That's partially my point. Unfortunately, it seems to me that with modern tools, libraries, OSes (Yak Shaving is actually one consequence of those) it's extremely costly to actually finish something of genuine robustness and quality. As I was telling to my friend once, at university we made database-centric applications using Delphi in under an hour and how much does the simple (couple screens, HTTP request, couple buttons wiring them) iOS application cost now? About a $1000? And do you feel that people mostly building not what they want or what would enrich the community but what their tools allow them? Why after release of golang everyone started to develop data-storages with it? Does world need 100 more database systems (while few of currently existing properly support ACID)? Why people not building next-generation GUI tools with go? Because it does not easily allow it (it would be too cumbersome/costly).

Indeed. 90% of the time, the reason it's so costly to get anything done in industry isn't the developer's technical ability to get the job done, it's operational constraints: build pipeline, ops, company policy, communications breakdowns. If you can remove most of those impedances by only doing 20% of the work and still making 80% of the return on your investment, there's little reason to sink budgets into the other 80% of the work. It might seem wasteful when you look at something and see optimizations left here and there, optimizations that are a cake walk to the average developer, but the optimization doesn't always save/make as much as it costs to implement/deliver.

Even though the 15 lines of code seems simple and you can knock it up in a prototype in 6 minutes... that 6 minutes of your effort then needs to have tests written for each workflow, it needs to go through a Product Owner who needs to assign acceptance criteria, it needs to go through a QA test plan, it needs to get through acceptance testing and hopefully you've got a battery of tests that means it doesn't need to go through regression testing... and then assuming you've got CI/CD in place, it initiates the deployment pipeline and makes it to production without any major headaches. So you see, the optimization even though simple on your own project, and may not appear to "cost" much - certainly not in terms of technology actually has a massive amount of "hidden" costs - which is why it takes large corporations so long to deliver anything.

For me, the reason is that things are never done, they're just "done".

Once I got past that mental obstacle and started releasing things that were done enough, then I got a bit addicted to it.

Done enough is good enough, as long as you achieved the goal you set out to achieve, it's done. No more energy is worth spending on it - unless you change the goals.

Reply on news.ycombinator.com