Reset for a longer lasting developer
Software is a peculiar industry. Say for example, you work for an architecture firm, you design a product, iterate on it, build it, make adjustments while you are building it, and then now you are done with the product. Art is the same way: film, music, books, even consumer electronics. No patches, no security updates.
In software, however, nothing is ever finished. As soon as you ship a product, or even before, you start working on version 1.0.1, or 1.0A, or version 45, patch 2 (if your company hasn’t boarded the semantic versioning train). This is, of course, due to the nature of the product. It costs virtually nothing to send improvements to customers already using the product. And in fact, they expect the product to change and improve over time, after they’ve bought it.
This isn’t universal. Some shops don’t send over-the-air updates to their products, but the most do. And this aspect of Software development influences how it feels to be a developer. We still occasionally get to celebrate an initial product release, or a change big enough to warrant a new (marketing-level) version name, but most of the time our work is about continual improvement.
Nothing is ever finished, everything can improve
This is a dangerous pattern of thinking. And if it isn’t regulated carefully by management and planning, it can put us in a sisyphean cycle, of always working towards the end of the next sprint, never feeling we have accomplished any concrete packet of work.
Perhaps even more important than an abstract feeling of accomplishment is true validation that you have worked hard and produced something valuable. If you work as a by-project contractor, you may in fact get a big paycheck at the end of a project. But if you work full-time at a company, you are just at one point in a continuous cycle.
But we need something more, something to feel like the work we have contributed to over the past months or years has been valuable. I’m not talking about a bonus or congratulatory work party. I’m talking about hitting the Reset button.
The burnout is real
A friend of mine of mine working at a software firm recently told me he has been “in a state of burnout or close to burnout” for six months. Six months driving on fumes. He practices all the work/life balance tips, and this keeps him going - getting enough sleep, eating well, going on runs before work, drinking lots of water. But the fact is we are expected to try and optimize our lives for maximum and continuous productivity. And, in working life (this is across most industries, not just Software), we aren’t expected to get a Reset.
What I mean by reset is a true, long, break from work. And we need these at regular intervals.
Schools have figured out that students need this. In University, the year is divided up into Semesters with breaks in between. At most schools, students get a three month Summer off. This allows students to travel, spend time at home or take a summer job, but most importantly to Reset.
Now, I’m not advocating for three months of the year off. That isn’t economically feasible. But I do believe that, as engineers, we would not only be happier at our jobs but more productive, more consistent, and more likely to stay if we took actual, long, vacations.
And by “long”, I mean at the very least three weeks. I’m also talking about infrequent sabbaticals - every few years taking some months off. We can use this time to travel, spend time with family, and recover from a life of uninterrupted productivity.
At many workplaces, no matter how many vacation days a year are afforded, there is a culture that taking three or more weeks off is frowned upon. But does a two-week vacation really help you Reset? The first week you are probably still coming down off of the buzz of working life. Adjusting your sleep schedule to sleep in - or, you’re travelling and getting over jet lag.
By the end of your first week of vacation, you might be able to start really enjoying being away. But as soon as you get in the rhythm, your two weeks are up, hop on a plane, get to work jetlagged on Monday.
We need more time - time to cool off and get out minds off work (meaning no emails!), time to enjoy a different rhythm of life, and then time to ramp back up to a working mindset.
Practical tips for dealing with burnout
So how do we accomplish this in our never-stop workplace culture? Here are a few practical tips:
- Even with a restrictive PTO schedule at your workplace, you may be able to negotiate for a better deal. Consider prioritizing vacation days over a higher salary - time is more valuable than money.
- Plan trips of three weeks or more, ideally to take after a big block of work is finished.
- Don’t stay connected during your break - sign off from email. Get time outside, away from screens. The body needs to recover from office life.
- Use your trips to be constructive in other areas of your life - have new experiences, visit faraway friends or family, or just spend more quality time with your parents, spouse, or children.
- Before your trip, make sure everyone at work is informed well ahead of time, and prepared for issues that come up in your absence. Well-documented, tested, and clean code will make it easier for others to debug your work while you are gone.
- Understand that employees (and managers!) taking long trips will lead to more a more productive and happy workplace.
- Set an example - if you are always available on email while you are on vacation, your team will feel expected to do the same. In the end, this limits the effectiveness of the Reset.
- If there is pressure from higher up to restrict time off, be an advocate for your team, and yourself!
After working in the same job for years, taking infrequent, longer trips - four weeks, three months, six months - becomes important. Longer sabbaticals let us truly get in a different rhythm, not just experience a break in our usual one. They give us perspective, help us be human. Help us feel like we have done a real, substantial, sum of work, and we can be happy with it.
At least until we get back and have to patch the bugs that cropped up while we were away ;)
Recommended product: Coding Essentials Guidebook for Developers