Side-projects Vs Work (for learning)

Tagged: work meta rambling

Lately, I have been thinking a lot about improving and learning as a programmer through the use of side projects in contrast to learning in the workplace. I haven't arrived at anything entirely conclusive, but I think that writing up some ideas and some thoughts here might help me reflect a bit more.

It feels as though I'm stating the obvious when I think about the differences between work and side projects as a vehicle for learning. However, I also feel like there's something more, just outside my reach, that I'm just grasping at. I'm hoping by writing some of it out things will become a bit more clear.

So, perhaps let's start with what feels obvious to me:

Work & Learning

Any of the following could be true when it comes to learning at work (in my experience):

Sink or Swim

In a workplace, it is, to some degree, sink or swim. You are not leisurely writing code whenever you feel like it, and your capabilities and performance are pertinent to your success and your ability to keep your job. Yes, this is a generalization, but I think it is largely true.

Sink or swim means you are learning under pressure. This is going to enable some abilities and prevent others regarding learning things. Further, with sink or swim comes the implication of deadlines and goal posts that you or someone else might be setting for you; again, pressure. I'm not exactly qualified to say how pressure could change how one learns but it's a factor that we should outline at the outset. Let's move on.

Working with others

For myself, I have mostly worked on side projects alone and worked with others in workplaces. Some of the most effective learning I have experienced has been at the hands of others who are kindly willing to share what they've learned along their journey. This isn't any surprise. The mentor/mentee or master/apprentice relationship has existed for a long time. Since this is a bit obvious, let's cut to the chase. when working with others you are:

  • (Hopefully) able to have an iterative process that involves getting feedback on what you produce and what they produce as well.

  • Able to get context more quickly from someone who can simplify complexity down to what is essential for you to know.

  • You can learn what is considered idiomatic in a codebase or in how people on your team use their tools.

  • You can (hopefully) pair program, which in my experience, has been one of the fastest methods to expedite my learning.

A lot of the above doesn't exist in a side project.

Reading Existing Code

I would say nine times out of 10 when you are working on a code base at work you are working in a brownfield space. This means that you are for the most part not writing new code (ie, greenfield).

Having existing code means you have patterns that you can lean on and this allows you to absorb how others do things. Usually, I would say this is good. Sure, there will be code bases that have lots of bad patterns but, inversely, this can teach you what not to do.

Code Review

If you're working on a team you hopefully have code review happening. This is another thing that is absent when working alone on a side project. Code review can be a painful time for some folks as it involves, often, getting direct feedback on what you may have missed, what you may have written incorrectly, or failed to do as a whole. When you work on a team it is up to your teammates to point these things out to you. When you work alone it is up to you to see the mistakes when they appear and then try and avoid making the same ones in the future.

40 hours a week

It can't be avoided, but working 30 to 40 hours a week is a heck of a lot more time to work and learn a specific thing than most folks have to put toward side projects. If you are working away, learning, and contributing to a code base full-time during the week with a team you're going to learn more than you do on a side project.

Uh oh, that seems like a pretty big claim. I can hear the arguments already bubbling up from you, dear reader.

I should say that in this hypothetical situation though, I'm describing a workplace where you are working on a codebase that is either new to you or challenges you in some capacity. I'm not talking about someone working on a legacy code base where they change one or two lines every few weeks and are just scraping by doing the bare minimum. I'm talking about code bases that have new feature requirements or perhaps have ambitious refactoring goals etc. 30 to 40 hours a week on something like that goes a long way.

Side projects & Learning

Hey! I thought this post was about how learning happens with side projects, not in the workplace!

Well, yes. What I described above is an ideal situation where your work is interesting to you and you are learning things you want to learn. That can be infrequent for many people, and I think that is a big factor that drives people to do a side project.

So, how might someone learn differently when they're working alone on a side project than in the circumstances I've described above?

No Pressure

Let's return to pressure.

Working on a side project, beyond putting pressure that one might put on oneself, there is no sink or swim situation. This is not something you're doing to pay the bills. I believe that programmers flock to a side project as a space of respite where they can do what they originally loved to do—programming—without anyone breathing down their neck or deadlines to hit.

When you are not under pressure you can take as long as you need. This is obvious. But the big underside of that iceberg is the ability for new ideas, understandings, and comprehensions to surface as time passes. So much of programming can be made better by giving oneself space to let an idea unfold. Sometimes I've "learned something in anger", (an expression I think means to learn something in a pressured environment), but never really understood that thing until enough time has passed.

When working without pressure we are, of course, susceptible to other things. Perfectionism, waffling between methodologies, losing motivation, and abandoning projects (among others). These things all sound negative, but they are also things that we can learn from that don't happen as often in the workplace.

100% Responsibility

When you write for yourself, you are responsible for what you write. Whether you are deploying the code that you are writing or not, you and you alone have written all of it. This is a unique circumstance that often doesn't get replicated in the workplace. When something breaks you have only yourself to look for the cause. When you go back to old code you are the one who wrote it and you were the one who has to decide whether it needs to be refactored or not.

This kind of responsibility enables learning by mistake. You can make mistakes in the workplace, of course, but when I'm entirely responsible for the code I write on a side project, the immediate pain of making a mistake is going to be memorable in a different way than at work. I don't mean to say either provides a better learning experience; they are both different.

I suppose this gives you the ability to measure your progress based on how you used to write code and how you do it now. There is something about being able to see something that you struggled with, alone. To be able to see that progress, that can be very motivating. I have some other thoughts on this but they're still percolating.


I think the freedom to use whatever tools you want or to build whatever you want is one of the main draws of working on side projects.

In my working experience, I've come across many folks who often don't like the tools that they use at work. I think it is rare to find a job where you get to use the programming language, tools, etc. that you like. And so again, the side project becomes a haven for expressiveness and control.

How does that change how one learns? Well perhaps most obviously, you get to learn and try new tech that interests you. You can get better at, say, using a niche language that might not be found in the workplace.

Further, for those who like to work on the bleeding edge of certain technologies, using technologies with limited documentation (forums, stack overflow posts, etc), can build a certain resiliency (for example, having to read the source code of a new language since the documentation hasn't been completed yet).


I think that programming is an inherently creative task and that creativity is closely linked to the freedoms discussed above. With freedom comes the possibility to let the mind work outside of boxes it may have been in at work. I think that we learn differently when we can do this. I don't have much more to say on this, and I can't back it up. Again, just a feeling.

Wrapping up

I didn't really arrive anywhere conclusive in this post. I guess I mostly just felt like rambling and indulging some thoughts I've had lately. As for me, will I be working on projects forever? I hope I'll always try and make time, but this current time in my life has awarded me with the most free time I've had in a while - a privilege I likely won't have in the future, I imagine. For now, I'm lucky to be able to learn in both "places" - work and on my own. When the time comes to only have one (or perhaps neither!) I'm sure I'll have some new reflections on the matter.

Well, that's it. No fireworks or revelations this time around. Mostly I think I just need to go make dinner and eat something or I'll keep rambling.

Thanks for reading!




Another thought that occurred to me while editing this post: being a programmer is one of the few professions I can think of where the people who do what they do at work sometimes also spend their free time at home doing it. I could do a whole post to unpack this phenomenon. It's strange and I'm not sure what to think about that yet.