In 2019, I wanted to create a website that closely followed our custom design and had smooth animations and interactions. I looked at UIkit(opens in new tab), but I didn't pick it for two reasons:
It had its own opinion on design
It didn't meet my requirements for "smoothness"
I was developing the framework in parallel with the website I was working on and it was wonderful. I was able to make the code just right and implement just the features I need. I took some inspiration from UIkit, but stuck to my main idea.
At this point, my enthusiasm slowly started to fade away. Without realizing it, I had put myself in a position where I wanted to solve problems that don't yet exist and solve them perfectly. But I still believed that in the end, it'd be "worth it".
Then, our team started to grow. I was no longer the only one working on that website. Since it used my framework, I had to onboard new people with it. This meant that I had to write up a README, then documentation, example usage, etc. Despite that, we still had to clear up some stuff in Slack.
Because our team grew, so did our workload. This caused work on the framework in parallel with the website to transition in work on the framework during the weekends and early mornings.
Recently, I started getting more and more into the React ecosystem. Late to the party, I know. I also started noticing more websites with
<div id="__next"> or
___gatsby. So no matter how I build my framework, it wouldn't work with the way most people build for the web. Since I want to start using these tools as well, my framework won't work for me either.
Unrelated to this, I had slowly started to pay more attention to my health and well-being. I changed my eating and sleeping habits, started to exercise and stretch more, I even started reading books… This made the weekends and early mornings much more packed and valuable.
And now I'm here. I had made something that nobody really uses, but still represents a solid part of our workflow. What do I do? Well, I think I've learned some lessons in the past 3 years.
Code Doesn't Matter
Unless you're building software for aircraft or medical equipment, nobody really cares about your code, and neither should you. Especially in web development. At the end of the day, you want a bunch of boxes with text and images in them. You can have a hellish codebase and still get the job done. A perfect codebase doesn't exist. At least not for a very long time, in large projects, or with many people involved. Things will get messy and you should be ready to accept that.
Maintenance Is a Burden
Let's say you've built something and it works perfectly. That won't last long. Bugs will appear, new people will join and documentation will be needed, features will be requested. Who's going to handle that? If you're doing this as a side project, are you prepared to be distracted by these things while working? If not, are you prepared to do them in your free time?
Even if people start contributing with pull requests and taking some of that load off of you, you'll still have to review and approve of what's going on.
Third-Party Is Fine
If you find someone else who has done the work for you, use it. There might be things that you don't like, but compared to the hidden costs of maintaining something yourself, they won't matter. If that third-party code has been out for a long time, chances are that most common bugs and edge cases would have already been handled. Doing things yourself should be your last resort, because you'll slowly discover the same issues as well and waste time on solved problems.
On the off-chance that you really want or have to build something, launch it as soon as you can. As David Heinemeier Hansson said on episode "Launch Now" of the Rework podcast(opens in new tab):
If you're not uncomfortable by the time you're launching, it's way too late.
I never really launched my side project. It wasn't "ready". At the same time, it became a bigger and bigger dependency in our main projects. That's an issue, because you're building on top of something that isn't validated by other people. If I had shared it, maybe people would have helped out and given ideas for improvements. Or, maybe people would have critiqued it and made me question whether it's valuable.
And that's what I was most afraid of — that the project isn't valuable. But no matter how much effort you put into something, you still can't know for sure if it's valuable until other people give their own points of view. That's why it's better to launch as soon as possible:
If you've built something valuable, you'll get more like-minded people to help you out with it
If you've built something pointless, you'll save time and probably learn about new and better approaches
We should work on solving new problems, not existing ones. If you find an issue with someone else's code, report it or directly submit a pull request and fix it. Not just for yourself, but for everybody else! Your contributions will be nicely welcomed! Don't create something new with its own set of problems.
It's impossible to build something entirely by yourself. At some point, your "pristine" code will have to interact with other people's "messy" code. Sure, you might not use third-party code on your website, but its existence still depends on it. The operating system it runs on is not built by you. The browser that your viewers use to see it is not built by you. The protocols that carry your data across the wire are not designed by you.
You will always depend on other people's work. Embrace that!