3 ms·
> Unfortunately, "impact" is almost always measured by what features you shipped rather than considering the impact your code had on the long-term maintainabili
by proc0 3y ago
> Unfortunately, "impact" is almost always measured by what features you shipped rather than considering the impact your code had on the long-term maintainability of the codebase.
I've been trying to communicate this with absolutely no luck at all. Just coding is not considered "impact", meanwhile there are a ton of bugs and features take ridiculously long to complete. I believe this is major misunderstanding or lack of knowledge as to how software should work, thinking it's analogous to building hardware where you need more and more people to scale productivity.
- bazil376 3y agoIt drives me nuts. People cramming “features” into the app with reckless disregard. Moving through the codebase becomes akin to walking through quicksand.
- Tknl 3y agoHave you tried showing results of code qualify scanning tooling such as sonarqube or sonarcloud? This should show a downward pressure on quality.
- rogerthis 3y agoImpact should be measured as "features and their (monetary) value", not only "feature". Btw, I don't buy "long-term maintainability of the codebase". Ok, _I_ buy it, sometimes; my son doesn't. This above may be sad regarding the art side of things, but, well, it is what it is.
- CM30 3y agoYeah, this 100%. Which is why I suspect a 'winning' strategy for a career in software engineering is 'get involved in big new projects early on, take care of the low hanging fruit without much care for code quality or maintainability, and saunter off into the sunset before you have to deal with the consequences of your actions'. Meanwhile the folks stuck behind end up with the blame for these people's mistakes and the problems caused by their work, and get treated like poor performers because they can't just rush out features at the same lightning pace.