I've only recently come out of my burnout, despite it happening years ago. It sucks. It sucks bad. But looking back, I can see many of the causes crystal clearly, that weren't so apparent at the time. Here's a list:
1. Think about your project and only the project
Let's face it. Business wants you to make the best product you can "for our customers". You put off fun features for the sake of missing a deadline. You plan and analyze and break a project into sets of deliverables that then must be coded by a monkey (you). You demo it, gather feedback, iterate. All without thinking anything for yourself.
But newsflash: you started programming because you thought it was fun, why not keep programming because it's fun? Take that little extra time to put in a feature you want. Challenge yourself a little bit in doing something you didn't think you could. Show it to everyone you know, and don't just ask for feedback, but brag about what you've done.
2. Have a negative attitude toward everything.
You know Docker? It sucks. Who would trust their production environment to a new, unstable, toy. Go? Do I look like I want to write every library myself? Everything I need is already in PyPI. This project I'm working on is so caught up in office politics, it's never going to work. Jenkins? 2008 wants their tech back.
It's really easy to fall into the "being critical" trap. It's easy to tell other people what the "wrong" choice is. I imagine it's because as software engineers, our job is so find faults in our applications and fix them. And if we don't find them, someone else finds them for us.
But I don't think we need to be negative about our job, decisions that are being made (even if it's not our decision) and what we're working on. Some of the best projects I've worked on worked out that way because we had a great, positive team. We enjoyed showing up every day to work, told each other when we did awesome things, held back heavy-handed criticism and phrased it in a productive manner.
3. Use the tools you know, because you're faster that way
So you're an uber expert in Java + Spring + Hibernate. Nobody can touch your python skillz. Every personal project you do should be in these, because all that matters is the business side of things, right?
Wrong.
While it definitely makes good business sense, you should prototype, play around, and become an expert in new tech, even if it's unvetted. While this might seem like obvious advice (it's repeated alllll the time), it becomes a lot harder to do as you grow more experienced.
4. Switch jobs often
Otherwise known as "chasing butterflies". Getting bored with what you're working on? Have an itch? Time to dust off that resume!
This is bad, bad, bad.
When you have several short employments, it can usually help boost your salary quite a bit, but you are robbing yourself of:
- Growing in the company (developer -> manager -> director)
- Gaining an expertise in a specific area. Considering it takes 4-6 years for a PhD student to get their PhD, that's a lot of time you need for learnin.
- You are having to start from scratch often.
- If you are a good developer, you have to "prove" yourself (people listen to you) all over again.
So how do these contribute to burnout? Your career stagnates, you don't develop your skills as deeply (only breadth), people dont trust you'll stay employed for a while, and you're constantly having to prove yourself.
5. Work long hours, ignore your life
"You don't have to work a lot of hours, but some people choose to." You want to impress your boss. Hell, you want to impress yourself. So you go die-hard to meet an impossible deadline. You delivered the project on time, with all the extra features you wanted. You are the hero. High fives all around. And if you're lucky, you'll get that bonus.
That's great the first time. But how about the second. And the third. It's a bomb, and you dont know how short the fuse is.
Summary
In short, it's easy to burnout. Do these 5 things, and you can burnout too.