How important is it to finish projects? [closed]

Question

I'm a student (yet to go to uni) and I've been programming for about 5 years now. Over that time, I've flitted around from language to language, from API to API, and project to project. I've tried setting myself on one thing, but I lose interest. My entire PC is full of half finished projects (and at least four times as many have been formatted off my disk).

I start to wonder if my lower motivation towards programming for the fun of it (it is one activity I really enjoy) is because I never get a finished project at the end. I can't tell if I just have too open ended goals, or just a low attention span. I tried doing some smaller projects just to finish them, but they do not interest me at all.

Could this be a cause for my drop in motivation? Also, when I apply to go to uni (and in the future hopefully, a software job) is it likely to be an issue?

In summary:

How important is it to finish side/hobby projects, be it for career, motivation, or education?

Answer 1

Obviously finishing a project is important in the "real world" as unless the project is completed and delivered you don't (or your employer doesn't) get paid.

However, for hobby and learning projects it's a little more complicated. Having finished projects demonstrates to potential employers that you can deliver what you set out to deliver, but it depends on what you mean by "project".

If you are doing the project with a view to having a complete product that showcases all of your skills and may be something you want to make money out of eventually then yes you should finish it, or at least show that it is actively being worked on.

If you are doing the project to learn specific things (how to stream video, password encryption, what ever) then once you have that aspect working it's less vital to have a fully functional product as you have effectively completed the project. What you should have is something that can you can show prospective employers to demonstrate your skills.

For example, this might just be a web site that says "Welcome back, Joe" after successfully logging in and nothing else - but that's fine as you are showing off the code behind the website that demonstrates you understand password encryption and secure connections etc.

Answer 2

Take it from someone who has the same problem, finishing at least some of your projects is very important. It's completely ok to do some experimental projects and abandon them when you've learnt what you need to or it simply wasn't a good idea to start with.

However, creative people tend to like the challenging first part of any project more than the boring "tidy up, package, and get out the door" phase at the end. You need to come up with some strategy to overcome that or you'll

1) Never get any public credit for anything you do (if that's what you want)

2) Never be able to earn money from what you've done (if that's what you want)

But worst of all is that others and yourself will start to identify you as someone who doesn't finish things, and that's both a very bad label on you for other and bad for your own mindset.

So find a partner, reason or discipline to at least start finishing some of your projects.

Helpful Strategies for procrastinating programmers

• Make a list of all the good things that could happen if you did finish the project and of all the bad things if you don't. Then tape it to your monitor :)

• Set a schedule! Projects take up the time alloted to them, so a project without deadlines will take forever. Set a schedule with monthly and weekly milestones

• Set a daily goal, "Today I'm going to accomplish this"

• If you're doing an application or something similar, concentrate on making it runnable and usable so you can start eating your own dog food. You're probably working on something you're interested in so actually using it regulary will motivate you to improve on it.

• Beware going on big refactoring excursions, I broke my app for four months because of extensive refactoring and the development slowed to a crawl simply because I couldn't run it and was demotivated to work on it. Do refactoring but try not do to it all at once :)

• Make a list of everything that needs to be done in order to finish (I recommend abstractspoon's todolist) If we don't know how much left then will we know when we're finished? Working towards an unknown goal can be pretty demotivating

• Go through the list and cut every that isn't absolutely necessary (put it in a nice to have category). Finishing the product will give you a boost and those things can be done then. It's better to release something than nothing. Not even the iPhone had everything in the beginning.

• Don't be distracted by shiny new things. The main reason I don't finish projects is that I find a new fresh challenge. If you absolutely positively can't resist starting a new project before the old one is finished keep working on the old one in parallel or it'll die off completely. Also, see the next point.

• Set a minimum working time. If you're really sick of a project, set a minimum time to work on the project each day, even if it's only 15 minutes or an hour. Chances are that if you get started you'll work longer than that.

/me goes off to finish his next big application/programming language/facebook killer ;)

Answer 3

My entire PC is full of half finished projects

Are you sure they're even half finished? The value of actually finishing something is that only then do you really appreciate how big task it is to finish anything. Programmers have inherent optimism to consider almost anything 80 % done most of the time, but it always turns out that the remaining 20 % will take at least the same time and effort as the first 80 % did.

So, I really recommend finishing at least one project. Paying customers don't care if a project is 50 %, 80 % or 99 % done. Only 100 % done counts.

Answer 4

I have countless projects from my student days that remain unfinished. I don't think it's important to finish them. I never finished most of mine. Some of them were completely hair brained, like creating a better string class or manipulating bitmaps with Pixel class arrays.

Maybe you are choosing projects that are too big. Choose something really small. Something that wont take more than one Saturday afternoon to complete. You'll be satisfied upon completing it. Maybe you will feel energised to do another.

One important thing to remember is that when you reach the working world you will be spending 8 hours a day solving problems. It gives you a lot more time to tackle large projects than in the sporadic student lifestyle setting.

Answer 5

Take pride in your unfinished projects folder and don't beat yourself up about it! If you were in another discipline, e.g. art, then the unfinished projects would not really matter, the point is that you are having a go and that in itself is admirable. You could be sat at home watching the television instead? Or wasting all your time on Stack Exchange sites (oops!)

Microsoft never shipped the 3D 'Fahrenheit' API that I once hoped for, they never shipped the 'database' file system that was to replace NTFS and they killed the DeepZoom 'Seadragon' project that could have been awesome. They probably failed to complete and finish hundreds of other products, not necessarily out of motivation to 'embrace, extend and extinguish'. They have also shipped whole operating systems that were a lot less than '98% complete'. Does that make them poor completer-finishers?

'Completer-Finisher' is actually a phrase from the Belbin Team Model. Maybe you are a 'Specialist' or a 'Resource Investigator' and suited to a team where others do the completer-finisher tasks. Seeing things this way enables you to look on your situation more positively.

Answer 6

If its any consolation despite being a professional software developer for over 8 years I still find it difficult to finish personal projects. I've always felt that its a combination of open ended goals, a desire to 'do the cool bit first' and a lack of any real pressure to complete it.... to answer your two questions however:

I think treating the projects as failures because they were not 100% complete will impact your motivation and may stop you really getting into a wonderful field of work. Instead of looking at them as failures try thinking about what you learned from them - what new languages/frameworks you now know, what programming lessons you learned, what tools you now have skills in and what people/communities you interacted with whilst doing it. Looked at from that perspective its rare to find a personal project that didnt contribute in some way to your knowledge.

You will find when at University or in employment that there are two major differences which ensure that you do complete your projects. Firstly your goals are usually quite well defined - particuarly during the first two years of university. Secondly you have real pressure to complete a project - you need to do so to pass a class/module or your manager is telling you that project XYZ needs to be handed over to the test team for a specific date. This provides a focus that I've never been able to replicate on personal projects.

Answer 7

Firstly, it is important for the self-satisfaction. You have achieved something from scratch to a clear end state. You can then pop one item of your "project-stack-in-mind", and for me it has always been a relief.

For your career, and more precisely for job interviews, until you have finished your project, you don't have anything to show or talk about... Showing an half project is never good. It might be buggy, ugly or simply not working. You can't even mention them to the interviewers otherwise they will ask "Why didn't you finish them ?"... If you answer "I don't have time", it means you can't schedule properly your tasks, you are not persevering. Moreover, you had time to start other projects so your argument would be wrong. You would have to find a clever answer...

Answer 8

I was in a similar situation as Jon Malcolm, but I was wasting time in the wrong places. For personal projects, I decided to lower my standards in favor of complete functionality. That meant no ajax, no localization, not much validation, no authentication, no pagination, barebones UI, no unit tests and so on. Just get the business part working... I call it 'the straight line'. The solution would be complete and should work under ideal conditions. Once that was done, if the project was still interesting, I would continue iterations of refactoring till I lost interest.

Answer 9

I have similar experience and that last 5-10% of even a small pet project can be a killer.

My advice if you want to finish? Tell friends, coworkers, family or whoever might be interested about this cool new thing you're working on. Involve them, ask them questions. Hopefully you will gain a few followers that will ask about your progress. The pressure of knowing that will motivate you to keep going through the mundane but necessary steps to ship your project.

Answer 10

Finishing projects is what separates the kids from the adults, the wheat from the chaff, the men/women from the boys/girls.

"Real programmers ship."

Answer 11

To know if you must finish a project or not, you must evaluate the value you will get from it compared to the time you must invest in it to complete it.

If the value you can extract from it is lower than the investment, you can consider it at Sunk Costs.

In economics and business decision-making, sunk costs are retrospective (past) costs that have already been incurred and cannot be recovered.

Too many unfinished projects lead to waste. Waste is one of the most powerful enemy of lean.

That said, sometimes, it's better to abandon a project to focus your efforts on one that will provide much more ROI. Many people finish everything with obstination, and fail to catch really good opportunities.

Answer 12

Plain and simple: if you want to finish it , finish it! If you dont want to, dont! You dont have anybody waiting for the delivery , so why agonize so much? Doing hobby projects is not the same as industry projects. They are very different. No one will ask you why you did not finish your hobby projects if you dont tell them that you left them unfinished. There are a billion hobby project codes floating on the net. You think anyone really cares about them? (other than lazy univ students looking for a quick and ready final year project)

Answer 13

Seth Godin has written a lot about getting into the habit of shipping:

http://the99percent.com/tips/6249/seth-godin-the-truth-about-shipping

I think it's important, and here's why: it's not enough to do a project for yourself, even though it may be of some educational value to you. If you never share your gift with the world, you're like an artist who never shows his paintings to anyone.

It's something I struggle with, too. If I had to analyze why, I would say that I tend to over-engineer and over-think my personal projects. I will make too many assumptions about the problem, many of which are invalid, then I will put in too much work in before I come to this realization. That's de-motivating, and at that point I lose momentum. There is one idea I've been iterating on for the past couple years and I have repeated this pattern several times.

My plan going forward for all personal projects is to focus on a small subset of the overall vision, implement it and put it out there (whether it's an open-source github project, a website, an article in a series of articles).

Then if I am still sufficiently motivated, I will iterate on it again. I am hoping that the satisfaction I get from shipping will sustain me through additional iterations.

Answer 14

It's very important.

I understand whipping something up as a proof of concept and then letting it sit there. That's fine. However, customers will not pay for anything less than a completed project.

The bottom line is this... Sales Drive Everything. Without sales there are no salaries. Without sales there are no capital improvements. Without sales there is no company. Sales come from customers. Customers will only pay when they are satisfied. Satisfaction means the finished project works and works well.

To use a football analogy: The red zone is the last 20 yards in front of the goal line. It's the most grueling part of scoring a touchdown. The same applies to a programming project. The last 20 percent is often the most difficult to finish, but it must get done.