I've advocated working on projects that you'd like to learn to build and also
projects that you think you'll use, in the past but then there's another
category of projects that exist. The ones we don't like. Now, it should pretty
obvious that this category is pretty dense.
This can have projects that you don't like at all and also projects that you
think you'll like to do but then end up deciding otherwise because you either
lost confidence in the project or to be precise hit with the realisation that
there's a similar project that's built a lot better than you ever can.
This is quite common with me and let's see the solutions I've discovered.
Let's start with projects you don't like at all. I'd say just put them in a
project bucket list and don't touch them for now, we might approach these when
we think we are out of ideas to build something.
Now to the projects that we started but then left them half baked.
I can always bring in TillWhen as an example here but I won't this time. I will
link you to it though.
TillWhen - Just a Time Tracker
So let's see, how can I explain this without sounding like a jerk, which is very
hard to do.
It's okay to drop projects in the middle and the main culprit most of the times
is the amount of effort you have to put into the project. At least after my
research on how I drop projects, the general process I follow when dealing
with an idea is to note it down somewhere with the set of MVP Features that I'd
The next step is to start the project and decide the stack for it, and this part
takes a good amount of time because now I have 2 options, use something new to
learn it and then use something that's been setup properly already and use that
After deciding the above, I end up either creating a project or dumping a
project based on two factors.
Now this is very simple, if the project is more for experimenting, then the new
stack, new arch approach works really well and I learn a few things but most
commonly end up dropping the project when the new stack creates more problems
than required. It's not that the stack can't handle the issue , its the amount
of work I'd have to put to fix something small that I could've solved with a
stack I'm used to.
If I take up a project that's supposed to be a proper product and be released
then using a new stack and experimenting with it will be a bad idea because I
know I'll loose interest because of the above point.
On the other hand, if you want to try building a small addition then don't start
from scratch and try adding that addition to an existing product to see how it
works out and do it on a different branch of your git or version control
workflow , so you don't have to commit to the new experimental addition.
I'm the kind of guy who likes to work on projects that put up a challenge, a
simple CRUD app to manage team projects is not a challenge at all but I ended up
trying to build one and have been forcefully pushing myself to build it.
This whole post is a way to just remind me that it's okay to drop the project.
But, I also have to realise that not all projects that are out there can be left
I should focus on extending existing projects and maybe even work on integrating
different projects with each other. This is where Time of acceptance comes into
play. This differs from project to project but there's a general average you can
find out. Mine is 3 days. If I can't build an MVP in 3 days you can forget that
project. There's no way I'm going to work on it for more than that unless it's a
challenging issue and I'd like to break my head longer.
Simply put, Time of Acceptance is basically the amount of time people take to
accept that this project is not worth it anymore, and this can be a subconscious
decision and this might take longer for the conscious to realise.
It's good to try new stacks, new arch, building new arch and also trying out new
languages but when you are forced to build a minor part of a production project
into a new stack it can be quite daunting and push you away from it, so as I
mentioned in a few posts back, have a default stack that you fall to for
building production apps and only try new stacks on something small that you've
already built so you know the parts that need attention and then you can look at
how that language would handle that issue or how the new stack makes it harder
or easier for you to approach it.
If I would've done the project management app in an existing setup stack with
login, tab, and other architecture and cosmetics figured out, I would've built
it in a few hours but since I've been slacking off the whole thing on trying out
new languages , trying out new database schema designing techniques , the
project is just a huge experiment.
And that's mainly because It wasn't started with the honest mentality to
actually be a product for the people, it started as an experiment and is going
to be left out to be one.
The only way to avoid this from happening is to avoid the effort you put into
building it. Use generators, use project templates and/or tools that already do
something you are trying to do. Like, can a telegram bot achieve this, can I use
an existing program and just integrate with it to make it easier.
Like if building JARVIS is something you'd like to do then start with an
existing NLP engine and use that instead of going crazy like me and attempting
to build an NLP engine from scratch. While the latter would help you learn about
processing text efficiently and data structures to help you work with huge
amounts of existing buffers of data to figure out what the entered text meant
but then that's about it. You could've just read about it for future references
but no, you decided to build it again because using Facebook's Wit.AI wasn't a
good option back then.
Most products you see from huge companies are built well because there was a
team who was paid to dedicatedly work on it and you have the option to jump from
project to project and that'll always get in the way unless you have a razor
sharp focus, which I don't.
Also, the solutions provided above are all with respect to people who work as
solo developers and are building things because they think it's fun and don't
really expect a return from it.
Proof of this? TillWhen
The donation button there is just a small add-on that I don't even expect people
to use. It's there on the website as a formality.
The UX was so intentionally decided that I put the page outside the actual app
environment, you can't see it till you actually logout. I didn't really want
people to pay for something like a time tracker and just added that so if
there's someone who'd like to help the developer, they could.
I do update TillWhen and add improvements for performance and stuff but that's
because I can see TillWhen growing, not at a very high pace but it's cool and
that acts as a return for me.
On the whole, your side projects can turn into disasters and it's okay.
You can end up not wanting to complete them and that's okay too.
To solve it though, use smart arch decisions to reduce your initial work for
Don't try building everything from scratch for something that you might not even
work on from a few days from now.
This doesn't mean you will not try out new languages, tech stacks, etc. Have
dedicated projects that you'd build with during the learning process so it
doesn't effect a potentially good project that you could've built.
A music player, a todo app, a god damn random colour hex generator if you want.
Now these projects are small enough to be built in a few days or maybe even
hours but the point is they are easy and that gives you time to learn something
new and/or experiment with.
I needed to figure out ways to handle ACLs better and I created a whole project
for it when I could've just tested it on an older project on a dummy branch and
this stupid decision to build the whole base arch contributes to this post just
as much as the project management app that I talked about in the first few
That's it for this one