221–230 of 308 posts
If you were a professional painter and every couple of months, someone snuck into your art studio, threw out all your brushes, paint, canvas, and then dumped a huge load of requests for you to "fix" your old paintings, I'm pretty sure you'd get burned out pretty quick.
FAANGs maintain their code? Impossible.
Earlier quoted context omitted.
I personally really like maintenance programming, but I wonder if I've been lucky. All the systems I've ever inherited, I've been able to make impactful changes to them such that they stopped being that one system that causes everyone production headaches. Even the systems that I couldn't make much changes with directly, I was able to isolate, and route other systems around them, such that new data stopped depending…
You may have been incredibly lucky, or have a secret sauce I don't understand. I've worked a pair of maintenace positions. The previous one was incredibly creaky and had no other systems, so changes were scary and there was no recourse to move to something else. The only I'm working now I'm maintaining client code so I don't have any agency there either. Maybe it's agency? Ultimately I don't feel like my contribution…
There's something deeply satisfying to me in cutting out thousands of lines of code and no-one even noticing.
I will even go back and look at that commit over the next few weeks with a feeling of peace and accomplishment.
I've sometimes 'stolen' time from feature work to do that refactoring, and it's the massive reduction of complexity and TLOC that often gives me satisfaction, not delivering the feature.
Don't get me wrong, I've delivered features and applications I'm proud and happy with too, but I think there's a significant minority of us who really enjoy deleting tons of bad code too.
I wonder if software presents a unique situation as we generally make a pretty decent salary and to transition to a new career involves a pretty significant pay cut. So some developers become trapped in jobs they hate with golden handcuffs. I really don't enjoy software development at all, but at this stage, to even think about doing something else would result in a massive pay cut. I did it once when I was younger,…
Efficiency wages just means that the pay is set higher than what it'd take to clear the market. It means that people who'd otherwise have even better career prospects become programmers instead, people who would otherwise quit to work in a different field or for a competitor don't, and that employees generally see jobs at the current compensation level as something relatively scarce and hard to acquire in unemployment. Employers pay these efficiency wages because getting more out of their programmers is worth the extra expense, but on the flip side it means that they're more able to ask for overtime and otherwise apply stressors to employees.
Lots of places have efficiency wages, and they all tend to be stressful AIUI. Oil workers are notorious for this - massive salaries for dirty, dangerous, and difficult work shifts.
Tournament theory is more about how difficult it is to measure programmer productivity. So, don't even bother; instead get a sense of which programmers are doing better than the others, and make a significant portion of compensation based off "winning" this vaguely stack-rank shaped "tournament". In theory, if employees are risk-agnostic, this is as economically efficient as measuring their output and paying piece rates, but without the overhead of measuring output. In practice, this is yet more incentive for overtime, hard work, extracurriculars, networking, etc. Basically, instead of paying for the direct output of giving your job your all, they pay the best at doing that the most and let people figure out how that should translate.
The stereotypical jobs for tournament theory compensation are corporate executives and professional athletes - how hard an athlete works in the gym and what statistical performance is worth what are hard questions, but "who's the best 10 players in the NBA" is a lot easier to answer.
Anyhow, that's my understanding of the main factors leading to software developers being so well-compensated in the US and why there are so many unhappy and burnt-out developers. Part of the same complex IMO, it's fundamentally a result of programmer productivity being so important to businesses and yet so hard to measure.
The thing I'm curious most about is how pretty much all the example jobs I gave are skewed male. It's not every male-skewed job that fits the bill, but it's still something. I'm not at all sure what, though.
Earlier quoted context omitted.
You always want at least a week of data collection, to control for weekly effects. People are often happier on a Friday than a Monday, for instance.
I'm not sure how much of a difference the day of the week would make for people who are really burnt out.
Earlier quoted context omitted.
We are sampling a Bernoulli distribution for measuring burn out. A software developer could be burnt out/ not burnt out. The variance of a Bernoulli distribution is P(1-P), which is (.83)(.17), since 83% of the respondents answered that they were burnt out.
But why are they "burned out"? Is it because they're a software developer or because they live in an advanced post-industrial civilization in the midst of a global pandemic? Could they feel burned out today but not tomorrow? Has the sun come out in the UK at any time in the last two weeks? Do all the participants even agree on the definition of "burnout"? Were there five other similar studies done that we don't know…
It's not important whether the sun came out in the last two weeks or not, unless we were trying to measure the weather affecting burn out.
It's true different people might have a different interpretation of burn out, but it should be pretty similar to other people. I'm going to assume all people who took the study understand the idea behind burn out.
The point of the poll isn't to answer why but to measure the percentage of burn out with some degree of accuracy. The margin of error in this poll was 4.5%. That's how all yes/no polling works. We don't know that 83% of people are burnt out, but we are reasonably confident that 78% to 88% of people are burnt out.
Are software developers any different from other professions with regards to burnout?
Yes, we have the disposal income to take a few months off work when we want to and can spend that extra time writing blog posts about how hard life is. Everyone else just sucks it up.
This is such a great example of bullshit studies. Yeah I'm gonna go on a limb and say this is a marketing campaign. It's an insult to science to call this a "study". From the pdf: > The fieldwork of this study was carried out at remarkable speed, from the 23rd to 24th of June 2021 Data was collected in 1 day. Is this a joke? No it's not! > The population sampled included Software Engineers aged 18+ living in the Unit…
Your arguments are specious; perhaps you're simply angry that you didn't understand an industry you've worked in for a while? Perhaps you're in management, or in the 20% who aren't burnt out, and you're embarrassed by proxy? Psychological experiments and surveys are often done in only one or two days. Why would a wider window of time help when taking a snapshot of a current situation? Hm, is 258 a small sample size?…
"To reduce self-selection bias, invitations to complete surveys were sent out to members of Survation’s panel and the surveys were then conducted by online interview. This approach is far more rigorous than say, running a poll on a website in which anyone can choose to take part."
Are "members of Survation's panel" a random subset of developers? How many invitations were sent out to get 238 responses (i.e. what was the response rate)? Are developers with burnout more likely to respond to a survey about burnout? Was the sample population demographically similar to the overall population of developers?
It could be genetic. RCCX gene mutations may make people more susceptible to CF/ME and being a software developer. For most people CF/ME will present as burnout.
it's very weird when people take correlation and present it as causation. I feel there are at least few steps in statement that people with that gene mutation are more susceptible to burn out. Like people with that gene mutation "like to be independent", "like variety", and therefore lack of those in regular 9-5 software development leads to burn out. How it is presented as a causation has only one practical applicat…
It’s a proposed causation hence the ‘may’ qualifier. I’m suggesting people should check it out further. They may be surprised.
Also, it has huge implications beyond employment. My particular RCCX mutations yield hEDS which I can now treat. I wish I would have known 20 years ago. That’s one of many treatable genetic disorders that people barely know about.
It would also mean burnout is curable, so instead of not hiring people susceptible to burnout we can instead cure it for everyone.
Earlier quoted context omitted.
Sorry, but what part of "they only surveyed software developers in the United Kingdom" gives you the impression that their sampling might actually be good ? Worth noting that the study itself doesn't seem to mention their sampling methodology.
Studies are never meant to be an ultimate answer to everything. And just because they're not the ultimate answer, doesn't mean that they are therefore worthless, bad or "bullshit".
Earlier quoted context omitted.
> How much of the workload is just the dev shortage/insufficient staffing? ZERO PERCENT. Listen to me very closely. The quantity of people has ZERO IMPACT on your work quality. Well... maybe like 3%, but hear me out. Your manager has a HUGH impact on your work quality. The work that is given to you, your PERCEPTION of the work, the urgency of the work, your development opportunities (and your response to them), the p…
You're talking about quality, but what about quantity? If you need to develop: - the back end for an application - the front end for an application - some external APIs for the application - a structured data storage layer, say, with an RDBMS - an object storage of some sort, for example, on top of S3 - some sort of reporting functionality - mailing list functionality - etc. Then no matter how good your manager is, t…
There is obviously some validity to your point. A 10 person startup could not run a mature company the size of Twitter. But that same 10 person startup will likely not see a double in productivity by hiring another 10 programmers. My experience has shown they will see a mysterious doubling in their miseries, and a many more "strategy meeting" to ameliorate the issues.
I hope that you would agree with me that it is feasible for a skilled programmer to accomplish everything in your list in some expedient amount of time, even though it would clearly go faster if he had a buddy to work with.