|
|
|
|
|
|
by dnautics
1762 days ago
|
|
|
For me, I realized though that you do have control. The solution is counterintuitive, though. If I am at risk of burnout I slow down a bit, but I don't outright quit. I also queue up labor that will derive small tangible, almost guaranteed wins. Although programmers seem to burn out a lot (probably because there are almost no limits to how much effort you can put in... There's always more code to be pushed, after all), programmers uniquely have the tools to reschedule small tasks (e.g. refactoring, writing those tests you've put off) that can create small emotional "success hits", sometimes even with primary stimuli (green passing tests dots). These can serve to reassociate effort with reward. Conversely, taking a vacation immediately after burning out is likely the worst thing you can do, because it associates not-effort with reward. Typically I like to drop in a timing-non-negotiable vacation far enough in the future to dissociate from the burnout, e.g. 2mo. Anyways, it's been many years since I have had a full-on burnout. (I have had project burnouts though, where I refuse to continue working on a given thing and pivot to something else with a more favorable seeming reward schedule). |
|
|
When management gives opaque or “unjust” performance reviews, it can almost directly trigger burnout in tech. Similarly if the process is not perceived as transparent engineers can simply feel like they are hitting a brick wall.
Given the high turnover rate in tech I’ve sometimes wondered if it’s even worth having a performance management process. Unless someone has straight up stopped working for a prolonged period, it’s unlikely that they will stay with the company long anyway.