Ask HN: What should I do if I feel burnt out?
The reason is that recently one of "star" developers at my current employer was poached by another company. As a result, most of his work (which I had no clue of) came on my shoulders. The code that I inherited is unidiomatic and written in a way that only the author could understand. And now, since I "own" the code, I've been putting extra hours and working on it as much as 15 hours a day to understand it and make fixes (which has become my day job). Despite of all this, I've failed to deliver on most deadlines (as the managers had higher expectations from me). To add to all of this, I've been diagnosed with hypertension, that gets worse with stress.
Given this, should I risk being labelled incompetent, by telling my stakeholders about my problems or should I put in the long hours needed to get stuff done (as that's what people in startups do).
32 comments
[ 4.2 ms ] story [ 70.3 ms ] thread1-2 weeks of vacation is what "normally" suffices, i.e., what "normal" people do. "Normal" people as contrasted with "burned out" or "on the road to burnout" people. It's not going to be enough for the latter group to do what is normally done: if it were enough, they wouldn't be burned out in the first place.
If you don't have a smart manager, well, take off QUICK. I had a burnout in 2006, took me the best part of a year to recover, and that was actually quite hard.
Gaaaaaaaaaaah.
Sorry, that was just my scream of frustration about a world which doesn't make this answer obvious.
You're an adult now. Go to manager; say that you've inherited a code base written by a more senior developer which has a substantial amount of technical debt in it and you'll need time to get up to speed on it. Work together to get a better understanding of when the milestones will be shipped successfully. (Unobvious-to-younguns true fact about managing: managers often need predictability a lot more than they need speed.)
Do not work 15 hour days to try to grok the code better. If you model your manager as a heartless automaton (and he isn't!), he'd heartlessly prefer you to be resting at home rather than in the hospital, since only one of those means you'll be filing TPS reports tomorrow.
Do not attempt to sprint your way out a scheduling issue. The business will always be capable of finding another catastrophe. You know how there are a herd of cows or a murder of crows? There's a startup of catastrophes. Companies/individuals/teams which develop crunch cultures never stop crunching. They ship whatever the blocked milestone was -- late, of course, because crunching very rarely actually speeds shipping -- and then promptly identify a new milestone to crunch towards.
It is not the job of 23 year old developers to insulate the business from the predictable consequences of the actions of more senior employees. If your manager feels differently, there are many saner managers available. That's a pretty radical step, but choosing burnout is a much worse step. Burnout is not fun. You wouldn't choose to develop adult-onset diabetes because it would avoid a difficult conversation at work. Don't choose burnout, either.
... because that's less likely to succeed than using 8 hours a day.
Even if you neglect the long-term eventuality of burnout working more hours in a creative/intellectual job does not result in more work being done: it will nearly always result in less.
If you can't get the work done in your normal working hours it means that the deadline is actually impossible. Some problems cannot be solved by throwing numbers at them; your manager has to throw planning at them.
- saying "it's going to take me X months because of the technical debt" is not an acceptable answer to the manager;
- working 15 hour days and taking X months more than the deadline is rewarded particularly if every diff is recorded in some kind of micromanagement tool used by the manager, for being "team spirit" even and especially with lower productivity.
Since not everybody can hop jobs easily, a successful way to survive in such a situation CAN be to just pretend to work long hours, put in the face time, enthusiastically play along with the micromanagement game and hope the job market will improve before the company goes under or the department is disciplined for its lack of productivity, and before this situation takes too deep a toll on your intellectual ability and happiness. The key is continuous small, trackable deliverables, and focusing on additive changes rather than improving the existing codebase.
It's important not to think about karma as such managers get promoted out of the way before their results catch up with them, and you'll just get more miserable as you watch them fly higher and higher on their column of hot air.
/rant
That's a reality I forgot about. Your advice is far better than mine is for someone just starting out.
Then there's "faking". That damages your soul, your heart, your inner person. Have integrity. Don't fake.
So, if he/she has to put in the insane hours to prevent being laid off, he/she should be job hunting for a sane situation, starting today.
As a project manager of approaching 20 years experience, I would agree with this. Some things can be fixed with temporary extra effort, but a lot of things can't. If a task I budgeted x days for is going to take 3x days, I'd rather know asap. That way, alternative steps can be taken - scope can be cut, extra people can be assigned, deadlines can be moved or budgets can be changed.
It's better to have these hard conversations as soon as possible.
Besides all the research pointing to that fact, I myself has burned myself into smitherines from stress and a toxic working enviroment. It took me two (2) years after my burnout to be able to work more than 2-3 hours a day and 4-5 years before I could work 8 hours a day for a week!
The brain is plastic, this means that it changes from stress and once you have overloaded it, it becomes more sensitive!
It's like breaking a bone - even though it grows back together, it will always be weaker.
That said, I also have burned out before and it is not fun. While I didn't have the long-lasting negative effects you describe, I have grown a strong reluctance towards working "long hours" on other people's ideas.
They don't break the bones, but merely introduce microfractures.
There should be a way out of this which will leave you, your manager and your coworkers happy and productive and your company successful as a result. Focus on that belief when you plan to talk to your manager, and try to ignore any fear you have about negative impressions they may have of you. And take a break as soon as possible.
Start a conversation with your manager and a HR representative immediately. Burnt out engineers are a sign of bigger problems, and I guarantee that you are not the only one in that situation. If your company is worth working for, this type of conversation is welcomed.
Some context: my most recent experience with burnout was about a year ago. A result of 8 sequential 130+ hour weeks. Around week 6 or 7, my code was utter garbage (more than usual), my attitude towards the project was awful and I was setting a bad example to my peers & team. In retrospect, I was probably hurting the company more than I was helping.
Today, those 20 hour days with 2 to 4 hours of sleep screwed with my memory retention and general ability to focus. Wish I could take it back and do it differently.
For me the burnout cycle ended after several conversations with the company's founders. They were very clear that employee health is paramount to the company's success and continue to work on mitigating the root causes of engineer burnout.
Once someone's reached a 15 hour workday, that's pretty much impossible. Normalising hours to 8 has absolutely got to be the first step.
(disclaimer: what works for one person may not work for everyone)
Nutrition, exercise, regular breaks, and a reasonable amount of sleep are what I consider the bare minimum and should be implemented with a thought out plan.
When faced with the 15 hour week. I start by creating a time budget, allocating my personal priorities first.
Here is a simplified example:
Sleep: 6 hours Exercise: 1 hour Meals: 30mins x 4 = 2 hours Breaks: 8*15min = 2 hours ------------------------------- Total personal hours: 11 hours
Remaining work hours: 13 hours /day
1 Day off every week to run personal errands, shopping, etc.
For me, this budget yields a 6 day work week totaling close to 80 working hours ensuring a break roughly every hour and 4 nutrient dense smaller meals.
Hope this helps.
That depends on if you are incompetent or not.
No, seriously - it's very hard to judge the level of your own skills, both technical and others. Try to find a senior dev who is not a total asshole and go ask them. If they worked with you earlier, it's all the better, but probably any experienced dev (who's not an asshole) will do. Just tell them honestly what you're doing, what you're struggling with, what you did in your previous work, things like this. This should be enough for any decent senior to tell you how skilled - relatively to others - you are. Would it be easy to change the job? Which kind of development (embedded, mobile, ...?) would be the most natural for you to pick up? What would you need to learn to change your domain to something else than your current one? Just have a little chat and you'll at least know your options much better.
And also, if you're unable to find a well-meaning, non-asshole senior dev in your company you should be out of there already!
Neither.
You should out the "star" and give your management the opportunity to solve their problem.
What's the problem with the "star"? "Getting stuff done" is only half our job. The other half is "keeping things done". You're probably the first one to discover his charade. (Yes it's a charade if you're hitting deadlines while creating techincal debt for everyone else!)
What's management's problem? They understand "getting stuff done" but obviously don't understand "keeping stuff done". They have failed by allowing all this technical debt to be accumulated. Where's the due diligence? The peer review? The code review vs. standards? The regression testing? They need to get their house in order and you're just the person with just the right ammunition to help them get started.
Your best option is also the right thing to do: fix the problem long term and give everyone else (management) the best opportunity to do their jobs properly. Anything less is bad for everyone, especially yourself. Remember, it's a marathon, not a sprint.
What you see as lemons is actually a rare enterprise opportunity (at age 23!) to make lemonade. Take advantage and become the real "star".
You know that feeling when you leave the office at 11pm having finally sorted out that bug? Nothing beats that feeling, you sleep VERY well that night.
You know your limits better than anyone. Pull a few late ones, but not too many. If it still seems too much work or too hard, then tell stakeholders.
The fact is, you're putting in 15 hour days to give them a chance to get extremely wealthy. You deserve to do so in a way that lets you live a life you are happy with. Always a relevant link http://www.jwz.org/blog/2011/11/watch-a-vc-use-my-name-to-se...
Employment in a startup can be very rewarding, but it needs to be mutually beneficial. If you're getting taken advantage of, bite back. A good friend doesn't just praise you, they criticize you when you're failing, and in this situation the company is failing you, as both an employee and a human.
Good luck.
Your brain needs time to absorb, process, and synthesize. It can't do that if you're trying to force-feed it new information faster than it can handle.
Take some time to write a couple tests against the code, to make some small refactorings, etc. If you still feel overwhelmed or underwater, talk with your manager and just tell them the code is a pile of crap (if it really is). They don't want to hear it, but they might cut you some slack.
Communicate with your management. Explain the situation. Be on the point. Don't over explain.
Things will work out. If the management doesn't care, it's not the company you should be working for.