Crappy personal projects
2020-01-14

I feel it’s important to work on something for yourself. Something that you have lots of creative freedom in.

Most software engineers (and other tech-people) are probably working at a full time job of some sort. You have somebody telling you what to work on, somebody else telling you the design (either API or UI guidelines), while still another person gets to review your code and the way you implemented a solution to a problem.

This all makes perfect sense for a company. They have the resources to hire a lot of good people to specialize and be more efficient at solving the business problems. Having somebody to regularly go back-and-forth with your users and decide what they need most is extremely valuable. But it’s also valuable to the Software Engineer to take big risks – create something crappy sometimes. It’s better not to do that at work, so create your own crappy projects at home every once in a while.

Your home projects will always be crappy at first.

I was trying to solve my blogging problem for over a year. I wanted to be able to write blog posts in markdown with minimal overhead, on a site that I controlled. I made several different crappy programs that all worked OK, but I gave up on them all eventually. I gave up on them because they didn’t solve my problem, even though they were fun and interesting while I was working on them. I was looking to existing solutions for inspiration, but never really knew what I wanted to build.

Finally, after a year or so, the idea came to me that I needed to create something different. I like the idea of minimal static sites that don’t require JavaScript to work, and with some planning this time, I had a thoroughly imagined static site generator. With that strong vision for the product, it was simple to just write the code. It’s not clean, and certainly wouldn’t pass a code review, but it’s a simple program that achieves my goals.

This was the first time I felt satisfied with what I had created. It solved my problem. It was simple. It was easy to iterate on. I fully understood all of it. It felt just like the time that I first replaced a motherboard in a broken computer – I understood all of the pieces, how they worked together, and was proud of the result.

Eventually, one of your “fun” projects will be crappy, but worthwhile to improve on. Maybe it’ll become less crappy with time, and maybe other people will even want to use it. That only can happen from all of the lessons that you’ve learned from the abandoned crappy projects. It’s a skill to be able to build something that fills a need, and it’s worthwhile for everyone to learn.

Extra:

If you have any doubts, think of something that you want to build. It doesn’t matter how good you are, just try it out. See how it goes. Don’t stress about following all of the best practices, just follow your gut. By the time you’ve started making real progress on your project, you’ll probably already have ideas about how to do things better. You’ll already start to see how crappy your project is (for one reason or another), but that’s the point. It has to be crappy. The realization that it’s crappy is what will fuel you to keep getting better, and it’s where the best ideas come from.

© Jacob Kania