Most of the low quality projects I have worked on have had thoroughly demotivated devs.
Usually combined with lackluster management and sometimes a serious case of toxic dev culture.
I’ve become a nudger to try and counter, refactoring things, casually suggesting code improvements, and poking the culture with talks and genuine respect for the people going through change. There is always the risk of pissing someone off if you don’t weigh your words, so respect is key.
It’s hard to be consistent tho, especially if you repeatedly fail to get ideas across to a tough crowd...
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
I'm also interested in hearing about any defect measuring systems on any of your projects. Did you measure things? Does measuring defects change anything?
Do projects that do measurements have better outcomes in your experience than projects that don't or projects that do a poor job with measurements?
It works in my immediate surroundings, i managed to get several old complex systems refactored by doing it, the business value here being increased application performance and feature output.
I remember distinctly one place where we took bugs quite serious. We had a hard limit of ~15 bugs of varying severeties, any more than that and bugs would get higher priority relative to new features.
It was quite efficient, after implementing it, we definitely had less bugs on production.
I'm not sure if it was the measuring of just the proper focus they received that did the thing, but it definitely did something.
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
I've tried to be a "nudger" too and it definitely helped by my projects also suffered from some of the 36 classic mistakes so we never went as far and as fast as I would have liked.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Most of the low quality projects I have worked on have had thoroughly demotivated devs.
Usually combined with lackluster management and sometimes a serious case of toxic dev culture.
I’ve become a nudger to try and counter, refactoring things, casually suggesting code improvements, and poking the culture with talks and genuine respect for the people going through change. There is always the risk of pissing someone off if you don’t weigh your words, so respect is key.
It’s hard to be consistent tho, especially if you repeatedly fail to get ideas across to a tough crowd...
Thanks for your comments, Sebastian.
Has your "nudger" approach been successful?
I'm also interested in hearing about any defect measuring systems on any of your projects. Did you measure things? Does measuring defects change anything?
Do projects that do measurements have better outcomes in your experience than projects that don't or projects that do a poor job with measurements?
It works in my immediate surroundings, i managed to get several old complex systems refactored by doing it, the business value here being increased application performance and feature output.
I remember distinctly one place where we took bugs quite serious. We had a hard limit of ~15 bugs of varying severeties, any more than that and bugs would get higher priority relative to new features.
It was quite efficient, after implementing it, we definitely had less bugs on production.
I'm not sure if it was the measuring of just the proper focus they received that did the thing, but it definitely did something.
That's great. I'm glad it worked for you.
I've tried to be a "nudger" too and it definitely helped by my projects also suffered from some of the 36 classic mistakes so we never went as far and as fast as I would have liked.