2080 assumes you get no sick leave and no annual leave. In Australia we're on 37.5 hours/week, 4 week annual leave and two weeks sick leave, plus ~10 public holidays. So about 1660 hours worked per year, assuming you use all your sick leave = 365.25*5/7*7.5-(8x37.5). The other answers seem to assume you're in the USA, but I suspect Canada is closer to Australia in terms of sick and annual leave.

Especially today with rented software, the licensing can be extortionate unless you're on a FAANG salary. $1000/mo isn't out of the question for someone using standard commercial packages, and if they're using SAS or something their salary could be similar to the software cost (the lowest price is ~$9000/year). I'm not donating even $5000/year to my employer (I've worked using software that cost that). Remember: a job is where they pay me, a hobby is where I pay them.

@Erik good point. The one time I gave useful exit interview info was when the boss opened with "I'm not entirely happy with {your area} and am thinking of a major change. Do you have any thoughts". And yes, I did have thoughts :)

@iheanyi IMO it's entirely plausible that the team member is defeated by the build "process", since that seems to be "load the project into a random IDE and hope for the best". Take away that problem and there might be no problem.

an automated build environment is work quite a lot of pain to set up, if it takes pain to do so. In this specific case it would have meant you had a know-good build to push to the app store... (for context, I'm part of a team of three in a bigger company and we have CI set up for C++/linux server software, android, iphone and web. It was significant work to set up but it paid for itself in less than 6 months)

I think it's reasonable to struggle a bit trying to articulate why vim/ linux/ cmake are useful tools when confronted by "our official build process is to fire up an IDE on a random Windows box and hope for the best". At least I think so, because I've gone through that with someone who just couldn't/wouldn't understand why "every time I build this program behaves differently even if there are no code changes" could possibly be an issue.

I would add the caveat that having more than one person able to do any given task is also bedrock once the company has more than one employee. So someone else needs to work with this person in order that two people can maintain the build system.

@Acccumulation : if windows is spyware and the company doesn't have a solution, there are far worse problems than the SSN of a single employee. No company big enough to have 8 employees is paying in physical cash, for example, so spyware could lift the company banking access details...

I disagree: going to management is one option, but while that is happening they can also start modernising their devlopment provess per Chris Strattan's answer. They should be doing that anyway, and it may well be that the "difficult" guy would be happy to do that job.

Worth considering how you would know whether a response was sent that you were not CC'd on. That raises two questions: how could you know that had happened; and whether there should be a process where it doesn't.

Jante seems like serf law "You're not to think you are as good as we are".

"an occasional paid day off is kind of a perk of being salaried" is the universally applicable part of the answer. I've worked in Australia and Aotearoa with this perk. Also worked for employers who rely on salaried people not being paid overtime but refused this kind of request... then wondered why people stopped being available after hours. That's a fatberg and a half.

You could be the other sort of "full stack developer" - one who understands how the hardware actually works. I find that some of the problems and techniques from hardware design are very relevant to software (embedded and strongly multi-threaded software, at least)