On the Unhappiness of Software Developers (2017)
arxiv.org
arxiv.org
Freq Cause
186 Being stuck in problem solving
152 Time pressure
107 Bad code quality and coding practice
71 Under-performing colleague
63 Feel inadequate with work
60 Mundane or repetitive task
57 Unexplained broken code
42 Bad decision making
40 Imposed limitation on development
39 Personal issuesThe 3 key ingredients to motivation are: autonomy, mastery, and purpose.
Nearly every time I've been unhappy writing software it has been because of a deprivation of autonomy, mastery, or purpose.
I've been ordered (deprivation of autonomy) to work on things I didn't think mattered (deprivation of purpose) with a language I wasn't familiar with in a context I wasn't familiar with, in a way I thought was wrong (deprivation of mastery and autonomy) for political rather than technical reasons (deprivation of purpose). I have never been unhappier and less motivated than that.
There exists negative motivation. If you have $50k in credit card debt, you are very motivated to pay off that debt, but you are neither happy to have the debt nor happy to pay. You just plan to be more happy when it's over.
This kind of motivation can also be present on the workplace, along with positive motivation (when you are happy about something and want more of it).
Robert Sapolsky (Stanford Professor) has said:
> If I had to define a major depression in a single sentence, I would describe it as a "genetic/neurochemical disorder requiring a strong environmental trigger whose characteristic manifestation is an inability to appreciate sunsets."
I think engineers are hyper competent can do individuals with deep belief in possibility & potential. Few organizations can match & support this vanguard fleet well/at all. A corporate entity can very rarely accept & permit itself to support something far beyond it's grasp. It has to be willing to negotiate & work with people who know more & have more insight than it can. Almost no corporation can find that humility. They cant accept their own limitations/ignorance & trust/enable.
There's some org blame possible in this list. But all masked/hiddenz said in typical corpspeak to protect the guilty non-technical cant-knows.
Am I the only one who loves this? My main complaint about my day-job has typically been that the problems are too boring and easy.
that’s the difference of devs that stay motivated and happy
even ones that don’t have pressing monetary concerns are just skittish sometimes. those folks can productive but boy do they look miserable.
kill the fear and the stuck problems become less of a thing
This has never happened for me the closest I have gotten is that I have to give the client to option of sticking to our initial plan or change it for the expense of more time and money.
I wouldn't really call that being stuck with a problem tho, its more the client is stuck with a decision they don't want to make.
It's a little unfortunate the paper doesn't go deeper into this beyond a few lines:
>As one respondent commented: “I feel negative when I get really stuck on something and cannot get around it”. Another respondent elaborated: “I also thought of situations where I’m debugging some issue with the code and I can’t figure out why it isn’t working – when it seems like everything should work, but it just doesn’t. This is definitely one of the biggest gumption traps I encounter”.
To me, the most annoying part isn't just getting stuck, but getting stuck in conjunction with the (lack of) complexity of the issue in theory, and the time pressure (#2 on the list). A lot of problems just shouldn't take as long as they do, but communicating with frameworks, other people's code, poor assumptions (#3?), weird requirements definitely make problems a lot more difficult.
The majority of the work is just trivial plumbing in theory. It's not some complex algorithm. Yet the complex algorithms are often documented far better, you're given more time, and at least personally, it's a whole lot more interesting to work with than fighting a Frankenstein application just to do something extremely minor like conditionally changing font colors.
Often times most of the issues from the list are all caused by incompetent management:
- Time pressure - management f/u deadlines
- bad coding and quality - management hired coding monkeys
- under-performing colleague - why not fired already ? Management
- Feel inadequate with work - picking wrong ppl to do the job
- mundane and repetitive tasks - management gives no time on automation
- unexplained broken code - same as bad quality
- imposed (often artifical) limitations on the devs - who makes those decisions?
—-
More than half of this list is cause by incompetent management / bad decision making.
—-
Personal advice for ppl suffering due to those issues - find a better boss.
* Managers create all the problems,
* Problems not created by managers are created by my team members,
* Everyone around me is incompetent except myself,
* The problems I create have everyone else to blame but myself, because I'm flawless and I was just put in a bad situation.
* goto start.
I've been in a fair share of time-constrained problems, but honestly deadlines tended to slip because of a mix of emergent technical requirements that dev teams didn't managed to see beforehand, and scoping tasks that severely undershoot the requirements. Scoping and planning is hard, specially with limited info, and you can't reasonably allocate 10x the resources to your project just to have a decent slack in the critical path.
Also, bad code can and often is subjective,and I've seen competent and above-grade engineers underperform because of task- and life-specific issues.
It's high time that developers cease the "everyone around me is incompetent and responsible for al problems" mindset.
Also, we are for some reason blessed with management with not much soft skills. Stuff like new manager coming in and insulting people right and left on the first day with no reason just because they are insecure or arrogant is frequent too.
There are good manager, I worked with some. But bad management is frequent and there is very little accountability for managers, so they get stuck for years and decades.
Make things more open-ended so you can change things later? Too risky, too time-consuming. All frameworks, methods, etc. used become increasingly more closed off, and fixing them after the fact is an afterthought. 2 years later something that should take 2 hours now takes a week, but who cares.
Hiring weaker individuals when your codebase has no obvious flows? Clear signs of executives, HR managers etc. pinching pennies. Don't set people up for failure, and use stronger individuals to create environments where weaker individuals are set up for success instead. This is leadership and teaching 101.
No slack in the team? No time to work through codebase problems. Most of all, assumptions that there will be no slack cause the team to become so skeptical, they won't even mention long term issues. It creates the very mindset they claim to dislike: one where mercenaries shine, getting a quick buck and not caring about the feelings of those coming after them.
The only thing I don't agree with, is not matching individuals. There just isn't enough interesting work for the entire software developer crowd to go into. CRUD-plumbing webdev rules the world, it is extremely unimaginative but it pays well. Ironically, having the entire industry take a breather and look at the problem from a higher level might be the thing to make it more interesting and less painful, but I doubt there will ever be enough jobs in the more complex, visual, animated and/or hacky fields anytime soon to accommodate all the developers now stuck trudging in the stereotypical CRUD webdev shop.
I say this knowing someone from a different, non-management discipline will run into the same issues while working in a software team. UX, UI, graphics artists, testers, etc. all suffer similarly from management incompetence.
They are, but the first line of defense is often broken due to problems that are controlled, if not outright created, by developers.
I mean, isn't feedback from developers the main source of info available to a manager? What if that info becomes highly unreliable due to natural occurrences like emergent requirements? What happens to a schedule when midway through the project someone realizes there's something fundamentally broken with the architecture put together by the developers and suddenly you need a major rewrite to be able to meet your requirements?
Don't confuse accountability with responsibility. Managers are held accountable, but developers can and often are responsible for misdirections and blockers and the need to rework.
Trying to pretend that the role of a manager is a Dickensian figure whose purpose in life is to rain misery on developers, who are perfect and flawless, is not a honest starting point for a discussion on unhappiness of software developers.
Then why is that feedback routinely thwarted or ignored in so many places? You make it seem like developers aren't giving feedback. Most places I worked at, at least 1-2 developers in a team of 7-8 were passionate enough initially to provide feedback. Then their feedback gets shot down repeatedly for no other reason than "low priority". What do you think happens to people who have to make a conscious effort to document such issues, articulate them and provide potential solutions? They figure "you know what, this isn't worth the effort, it won't get picked up". That's valuable time they could spend coping with their frustrations instead of hopelessly tackling them head-on.
Managers are held responsible because when we speak of managers, we're not just talking about middle managers. We're talking about all managers, including the executives. If those executives prioritize short term sales over long term company health, don't be surprised when your ICs follow your example. If you're a leader, set the example you expect others to follow.
>What if
"What ifs" are primarily exceptions. How about we tackle the vast majority of cases where short term financial gains are prioritized over long term company health? That's where the feedback matters most for passionate ICs, and that's where feedback is waved away the most.
>Trying to pretend that the role of a manager is a Dickensian figure whose purpose in life is to rain misery on developers
You're the one claiming this. Don't take us all as not understanding the point of view of executives. Understanding doesn't mean agreement, nor does it mean the chickens won't come home to roost someday. If you consciously decide it is worth making your codebase a complete mess for short term gains, don't cry when in 5 years, all that's left is a bunch of jaded developers only in it for the money wondering why it takes them ten times as long to fix something trivial.
In my 15 year career I’ve never seen line manager being let go for poor performance. I’ve seen a good number of underperforming devs getting canned and some higher-ups (usually for political reasons or just phoning in completely) but never line managers.
Of course it is, that's well-known.
But for 20 years of career 99% of all managers I ever worked with outright ignore the feedback.
Most people should not be in positions of power -- ever. It quickly turns into an ego trip where inconvenient facts are ignored and hand-waved away. And always letting somebody else deal with the fallout of your incompetence.
Programmers are not stupid. With your feedback routinely ignored you learn to keep quiet -- why expend energy on something futile? Or you change jobs.
Take a wild guess which of both happens 90% of the time.
I deliberately stayed at that level, even though I could have easily bubbled up higher.
I felt that I could make a big difference to my team, and, by running a good team, make a big difference to my company.
There were a lot of problems in the corporation; bad decisions, HR issues, administratium poisoning[0], etc., but the consensus seems to have been that my little team was really quite effective, and I kept engineers for decades.
Managers can make a big difference for the positive.
[0] https://www.mit.edu/people/dmredish/wwwMLRF/links/Humor/Admi...
Do you tell a painter to get it done by Monday?
That's why small iterations are there in the first place: to constantly add incremental value, not "big bang" plan-the-work and work-the-plan but reacting to change.
Sure, an artist can have leeway for their creative efforts. But allowing artists to work on a muse-driven timeline is also why the stereotype of a "starving artist" exists.
Engineers on the other hand have some product with at least a baseline of utilitarian value. Those generally need timelines because somebody is planning on a delivery of that utility.
But I think both those are besides the point. You can have a structured process that also integrates creativity. I think treating them as mutually exclusive is a false dichotomy.
I reckon there’s some selection bias here too, people who perceive themselves to be incompetent probably talk about it less.
The issue here is not what's the true skill level of anyone in the team. The problem is this recurrent theme of software developers demeaning everyone around them while portraying themselves as flawless saviours.
A key trait of software development is JIT onboarding and continuous development. If you develop your skills and today you're a better developer than you were yesterday, that means that yesterday you were a worse developer and quite possibly quite bad by your measuring stick from some point in the future.
Thus if JIT onboarding and continuous personal development is a basic aspect of software development jobs, why is not being ab absolute expert on everything the target of so much criticism and abuse?
I often look to the work I've done in the past and often times I come across less optimal choices that today I wouldn't make. I'm sure the only ones who don't experience the same are thise who learn nothing from anything. Therefore, why use that as a target for abuse?
This is a horrible trait and a recipe for painting oneself into corners unless you are only working on trivial stuff that's been done before.
Most of us are decent enough at our jobs, and generally the industry does a good job of weeding out those who can't perform or they end up lost and irrelevant in some big company. There are certainly some bad developers out there, but there's bad doctors, bad lawyers, etc. in the real world too.
That said, the impact a bad manager can have is definitely of a greater magnitude than a bad engineer, generally speaking.
People are generally good and want to do a good job and be recognized by their peers.
Different people have different strengths and skills. It’s the sum of those things that makes a team. Alone we could do some of the things we want to achieve but it’s together that we can make it happen.
In particular I’ve seen situations where every single person is working hard doing their job in a defensible way, but the code base is heading towards a cliff because no one has the incentive and/or skill set to point out that the short term decisions made on either side of the engineering /product divide are steadily inching us towards a state where the code base will be too complex to add a feature or fix a bug without creating more bugs.
Ultimately this type of problem has to be owned by management with support all the way up the chain in order to be solved. That doesn’t mean ICs and PMs don’t have a role in the solution, but this is why engineering management is hard and requires technical depth.
Tearing down a straw man is not an impressive feat.
The inconvenient truth is that a lot of programmers are just not that good. They lack the self-awareness, insight and experience to look into the near future and realize they're contributing to the problem.
I was there too. Facepalmed really hard after I realized it years down the line.
Neither is being cynical.
Everyone is at a different point in their life and has different skills and has the potential to do good work.
I don't know what problem you're referring to. Maybe you could enlighten us and tell us what it is about self awareness, insight, and experience and gazing into crystal balls that make developers, "good."
You seem to attribute spaghetti code to a personal failure to have characteristics you think are essential. How’s anyone supposed to live up to that?
I have a different theory. I think that it’s a combination of things which cause spaghetti code. I agree with others here that poor management is a strong factor. Also poor communication, time pressures, vague specifications, insufficient proof or testing, a lack of documentation, family emergencies, lack of motivation, general anxiety, social dysfunctions on the team, and so on.
Everyone I’ve worked with usually had something going on for them. Even if they were just starting out or changing careers or had been at it a while but felt like they weren’t getting anywhere.
The bad developers, to me, were the ones who brought others down when they could have raised them up.
Can we live up to that? Absolutely, but it takes time, practice and a lot of screwing it up -- so, sadly, it can't happen with people who are still kind of fresh. Sad fact but what can you do. I made my peace with it, begrudgingly.
Its not “on purpose” by those devs, but its hard to argue it was a sane decision by management.
To spend the time and effort to write robust, maintainable software would slow them down and give away their niche to a competitor. So it makes sense to hire decent people and toss code at the wall until they find that niche.
Other businesses in industries like security or real-time systems prioritize and value different things. There's usually more of a focus on performance and reliability. That means longer development timelines but the cost of failures is much higher.
If the technical debt is big enough it can cripple the growth of the company to the point a competitor that initially was behind -> gets ahead.
I can give one example in map making industry - TomTom vs Here in EU.
I completely agree with you. Thing is - not everyone can do that.
Thats why top companies hire best talent and not anyone who applied.
Thats why there is a canyon size difference in compensation between one “expert” engineer and another EXPERT engineer.
It sounds like elitism, thats just how it is.
Why not? If you don't have an accurate understanding of the problem you NEED to allocate extra time to gain that understanding or redevelop as the requirements emerge.
> emergent technical requirements that dev teams didn't managed to see beforehand
What? So developers that see poor breifs and ask for more time to manage that lack of information can't be given that time but then its the developers problem for not asking for more time to manage that?
Your developers don't have a crystal ball!
It's high time that Management stop blaming developers for the things managers control.
Are managers at fault for all problems? Intuitively I would very much doubt that’s true of any project anywhere.
Are managers responsible for all problems? It depends on the environment and level of autonomy but.. kinda, yeah. The first rule of leadership is that everything is your fault.
You kind of have to pick which one you want to define “to blame” as here, but I’m tempted to stick with the latter, if only because I don’t know of a lot of managers that had guns put to their head to take the job, and my own experience tells me that the pay disparity usually covers it.
At least try to be honest with yourself, plz.
Thanks for this.
If you are in a personal relationship that works, you will know that any successful team boils down to the interaction between the members of that relationship.
To blame one party, is immature IMO, even if objectively there might be some truth to it.
In any team situation there will be humans involved who have shortcomings - even the top all-rounders have them.
The ways that other team members can react to those shortcomings are multifold. There are ways of reacting that bring out the strength of the other members and hence create a stronger team overall.
It requires a common understanding of- and focus on- the common goal. If a team member furthers his own goals only, they are the problem and not the possibly imperfect manager, for example.
Thankfully, nobody could constrain me in my open source work. I (with the help of community members) built:
- SocketCluster (https://socketcluster.io/): A distributed pub/sub framework.
- Capitalisk (https://capitalisk.com/): A lightweight quantum-resistant blockchain which is less than 5K lines of code.
- LDEX (https://ldex.trading/): A deterministic decentralized exchange (DEX) which can work with many different blockchain protocols. It's less than 4K lines of code in total and only has 3 small third-party dependencies (including sub-dependencies).
> under-performing colleague - why not fired already ? Management
Everybody underperforms once in a while. With enough coworkers, there are always a few on that bracket, even if no one is incompetent.
> Feel inadequate with work - picking wrong ppl to do the job
You are the one that controls how you feel and what jobs you accept. Are you complaining that management hired somebody for doing a job that they need done?
But indirectly, a lot of times management causes those issues by adequately responding to market needs. The world sucks, and while managers do create a lot of problems by themselves, they didn't create them all.
If something is important and I don't feel hugely guilty if I fail, I will enjoy time pressure.
Repetitive tasks can be amazing, analyzing the patterns and optimizing them away is a cool exercise. It hurts when people forbid you to do so ("don't write a script for this" "why are you changing this to do it your way, it's not right"). Same for imposed limitations.
Underperforming colleague is only an issue is if it's unspoken, not discussed or imposing secrets on you. If my colleague is slow then I want to reallocate the efforts so I can do a bit more to avoid him dragging down the team, and I just don't want the manager to bother me with slow perf if there's a slow guy nor I want that slow guy to force me to lie so he can stay his way. It just has to be open and optimized.
Unexplained broken code requires a shift in thinking: freedom to break it, freedom to get time to do so. You need to reverse the context, system and desired outcomes to improve understanding and fix it.
Another aspect is that I think adult life removed a lot of important emotional layers: no more open challenges that tame into natural competitiveness, that unleash positive pressure and brain activity leading to learning with more fun. A lot of jobs devolve into politics. Quite often I've heard people tell me "shh don't tell we're done so we can slack a bit". From the smallest jobs to highly paid engineer.. same behavior occurs. Kinda creates low levelling.
That's not a bad thing per se. However, management always fails to account for e.g. mental fatigue after finishing an important milestone that most of the time has been grinding hard at for the last month.
That fatigue needs a week or so to disappear by itself -- just getting one good massage, sex and sleep doesn't fix everything. If you're loaded with work again starting tomorrow you'll do a sloppy job and will keep accumulating more fatigue.
I'm not saying an army of unmotivated lazy slackers doesn't exist out there. It absolutely does. But not everyone is like them. Sometimes people really do need to relax a bit in order to recover their ability to be useful to the business.
Our stupid system of requiring 8h a day for 5 out of 7 days misses 99% of all human specifics and it simply doesn't care. That's not okay.
Is this a real thing? I have never known there to be a technical problem in work that I wasn't able to solve, all of my problems have been from ever changing requirements and clients refusing to give detail.
Is there a role for me that maximises technical complexity and minimises managements role?
> “I feel negative when I get really stuck on something and cannot get around it”. Another respondent elaborated: “I also thought of situations where I’m debugging some issue with the code and I can’t figure out why it isn’t working – when it seems like everything should work, but it just doesn’t. This is definitely one of the biggest gumption traps I encounter”.
Here's a contrived example.
Let's say you became a house builder because you liked building houses from scratch. In a few years you find yourself working for a company and you are the window frame expert. You calculate, design, draw windows for the bespoke houses. You also make sure they fulfill building regulations. All day long. Note that you don't get to make the windows, other guys in the company do that.
Then you realize that this is not what you had in mind when you wanted to become a house builder. But the company pays you very well and you have some nice co-workers. You need to leave but you don't.
We can argue about the specifics, but stuck in solving that type of problems (especially if it's for incompetent co-workers) can drive you mad in the long run.
2. "stuck solving problems pushed onto me" Oh wow, how I hate that. Like when a user f*cks up their account on a Friday evening because they mixed up the "Delete" and "Rename" buttons (how do you do that? they are even color-coded..) and of course they have an urgent deadline so now instead of going home early to enjoy the sunshine I have to clean up this mess. And of course it's always the big important clients who employ cheap unskilled employees, so of course their mess gets triaged as critically important.
I believe the study intended to poll for #2, but clearly they didn't formulate it well so that #1 fits, too.
I highly doubt you are referring to the same thing.
One thing is being challenged to present a solution. Another entirely different thing is being stuck with an impossibility when you are reaching a deadline and all your managers and peers look at you as if you're hopeless when in reality you're just working a workfront that is not practically solvable.
I've been in a project where I was assigned a task that was severely underscoped and was riddled with emergent blockers. The quick description of the task sounded like a trivial thing that could be done in a couple of days, but in the end it turned into a months-long, multi-team effort. I was a few weeks into the project when another engineer was tasked to help me out, in the spirit of "let's pull this idiot out of the mud because this is getting embarrassing". It took a week or so for that engineer's mood to change from "here I am to save the day" to "please someone, anyone help me".
Does this sort of scenario fit your "problem solving" ideal, where everyone just loves the whole experience? I highly doubt it.
One of the key factors in happiness and fulfilment is the sense of mastery and performance. Sometimes we need to shift to a lower gear to move over bumps in the road. Sometimes we find ourselves in the depth of a gorge with no possible way out. The latter leaves everyone miserable.
why judge yourself for others incompetency?
Regardless of the example,the point is that it's naive and very ignorant to portray all blockers as feel-good "I overcame a challenge" opportunities.
Sometimes you feel good because you managed to jump a hurdle, sometimes you feel bad because you're stuck in the middle of a ravine with your arm crushed by a huge rock and the only tool you have is a pocket knife. Sure, you exercised your problem-solving skills on both scenarios, but they are hardly on the same level in terms of personal fulfilment and happiness.
For me, yes. IF you remove the manager constantly asking "is it done yet" and "why isn't this done".
I like having and solving large, unscoped, deeply technical, problems as long as the nagging doesn't happen. My last launch (this month) was a 6 month long 3 team project that no one but me understood. It's now a documented feature, with unit tests, and it is extremely simple. In fact, one of my CLs which took ~2 weeks to make was adding 1 `if (X) { continue; }` and I sent that to my manager as "look at this amazing milestone we crossed" and him not getting it :)
Yes, programming itself really is fun, but only if you care about the thing you're working on (which most of us will for our own personal/side/business projects, but not that many of us work on exciting stuff in our 9-to-5).
I mean... You can only do so many years of repetitive coding tasks in a typical corporate environment. That's why so many senior devs (upper 30's and 40's) either move to a management position or quit the industry ("quit" as in they start working for themselves in their own business or they just do something different and maybe do contract work from time to time).
Personally, I can't imagine myself doing the corporate worker drone programming for much longer (10+ years has been more than enough), I want to stop some time in not too distant future and I'm actively working towards that goal.
- "Being stuck in, problem solving": great, fantastic, hooray, woo, yay, hoopla
- "Being stuck, in problem solving": not so much
- I had to help my uncle Jack off a horse
Yes, in the end the customer will be happy. But you spent 99% of your time glueing stuff and 1% of your time thinking about what to glue.
I've seen software engineering described as 'complexity management' and I think that gets closer to it than purely the use of other libraries which is commonly called just 'glue'.
Complexity management is a nice name. But again, it's only 1% of what you think about in a typical job. The rest is applying duct tape and glue.
Half a year later, it will be discussed again. The odds of the issue being picked up are higher, but still not high enough. The same song and dance is performed, only for the issue to be put all the way down on the backlog, the place where issues go to sleep forever.
I much more understood the “happiness” to be constrained to how you feel about work. There’s no mention of happiness outside of work.
I didn't become a software engineer to write yaml or negotiate K8s resource allocation.
I also argue that we're probably fucking it up a lot, causing it to be more painful than it needs to be, but that's because we consistently get our developers to do infrastructure work.
A corollary to this, locally running the code AND integrations is essential. If you don't have the ability to replicate the full system locally, your devs are hamstrung and will take much longer to solve what could be very easy problems if only they could have debugged it locally and quickly. This is related because if your infrastructure is shooting for the moon in complexity, your devs have little hope of replicating it locally.
The perversion of it is that it comes across that I’m against DevOps. I’m absolutely the opposite. I’m against attaching bullshit marketing labels to good practices and making them a cancer on the project (cough devops, agile cough).
I’ve dealt with this recently. The “DevOps guy” was a toxic, condescending gatekeeper who wouldn’t co-operate with the engineers at all, but had the ear of the management.
He had a bunch of servers and builds he was really pleased with that were not at all documented and completely useless to everyone, because no-one understood it and couldn’t ask questions.
Good ops should be utterly transparent and utterly out of the way. Not hidden magic, just so easy to understand that it ticks over doing what it does without interrupting your workflow. And always reproducible locally.
Give a prick even the slightest chance to poison your company and they will is about the only 100% reliable piece of advice I could give anyone in this industry.
There is absolutely no bullshit in replacing waterfall's big upfront design and risk-prone one-shot dev project with an iterative process where at each cycle you reevaluate your course and your planning, always based on developer feedback.
There is also absolutely no bullshit in avoiding the mistake of artificially separating the devprocess into sysadmin stuff and dev stuff, and actually get developers directly involved and more importantly become mindful of the reality of everyday operations.
Portraying agile and DevOps as bullshit is clear telltale sign you are completely oblivious to the issues software developers face on a daily basis, and how agile and DevOps help solve or mitigate them.
2) agreed.
3) I never did that. I’m fully aware of the issues software developers face on a daily basis. I am one. Same as almost everyone here. Agile and DevOps (capital A, capital D, capital O) are corrupted buzzwords used to saddle engineering teams with snake oil salesmen and deeply suspect printable credentials.
But by all means you keep on throwing around baseless aspersions about who has the right or wrong kind of experience if they say something you don’t like.
"a 60 minute meeting where no decisions are made because everyone just shouts at each other so you leave with a headache"
to "a 60 minute meeting where no decisions are made because everyone just shouts at each other but you can turn down the volume on Zoom"
It sounds really stupid, but that literally helped make a giant difference.
This last week was the funnest in a long time. A colleague who works at an office 7000 miles away flew in the for the week so everyone on team locally came into the office this week. First time in over 2 years I've seen everyone there. It was really fun.
If you need other ppl company to fill the emotional emptiness - dont work remotely.
Its more for the ppl who work task based or hourly based consulting and are free to do something else after.
If home isn't fitting for you, try anywhere else on Earth. There are probably new environments that are possible that have not yet been created. Let's explore those. It's very likely that the office isn't the single best place on Earth.
- Junior developers who can't get their code pass code review process
- Senior developers who don't know what's going wrong in a microservice products. Rabbit holes are everywhere where you don't know where, who, how to fix the bug in a strange service.
- PM who can't write clear JIRA tickets
Seems to me like in many places, career success is mostly driven by metrics that are not related to good software engineering practices (specifically showmanship). Normally I would expect success to be measured primarily on metrics closer to the actual professional skillset.
Not arguing for or against, just surprised not to see it in the list.
It's different at the team level, but nobody's really cracked it for individuals yet that I'm aware of.
I am honestly not sure how to improve matters at this point. I tried to lead by example to little avail. E.g. "look at how I documented that kind of issue here as a guideline moving forward". We tried issue templates that are effectively a checklist of required information, but not every problem fits into a round hole. Many (most?) are actually quite odd-shaped once you apply nuance and context.
There are also those really annoying interactions in Teams where someone will type out "you have a minute?" instead of just describing what they need someone's attention for up front.
At some levels, I wonder if I might have the wrong team for this kind of job. How does HN deal with team members who have trouble slowing down and communicating their thoughts well?
At my work we have these "catch up" meetings where theres no agenda, time limits or minutes for our meetings. Every one in the team puts down tools and we take turns ranting about what ever is on our mind at that point, after 2-3 hours the meeting is over and we all go back to work with less time or understanding.
1. Time pressure. I can't develop code that works right. I am not talking about perfect performant portfolio work but as a backend developer many times I can't even hit the minimum standard of code quality because everything always needs to be done yesterday. Then I am responsible for it, and all the problems caused by deadlines are my problem, and every manager forgets they assigned me the deadline.
2. Pagerduty. Absolute worst thing to ever be perpetrated on development teams. It allows the C-levels to run "lean" teams because 4-8 developers rotate minimum 12/5 shifts, usually 24/5. 30 years ago this might have been necessary. We have been able to stagger timezones for the last decade now easily.
3. The work. It took me 10 years to land (by chance) a company with work that is interesting to me. My bar for interesting is so low at this point that on a scale of boring to life changing something that even remotely has me write other than boilerplate scores pretty high. Even now, I am responsible not only for the software but also for the devops (this is not a small company) which inevitably gets blocked to death by SREs, code review on another 2 repos for deployment, my own QA, etc. I do, effectively, the work of 4 different positions. I am paid for being a developer. Either raise my salary 40% or I will start dropping tasks.
Remote work has been an absolute boon to me. I am unsure how anyone could take a negative stance on it. Sure I don't talk to people often but I don't honestly care. Work has always been work to me. Coworkers are not your friends and honestly they probably shouldn't be. Find meaning in your life elsewhere. With remote work I can actually do my job (program) instead of being in meeting after meeting where a PM waxes poetic on whatever is important to them in order to justify their meager existence at the company. I no longer have to listen to the CEO go on for hours about how good the company is, or feel like I have to join in for beers instead of going to do what I actually want, etc. Fuck everything about the office. I am fully convinced this is not an "extrovert" vs. "introvert" battle, but rather a battle of people who have actually woken up the realities of being a serf vs. the people who remain asleep suffering from stockholm syndrome.
Yes, but that's not because I am happy all the time while working. It's because I have a purpose in life and a family that keeps me happy. Trying to optimize work to be a place to increase happiness sounds equally promising as breeding dogs whose shit smells like flowers.
"Psychological disorders such as job burnout and anxiety could also be reduced by limiting the negative experiences of software developers"
I fully agree there, too. I've fired highly profitable clients in the past, simply because their behavior (mostly too emotional, too chaotic, bad management, no time planning skills) was making our entire team unhappy.
Quote from the paper: "I also thought of situations where I’m debugging some issue with the code and I can’t figure out why it isn’t working – when it seems like everything should work, but it just doesn’t. This is definitely one of the biggest gumption traps I encounter"
I totally don't get that one. For me, the path towards finally figuring out a challenging problem is the single most exciting thing in my job. This is precisely WHY I became a software developer.
I'm truly surprised to hear that, apparently, many of my peers despise this aspect of the job.
> "The happy-productive worker thesis states that happy workers are more productive. Recent research in software engineering supports the thesis, and the ideal of flourishing happiness among software developers is often expressed among industry practitioners..."
'Recent research in software engineering...' now, what does software engineering research have to do with emotional psychology, again?
Psychology of labor is a thing, and has been for ages. The idea behind it is simple: it's people with a mind that do the labor, so their psychological state has influence on the work done. Is it software engineering? No, but the article purports to identify factors that influence the psychological state during software development.
That said, I do believe such studies to be of minimal value. Voluntary surveys are absolute bottom of the barrel. Identifying 219 factors from such a study seems like analysis gone mad. The extensive discussion of the non-normality of the central happiness statistic seems a point in case: it's trivially visible, it's not interesting, and doesn't play a role in any further analysis or conclusion. They do remark that the mean value they find is higher than in other studies, but can't explain it. Not that they need to, because nothing would change in the paper if the value had been lower.
Basically, this looks like an experiment from a starting PhD, who needs to push out one paper per year. Sadly, it isn't. The authors are senior researchers, who seem to have little idea of psychology.
Has anyone tried to replicate that results, with preregistration of study? What was the outcome?
> 152 Time pressure
I can deal with the 1st as long as the 2nd doesn't become 1st.
edit: speeling
And there lies its problem.