Keeping Busy with Side Projects

June 15, 2016  ·  fedora, github, code, haskell, coq

Some 3:00am thoughts:

When talking about projects and side projects with people, one thing I very often say is “I need to be able to move around between projects.” This is something innate to who I am. It’s simply how I work.

This doesn’t just apply to side projects. Even with my work in the Fedora Project, I bounce between projects. Some days you’ll see me spend time hacking on Infrastructure projects, helping with updates to servers, fixing services that go down randomly at 3am (I’m a night owl, so I’m up anyway). Other days you’ll see me working on the packages I maintain, keeping them updated or fixing bugs that people report on them. Other days I’ll work on Fedora’s plethora of web applications, fixing bugs or writing Haskell clients to interact with them (finding and reporting bugs as I go). Still other days you’ll see me work on the Websites team and pretend to be a designer. If I didn’t have this freedom to move around between projects, I would not have lasted very long in the Fedora community. It is this freedom to move between projects that makes Fedora so interesting to me.

But, of course, this also applies to side projects. If you look at my GitHub, you’ll see I have over 300 repositories. Now, some of these are projects that never took off and barely have any commits at all. Some of them are forks of projects to which I have only sent one or two patches. But a lot of them are projects that I started myself and into which I have actually put a fair amount of work.

Take, for example, my project. This started out as a side project 5 years ago and I still maintain it. Fedora has even started using it for various URL shortening requirements. Another example is my bing_translator rubygem, which Scott Olson and I maintain. Or my category theory library I recently started on in Coq as a learning exercise. Or my experimental, incomplete chess engine. Or my toy bioinformatics algorithms library in Haskell. Or my encoding of metrics spaces in Haskell. Or…

The point is, I have a ton of random projects and I start new ones all the time. I do this for a lot of reasons:

  • I like learning about many different things, and so I write code to teach myself these things.
  • I like solving repetitive problems by automating them.
  • It gives me something to talk about with people.
  • It allows me to bounce between projects as I get bored or stumped.

That last one is key.

Keeping these projects around means that if I invest a bunch of time into one project and get burnt out or stumped on a project or just plain bored, I can set it aside for a while and go hack on one of the other projects that seems interesting to me. With any luck, I can talk about the projects enough on IRC that my friends finally get interested (or hate me :P) and hack on it with me. I’m a huge fan of having a plethora of people off of whom I can bounce ideas. This is also why I enjoy giving presentations at the YSU ACM and volunteer to give so many. Because if I can spark interest in my projects (or at least in some of the theory behind them), then I have more people with whom I can communicate and share ideas and gain feedback. Unfortunately, the way computer science education is structured at the undergrad level (at least in the United States) makes this fundamentally hard to do, but that doesn’t stop me from trying.

I have a friend who recently graduated and he messaged me the other day and linked me to his resume asking for feedback, which I gave him. But one of the things I wrote was “Try to list a few more projects. If you don’t have them, get hacking.” and I meant this really sincerely. I attribute most of what I know about programming and, well, most topics, to the number of side projects I have. And I’ve learned more in a few weeks of hacking on some of those side projects than I’ve learned in any undergraduate computer science class I’ve ever taken.

So? Hack. Start side projects. Make them open source. Get people/friends involved in them. I don’t care what language you use, what concepts you encode, what problems you solve. But stay busy with them and bounce around between them. Give talks about them. Brag about them. Because they’re worth bragging about.