loading...
Cover image for How do you deal with half-finished projects?

How do you deal with half-finished projects?

madza profile image Madza ・1 min read

Often due to the absence of proper planning, lack of inspiration, no proper technical knowledge and so on, you might hit a roadblock while working on a project.

Do you push forward to complete it no matter how long it takes or do you start to work on others until the inspiration strikes, you have researched enough and then re-visit it?

Discussion

pic
Editor guide
 

rm -r UnfinishedProject

:)

 

I never remove my old or unfinished projects because I still might what some of the code for other projects also doing that is like throwing away hours of your life, at least in my opinion!

 

I think you missed the smiley. ;)

:), is that better? I did not mean to make it sound sarcastic.
Sorry my mistake LOL!

I meant mine. Doesn't matter. LOL

 

(Serious answer)

cd unfinished-project
git init
git add -A
git commit -m"init"
git remote add origin some-github-private-repo
git push origin master
cd ..
rm -rf unfinished-project
Enter fullscreen mode Exit fullscreen mode
 

Worse than throwing away. You can't undo it. Totally agree.

 

Lol, same...

 

never, ever. Read my post as to why.

 
 

This made me chuckle.

 

Different projects have different timelines, personal or not.

Sometimes, when you hit a road block, you simply can't afford to move the block. You must drive around it. Other times you may take your time to move the block and thats ok. You have to understand what makes you money at the end of the day.

That said. Never, ever, delete a piece of code. Even test scripts, have them in a single repo if it helps, but don't delete them. It takes less than 10 seconds to add, commit, and push to a remote git repo. By all means do it.

In short, make it work if you need, make it shine if you can afford it. There are some cases where you can't afford to not make it shine (project size, number of devs, etc).

Leave it public if you can. I've had prolonged times without a job in my life, doing for myself investing previously earned dividends in projects I personally believe. They have failed for various reasons. However, in comming back to the market, all those little projects, and examples scripts, and demo talks, and etc, proved more helpfull than my CV which is itself rather enviable, if I can say so myself. I ended up in a job, I absolutely love, where none of the requirements are actually on my CV.

Those pesky projects will get you a better job quicker than your diploma or CV. This is my personal experience. I don't have a diploma, but I can speak in comparison with colleagues.

I have deleted code in the past. It is probably the only real thing I regret, everything else was a lesson I should have taken; however the code is lost. There is a saying in systems engineering, don't do what you can't undo.

 

Awesome insight! πŸ”₯ Thanks a lot! πŸ˜‰

 

There was a great article, big props if someone can find it, that proposed to have a rule like 100-10-1

  • Note 100 half assed ideas in your notebook
  • Do a MVP for the ten most promising ideas
  • Transform the best of those ten MVP in a real project that you want to maintain long term
 

MVP is most valued project?

 

No, it's a concept from the lean startup movement. It means minimum viable product (or minimum loveable product) and is meant to evaluate whether it's worth it to invest time and efforts in a new project.

Lookup lean startup

 

First step I take is to redefine 'finished' for the project. In other words:

  • when the original plan was to have a full featured product, redefine it to an MVP with just essential features.

  • When the idea was to build an MVP, maybe just make it a demo/showcase project. Not enough to test with real users, but enough to show others what the idea is.

  • When just planning for a demo and getting stuck, document next (potential) steps before you leave the project completely. If you cannot come up with next steps, document the reasons to abandon the project.

Do not leave loose ends. Redefining the project ambition gets you to 'finish' the project succesfully. Often times it then becomes easier to take this or another project to the next level. At least, finding closure opens you up for opportunity.

 

Yeah, unless the particular project is very small, specific and possible with just certain tech, there will always be ways to optimize the performance, redefine the code, upgrade the tech stack used, etc.. Sometimes it's just better to leave it when all the functionality and UI is what the client or you wanted, otherwise it's an endless loop to pursue all the mentioned above and thus the project is never finished πŸ˜‰

 

I keep projects in a personal git server via my NAS so, when I stop working on a project, I can remove it locally and fetch it remotely if I feel like taking it up again.

Just did it recently. Started work on an app a while ago, put it on hold, and when I want to come back to it later I, just did a 'git checkout my_old_project' and continued!

 

Commit it and move to my special archive folder. Usually, after some time, I get back to find some algorithm to use in another project.

From time to time, I use old project to build a component for my current one.

 

That's how I usually approach this, tbh πŸ˜‰
The problem is 'archive' folder tends to become massive at times, aka too much stuff going on at the same time πŸ˜ƒπŸ˜ƒ

 

Exactly! That's why I always commit it as the local copy in archive folder is just a temporary solution, and occassionally, I delete it (system re-install, harddisk change, need more space for porn :-D, etc.).

Before GIT, I used SVN and I have "work" repository of about 20GB with just my small projects - I was too lazy to create a new repo for each of the projects :-).

I tend to have only the most important projects - those I feel that can be reused.

 

For a long time I had a heaps of these half-started projects. Always over-ambitious, lacking direction and getting stuck (since I always seemed use them as an excuse to try new tech too)

Nowadays I promise myself not to get into them at all, because I've found that by myself I don't have all the tools needed to complete side projects and end up sinking so much time, effort and mental energy.

I was inspired by this question to write this out more fully -

 

Some people may say that unfinished projects should be removed or abandoned, but that will make you a habit to unfinish every task (this will grown over the time).

My best advice it's to classify your projects into "useful", "re-think" and "Better get rid of this sh*t"; after that, remove those projects You don't really need and start finishing the easiest ones. Don't spent to much time so You don't burn out.

You will get more focused on finish tasks rather than "is this project finished?". Sometimes, the anxiety to be focused in the last one , stop us from finish our stuff.

 

I play games when I face serious issues! :))) Sometimes it helps and opens your mind to find new ways to handle problems! Also, Never delete older projects and write the environment and package versions you used! I think every project has its own difficulties and you may be able to solve them after a while!

 

I use github issues as my todo list. I feel overwhelmed by all the things I could do to improve the project and I don't know how to do them yet so I get down the intention and maybe a link or screenshot (like for a web component). Then I hope I'll come back to it one day and pick it up.

Sometimes I give up because my interests have moved on and I keep a repo as a record of what I made and how I made it.

 

Oh and Trello is also nice for building up ideas of projects that I might build one day and there is no repo yet. I links and todo items.

Planning a project before coding it is a a great practice anyway, so you know what obstacles you'll have. And if you pause halfway so you can do something else, you can come back to your plan or someone can pick it up.

But keep the plan flexible - allow for uncertainties to me figured out and the change to change as needs change.

 

This happens to me more often than not. It took me 2 unfinished attempts while I was learning to finally get one project up and running. Took me a really long time, too (like 4 months and 3 months) But I decided to keep them either as reference / practice or as a reminder of how NOT to do things. I ended up with a sweet app to show around in my portfolio.

After that I realized that it is much better to keep the code, the only mistake I was making is setting goals too high and far for my current skillset and time.

I think the only thing you really need is planning. Nowadays, what I do is divide a project into multiple milestones, and then push as hard as I can to reach one of them before stopping. Afterwards, I can either move on to the next milestone or stop and continue with it some other time. Either way, I finished something I proposed myself, so inspiration & morale remains high, and I can use those breaks to learn the things I might need for the next goal.

 

You're not alone. Right now I'm sitting at the corner of my room and crying. I don't know what to do. But now, I feel better

 

Generally, I try and pull extract anything that could be a library before archiving a project. E.g., if I wrote a small event system or something, I'll try to clean it up and move it to a separate repo (even if it's just local). This way, at least I got something usable out of the experiment.

 

I keep unfinished projects up on GitHub (but hide all the tutorial repos). I feel like it shows potential new employers that I'm at least trying new things in my free time, that I'm not afraid to let a project go if something more worth my time comes up, and gives other folks an idea of what I'm into.

Plus it's always fun to pull up a repo and some example code when you're talking to someone about what THEY'RE working on. You might be able to help them out.

 

I usually freeze it and put it into a private repo. So people won't see my unfinished projects. I'll come back to them (don't know when) when I have an idea. Or never come back!

 

That's a nice approach πŸ˜‰
Unless you have created the repo specifically for collaboration and PLs, you might want to hide the code, otherwise some might think it's your finished code and it's broken πŸ˜‰

 

That's one of the ways I promote myself. Don't show incomplete, broken, or ugly projects. Because the total of the project might mean nothing.

 

I move to another project or try yo learn something new even if it's no related to the project until inspiration come back. It can take some time sometimes.

 

I always save it. I never delete my old projects, cause may be I will finish it someday or reuse separate components...

 

I delete them silently from GitHub

 

No project is ever 'finished'

 

Move it to a repo, forget about it, and head back to it later either to have a laugh or grab some snippet of earlier genius I had

 

Many great insights, thanks for starting the conversation.

 

DEV Community is awesome πŸ™β€

 

I use it on my CV and tell people its unfinished. Imperfection make us human :')