software burnout and hardware burnout are different animals and i'm tired of reading advice written entirely for software people.
in software, when you're burned out you can take a leave, recover, and the codebase will more or less be there when you return. in hardware, schedules slip and samples go bad and your absence can invalidate months of other people's work. the stakes of being gone feel different.
also: in software you can reduce scope. in hardware you are often literally the person. there are three people in my company who know this architecture. if i'm not here, nobody is. the bus factor is my anxiety disorder.
some hardware-specific burnout accelerants:
the tape-out treadmill. tape-out, bring up, debug, repeat. each cycle is 6-18 months of crunch. by the third tape-out in 5 years you're running on a kind of numb momentum. not burning bright, just not extinguished yet.
the supply chain chaos hangover. 2021-2023 burned a lot of hardware people out in ways that still haven't been acknowledged. heroic effort, endless pivots, components arriving wrong, customers furious. we solved problems that had no solutions and then came into 2024 expected to do it again as a base expectation.
the visibility problem. hardware work is invisible until it fails. no one celebrates the bring-up that went smoothly. everyone knows about the one that didn't.
how i've dealt with it: hard schedule limits that i actually enforce. no silicon review calls after 7pm local regardless of timezone. two full days off per tape-out before starting the next one. and i've started documenting my architecture obsessively, partly for the team, mostly so i am not irreplaceable. the irreplaceability is a trap.
software people have it easier in a lot of ways. but the burnout culture content isn't written for us and that invisibility is its own small thing.