One (and a Half) Reasons You Should ALWAYS Be Working on Side Projects.
Picture your day-to-day at work. You go into the office, sit down, do your morning standup — a quick meeting in the agile method to update everyone on the progress you have made on your tasks — and open your email to see what meetings you have. You walk down the hall to whichever break room has been allotted to your team and pour yourself a cup of coffee. At some point in the morning, between meetings and conversations with coworkers, you write some code on the new feature of the product your company builds for your latest ticket or to solve some bug that has been tasked to you. You might have a conversation with an architect, your CTO, or a senior dev and discuss the architecture of the systems you work in.
Depending on the workload and your office, the amount of focused time you spend writing code could be as short as an hour or as long as four hours. Depending on the other engineers who work in the code base and the scope of your team, the code you are writing could either be for core functionality or simply utilizing structures that already exist to implement a small feature to close your Jira Ticket.
Later, probably after lunch, you open your private email or Hacker News and read some of the latest articles about what is happening in the industry. These articles may talk about the newest features in the newest language you are working, in or simply discuss someone’s opinion of the “state of the industry” or “state of front-end development.”
At closing time, you pack up your laptop, get in your car, and drive home to hopefully spend time with your loved ones and/or potentially watch a lot of television.
If this sounds like a typical day for you at your office, I regret to inform that you probably didn’t learn much about software development on this day. And even if you did read about functional programming in Javascript or the benefits of Test Driven Development, after a week or a month of not being exposed to the topic, you probably will not remember it.
Passive Learning vs Active Learning
When you read articles about topics that interest you and gain information you could use to answer questions, you are engaging in a process called passive learning.
Passive learning is defined as “a method of learning or instruction where students receive information from the instructor and internalize it.” It is a method “where the learner receives no feedback from the instructor.”
Applied to programming, I believe it is even reasonable to go as far as to say that passive learning is any learning you do where you receive no feedback from your peers or the compiler.
Much of the learning we do in school is passive learning. Your professor lectures on a topic and you take notes. There is minimal meaningful interaction.
If you are a great student, after class, you formulate these notes into consumable chunks and review them.
After repeating this process for a while, your professor quizzes you on these chunks of information, gives you a grade on how many notes you remembered compared to what he feels you should have remembered, and, if you do not encounter this information again, you slowly begin to forget what you learned.
You can passively read about something many times, but if you don’t actually put it into practice, and if you don’t review, you won’t be able to retain it.
It takes time, repetition, and a desire to learn to improve your coding with techniques you read about.
It also takes meaningful, active practice and thinking to develop strategies about how to utilize a new technique in your code and how it could benefit your workflow.
To Learn, You Must Apply
In a skill-based endeavor like programming, in order to actually learn what you read, you must apply the ideas and techniques you read about.
Reading articles about new programming techniques and paradigms is not enough. You must find the time to build software with them.
That’s where your side projects step in.
You have to Start Somewhere
To become a great programmer, you need to afford yourself the time to be a crappy programmer.
The best time to do this is during your own projects.
Working on side projects is the equivalent of Stephen Curry practicing hard-to-hit three pointers. We’ve all seen him shoot greater-than-NBA-length threes at high accuracy while being covered. What we didn’t see is when he struggled to shoot even high school or college distance three pointers. Or when he first moved from shooting high school-length threes to NBA-length threes and his shooting percentage went down. Or when he missed the short jumper which would have made his middle school team win (all stories I completely made up about Stephen Curry, but the point is that he must have practiced before he became a superstar, and he must have failed).
Working on side projects affords you the opportunity to write less-than-optimal code that you think is really good before you can write optimal code.
Side projects give you the freedom to not understand and try to just “write some code down” to figure problems out.
Side Projects are safe spaces for you to take the actions required to move from a junior developer to senior developer, to cross the threshold where an engineer no longer goes down pathways in design of the system which are not beneficial and/or not sustainable into the future.
We love to preach about designing before you write the first line of code and trying to write code that is extend-able from the start. These are both good ways to write code, but you can’t appreciate these ideals or see and implement these strategies without having written a bunch of less-than-ideal code in the past.
If you’re going to have to write some “less-than-optimal” code anyway, you might as well do it in the comfort of your own git repo rather than in professional systems at work.
So open your text editor, take one of the ideas you thought were cool in the past and get to working on that side project.
