Some five years ago, I wrote a popular article about side projects. In that article, I asked a simple question. What does a good side project look like? How can you know that a given side project you're working on will actually push you further ahead in your career?
In that article, I argued that the ideal side project should be something that helps you learn new skills. It should make money. It should give you space to flex your creative muscles, and it should be limited in scope.
While I still agree with many of these statements, I now believe side projects can be a more larger, long-term practice. They can elevate your skills to such a degree that you may feel like you no longer fit in your current job.
I say 'job' because I want to draw a sharp distinction between a job and a career. I don't think this is well enough defined in our field, especially when you look at the way job ads are written.
For example, businesses often say they want a 'Senior React Native Engineer' for whatever yearly salary (usually over $100K). A few years back, I might have considered trying to get such a job. I would have thought it valuable to learn such a skill set because it popped up so often. It's clearly in high demand and is something you can learn in your spare time, using side projects as your learning vehicle.
That said, I wouldn't consider such a position to necessarily be a career.
Differentiating a job vs. a career: a career is more than what you do for money
A career is your life's work. A career is what people think of you long after you're dead. It's the thing you contribute to the world, hopefully some lasting change, hopefully something truly innovative that shatters some kind of barrier and provides a unique value incomparable to most things that came before it.
I know that's setting a rather high bar but, once we dig into it, I think you’ll understand why it's so important.
In a real career, you are in charge of making a meaningful and lasting change, and you are trusted to pick the right tools and work with the right people to accomplish that outcome.
Most employees are not in that situation. Instead, someone above us picks the tools and the people, and we have to go along with it, whether it truly is the right choice or not. Oftentimes, bad software engineering practices become popular because they are convenient in the short term, and they over-promise on what they can deliver in the long term.
People who would have otherwise been great engineers end up stagnating for their entire careers because they picked the wrong problem to work on and the wrong people to work with, so you need to be very careful about who you pick as your mentors.
If you do take a full-time job, I think it’s important to ask if it is a position where you will be given the autonomy to make and advocate for technological choices. Is it a position where you will be given some degree of ownership over the product's direction and design? Will you be working with someone who has accomplished something substantial (that you respect), someone who can teach you a valuable set of skills?
What separates this job from factory work? How will this job challenge you in new and interesting ways? Will you be given the opportunity to grow beyond merely memorizing the APIs of a third-party framework like React Native?
I found myself asking these questions, and the answer wasn't one that made me feel all that good about these kinds of jobs.
In the end, I didn't choose React Native. In that job, I probably wouldn't have the autonomy and power to choose a different tool or to build my own set of tools.
In many ways, that kind of job isn't all that different from factory work. It would be like assembling IKEA furniture. You're given a framework, and all you have to do is snap the parts together.
For some, that's a fine existence. You're just doing your job. But I wanted a career I could learn and grow in, which certainly wasn't happening when I was a full-time mobile app developer.
And I think it's important to recognize that sort of thing and to be honest with yourself about it.
Use your side projects to gain a deeper understanding
This is the kind of reasoning that led me to make my own game and game engine from scratch. I didn't want to merely use a framework or tool someone else made. I wanted to understand how computers and graphics work at a deeper level so I could create something truly innovative.
I didn't (and still don't) think React Native and most of these SDKs are designed well. I think they're overly complicated, more like trying to stack one more layer on top of a building that is already falling over. I believed (and still believe) we can do better.
And most importantly, I wanted to be surrounded by peers who don't think I'm crazy for thinking that way, people who encourage me to innovate and make something better, even if it takes a ton of time.
Unfortunately, most companies simply aren't in a position to do that. The demands of the present day outweigh the perceived benefit of investing in a better way to work. As a result, people in most programming jobs can go year after year without really learning anything that helps them grow. They flit from one third party framework to the other, and they don't get a chance to scrape away the layers and build something better.
I wanted that chance, and I used my side project as a vehicle to learn lower level programming and build that better thing that might be impractical for some employers but totally practical if your goal is to run your own company and make innovative games.
My side project and how it changed me
Two years ago, I started following Casey Muratori's Handmade Hero series. It goes over the entire graphics pipeline, and it teaches you how to make cross-platform games and apps that work at a lower level. It's the kind of computer science education that is sorely lacking, and I dove right into it.
I probably invested ten hours a week in addition to my existing full-time job, putting me at an average of fifty hours a week for two full years. During holiday breaks, I invested even more time because it's something I'm interested in.
The results of that small effort are kind of remarkable. After one year, I had the beginnings of a 2D platformer game drawing solid color blocks, with a game character who could jump around and collide with surfaces.
Over two years in, I now have a fully playable puzzle game with 34 levels. It works on my Mac, and I'm now working on porting it to Web Assembly so more people can play it.
Most importantly, this time investment gave me a totally new view of software development. I have managed to create a cross-platform game that isn't glued on top of the existing SDKs (like React Native) but that works with them to produce something fast, elegant, and easy to maintain.
I learned how to program in C. I learned about CPUs, GPUs, and graphics programming. I've written one 2D renderer in Metal, and I'm working on porting the same thing to OpenGL.
I've learned game design skills. I have come up with over seventy puzzles and have made a series of increasingly better prototypes. I keep getting rid of my old work because as each month passes, my design skills improve, and I have a different idea of what I would consider a good puzzle.
I wrote a 2D physics system that is fine-tuned for the things my game does. I made a pixel graphics editor because it's fun and it only took a few days. I also wrote a texture packaging tool to make texture loading faster when the game starts up.
I paid exactly zero dollars to Unity/Unreal or any of the third party engines. I own 100% of my game engine outright, and I can use it as a basis for future game development.
This hasn't just been an investment in my skills and understanding. It's been an investment in the tools my company will use in the future. Who knows? I might invent a new way to do cross-platform app development that other companies can use.
Expect your side project to change your outlook and opinions. If you no longer believe the same things, it's a sign you're growing.
Like I said earlier, I didn't always hold the views I hold now.
Not too long ago, I may have wanted a title like 'Senior React Native Engineer'.
But now I really recognise the difference between assembling IKEA furniture and handcrafting a desk from wood you selected yourself, and you have to choose which route you want to go. If your goal is to learn, you can only learn so much when you are limited by premade kits. There are only so many allowable configurations, so many combinations. It just naturally puts a ceiling on your growth.
If you've been using a coffee maker to make coffee for years and years, have you really gotten any better at making coffee? I know I haven't.
And I know that if I wanted to get better at making coffee, I would have to dive deeper. I would need to start importing or growing my own beans, roasting them, paying attention to the quality of the water I'm using to make that cup of coffee. If making the best cup of coffee were my life's ambition, that's the route I would have taken.
But I know that's not the route I've taken. That's why I don't turn on my Keurig and call myself a coffee expert.
This is the sort of criticism I have levelled upon myself, as a so-called software engineer. For me, I started to ask: how can I really call myself by that title if all I've been doing is following the instructions on the package?
Now that I have worked on my side project for two years, I have the sort of experience that makes merely following the SDKs' instructions all too easy, kind of boring if I'm being honest. I routinely whip through work that used to take me way longer, and clients are amazed with the speed. That means I can negotiate higher pay rates or simply work less and give more time to my side projects.
Last fall, I quit contracting full-time and have stepped back to part-time to work on my games. I didn't think I was learning enough as a full-time mobile app developer, and I was getting the work done so quickly that it didn't really make sense to keep me full-time. Money wasn't enough to keep me happy, as I believe life and career is about more than money.
I am obviously in a fortunate position, having the ability to work those extra ten hours a week for two full years. I know not everybody is in that position, but I still think any amount of time you dedicate to your side project is still valuable and will help you grow in your career (not just your job). And if you have the time and space to work on a side project, I have one more learning to share.
Innovation rarely comes from grabbing the low-hanging fruit. Give yourself permission to reinvent the wheel (or bread, if you're Nancy Silverton)
The key to a successful side project is to use that side project to develop an understanding that runs far deeper than your current one.
Don't go and learn another framework. Take the time to build your own thing from scratch. Pick lower level languages like C. Make your own programming language if you're so inclined. I'm sure you would learn a lot by doing that.
I'm reminded of Nancy Silverton, the founder of the La Brea Bakery. Back in the early 90s, she spent years experimenting with sourdough bread, using the natural yeast from grapes.
For her, this was a kind of side project, and she often woke up at 2 A.M. to tend to her various handcrafted sourdough loaves. It certainly wasn’t necessary, and nobody in Los Angeles was doing this at the time. But she kept working at it.
When she introduced her work to the wider world, it was readily embraced. The rest is history. The La Brea Bakery is a huge success. Nancy Silverton is credited with popularizing sourdough and artisan bread in the United States.
None of it would have happened if, instead of experimenting, she thought, 'Why reinvent the wheel? What can I really hope to contribute as an individual? Isn't it arrogant of me to think that I will stumble upon something truly novel in a craft as old as baking bread?'
The future is invented by people who, dissatisfied with what's around them, wake up at 2 A.M. to experiment with something radical and new.
