Zero open source pet projects
My developer friends usually have a dozen open source pet projects. I have zero. Why?
Whenever I’m working alone on code for fun, I turn up the “it has to be perfect”-dial.
Where at work I’m trying to preach the MVP mindset, discouraging for instance to custom-roll stuff like webpack configurations before a project has proven itself, or scoring 100/100/100 in lighthouse, there’s no way that I’d consider shipping something below if it has only my name attached to it. Once it’s obvious to everyone everyone that the project is fully under my control – so I argue to myself – every imperfection will be directly attributed to me – and I can’t pull the “but the deadline was super tight”-card. It’s silly, really. Even if I do show everyone my best, there’s hundreds of ways it could be improved. Effective People are the ones who just go out and try.
Pain inspires
One day I’m coming home from work, in a bad mood: We’re shipping a web and a mobile application in more than a dozen locales – localization being a challenging aspect of release cadence. We pay a SaaS provider roughly a thousand bucks a month to help us to manage our copy. The tool sucks:
- It’s buggy, nearly causing us to lose translations at times.
- It’s so hard to use that I spend an hour every two weeks explaining the subtle gotchas to PMs.
- It offers countless features I can’t imagine being useful to anyone, but lacks a couple ones I’d deem crucial.
It’s the second tool of the sort we’re using, and quite popular.
I know: I can do better!
In that moment I feel the pain of the current tool strongly enough that I’m convinced that I’m willing to invest the time to create the alternative myself.
Initial elation
So I spend a weekend on thinking about the problem space, how to avoid the issues I’ve seen with other tools, roughly sketching and iterating on an information architecture, the database modeling, tinkering with UI layouts for core views. I’m energized, I’m 🔥! The longer I’m tinkering, the more ideas I have of what awesomeness could be built in.
Rational drop
The weekend is over and I’m taking stock. Clearly I once again drifted from wanting to solve my immediate pain to trying to create the perfect solution for the use cases I know. Building it would take months. The outcome might be appealing enough to turn into a business – or not.
On the initial high, the usual paralyzation follows.
I decide to stop before I wrote a single line of code.
Regret resurrects an idea
A few weeks later, thoughts of UI patterns I imagined to use, keep chasing me.
I had put a bit of thought into what the best navigation UI for the project could be and had ended up with the conclusion that it would be a sidebar. Nothing fancy, but a known pattern that would allow the user to easily grasp the structure of the whole application, to know the current screen and context at a glance, and to to jump from one part of the app to another sigh a single click. I know and like the pattern so much, because I use it every day in code editors, where the file tree is shown in a sidebar.
The sidebar seemed straight forward to build on a weekend in good quality, even in a framework I had never used.
Going through
This time I built it.
Say “hi” to my sidebar component. It’s a JavaScript module usable from any JavaScript project. It’s implemented using svelte, a framework I was curious about due to its nature of compiling itself away. My playground allows you to easily see how it can be used and customized. Enjoy!
TLDR
- Start per projects before overthinking them so much that they turn into huge monsters.
- “Better done than perfect” – call an end to projects on time. Private projects can’t be dealt with the same continuous fashion as one does when working at a SaaS company.
- Helping out at existing open source projects you use yourself might be a more productive way to spend the time then creating the thousands ToDO-clone.