Good Software Engineers Have Side Projects
I’ve talked with a number of people, particularly business-type people, who seem to consider engineers working on side projects as a warning sign. This attitude, primarily held among non-technical people, is not only wrong but it actively interferes with their ability to find, nurture, and keep good software people.
Good software engineers almost always have side projects. In fact, those side projects are one of the reasons why they are good software engineers. The reason is simple: Good software engineering requires constant learning, and very few companies create a situation where all of that learning can occur on the job.
Technology, and software in particular, move incredibly fast. Today’s frameworks and tools are different than those of a year ago, and those are different still from those of five years ago. The details are ever-changing, requiring software engineers to be continually learning to stay afloat. At the same time, the techniques and practices that are used in software development, the deeper skills underlying the fast-moving surface, are consistent but require long and dedicated work to even begin to master.
This double requirement of keeping abreast of the latest tools and frameworks while at the same time mastering the underlying techniques means that in order to become and remain a good software engineer, you need to continually spend a tremendous amount of time learning. There are both requirements of breadth (keeping up to date with changing frameworks and tools) and of depth (improving your underlying skills), and it is very rare that learning on the job is sufficient to cover all.
Learning on the Job
There are some ways in which work can be a great environment for learning. You are often stretched to achieve things you’ve never done before, you get to work with other smart people, and with practices like pair programming and code review you can receive frequent, useful feedback on how to improve your skills. You get to work with a single codebase for long periods of time, learning what types of code end up maintaining well and what decays rapidly with time.
These are all good things, but there are also many ways in which the work environment hinders learning. The primary focus tends to be working product, which leads to a series of choices and practices that are distinctly suboptimal for learning. In order to deliver product, the tendency is to learn just enough of a particular library or technique to deliver what is needed now. Deeper learning or mastery of that library or technique are put off until it needed, even if it means suboptimal use or the missing of some opportunities.
Additionally, while learning is optimized by experiments, novelty, and risk, successful products are optimized by caution, using what is known, and risk minimization. Given the choice between a brand new, cutting edge library and one that is known and will get the job done, for a work project on a deadline a good engineer will choose the known library every time.
So given that the work environment is suboptimal for learning, and that constant learning is required to be a good software engineer, how does the circle get squared? With side projects. A side project is anything that is done on one’s own time, under one’s own control, and with one’s own expectations. Side projects can be everything that a work project shouldn’t be – experimental, using brand new experimental tools and techniques, and frequently sidetracked by deep dives into learning the details of a tiny component.
This makes side projects ideal for those parts of learning that work projects are not. You need not be afraid to try that brand new, cutting edge library because if it doesn’t work out, you can just throw it away without any repercussions to a schedule. Want to try coding in new language? It doesn’t matter that you’re 10X slower when you’re just getting started, or that no one at work knows that language, because this project is just for you. Distracted by that nagging annoyance about your development environment that at work you’d get a sysadmin to help with? Dive deep into learning how your operating system actually works, not worrying about the several hours it takes.
Because side projects are when an engineer gets to try out brand new, experimental things, many of those projects lead to very little in actual, visible results. They either won’t work, get abandoned, or get relegated to the perpetual ‘I should work more on that…’ bin. But the side effect is learning. By tinkering with new methodologies and new practices, engineers learn what works and what doesn’t in a safer, less pressured environment than work. By being able to expand outside of the languages and frameworks used in the workplace, they are able to expand their thinking and learn new ways of approaching problems. And playing with new libraries and tools, they find many things that aren’t worth using again, and occasionally new ways that drastically improve upon the old.
This is how new ideas and new ways of doing things make it into production software. You toil along, using the well known and established because that is how product is delivered on time, to a schedule. And every now and then, while tinkering on your own time with no schedule, you make a breakthrough or find a new tool that dramatically speeds up or improves some element of your process. You take that back to work, spread it around, and the product benefits.
What do you folks think? Do you engage in any cool side projects? What have you learned from them? Let me know in the comments!