Coding outside of work is a hot topic.
On one side is the Rise and Grind™ hustle culture, and on the other is a group of people that tell you to just go enjoy your life.
Read a book. Bake some sourdough. Learn carpentry. Anything—just not anything on a computer!
The truth, I think, is somewhere in the middle. Like any important topic in software development, the answer is often it depends.
Let's talk about coding outside of work. The career benefits, the burnout, and the ultimate life question behind it all: what do you actually want?
A career at light speed
I started my first development job in late 2012. I joined an existing company that seemed like it was run intelligently and had good future prospects.
This was before news and buzz around startup culture had permeated every corner of our lives—or at least mine.
I took a job doing .NET development along with some Classic ASP, VB 6, VB.NET, and C# ASP.NET.
I was on was an internal applications team, and we built and maintained the internal CRM, customer support tooling, and database schemas that the sales, customer support, and product application developers relied on.
Looking at the job as a whole, it was a pretty good first job. The pay was decent, the people were intelligent, and I was overwhelmed with the amount of new topics and learning I had to do (which was a good thing).
I was on a relatively small team of five or so people, and I was learning frontend, backend, and database development at the same time—although I didn't really know what those terms were at that time.
There was one problem: I hated being there. This job was destroying my soul on a daily basis.
Part of it was the technology we used which felt archaic and dull. And part of it was the internal codebases we worked on (product design/user experience was intentionally ignored for the benefit of cramming the most information possible on the screen).
But the biggest factor was the company culture.
Still, I did have one saving grace: my time spent coding outside of work.
Enter Ruby on Rails
Around this time, by chance, I had met a new friend who was also a developer. Back then, he was the only developer friend that I knew. We started hanging out more and as a result we started to tinker on different projects.
Outside of work, on nights and weekends, he and I started learning this relatively new framework at the time known as Ruby on Rails.
I loved it. It was the incredible opposite of everything I hated at my job.
It was easy to use. The "convention over configuration" mantra that Rails was built upon made so much sense.
Instead of writing the same stored procedures over and over in SQL Server I could just call a one-line function in the Rails framework. Why re-invent the wheel when a lot of really smart people have already figured this stuff out for me?
At work I developed applications using Windows GUIs that looked like they were developed in the 90's and had never been updated.
After work I ran all of my Rails commands from the terminal and felt like the baddest hacker there ever was.
At home I could build anything I wanted. I could use this shocking new CSS framework called Bootstrap CSS. The world was my oyster. There were no rules—no one telling what I could or could not build or how I had to build it.
During this time my wife was in law school and she was studying almost constantly. While she studied late into the night, I built dumb toy applications. In the morning I would get up early to watch tutorials and practice building apps, and then I would go to my day job and endure the day of work there.
At home I felt the creative flow and power of creating something new. At work I felt trapped.
I continued this for quite a while—until one day I finally couldn't take it anymore.
Onwards and upwards
I had finally had enough. I talked with my wife and we decided it was time to look for a new job.
As luck would have it, I found a company in my city hiring Ruby on Rails developers. I was still incredibly new to Rails—and I had only been doing real software development for a little over a year—but they saw enough potential in me to hire me and were willing to train me in the things I didn't know (which was a lot).
At this new job (which was infinitely better), I continued to build and learn and practice at home. I knew from an early age that I wanted to own my own business, and I saw software as the path to get there. So I continued to learn, practice, and build on the side.
Failed startup. 3 Months funding. You in?
A short time later opportunity struck. A startup here in the city had failed, the company had disbanded, and the lead investor was wanting to give the product one last go.
The same friend that I had been building on the side with was connected with the investor through a mutual friend. My friend gave me the pitch: we've got three months of funding to see if we can turn this product around—after that who knows.
Imagine yourself in that scenario. Would you take it?
This job did pay much more than I was currently making—but only three months of funding? Who would quit their nice, stable job for something that possibly only existed for three months?
Well, I did.
There are many other lessons that I could write about that experience, but I want to focus on one thing: the application we were trying to resurrect was written in Ruby on Rails.
At this time I didn't know this, but I realize now what I had been doing all along: I was paying the cost of the opportunity. All of those nights and weekends I'd been coding away were practice and preparation to take on this opportunity.
Today, I can word that moment more succinctly: the cost of an opportunity must be paid before it arrives.
In this new job, I grew tremendously. At one point I leading a team of five developers, two designers, and helping the business meet the objectives set forth by our investor and CEO. It came like a whirlwind, and it consumed my life.
I was not only coding all the time and polishing my backend skills to a razor edge, but I was also planning, leading a team, and mentoring other developers. It was many years of experience crammed into an incredibly hectic year.
After a year, this resurrected company imploded in glorious fashion (long story classic startups blah blah blah) and I moved to consulting.
Although this particular company failed, this pattern of learn, practice, opportunity continued to happen throughout my life and career.
A short time later, I was introduced to a new framework called Phoenix built on top of a language called Elixir (which itself was built on top of an old language called Erlang).
The same thing happened again. I learned it, practiced it, and a year later a simple consulting gig morphed into taking on the role of "Contract CTO" of a small startup company.
Looking back it feels a little serendipitous, but each of those little decisions linked back to one thing: coding outside of work:
- Took on CTO role at startup
- Took on CTO role because I learned Phoenix outside of work
- Heard about Phoenix from friends met at previous startup
- Joined previous startup due to friends made before and skill with Ruby on Rails
- Grew my skill in Ruby on Rails from job
- Got Ruby on Rails job from building side projects in Rails
- Picked up Rails because I hated my life (kidding but also not)
Learn. Practice. Seize opportunity.
Coding outside of work is not a magical force. The magical part is the habit of continually learning, practicing, and building.
This simple little practice rocketed my career years ahead—from commuting in every single day to a job I hated to working remotely with control over my time and energy—building the life I want to live.
At the beginning of this I said I was going to talk about the tradeoffs of working outside of work, but so far I've only talked about the amazing things that working outside of work brought me—and it has brought some really great things.
Well, this is the part of the movie where we rewatch the flashbacks with a different musical tone underneath. I just played you the highlight reel—but there's another side to this coin, and it's the cost of coding outside of work.
Health, relationships, career—pick any two?
Let's rollback to the startup company I joined that only had three months of funding. Was it an incredible growth opportunity and at times incredibly rewarding? Definitely. Was it also a sustained period of overwork, stress, wasted opportunity, and unhealthy self-soothing? Definitely as well.
You see, there's only a finite amount of time and energy a human can put into any activity. We only have a set amount of time per day. If too much time is allocated to a particular thing, that extra time is being stolen from another thing.
At my first startup when we worked insane hours day after day, night after night, and weekend after weekend—that time came from somewhere.
It came from time with our friends, families, finances, and from our health. We didn't sleep enough. We constantly ordered food from restaurants to sooth the stress and pressure we felt on a daily basis (food is a powerful soother, and it's often forgotten about since it's one of the more socially-acceptable vices to have).
No surprise here: our bodyweight went up and our health went down. Heavy meals, sugar, and caffeine fueled us.
Our relationships suffered as well. Time with our families was rare, and too much of the short time we had with them wasn't quality time—our minds were still at work.
I doubt this story is surprising to you—it's a classic tale. Person gets absorbed in work and throws away their family and their health. It's cliché, but it's true.
We'd think we needed to grind for "just another two weeks / just until we finish this piece of the product for this upcoming event / just until this meeting with the investors/potential acquirers."
Once before an Important Demo™ we stayed at the office and worked through the entire night—including sleeping on the ground for a quick nap before the demo.
But that time would come and pass, and then the next milestone would show up—and the cycle continued again.
Burned out, and for how long?
While there were some incredibly fun moments along the journey, the burnout and fatigue continued to mount. That's the cost of working too much outside of work: eventual burnout. We only have so much to give before we have to recharge.
And that burnout takes a long time to recover from.
There's an old adage about relationships that it takes half the length of the relationship to move on, and that's how it felt for recovering from burnout.
Even to this day I feel the dullness of burnout hiding just outside of my periphery. It's always there, ready to creep back in.
The one important question
Let's replay those flashbacks one last time.
These are the honest truths of the benefits and detriments of too much work outside of work. But the thing is, the truth is really somewhere in the middle, and I think the answer is determined by this question: what do you want from life?
It's a terrible question—not because it's a bad question, but because of how heavy and difficult it is to answer it.
What do you want? What do you want from your life?
The question is not should you code outside of work or not—but what do you want to gain from it, and what are you willing to pay for it?
There's no doubt that working outside of work has launched my career forward years at a time. There's also no doubt that it had a cost. When people I knew were taking vacations, watching Game of Thrones, or just plain enjoying their lives—I was working.
Do I regret all of that time working? Definitely not. I've gained a large amount from it. Do I regret some of it? Yeah definitely.
The important thing is to define what you want, and what you're willing to pay for it.
Depending on who you are and where you are in your life your answer will be different, and that answer will likely even change over time—it has for me.
A young, single person just starting out in their career may decide to pay now to reap the rewards for later.
A person coming to development with an existing family and responsibilities may be content with just working their 9-5 job and shutting it off for the day. That could be all they want—a stable and full life with their family.
There's no right or wrong answer here. There's just your answer. Each decision has consequences. Define what you want, what it takes to get there, and what you're willing to do for it.
I have a daughter now, and when she was born I decided to prioritize my time with her. If a similar opportunity arrived now that would require grinding away my nights and weekends, I wouldn't take it. I have things that are now more important than that (and for the record, I now also don't think that it requires that).
In what is now regarded as a somewhat controversial book, Malcolm Gladwell's Outliers: The Story of Success often mentions this concept of "10,000 hours":
Throughout the publication, Gladwell repeatedly mentions the "10,000-Hour Rule", claiming that the key to achieving world-class expertise in any skill, is, to a large extent, a matter of practicing the correct way, for a total of around 10,000 hours, though the authors of the original study this was based on have disputed Gladwell's usage.
Regardless of if the "10,000 hour rule" is correct or not, there is no doubt that someone who practices more at a particular thing will have a better result than someone who practices less. Or at least that person will reach their desired result faster than the other person (given the practice quality is the same, which is a big "if").
It's because of this that I understand those who champion work outside of work.
On the other hand, it's been well-studied that there are significant diminishing returns on working long hours.
In fact, a 2014 study from Stanford University and the IZA Institute of Labor Economics showed that work done after a certain threshold (~55 hours per week) doesn't give any noticeable benefit. I've found this true in my own experience as well.
In my experience, consistent weeks over 40 hours of work led to a loss of strategic thinking, numerous mistakes, and a litany of burnout effects.
I was recently pointed to an episode of the Indie Hacker's podcast where the creator of the Ruby on Rails framework, David Heinemeier Hansson (or DHH as he's been come to be known), was discussing this very topic with another successful software entrepreneur, Natalie Nagele.
DHH is known for his bold (and sometimes harsh) stance of not working outside of work. He points to his success with his company Basecamp, and the fact that they barely ever worked more than 40 hours per week.
While there's obviously more to the story than what he can share in one podcast episode, there's one point that he stressed on that I think is crucial: the quality of work matters.
At first, some quantity—then all quality.
You need some quantity of work to get going, but once you get moving, the quality of your work becomes much more important than the quantity of work.
Don't underestimate the growth from one focused hour of learning each day. Two hours isn't necessarily better—nor is four.
Like I talked about in my post How To Become an Outstanding New Developer, aim to be 1% better every day. A 1% improvement every day is a 37X improvement over a year.
Small and consistent wins will always beat out a short burst of intensity.
Neither good nor bad
So there's the actual truth behind coding outside of work. It's neither good nor bad: it's a choice.
It's a choice with different consequences. Neither outcome is bad if that's what you decide you want.
There's no doubt that more time, energy, and practice on a craft will make you better at it—saying anything otherwise would be silly. But, there's also no doubt that there is a cost to pay from the other areas of your life.
I now don't think working all the time outside of work is required—let alone beneficial. There's a sweet spot between some focused, intentional effort and enjoying the life you're working so hard to build.
DHH once tweeted something that has been seared into my brain:
Since I read that, I've been trying to figure out how to "waste some time" on the rest of the human experience. At some point, I think we all have to do that.
So the question that it all comes back to is this: what do you want?
If you've enjoyed reading this, I write similar things on my blog.
Thanks for reading!