133
80% of programmers are NOT happy… why? - YouTube
(youtube.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 29 Jul 2024
133 points (92.9% liked)
Programming
17314 readers
212 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
A part of it is horrible practices and a work culture which incentivizes them.
Who can be happy when the code doesn't work half the time, deployments are manual and happen after work hours, and devs are forced to be "on-call"?
Introduce Test-Driven Development, Domain-Driven Design, Continuous Deployment with Feature Flags, Mutation Testing and actual agile practices (as described in the Agile Manifesto, not the pathetic attempt to rebrand waterfall we have in most companies) to the project and see how happiness rises, along with the project's reliability and maintainability.
Oh, and throw in a 4 day work week, because no one can be mentally productive for that long.
IMO the biggest problem in the industry is that most developers have never seen a project actually following best practices and middle management is invested in making sure it never happens.
Out of interest, do you think that this would be a natural occurrence in the industry if a company were to say "right, no more managers, you self-manage and build this ting, and if it doesn't work we go bust", would software engineers look to build the best possible thing to their knowledge?
It's something I occasionally think about, because various companies like Valve and Fog Creek a decade or so ago did try similar stuff - and they had some great success with some absolute duds.
I think that would depend on the skill of the developers and the resources they are given.
A lot of us are only ever taught to be code monkeys and those would probably not naturally gravitate towards true agile practices (which most, I would argue, have never actually seen in a real project).
Another problem is a lack of access to domain experts, which is also crucial.
However, my current project doesn't have any managers, or even business analysts, there's only the developers and the Product Owner. We have access to some domain experts and we work with them to build the right thing.
It's going great and the only problems we are facing are a lack of access to the right domain experts sometimes, as well as some mismanagement in the company around things we can't do ourselves (like the company Sonarqube not working and us not being allowed to host our own due to budget constraints).
In conclusion, I think part of the problem is educating software developers - what true agile is and what the industry best practices are (some mentioned in my previous comment). Then you give them full access to domain experts. Then you let them self-organize. Basically, make sure you have great devs, then follow the 12 Principles of the Agile Manifesto to the letter and you've got a recipe for success.
Otherwise, results may vary a bit, as I think many would tend to continue doing the Fake Agile they were taught and continue producing the poor quality, untested code they were taught to produce.