I've worked in a few different capacities and have seen this happen, and seen previously excellent developers decide they simply couldn't take the pressure and head out for something easier. I can respect the latter and provided your interest isn't in attempting to "get away with pretending to work[0]", desiring a less demanding role somewhere else isn't something worthy of "flak".
Onto advice: I had a friend who worked at a shop that did high-end bespoke software centered around compliance management automation/assistance software for complex manufacturing operations. The company didn't have a product, but wrote a ton of software tying various things together, along with a 25% solution that they'd customize out for each customer. This guy wasn't the original author, but had become the SME for nearly the entire solution over about 8 years. He was a bit older than me; I think 45 at the time, had an unexpected fourth child, and effectively started looking like a train was hitting him every day.
I was working for a large telecom, at the time. I was not on their development team but was a full time developer[1]. Backend-only dev definitely exists depending on the languages you're writing in (though you'll probably have to write a line or two of JavaScript from time to time). Sysadmin work definitely exists at large companies; I know we had a large team (referred to as "Infrastructure") in various capacities (nix was broken into a few teams, CDN was its own group). I had worked with two of the Unix teams at various times -- by God, you'd be amazed* at how many things are done a command at a time. No scripts. I assumed it was some policy/fear/craziness. Nope, the manager of the team was a good friend so I asked him: entirely skillset.
There isn't enough background about your current job, so I'm not sure how close my recommendations will be to what you are already doing, however, I'd strongly recommend looking into the largest companies in semi- or non-tech sectors. Check they're IT ops/dev organization; note whether they're using a third-party[2]. If you want that "back-end only job", look no further. Our 7 or 8 most important systems served only massive global multi-nationals[3].
You'd be surprised how many organizations have large DBA teams. I'm not knocking DBA work; I've worked with great DBAs, but at a past job, all but one of the 6 member team did much more than run a commercial profiling tool, and add indexes from time to time. Bear in mind that every infrastructure job at the company I worked at had an on-call requirement which involved being willing to be awoken at any hour of the night for a week to remote-in for emergencies. It's pretty common to have an on-call requirement.
But let me tell you how I hope it turns out. My buddy took my advice and ended up getting an "Easy Corporate Job" -- in office, but with a promise of 3-days remote in 6 weeks. I remember him telling me that the job was so boring he finished all of his "daily to-dos" for the week in the first couple of hours on Monday, scripted half of them out his life and had the other down to a set of commands he could run to reduce the time required to complete.
He said "Duuuuude, this job is so easy. I work as hard in a week in this job as I did in a day in my last and my boss has never seen someone work so hard!" His burnout ended in a couple of weeks. His boss let him work from home "anytime he wants" at week 3. He never returned to working "his ass off" like he did at the last job, and he has been in the same position for years. He's made new friends on the team, who respect him for his abilities and his boss loves him -- I think partly because he's not using the team to step-stone into a better role. There really is a place for people who are OK staying where they are. That's not me, but I count several among my friends and I have enjoyed working with many who "handle their piece of the puzzle with expected results -- no more, no less"
It's been a decade, but I used to interview developers at big-corp. We used get the bottom of the barrel of the resumes. Nobody wanted to work for BigCorp "process-driven-agile-buzzword development shop". The thing of it is, I observed that the development shop[1] basically did everything that I've done at every dev shop I've worked at, since. But the "reason" they do the things (stand-up/retrospective/back-log and on and on) but instead of being used in support of Agile's goals, they're basically used as a kludge to reduce the amount of change that applications experience. Guess what that means for a large dev shop? They're all pretty bored.
I was under infrastructure in my role at at BigCorp (various levels, including under the CIO at once; it's not as cool as it sounds but it's fun to say). I saw how little was expected of those employees and steadfastly refused all attempts to move me there. I eventually left the company because I wanted to work on things that were more difficult/interesting and 90% of my co-workers "just showed up every day". And BigCorp will let you work remotely, even pre-pandemic, but it can be tricky and pulled out from under you from higher up, so the risk of a "Yahoo!" happening is pretty easy.
[0] Too often I've been on the receiving end of this individual, and because "at the end of the day the job has to get done", if your job is to pretend your job is important and pretend you're working hard, history has shown that I'll get the work, and you'll get in my way.
[1] There's a comment in my history explaining -- probably several -- but I was part of a small team developing software for internal infrastructure with full autonomy with regard to the technologies/choices I made, but had to write what was needed in the priority the company wanted it. I wanted nothing to do with the development shop for reasons that will become apparent.
[2] This isn't necessarily a bad thing; might even be good depending on how the arrangement is. I know of one support person at a large company who works through, I think, HP (maybe IBM?) supporting servers at a few datacenters. He's technically required to be at the DC in a few very limited circumstances (one of which is not "first-time setup", they're installed by another group), but he was working remotely well before the pandemic.
[3] Meaning, basically no e-commerce. You're managing an important ticketing system/status reporting service and a million custom internal apps for managing the business that were written a decade ago and Walter retired last year. We had a two-node web site running a Sybase back-end for our most important apps most of the time I was there.
> excellent developers decide they simply couldn't take the pressure and head out for something easier
Been working since late 90's with a 1.5 year break for grad school, but going through some extreme burnout right now and I totally want to do this. Don't want to try to "get away with pretending to work" at all, just want something easier with less pressure/stress.
> Check they're IT ops/dev organization; note whether they're using a third-party[2]. If you want that "back-end only job", look no further.
Can you name some specific companies to look at for this?
> My buddy took my advice and ended up getting an "Easy Corporate Job"
Which route did he go, the DBA team or the third-party IT org?
> Can you name some specific companies to look at for this?
Not any specific companies, no. I helped my friend do the job search, though. The criteria we used was "The role he was willing to take had to be in-house or majority in-house" and "Probably a support role". I also realize I wrote that wall of text way too fast because I've slightly mixed in two different peoples' stories by accident[0] one of which had nothing to do with burnout.
To figure out the first, we started at job boards and just "went through the list looking for big companies". Often, if they outsource, the job posting will be from that company, not BigCorp, but not always. From there, at the time, it was pretty easy to confirm by just hopping on LinkedIn and looking up people who worked in similar roles at the company. If you can find a few folks listing their employer as BigCorp, in your role, and the other things match -- he applied.
He was targeting power/telecom mostly[1]. And he ended up getting offers for all but one or two of the interviews he took, which confirmed my thinking that "big companies get terrible candidates". On paper (and in real life, for that matter), my buddy was an excellent candidate and incredibly smart... just burned out. The thing of it is, last I talked to him, he is still puts in more than 40 hours (remotely, though), and he was still the team hero.
> Which route did he go, the DBA team or third-party IT org?
I haven't talked to him in about a year, but he ended up taking a gig on a sort-of DBA team (sort-of in that their responsibilities covered on-prem hardware and some DevOps work, and the job listing barely mentioned DBA work ... and it was posted as a Unix Sysadmin job[2]). He's working remotely directly for the company in that role and another who took a job at a third-party IT org (HP Enterprise or something like that), remotely (with on-prem requirements on rare occasion, etc). I know the third-party gentleman ran into some problems and, I think, is working somewhere else (similar role), now though.
[0] I do this on purpose, on occasion, because 15-or-so years ago I commented on something including an innocent story on Digg (first iteration), which turned out that I didn't have all of the information on -- and it was far less innocent than I realized -- which someone pseudonomously provided. The result was a bit of embarrassment but not much more. I took it as a warning to be more careful with stories that aren't mine.
[1] For no other reason than "I worked at a global multi-national telecom, which was a 'sort-of' tech company and we in-housed most of our IT".
[2] Just. Yeah. ... Huh?! Big corporations and job postings in IT are a whole other topic.
Onto advice: I had a friend who worked at a shop that did high-end bespoke software centered around compliance management automation/assistance software for complex manufacturing operations. The company didn't have a product, but wrote a ton of software tying various things together, along with a 25% solution that they'd customize out for each customer. This guy wasn't the original author, but had become the SME for nearly the entire solution over about 8 years. He was a bit older than me; I think 45 at the time, had an unexpected fourth child, and effectively started looking like a train was hitting him every day.
I was working for a large telecom, at the time. I was not on their development team but was a full time developer[1]. Backend-only dev definitely exists depending on the languages you're writing in (though you'll probably have to write a line or two of JavaScript from time to time). Sysadmin work definitely exists at large companies; I know we had a large team (referred to as "Infrastructure") in various capacities (nix was broken into a few teams, CDN was its own group). I had worked with two of the Unix teams at various times -- by God, you'd be amazed* at how many things are done a command at a time. No scripts. I assumed it was some policy/fear/craziness. Nope, the manager of the team was a good friend so I asked him: entirely skillset.
There isn't enough background about your current job, so I'm not sure how close my recommendations will be to what you are already doing, however, I'd strongly recommend looking into the largest companies in semi- or non-tech sectors. Check they're IT ops/dev organization; note whether they're using a third-party[2]. If you want that "back-end only job", look no further. Our 7 or 8 most important systems served only massive global multi-nationals[3].
You'd be surprised how many organizations have large DBA teams. I'm not knocking DBA work; I've worked with great DBAs, but at a past job, all but one of the 6 member team did much more than run a commercial profiling tool, and add indexes from time to time. Bear in mind that every infrastructure job at the company I worked at had an on-call requirement which involved being willing to be awoken at any hour of the night for a week to remote-in for emergencies. It's pretty common to have an on-call requirement.
But let me tell you how I hope it turns out. My buddy took my advice and ended up getting an "Easy Corporate Job" -- in office, but with a promise of 3-days remote in 6 weeks. I remember him telling me that the job was so boring he finished all of his "daily to-dos" for the week in the first couple of hours on Monday, scripted half of them out his life and had the other down to a set of commands he could run to reduce the time required to complete.
He said "Duuuuude, this job is so easy. I work as hard in a week in this job as I did in a day in my last and my boss has never seen someone work so hard!" His burnout ended in a couple of weeks. His boss let him work from home "anytime he wants" at week 3. He never returned to working "his ass off" like he did at the last job, and he has been in the same position for years. He's made new friends on the team, who respect him for his abilities and his boss loves him -- I think partly because he's not using the team to step-stone into a better role. There really is a place for people who are OK staying where they are. That's not me, but I count several among my friends and I have enjoyed working with many who "handle their piece of the puzzle with expected results -- no more, no less"
It's been a decade, but I used to interview developers at big-corp. We used get the bottom of the barrel of the resumes. Nobody wanted to work for BigCorp "process-driven-agile-buzzword development shop". The thing of it is, I observed that the development shop[1] basically did everything that I've done at every dev shop I've worked at, since. But the "reason" they do the things (stand-up/retrospective/back-log and on and on) but instead of being used in support of Agile's goals, they're basically used as a kludge to reduce the amount of change that applications experience. Guess what that means for a large dev shop? They're all pretty bored.
I was under infrastructure in my role at at BigCorp (various levels, including under the CIO at once; it's not as cool as it sounds but it's fun to say). I saw how little was expected of those employees and steadfastly refused all attempts to move me there. I eventually left the company because I wanted to work on things that were more difficult/interesting and 90% of my co-workers "just showed up every day". And BigCorp will let you work remotely, even pre-pandemic, but it can be tricky and pulled out from under you from higher up, so the risk of a "Yahoo!" happening is pretty easy.
[0] Too often I've been on the receiving end of this individual, and because "at the end of the day the job has to get done", if your job is to pretend your job is important and pretend you're working hard, history has shown that I'll get the work, and you'll get in my way.
[1] There's a comment in my history explaining -- probably several -- but I was part of a small team developing software for internal infrastructure with full autonomy with regard to the technologies/choices I made, but had to write what was needed in the priority the company wanted it. I wanted nothing to do with the development shop for reasons that will become apparent.
[2] This isn't necessarily a bad thing; might even be good depending on how the arrangement is. I know of one support person at a large company who works through, I think, HP (maybe IBM?) supporting servers at a few datacenters. He's technically required to be at the DC in a few very limited circumstances (one of which is not "first-time setup", they're installed by another group), but he was working remotely well before the pandemic.
[3] Meaning, basically no e-commerce. You're managing an important ticketing system/status reporting service and a million custom internal apps for managing the business that were written a decade ago and Walter retired last year. We had a two-node web site running a Sybase back-end for our most important apps most of the time I was there.