3 ms·

Ask HN: Starting new job soon, how to minimize burnout effects?

3 points by brndoutthrw 5y ago

Starting new job soon, but I am burned out at my current job, anyway I can minimize effects of burnout at new place? anything might help books to read, things to do and not do, youtube videos to watch? note: I will start with 1 week gap only and +1 week PTO from current job, in total I have 2 weeks to rest

GabrelyanG 5y ago
Do you really like the job that you're going to do?
- brndoutthrw 5y ago
  I am a software engineer and I used to love coding, but things have changed lately, I still want to code and ship stuff, whether it is in current job or at new job, problem is, there are many things I don't like but I need to do them anyway, which is part of a job, e.g. PM created a ticket based on customer request which is going to change a lot of things in our code if done correctly, but there is not enough time allocated, customer request and refactoring code is not a problem, but time to deliver is a problem, PM is expecting it to be delivered in a month, but we know we need to make a hard trade-off here by making a patch and creating yet another tech debt, time is just not enough to deliver things with high quality. All these things piling up everyday and dealing with project with a huge tech debt affected my health, before this project I thought I am a good engineer, now I think I am a terrible engineer, I will fail in my next job and so on.
- brndoutthrw 5y ago
  I am trying to push myself to think positively, everyday I say to myself, this work is awesome, I am going to build things, doing things I like, coding and shipping features, but the time I open next ticket/IDE all these feelings are gone, how can you positively think when you are sitting on a shit
onion2k 5y ago
The only way to avoid future burnout is to learn to say 'no' when people ask for things. Someone wants a new feature done in double quick time - say no. Someone wants you to add another 20 points to an iteration because there's a customer call in a few weeks - say no. Someone is demanding you work late to fix a 'critical' issue - say no. Your team is going out to socialize after work when you're really tired - say no. Saying no is a super power. It's also incredibly hard to do in a work situation. You have to work somewhere that accepts you might fail to achieve things sometimes. Most companies really don't accept failure well[1]. [1] Interesting side note - because companies refuse to accept failure most employees only ever take on tasks they're basically guaranteed to succeed at. This massively limits the ambition of most businesses. As Chip Wilson (founder of Lululemon) says, you really should be aiming for about a 50% failure rate with your goals. If you're succeeding more than that you're not aiming high enough.
- brndoutthrw 5y ago
  I agree with you, but sometimes "no" is not an option, especially now with some organizations, where company success relies heavily on saying "yes" to any customer request and sales people "promised" to deliver feature in 2 months, not knowing that it takes 4-6 months if done correctly, if not correctly, then 4-5 weeks, but tech debt is paid by us not by sales people.
  - onion2k 5y ago
    Sure, and those are the organisations where burnout is common. Burnout is stress-induced fatigue and exhaustion due to over commitment at work. Unless you fix the over work you can't avoid the burnout. Saying "no is not an option" just means you'll have to accept the burnout instead.
    - brndoutthrw 5y ago
      I am hoping new job will be different for me, to avoid getting trapped into burnout loop again in new place, I am trying to minimize effects and memories to carry from current work. Do you have any recommendations for it? maybe some articles, specific mediation techniques, books, videos, anything?
- mytailorisrich 5y ago
  If your an individual contributor, a "dev", you cannot say 'no' to feature requests, fix requests, etc. That's not your job and you do not have the authority. What you can, and should, do is provide feedback on these requests to the people who have the authority in a positive and constructive way. Then, you can leave if you really cannot stand it anymore.
  - onion2k 5y ago
    If your an individual contributor, a "dev", you cannot say 'no' to feature requests, fix requests, etc. That's not your job and you do not have the authority. You can say no. You have to be able to back it up with a reason, like "we don't have the resources" or "I've already got 20 points of work to do", but you absolutely can, and should, refuse requests if you're not in a position to do them. Saying yes to everything is how you burnout, and how products end up mired in tech debt and eventually fail. On my team I accept even the most junior devs telling me they aren't able to do something so long as they can give me a good reason. If they say yes and then don't do it the outcome is much worse. Every single person on a project should be working together to for the best possible outcome. That means accepting responsibility for your actions on the project - and that includes giving your PM important information like the fact you won't be able to do something.

mytailorisrich 5y ago
As I said you should provide positive and constructive feedback. You are here to do your job and be helpful, not to pick and choose what you want. You cannot refuse a decision made by management apart from quitting. As an individual dev "we don't have the resources" is not something that you can really say, either. Maybe I'll take an example: You're fully busy and you are told that a new feature was requested and agreed that you need to implement. You don't just say 'no'. You say that you are fully busy on another feature and that you then have several other features on your todolist and ask how you should schedule that new feature. Maybe it's urgent and you'll be told to drop what you're doing and work on it, instead. Maybe it's not and it'll go into your queue. Maybe it'll be allocated to someone else (e.g. it's urgent but what you're working on is also urgent so better that you continue). You do not say 'no', you propose ways to make it happen the best you can considering what you've already been asked to work on. If there is no good way then there is a management/project decision to be made (not by you). That perhaps boils down to pretty much what you're saying, but how you communicate it is very important and so is understand where your authority stops.
- onion2k 5y ago
  You do not say 'no', you propose ways to make it happen the best you can considering what you've already been asked to work on. If there is no good way then there is a management/project decision to be made (not by you). This is the exact problem. If developers can't say no then, on occasions where management or product aren't willing to compromise and do insist that a feature is added beyond the team's capacity, then the developers either have to work past healthy hours or they have to resign. That is not a reasonable point of view. Developers should not be in a position where they have to choose between overworking or leaving. Good companies accept and value everyone's input, including the developers, and trust them when they say there's a good reason not to build it. Building good software is a collaboration between everyone on the team. Management and product should not be in a position where they can demand things from developers who have to just accept what they're told. That is very unhealthy and leads directly to people burning out. This is why it's important to be able to say no.
  - mytailorisrich 5y ago
    Accepting and valuing input is one thing but in the end people in management positions make the decisions and people who report to them execute these decisions. These decisions do not always please those who have to execute them but that's how it works. If management makes a decision and you don't like it you have three options: (1) disagree and commit, you don't like it or agree with it but you'll still do it to the best of your ability because that's your job. (2) refuse to do it and most likely be fired. (3) quit. That's life. Good management is to seek input then to make decisions. A dev's job is to provide useful and constructive input (which usually involves trying to find solutions) then to execute the decisions made even if they don't agree with them.
    - brndoutthrw 5y ago
      can you recommend any books, articles or videos to learn from?