Build a new open-source project every year

Learn a new programming language every year. That’s what Andy Hunt and Dave Thomas recommend in their industry classic The Pragmatic Programmer. And it’s great advice — different languages take slightly different angles to solving problems and learning new ones broadens your horizons. But while writing code is important, there are a few other things that we need more practice at.

Keeping up

The industry moves forward at an incredible speed. Technologies come and go; what is a great step forward now can become a major hindrance five years later. Faster machines push programming languages further up the ladder of abstraction to make programming slightly more productive.

Keeping up with all that isn’t easy. At our jobs were paid for doing what we already know. Our skills deepen but also narrow over time and seeing our stack being deprecated might be quite a shock after all those years.

How not to get stuck in the past? Well, this is how I do it.

An open-source project per year

Apart from learning a new language, I aim to build at least one new open-source project each year. There’s only one rule: don’t use a stack that I use in my day-to-day work.

Releasing a project requires more involvement than just trying out a few examples from the getting started guide. The bit of code you’re writing will one day need to be finished and published and that sets a whole different dynamic to the exercise. Shipping holds you accountable.

Projects go through different stages — from the first idea and initial excitement, to the awful slog at the end when you’re glad it’s finally over and you never want to see it again. When there’s no deadline, it’s too easy to abandon whatever you’re doing when it gets difficult. But that’s exactly when we learn the most.

An exercise in shipping

It takes focus and discipline to lock down an idea and deliver it from the start to finish. But being able to do that can be the difference between a cog in a system and a professional that delivers solutions actual problems. We all have ideas and bursts of inspiration. It is taking them to the end what makes the difference.

Particularly in larger companies, software developers don’t get a chance to witness the entire machine that is behind a product. From the concept through design, development, sales and eventual support.

Shipping an open-source project is your chance to try a mini-version of many of these things yourself. How many times will the requirements change because you changed your mind? And how easy will it be to market your idea to users and find contributors?

Size doesn’t matter

With a full-time job and three little kids to raise, it’s not easy to find enough time or energy to work on these side-projects. But we didn’t choose programming because it was easy.

Investing into your skill set regularly is an essential part of a career in software engineering. If you don’t have time to do it, you’re not doing it right.

You don’t even have to work on it outside your office hours. Many companies organise hack days and allocate personal development time to their employees. If your personal time is all booked, look for opportunities that offer this option.

Besides, your new project doesn’t have to be a rewrite of the Linux Kernel in Go. What matters is that you take it from the initial idea out to market. You’ll get to chance to experiment with a few new things and deliver a finished product on your own. This package has about 80,000 downloads a day on average. If you look at GitHub, the sources count three lines of code.

Final thoughts

Don’t stick out with a rusty old library forever just because you know it well. Open-source projects are a fun way to learn and explore and even if you can’t build the next Linux in your spare time, you might be able to help a few people. You never know who else might pick it up. If nothing else, having a history of open projects is also a great way to prove your programming skills to future employers.

This is why I try to build at least one open-source project a year. In 2014, I made tco and scriptster (and dr at work). In 2015 it were catpix and gitwalk (after a lot of struggle). I’m not sure what I’ll be doing in 2016 yet. Maybe something small in Rust or Go?

What will you build next?