Like most developers, I enjoy making things, but also, like many developers, I often don't finish making them. It's a constant source of frustration that I come up with lots of ideas for things I'd like to make, such as:
A garden manager that lists what we're growing in our garden each growing season, when to plant them, how much to water them, and other information about the plants that would be useful.
An app to use when I'm at the gym to record how much weight I'm currently at on each weight training machine so I can know what setting to use. It would use a Google Sheet for a data store.
A desktop app that captures and stores code snippets that I can tag and search for later to copy and paste.
These are all neat ideas (at least they are to me) but I've only barely started one and the other I've hardly moved past the research stage. The garden manager I went a good way in before losing interest. It was more work to make the thing than to just water the garden whenever it felt like it was time.
I've given this a bit of thought, and here are a few reasons I've come up with for why I don't finish what I start (or don't even really start) when it comes to side development projects.
Too Much Friction Up Front
Ever been excited to kick off a new coding project and then found that you were going to have to wade through pages of documentation on a charting library, a full-text searching library, and an authentication module to solve the major challenges it presents? Even if you've worked with charts before, there's always going to be thirteen new chart libraries to have entered the space since you last used one, and you don't want to use that dusty old thing that's now deprecated or even no longer actively supported, right? And you're not going to be irresponsible about safeguarding your user's data when there are so many variations on authentication to parse through now. I mean, sure, you could just do an Auth0 integration and leave it at that, but even setting that up can be a chore.
I just started a new business project idea that I decided to build in Angular, because I have spent so much time working in Angular and, well, I like it. I know, you were expecting me to be all like "Because Angular is better than React and Vue and Svelte and it RULES!!!!! Everyone not using Angular is picking lice out of their hair and sprinkling it on their kombucha!" But I don't have very strong feelings about JavaScript frameworks, and I just like Angular. I know its ins and outs and I like the elegance of how the parts fit. And Angular 15 had just come out and so I'm going to use that of course. I already had an Angular project started in Angular 14, but when I tried to run through the migration process to v15 my npm install was blowing up on lots and lots of failed upstream dependencies. It took me almost an hour to work out why: I was running Node 14 and I needed to be on a much later version. This was a brand new PC I just built a week before and I had to install nvm, then the later version of node, and then the updated Angular CLI, all so I could run the migration script again, and that wasn't even the end of all the problems. This is a framework I've worked with for three years and I'm still fighting with it from the very start.
When you do nothing you feel overwhelmed and powerless. But when you get involved you feel the sense of hope and accomplishment that comes from knowing you are working to make things better.
I should add that this wasn't even the first technology I was planning to use. I meant to build the thing in Meteor with Angular, but the documentation and tutorial for Angular Meteor are so dated that I found myself spending hours resolving one problem after the next resulting from incorrect configuration steps that no longer applied to late versions of Angular, and I finally just decided I would be better off just building in Angular and MongoDB on their own, with possibly a layer of Deno microservices. And this is just for the rapid prototyping phase.
We've reached a point in building web applications where the technologies available to us have branched in so many ways that you have to consider which version of the engine you're running alongside a framework and package dependencies galore that can all conflict with each other. The amount of time and effort I need to put into just scaffolding a lot of projects to get things rolling can suck the motivation out of me. I come in all fired up and ready to tackle the challenge of building something and I find that I can't even start building until I climb a long and winding trail up a mountain of interconnected technologies that don't want to work together even though they are designed with that in mind.
Someone Else Has Already Done It
I said earlier that I was planning to code a garden manager and got a good way into it. What took the wind out of my sails on that project was discovering another garden manager app already on the market that seemed rather well-designed. It suddenly seemed as if I would never come up with something as feature-rich and visually appealing as what had already been done. So I put that project on ice.
I'm Likely to Fail, So Why Try?
I tend to wrestle with a pervasive fear that I will be wasting my time starting a new project. The fear comes down to a few thoughts:
I'm wasting my time on something that I will never finish.
I'm not good enough at software engineering to solve all the problems that will emerge.
I don't know technology X well enough to use it successfully.
Even if I do build it, I won't be able to turn it into something successful, i.e. it won't make money because people won't want to use it or pay for it. (Obviously, this only applies if I'm trying to make something that would be offered as a paid service).
Tell That Fear Voice in Your Head to Get Lost
Here are some counterarguments against not starting that new project you've been mulling over.
Push Through the Pain to Get to Breakthrough
I wish I could say I always push through challenges without complaints, curses, or fist-pounding on my desk in frustrated rage, but I'm guilty of acting out my frustrations in embarrassing displays. Still, I find it far more satisfying to push through these frustrations and keep digging for answers through Google, StackOverflow, and past experience to get through whatever is holding me up. It's not always fun but it is educational. I learn a lot working through a problem but nothing by giving up. And over time, you can start to view these as a fun challenge to overcome instead of a hassle that is blocking you from moving forward.
Review the docs again if you have to. Google the error message. Remember that someone else has already had and solved this problem 95% of the time. The other 5%, it's usually something superficial and you'll find it if you just dig a little. Prayer is sincerely always a good option and I try to go to it first.
Make Your Own Contribution
Finding out someone else already made your neat business idea or clever tool can be demoralizing, but it doesn't have to be. Make it anyway, and make it your own. No one else is going to build something exactly as you do, and your choice of features and styles are going to be different than anyone else's. Think about how many different to-do apps are out there (ToDoist, Microsoft ToDo, Google Tasks, Notion, etc.). Each one does this simple thing of helping you organize your tasks differently, with a diverse set of audiences in mind and areas of focus.
A lot of the point of doing a side project is to learn how to build something. You'll face different challenges each time. Maybe you're having to learn how to do full-text searching or handle authentication. Each project you start and work on will force you to learn new things, so even if you don't end up with a five-star result, you will still have picked up additional skills that you can apply to future projects.
Define Your Success
Failing at a project is a fear that is easy to struggle with. But we often forget that we can define what success means. For instance, if I set out to build a service that is used by 50,000 people within five years and I don't get to that number, then I failed at that goal. But if 5,000 people end up using it, or even 500, it's still offering value to a large number of users. Or if I try to build something and no one ends up using it, or forking it on GitHub, or starring my repo, or even if I don't finish it, I learned things by doing it and gained valuable experience. Maybe I try again next time and do it differently. Maybe that new framework would work better, or that library.
Our doubts are traitors and make us lose the good we oft might win by fearing to attempt.
The thing about failure is that it's only failure if you decide it is. Sure, failure can be defined objectively if you have clear goals that haven't been met. But you can have other goals that you did. And you can celebrate those as victories on the way to a larger success down the line. Real success happens only after lots of failures along the way.
Hopefully, this gives you some ideas to chew on when you find yourself, as I often have, feeling paralyzed with inaction when it comes to starting a new project. Let's keep building, learning, and defining our success.
Cover photo by Roberto Moreno on Scopio
