7 ms·

How to burnout a software engineer, in 3 easy steps

96 points by damethos 3y ago

mnky9800n 3y ago
I feel like this is the playbook that university administrators go to sleep reading every night.
unsupp0rted 3y ago
Micromanaging, yes. Another one: synchronous meetings and random phone calls. If I have a synchronous meeting at 11am, I get nothing of value done before 11am. If I've loaded an hour of context to search for a hard bug and at 4pm I'm forced to answer a "just 2 minutes" phone call, then I'm done work for the day.
- KindAndFriendly 3y ago
  +1 and even worse: at 10:55am the sync meeting gets postponed to 12:15pm because the organizer is "stuck in some other important meeting"
  - x86x87 3y ago
    At 12:20 the meeting gets cancelled and "we'll sync offline"
- traviscj 3y ago
  I used to feel this was true for me, and to a large degree still do. But lately I’ve been wondering to what extent this is a self-limiting belief, and how much I can train myself to remain productive in the face of interruptions. My life is more complicated now than when my career started, and the interruption causers seem to be multiplying, so I’m seeing it as something I need to learn to deal with if I’m going to be able to stay in the field.
  - coffeebeqn 3y ago
    Since having kids I’m a lot more able to get in the zone for 1-2h at a time since I rarely get a whole day free (also due to a more senior position). I think it’s largely procrastination. But I also try to batch and minimize the meetings the engineers on my team have to take
  - x86x87 3y ago
    I will tell you what. When I joined this field (decades ago) an entry level engineer would (after rampup) do more than whole teams do today. This is not because people were somewhat better back at that point in time. We had trust, respect for people's time and overall everyone was at least directionally pulling in the same direction. Today we have a low trust, hustle and micromanagement culture. I am shocked every time people with experience simply don't help grow a junior engineer (because fuck em and they're gonna find a better job if they grow, amiright?). I am shocked whenever we throw people at a problem while it was shown over and over again the approach does not work for that problem. Shocked when trivial improvements are hailed as the ultimate engineering feat and impressive engineering feats are met with meh. I am shocked when people do not think (at all, zero, nada) about the performance and maintainability of the code they bang out. People just started giving zero fucks. The future is bright.
    - nine_zeros 3y ago
      > Today we have a low trust, hustle and micromanagement culture. I am shocked every time people with experience simply don't help grow a junior engineer (because fuck em and they're gonna find a better job if they grow, amiright?). I am shocked whenever we throw people at a problem while it was shown over and over again the approach does not work for that problem. Shocked when trivial improvements are hailed as the ultimate engineering feat and impressive engineering feats are met with meh. I am shocked when people do not think (at all, zero, nada) about the performance and maintainability of the code they bang out. Do you work at my company?
      - bluefirebrand 3y ago
        This is basically what every company is like nowadays. I think we can thank the MBA-ification of the workplace for that.
- incrudible 3y ago
  > then I'm done work for the day That is a bit of a you-problem though. Pointless interruptions are bad of course, but if you not being responsive blocks other people, that is a problem too. You write that you also have an issue with synchronous meetings, which would be the alternative to get input from you in a plannable way. Doing all communication asynchronously is not acceptable if you are at all involved in team work.
  - x86x87 3y ago
    Jfc. I'm going to slap the next person that claims they're blocked. Blocked means that you've tried solving the problem and that you've tried in multiple ways. Also you can be blocked because production is burning down or "blocked" since you give 0 fucks and have zero incentives to try. If you claim you're blocked and I get a blank stare when I ask you what the problem is, what have you tried and what is your current hypothesis on why thigs are not working I am going to slap you so hars that you'll be back to using RCS for source control.
    - incrudible 3y ago
      You must really be a hot shot to afford this attitude, or you are one of these passive aggressive types that express it in subtle ways that do not get you fired. Let me explain something from the employers perspective. If you expect people to spend hours trying to figure out something that is not obvious, that could reasonably be cleared up with a five minute conversation with the expert (you, presumably) then you are wasting my money. I am paying both of you. I expect you to cooperate. I do not accept a toxic communication environment. Minimizing communication may increase productivity, but massively raises the risk of producing the wrong thing.
      - x86x87 3y ago
        Let me explain something to you: if every time you don't know something you start bitching about it and ask everyone around you until you wear them down to ELI5 you are dragging everyone down. This is not about that one instance where 5 minutes saves you days of struggling. This is about becoming and being self sufficient to the point you are an asset to the business, not your liability. In your convoluted example: how do you know who the expert is?
taurath 3y ago
Create deadlines arbitrarily and without discussion or even a feasibility check Lie to their team about their criticality, before laying off half of the same team Replace large amounts of management 3 times in a single year Hire so many people nobody knows what their role is and everyone competes for influence Ensure that every engineer has at least 5 hours of meetings a day, half of which aren’t relevant to their team. Stack ranking Don’t give them a raise for years despite praising them for being a top performer with large impact Arbitrary KPAs which undervalue anything other than LoC Make people be on call with no training for what theyre being on call for, and have critical alarms go off every 3 hours Host meetings in front of your giant glass wine cellar larger than most your employees apartments. Bonus points if you talk about belt tightening in that meeting Make sure that things never calm down after a giant release, make it the new normal until people start dropping out on medical leave, then install a new engineering leader who loudly states that he thinks the engineering team is lazy Fire or layoff people, give their duties to an already busy engineer, promise that engineer it’s short term but never replace them, give that engineer a middling performance rating for not excelling at their “core” job despite doing the work of 3 previous engineers, deny them a raise, get a promotion and a massive raise as a manager
- junon 3y ago
  Claim you work "like open source", proceed to have six disparate systems I have to log into every day. Have useless stand-ups at the ass crack of dawn "just so everyone sees each others' face, isn't that nice?". Change the priority of eleven different projects every week. Lie about finances and runway, miss paychecks the week after doing so. Ask employees to work extra hard so it doesn't happen again. Favor one employee due to $personal_reason, ignore the other engineers you've hired. Completely isolate customer feedback from people working on product and engineering. Make product decisions without discussing with engineers. Go to fancy talks and banquets on the company dime every month and never be in the office. Blame employees for not "letting you know earlier" when they finally get a chance to tell you something is on fire. ... I could go on.
- belter 3y ago
  Are we colleagues? :-)
rewmie 3y ago
I don't consider well sourced any article that attempts to summarize burnout causes that doesn't mention pressuring workers to work long hours to meet impossible arbitrary goals imposed by leadership, or leadership pressuring teams to perform under veiled and not so veiled threats of dismissal.
coffeebeqn 3y ago
> Burnout happens when my work doesn’t matter. This is over simplifying it. There are dozens of reasons- currently my job is fairly easy and we are shipping to the customers but we are understaffed so I’m supposed to keep track of 20 separate things. When the appropriate amount for this company would be 2-3. I usually quit because I lose hope in the senior leadership.
distortionfield 3y ago
> Working on projects that never ship is, anecdotally, one of the largest causes of burnout. This stings. I’ve spent so much of my software career writing code that management just threw away after months of work because priorities shifted, or money moved, or a C suites mistress didn’t like the name of it. It’s beyond frustrating to design, implement, and actually complete a hard software product that never sees the light of day.
jqpabc123 3y ago
How to burnout a software engineer This is just a specific variation on a theme that applies to all of STEM. The half life of a STEM career in the USA is about 10 years. 10 years after graduation, half those with a STEM degree are no longer doing STEM. Another 10 years and those who remain have decreased by half again. But once you start digging into all this you will slowly come to realize that the core of the problem is bigger still --- it is actually a cultural phenomenon that applies to American business in general. American business culture views those who create products as expenses to be restricted and controlled. In contrast, those who *sell* products are viewed as productive assets to be lavishly praised, nurtured and rewarded. The illogic here is deeply rooted and is fully illustrated by a phrase I heard over and over again down through my career. "No one gets paid until something gets sold" This is objectively true --- but no more logically valid than my counter point: "Nothing gets sold until something gets built" Bottom Line --- American corporate culture has an inherent bias toward those who sell and against those who create. This applies and is reflected across industries, regardless of the actual product being built and sold. And it has been this way for generations. The only workable way I found to change this was to dropout and start my own business.
- ahipple 3y ago
  "Nothing gets sold until something gets built" I suspect I'm not alone in saying this, but having started my "tech" career in marketing/eCommerce agencies, I have _definitely_ worked in organizations where the sales team would sell absolutely anything they could get somebody to agree to buy -- fully ignorant of whether it had been (or even COULD be) built.
  - mrbadguy 3y ago
    Yep, been there. It’s an absolute nightmare.
  - kalupa 3y ago
    oh dear, I thought that was common only in my own marketing-in-tech career! My solution was to move away from the agency and to the agency's vendors, instead. Worked so far, a decade on!
extraduder_ire 3y ago
I really like this format of telling people how to do the thing they don't want. Works way better, and is more memorable than doing the more common thing of telling people how to avoid the thing they don't want. CGP grey did a video like this that's still my favourite example of the format: https://www.youtube.com/watch?v=LO1mTELoj6o https://www.youtube.com/watch?v=LO1mTELoj6o
2OEH8eoCRo0 3y ago
Give them more freedom and remove process? Sounds dangerous. I agree with point 3 though.
justin_oaks 3y ago
> Step 3: Don’t ship code to customers In the same vein: "Shipping useless code". I worked at a company who created a product that everyone (except the bosses) knew was useless. A minimum of a million dollars went into it. Yes it shipped, but very few customers used it. That's seriously damaging to morale. The worst part was that we knew we were working on something useless.
- nvarsj 3y ago
  A similar thing happened to me. It's absolutely bizarre when it's happening and even more so in retrospect. Every engineer knows it's a product that no one wants. That experience triggered terrible burn out for me.
darkhelmet 3y ago
- prioritize process over product My most recent position descended into a farce. The company had been reborn from the ashes of the old company. The product was 15 years old and had accumulated a lot of tech debt during the crash-and-burn of the previous company. There was a huge list of things that must be done, or the company dies. However the new company spent 6+ months designing a top-heavy set of processes. After that, critical tasks from the "must be done" list that should have taken hours turned into a 2-6 week ordeal of following the process, meetings and busy-work. Generally a two week sprint to research, then put it on hold for a planning session, then another 2 weeks sprint to do the task. When it's something that must be done no matter what, and as quickly as possible, then this is sheer lunacy. I'm talking about existential risks to the company. I found out how the other engineers are coping with this. Just about everyone is actively deceiving management in order to get things done. It goes something like this: 1) just do the work during the research/planning sprints. 2) when the work is complete, write up your proposal and estimate time retroactively. 3) the engineers rubber stamp each other's estimates 4) during the time assigned, work on the next task instead, and commit the code at the end, right on time, exactly as predicted. repeat. The company pivoted from producing a product to producing arbitrary process. People's performance was measured on the accuracy of their estimates, so the engineers designed their own process to hit the mark perfectly. Unfortunately it's a good way to burn out.
waynesonfire 3y ago
Another irrelevant list which could arbitrarily contain any other three elements.
ttfkam 3y ago
> Look, Google has a huge writing culture. Design docs are the norm there. I don't know what Google they're talking about, but for non-customer-facing code, Google was atrocious for that when I was there. "Docs? Just read the code," was a VERY common refrain there. Google was absolutely non-negotiable on the necessity of checking in tests with your code, but missing docs was definitely the norm.
proc0 3y ago
I would add "make the boundaries of the role so blurry that nobody really owns anything but also owns everything at the same time".
atoav 3y ago
As someone who worked in quite some no-budget films I think this article has some truth in it. No matter what your project is, whether it is a fun thing with friends or a big corp, the people organizing it always have to keep in mind that everybody is in it for a reason. Abondon these reasons for long enough and people will not give you their full potential. Abandon those reasons longer and they will be gone. And you will be left with those who think they can still extract value from you or those who have problems saying "No" — a organization only consisting of these two types is dysfunctional. As a manager/director/producer you should be aware what the reasons are for your team members and keep track of whether you believe you can honor those reasons. That principle is diluted in most corps because money is involved. As someone who had to keep teams functional where members worked for free I believe it would be wise for more managers to understand how to do this. It is better to say: "Bob, I know you are in it for $reason, but I am afraid we will have to do $Y for the next to months. I promise you I will try to make it better for the time after!" than knowing it will be shit for them and saying nothing in the hope that Bob won't notice. He will. And he will remember.
lofaszvanitt 3y ago
It's mind boggling that people write blogs about trivial things like this... Are these people live on this planet called Earth or something is amiss?

96 points by damethos 3y ago

I feel like this is the playbook that university administrators go to sleep reading every night.

Micromanaging, yes. Another one: synchronous meetings and random phone calls. If I have a synchronous meeting at 11am, I get nothing of value done before 11am. If I've loaded an hour of context to search for a hard bug and at 4pm I'm forced to answer a "just 2 minutes" phone call, then I'm done work for the day.

KindAndFriendly 3y ago
+1 and even worse: at 10:55am the sync meeting gets postponed to 12:15pm because the organizer is "stuck in some other important meeting"
- x86x87 3y ago
  At 12:20 the meeting gets cancelled and "we'll sync offline"
traviscj 3y ago
I used to feel this was true for me, and to a large degree still do. But lately I’ve been wondering to what extent this is a self-limiting belief, and how much I can train myself to remain productive in the face of interruptions. My life is more complicated now than when my career started, and the interruption causers seem to be multiplying, so I’m seeing it as something I need to learn to deal with if I’m going to be able to stay in the field.
- coffeebeqn 3y ago
  Since having kids I’m a lot more able to get in the zone for 1-2h at a time since I rarely get a whole day free (also due to a more senior position). I think it’s largely procrastination. But I also try to batch and minimize the meetings the engineers on my team have to take
- x86x87 3y ago
  I will tell you what. When I joined this field (decades ago) an entry level engineer would (after rampup) do more than whole teams do today. This is not because people were somewhat better back at that point in time. We had trust, respect for people's time and overall everyone was at least directionally pulling in the same direction. Today we have a low trust, hustle and micromanagement culture. I am shocked every time people with experience simply don't help grow a junior engineer (because fuck em and they're gonna find a better job if they grow, amiright?). I am shocked whenever we throw people at a problem while it was shown over and over again the approach does not work for that problem. Shocked when trivial improvements are hailed as the ultimate engineering feat and impressive engineering feats are met with meh. I am shocked when people do not think (at all, zero, nada) about the performance and maintainability of the code they bang out. People just started giving zero fucks. The future is bright.
  - nine_zeros 3y ago
    > Today we have a low trust, hustle and micromanagement culture. I am shocked every time people with experience simply don't help grow a junior engineer (because fuck em and they're gonna find a better job if they grow, amiright?). I am shocked whenever we throw people at a problem while it was shown over and over again the approach does not work for that problem. Shocked when trivial improvements are hailed as the ultimate engineering feat and impressive engineering feats are met with meh. I am shocked when people do not think (at all, zero, nada) about the performance and maintainability of the code they bang out. Do you work at my company?
    - bluefirebrand 3y ago
      This is basically what every company is like nowadays. I think we can thank the MBA-ification of the workplace for that.
incrudible 3y ago
> then I'm done work for the day That is a bit of a you-problem though. Pointless interruptions are bad of course, but if you not being responsive blocks other people, that is a problem too. You write that you also have an issue with synchronous meetings, which would be the alternative to get input from you in a plannable way. Doing all communication asynchronously is not acceptable if you are at all involved in team work.
- x86x87 3y ago
  Jfc. I'm going to slap the next person that claims they're blocked. Blocked means that you've tried solving the problem and that you've tried in multiple ways. Also you can be blocked because production is burning down or "blocked" since you give 0 fucks and have zero incentives to try. If you claim you're blocked and I get a blank stare when I ask you what the problem is, what have you tried and what is your current hypothesis on why thigs are not working I am going to slap you so hars that you'll be back to using RCS for source control.
  - incrudible 3y ago
    You must really be a hot shot to afford this attitude, or you are one of these passive aggressive types that express it in subtle ways that do not get you fired. Let me explain something from the employers perspective. If you expect people to spend hours trying to figure out something that is not obvious, that could reasonably be cleared up with a five minute conversation with the expert (you, presumably) then you are wasting my money. I am paying both of you. I expect you to cooperate. I do not accept a toxic communication environment. Minimizing communication may increase productivity, but massively raises the risk of producing the wrong thing.
    - x86x87 3y ago
      Let me explain something to you: if every time you don't know something you start bitching about it and ask everyone around you until you wear them down to ELI5 you are dragging everyone down. This is not about that one instance where 5 minutes saves you days of struggling. This is about becoming and being self sufficient to the point you are an asset to the business, not your liability. In your convoluted example: how do you know who the expert is?

taurath 3y ago

Create deadlines arbitrarily and without discussion or even a feasibility check Lie to their team about their criticality, before laying off half of the same team Replace large amounts of management 3 times in a single year Hire so many people nobody knows what their role is and everyone competes for influence Ensure that every engineer has at least 5 hours of meetings a day, half of which aren’t relevant to their team. Stack ranking Don’t give them a raise for years despite praising them for being a top performer with large impact Arbitrary KPAs which undervalue anything other than LoC Make people be on call with no training for what theyre being on call for, and have critical alarms go off every 3 hours Host meetings in front of your giant glass wine cellar larger than most your employees apartments. Bonus points if you talk about belt tightening in that meeting Make sure that things never calm down after a giant release, make it the new normal until people start dropping out on medical leave, then install a new engineering leader who loudly states that he thinks the engineering team is lazy Fire or layoff people, give their duties to an already busy engineer, promise that engineer it’s short term but never replace them, give that engineer a middling performance rating for not excelling at their “core” job despite doing the work of 3 previous engineers, deny them a raise, get a promotion and a massive raise as a manager

junon 3y ago
Claim you work "like open source", proceed to have six disparate systems I have to log into every day. Have useless stand-ups at the ass crack of dawn "just so everyone sees each others' face, isn't that nice?". Change the priority of eleven different projects every week. Lie about finances and runway, miss paychecks the week after doing so. Ask employees to work extra hard so it doesn't happen again. Favor one employee due to $personal_reason, ignore the other engineers you've hired. Completely isolate customer feedback from people working on product and engineering. Make product decisions without discussing with engineers. Go to fancy talks and banquets on the company dime every month and never be in the office. Blame employees for not "letting you know earlier" when they finally get a chance to tell you something is on fire. ... I could go on.
belter 3y ago
Are we colleagues? :-)

rewmie 3y ago

I don't consider well sourced any article that attempts to summarize burnout causes that doesn't mention pressuring workers to work long hours to meet impossible arbitrary goals imposed by leadership, or leadership pressuring teams to perform under veiled and not so veiled threats of dismissal.

coffeebeqn 3y ago

> Burnout happens when my work doesn’t matter. This is over simplifying it. There are dozens of reasons- currently my job is fairly easy and we are shipping to the customers but we are understaffed so I’m supposed to keep track of 20 separate things. When the appropriate amount for this company would be 2-3. I usually quit because I lose hope in the senior leadership.

distortionfield 3y ago

> Working on projects that never ship is, anecdotally, one of the largest causes of burnout. This stings. I’ve spent so much of my software career writing code that management just threw away after months of work because priorities shifted, or money moved, or a C suites mistress didn’t like the name of it. It’s beyond frustrating to design, implement, and actually complete a hard software product that never sees the light of day.

jqpabc123 3y ago

How to burnout a software engineer This is just a specific variation on a theme that applies to all of STEM. The half life of a STEM career in the USA is about 10 years. 10 years after graduation, half those with a STEM degree are no longer doing STEM. Another 10 years and those who remain have decreased by half again. But once you start digging into all this you will slowly come to realize that the core of the problem is bigger still --- it is actually a cultural phenomenon that applies to American business in general. American business culture views those who create products as expenses to be restricted and controlled. In contrast, those who *sell* products are viewed as productive assets to be lavishly praised, nurtured and rewarded. The illogic here is deeply rooted and is fully illustrated by a phrase I heard over and over again down through my career. "No one gets paid until something gets sold" This is objectively true --- but no more logically valid than my counter point: "Nothing gets sold until something gets built" Bottom Line --- American corporate culture has an inherent bias toward those who sell and against those who create. This applies and is reflected across industries, regardless of the actual product being built and sold. And it has been this way for generations. The only workable way I found to change this was to dropout and start my own business.

ahipple 3y ago
"Nothing gets sold until something gets built" I suspect I'm not alone in saying this, but having started my "tech" career in marketing/eCommerce agencies, I have _definitely_ worked in organizations where the sales team would sell absolutely anything they could get somebody to agree to buy -- fully ignorant of whether it had been (or even COULD be) built.
- mrbadguy 3y ago
  Yep, been there. It’s an absolute nightmare.
- kalupa 3y ago
  oh dear, I thought that was common only in my own marketing-in-tech career! My solution was to move away from the agency and to the agency's vendors, instead. Worked so far, a decade on!

extraduder_ire 3y ago

I really like this format of telling people how to do the thing they don't want. Works way better, and is more memorable than doing the more common thing of telling people how to avoid the thing they don't want. CGP grey did a video like this that's still my favourite example of the format: https://www.youtube.com/watch?v=LO1mTELoj6o https://www.youtube.com/watch?v=LO1mTELoj6o

2OEH8eoCRo0 3y ago

Give them more freedom and remove process? Sounds dangerous. I agree with point 3 though.

justin_oaks 3y ago

> Step 3: Don’t ship code to customers In the same vein: "Shipping useless code". I worked at a company who created a product that everyone (except the bosses) knew was useless. A minimum of a million dollars went into it. Yes it shipped, but very few customers used it. That's seriously damaging to morale. The worst part was that we knew we were working on something useless.

nvarsj 3y ago
A similar thing happened to me. It's absolutely bizarre when it's happening and even more so in retrospect. Every engineer knows it's a product that no one wants. That experience triggered terrible burn out for me.

darkhelmet 3y ago

- prioritize process over product My most recent position descended into a farce. The company had been reborn from the ashes of the old company. The product was 15 years old and had accumulated a lot of tech debt during the crash-and-burn of the previous company. There was a huge list of things that must be done, or the company dies. However the new company spent 6+ months designing a top-heavy set of processes. After that, critical tasks from the "must be done" list that should have taken hours turned into a 2-6 week ordeal of following the process, meetings and busy-work. Generally a two week sprint to research, then put it on hold for a planning session, then another 2 weeks sprint to do the task. When it's something that must be done no matter what, and as quickly as possible, then this is sheer lunacy. I'm talking about existential risks to the company. I found out how the other engineers are coping with this. Just about everyone is actively deceiving management in order to get things done. It goes something like this: 1) just do the work during the research/planning sprints. 2) when the work is complete, write up your proposal and estimate time retroactively. 3) the engineers rubber stamp each other's estimates 4) during the time assigned, work on the next task instead, and commit the code at the end, right on time, exactly as predicted. repeat. The company pivoted from producing a product to producing arbitrary process. People's performance was measured on the accuracy of their estimates, so the engineers designed their own process to hit the mark perfectly. Unfortunately it's a good way to burn out.

waynesonfire 3y ago

Another irrelevant list which could arbitrarily contain any other three elements.

ttfkam 3y ago

> Look, Google has a huge writing culture. Design docs are the norm there. I don't know what Google they're talking about, but for non-customer-facing code, Google was atrocious for that when I was there. "Docs? Just read the code," was a VERY common refrain there. Google was absolutely non-negotiable on the necessity of checking in tests with your code, but missing docs was definitely the norm.

proc0 3y ago

I would add "make the boundaries of the role so blurry that nobody really owns anything but also owns everything at the same time".

atoav 3y ago

As someone who worked in quite some no-budget films I think this article has some truth in it. No matter what your project is, whether it is a fun thing with friends or a big corp, the people organizing it always have to keep in mind that everybody is in it for a reason. Abondon these reasons for long enough and people will not give you their full potential. Abandon those reasons longer and they will be gone. And you will be left with those who think they can still extract value from you or those who have problems saying "No" — a organization only consisting of these two types is dysfunctional. As a manager/director/producer you should be aware what the reasons are for your team members and keep track of whether you believe you can honor those reasons. That principle is diluted in most corps because money is involved. As someone who had to keep teams functional where members worked for free I believe it would be wise for more managers to understand how to do this. It is better to say: "Bob, I know you are in it for $reason, but I am afraid we will have to do $Y for the next to months. I promise you I will try to make it better for the time after!" than knowing it will be shit for them and saying nothing in the hope that Bob won't notice. He will. And he will remember.

lofaszvanitt 3y ago

It's mind boggling that people write blogs about trivial things like this... Are these people live on this planet called Earth or something is amiss?