Unhappy Developers: Bad for Themselves, for Process and Bad for Software Product
arxiv.org
arxiv.org
I'm not asking to throw out the results. I want help understanding how they are able to make this claim.
Consider it in different words. "Tired people are bad for themselves, for process, and for projects." To many, this will read as "hire folks that aren't tired." Worse, it will be "your folks are tired, so they will make things bad for themselves, their processes, and their projects."
At best, you will get people who will see it and victim blame in a way that won't help. "You are jeopardizing our ability to succeed with your tiredness. In addition to your current tasks, I'm assigning you the job of getting less tired." So... odds of increasing wakefulness, slim.
Now, it could turn out that it is something you can fix in this way. I don't know and that is my point.
That is, skilled developers will want a better product/process and they will want to work with other skilled devs. Putting them in less-than-ideal situations causes frustration.
OTOH, a poorly skilled dev will want to push the environment in the other direction, for no other reason than to obfuscate the lack of skill. Putting them in an ideal situation for the skilled dev causes fear. Their aim is job security.
Or when junior are increasingly demotivated due to excessive micromanagement (bad process), skilled developer is perfectly fine - he is the one doing micromanagement. The fact that juniors could learn faster and achieve more will escape such developer.
Moreover, more skilled developers are oftentimes better able to offset the bad process. The less skilled developer pays more price for bad process - it turns him from able to do work into unable to perform the work.
Technical skill and ability to organize or see through process are not the same thing. You wont be able to organize if you do not have enough of technical skill, but technical skill in itself wont make you able to create good process.
If someone like this is in a situation where they need to micromanage or mitigate that is going to be a source of frustration. If someone has dysfunctional or antisocial tendencies and that's the reason why they're technically excellent, yes, they will gravitate toward chaos, just like they would probably gravitate toward a co-dependent relationship in their personal life.
Also to be clear, when I say skilled I'm talking about relative to the expectation of the position. A skilled jr. dev will be one who possesses the potential for greatness and who does good work at that level. As a sr. dev may enjoy mentoring others, a good jr. dev will seek out mentorship. And an ideal environment will be conducive to and support these types of relationships.
I would say they lack the character to overcome their flaws... lack of intellectual curiosity and humility. I've worked with quite a few people with 10+ years of experience at large enterprise companies who were flat out dangerous to a project and had to be managed as to what they worked on. People with senior titles who were functioning at a junior level, who simply got the title due to the number of years of "experience".
At one place I worked I literally saw a team form from the outcasts of other teams. All they did was copy translated strings into string tables and crystal reports and resize elements on screens in cases of overflow. It was literally data entry. All 5 were highly paid sr. developers. When layoffs started happening at that company they were one of the first groups to get axed... one of them I keep in touch with took two years to get a job, and another recently reached out to me asking for any leads. He hasn't worked in nearly 4 years. I gave him some tips for career development and self improvement, he didn't care, he just needed a job.
"they probably don't consider themselves bad developers,"
That's a problem. Knowing your limits/flaws is pretty crucial, a bad developer tends to have an outsized view of their abilities. Conversely, good developers tend to battle imposter syndrome during periods of growth.
"they sure as hell aren't sabotaging projects"
Maybe not intentionally (or at least they view it that way), but incompetence has a funny way of dragging down a team. Not putting in the effort to properly understand the domain of the problem or the business model, architecting confusing/overwrought solutions which lack conceptual integrity, not communicating clearly on progress, trying to confuse instead of admitting they don't know, etc.
Nobody likes to stagnate. Give most people a safe place to learn as they work and you're likely to see them improve over time.
The stress of trying to pay rent in tech cities being one I can think of. Would be interesting to see if developers in more easy going places are more or perhaps less productive.
Come on.
Creepy.
Bad engineering feels like taking a loan of technical debt to pay your manager, so customers can be scammed receiving a half finished product for the price of a finished one.
In the other hand, when you do good engineering you can proudly stand behind your work, be motivated and engaged.
Sometimes it's better to invest a bit in other aspects as well. Of course, you don't protect a $100 bike with a $1000 lock. There are tradeoffs.
It was also fun to visit the crackpot posters. Some of the authors went to a huge effort, including having their own books printed, and so forth. Plus, there was usually beer at the afternoon posters.
I'm also not sure how low of a bar it is when they did a study, coded the results, creating a coding system for surveys that can be used by others, and did more research to make sure they were asking the right questions.
I'm willing to bet that this is the first paper in a series of them and they'll use it to grab more grant $$ to do more in-depth research.