Getting a project to the point where it becomes clear that an idea works is one thing. But in my experience getting it polished to the point that other people can use it, and writing documentation and ideally test cases with it, and then automating a build pipe line, maintaining versioning and a change log etc., is almost the same amount of work, except much more mundane and without a lot of room for creativity, so a lot less fun. No wonder many people don't like to finish.
The only reliable way that I finish my side projects is by using them for something I need to do anyway. If I can use something I made by going slightly out of my way, I get to improve it to completion (at least for the use case I'm doing). But if I have to go significantly out of my way to use it, then it gets abandoned like everything else.
That, and I have a tendency to put most of the documentation into a quick overview and really, really detailed error messages. In fact I'll often have quite a bit of code trying to guess what the user's intent was, because that makes things easier for future me.
Nobody has more unfinished projects than me. Nobody.
I'm the literal King of Unfinished Projects... The Emperor of Halfway, The Sultan of Lost Interest.
And... that's entirely OK. Not a single one of these unfinished projects was wasted time. Not one of them.
Projects take you on a journey - it's deeply educational, better than any bootcamp/crash course/class you can ever do. Projects challenge you and develop your mind. You learn new things, and overall grow as a person the more projects you take on and work on - even if they are short lived.
Sometimes I wonder how many unfinished (or should I say unpublished) works the greats like Mozart, van Gogh, Steinbeck, etc. had. Surely they didn't all produce masterpieces from the get go.
The trick is to "package" the code you write from the very beginning
For instance programming in Clojure it's incredibly easy to write your own libraries. It's just a separate namespace in a separate directory on disk. If you work on projects and push most of your work into mini-libs not only is it more maintainable but it makes it very easy to then reuse code in subsequent projects. So even if you don't wrap up the "main" project, most of the work is in a reusable format
You do generalize everything but its not overwhelming bc there is nearly zero friction to writing and using a library. It has to do with the ergonomics of the language you're using though. In Clojure you just point to the lib directory in your 'deps.edn' and then use the namespace locally. It essentially doesn't require any additional work - except you do need to decouple the code (which is good anyway)
The only extra work is you need to write a 'deps.edn' file for each mini-libs to specify its dependencies, but that take 5 seconds to do.
Lots of your mini libraries end up being just a handful of "helper" functions that for instance wrap some 3rd party lib. I find I reuse them later in other projects all the time
Library/namespace is so low level as to be obvious. Breaking up code by internal boundaries is fairly well-explored territory - every language gives you a way to modularize. Clojure namespaces aren't unique here, though functional programming with immutable data makes it WAY easier to do so, it's not improssible in other languages..
The barriers to finishing most projects are the "final mile" - taking it to production. So in general I agree - package from the beginning.
I advocate for making that the first mile. If you think you might need tests, a website, a library, and a mobile app - set up CI, a VPS with an IPv4 address, and apply for a dev account on CentralizedLangRepo and ProprietaryAppPlatform from day 1. Make it a habit to release early and often. That's the only way to earn the muscle memory for rapid iteration in any language.
with the move from `lein` to `deps.edn` it made local libs much easier to use. You can also push to your own github or pin to git hashes. It's all just incredibly easy - in a way that I haven't seen as smooth in a lot of languages (where there is more boilerplate involved). In effect it's just a extra namespace - but it's an namespace that's automatically shared across projects
You're probably right about websites etc, but working this way I just don't feel too concerned about dropping a project b/c the code will live on and get reused
15 comments
[ 0.22 ms ] story [ 59.9 ms ] thread> "I start projects, and I usually don't them."
I wish I could say I was that clever. It's absolutely an accident lol -- gonna file it under "DO NOT FIX"
That, and I have a tendency to put most of the documentation into a quick overview and really, really detailed error messages. In fact I'll often have quite a bit of code trying to guess what the user's intent was, because that makes things easier for future me.
I'm the literal King of Unfinished Projects... The Emperor of Halfway, The Sultan of Lost Interest.
And... that's entirely OK. Not a single one of these unfinished projects was wasted time. Not one of them.
Projects take you on a journey - it's deeply educational, better than any bootcamp/crash course/class you can ever do. Projects challenge you and develop your mind. You learn new things, and overall grow as a person the more projects you take on and work on - even if they are short lived.
For instance programming in Clojure it's incredibly easy to write your own libraries. It's just a separate namespace in a separate directory on disk. If you work on projects and push most of your work into mini-libs not only is it more maintainable but it makes it very easy to then reuse code in subsequent projects. So even if you don't wrap up the "main" project, most of the work is in a reusable format
The only extra work is you need to write a 'deps.edn' file for each mini-libs to specify its dependencies, but that take 5 seconds to do.
Lots of your mini libraries end up being just a handful of "helper" functions that for instance wrap some 3rd party lib. I find I reuse them later in other projects all the time
The barriers to finishing most projects are the "final mile" - taking it to production. So in general I agree - package from the beginning.
I advocate for making that the first mile. If you think you might need tests, a website, a library, and a mobile app - set up CI, a VPS with an IPv4 address, and apply for a dev account on CentralizedLangRepo and ProprietaryAppPlatform from day 1. Make it a habit to release early and often. That's the only way to earn the muscle memory for rapid iteration in any language.
You're probably right about websites etc, but working this way I just don't feel too concerned about dropping a project b/c the code will live on and get reused