I’m sure most developers have had the experience of buying a book on a new programming language, working through the first couple of chapters, being completely uninspired, and giving up on it. So you built a hello world app, who cares? Even if you make it through the whole book, what have you achieved?
Besides, by the time the book comes out, it’s probably out of date already. There has to be a better way to learn. And there is.
I used to teach English as a foreign language, and a popular methodology in that profession is task-based learning. The idea is that you’re more likely to learn by performing some meaningful task that uses the language area in question, rather than by reading about it or repeating drills.
This appeals to me, not just in language learning, but for learning anything. Whatever the skill is, I don’t feel like I’ve learned it until I’ve done it - “you don’t learn to walk by following rules, you learn by doing and by falling over”.
Trouble is, it’s not easy to try new technologies on client projects, especially if you work with organisations that haven’t entirely bought into agile. Even if they have, it isn’t always a good idea to play with new toys when there’s real money at stake.
But if you’re doing something in your own time, you’re not beholden to a client, and you have freedom. Side projects are an ideal chance to experiment, and an opportunity to learn by making mistakes, without getting bogged down in corporate bureaucracy. There’s no need to worry about purchase orders or change requests, you can just knock up a minimum viable product and take it from there.
Among all the debates about flavours of agile, and scrum rituals, it’s easy to forget that the main point of agile is about iteration. Being able to prototype something is a way to move away from the abstract, and a chance to see if it makes sense - in other words, “a prototype is a guess made tangible”
To start from a nugget of an idea and turn it into something real is a creative endeavour, and it’s good to remind yourself that developers can be creative people. The flip side of this is that, as with other creative disciplines, the difficult bit is having the idea. Well, that and having the time and energy, especially if you have a family…
As a lot of creative people find, there’s a certain pressure that comes from a blank page, and as the film director Robert Rodriguez puts it, sometimes “you only get the idea once you start”. Once you’ve built something simple, you can see what works, and what doesn’t, and you’ll generally find that the ideas will flow more easily.
My idea was pretty simple - build a tool (I’m trying to avoid saying “web app”…) to allow people to vote on their favourite tracks from a monthly playlist.
A trivial problem, perhaps, but something that mattered to me in the real world, and something with a clearly defined goal. Because Spotify have a well-documented API, and someone has written an Angular wrapper for it, this task was achievable for someone taking baby steps with an unfamiliar framework. With more experience, and more time, it’s possible to put together all sorts of interesting projects.
The beauty of open APIs is that they allow companies to benefit from the imagination of others, enabling the data to be used in ways that its owners may have never considered. This can be enormously valuable, not just for people who want to play with data, but also for the data owners themselves.
There are a lot of open APIs out there, so it’s likely that if your idea involves some kind of information, you’ll be able to get the data you want, or something reasonably similar to it.
With free issue tracking tools like Github and Trello, it’s possible to approach little projects like this relatively professionally. Or at least keep track of bugs and feature requests. And modern frameworks like Bootstrap and Foundation mean that it’s possible to put something together fairly quickly and for it to look fairly presentable, even for developers without much of a visual sense.
The other important point about iteration is that “you often don’t really understand the problem until after the first time you implement a solution”, and on side projects you’re free to change your mind. Because you haven’t got a project manager pestering you about burndown charts, you don’t have a team of colleagues writing other code that depends on your code, and you haven’t committed to a release date, it’s OK if you decide to throw everything away and start again with a different approach. Or throw everything away and do something completely different.
But chances are you won’t give up on the idea, because if it’s an idea that you actually care about, you’ll stay up late hacking away, and chances are you’ll turn it into something good. And you’re more likely to learn something if you’re excited about it. And if you care about it, then maybe other people will care about it as well. Plenty of side projects have gone on to be enormously successful.
But if your idea doesn’t have potential to win a big audience, that’s OK. You’re not in it for the money, you’re doing it just because you want to. And because it’s likely to remind you why you enjoy being a developer.
As they say on the shop talk show podcast, “just build websites”. Or apps. Or physical objects. Side projects for developers don’t have to involve code. Whatever floats your boat - the main thing is doing something you enjoy.