Another, very popular "personality trait" I see is people that have to constantly upgrade and replace tools and frameworks for minute or unknown benefits. This instead of asking themselves, "What is absolutely the best use of my time that will bring most benefits to the project?"
I have recently joined to help failing internal project that had constant stream of production failures ranging from not being able to deploy new version to production for 6 consecutive deployment weekends to 10% of user interactions (like user submitting something to happen and this happening twice, or reporting success where nothing happen or just blew up in his face leaving him hanging).
It's been interesting to observe seemingly intelligent people avoiding really necessary tasks (setup oversight and monitoring, understand underlying problems and their impact, prioritize, fix). Instead, everybody spent their time attempting another Java upgrade (from 6 to 8), Spring upgrade, switch from Subversion to Git, from Maven to Gradle, setup automated code formatting rules or pick hard on others because they try to write simple code ("no, you can't check null with ==, that's what Optional is for...")
I understand some of that was trying to shift the blame but these guys didn't really have to shift blame for the application being in sorry state. Most of them joined recently and haven't been able to contribute anything substantial because of various rules that were designed to prevent anything substantial can get done.
I really liked literally 30s of silence after in a meeting with management and the team I asked if it is their conclusion that back in the days where Java 6 and Spring 2 were contemporary it was not possible to build reliable applications with them.
Sounds to me like someone looked at the production failures and declared "These failures are due to technical debt and poor code quality. What can we do to fix that?"
And "we have dependencies that have been EOLed and need to be upgraded" is easy to quantify and fix - whereas "The codebase is too large, complex and unfamiliar for us to recognise bugs in one another's contributions" is difficult to quantify and fix.
> necessary tasks (setup oversight and monitoring, understand underlying problems and their impact, prioritize, fix
Necessary tasks are boring and it takes persistence to continously do what needs to be done. On the other hand checking various frameworks and endless rewriting may be considered fun by some. They're learning new things.
For the record I know how it feels as I've got a similar experience at work, people flock to new and shiny where old and tested works well and gets the job done.
Political players will use these things to gain power and benefits. They will get someone fired because the bike shed had a minor issue, and meantime will get everyone to ignore the power backups to the power plant.
I have recently joined to help failing internal project that had constant stream of production failures ranging from not being able to deploy new version to production for 6 consecutive deployment weekends to 10% of user interactions (like user submitting something to happen and this happening twice, or reporting success where nothing happen or just blew up in his face leaving him hanging).
It's been interesting to observe seemingly intelligent people avoiding really necessary tasks (setup oversight and monitoring, understand underlying problems and their impact, prioritize, fix). Instead, everybody spent their time attempting another Java upgrade (from 6 to 8), Spring upgrade, switch from Subversion to Git, from Maven to Gradle, setup automated code formatting rules or pick hard on others because they try to write simple code ("no, you can't check null with ==, that's what Optional is for...")
I understand some of that was trying to shift the blame but these guys didn't really have to shift blame for the application being in sorry state. Most of them joined recently and haven't been able to contribute anything substantial because of various rules that were designed to prevent anything substantial can get done.
I really liked literally 30s of silence after in a meeting with management and the team I asked if it is their conclusion that back in the days where Java 6 and Spring 2 were contemporary it was not possible to build reliable applications with them.