zlacker

>>todsac+(OP)
I tend to consider bullshit any point that finds somehow acceptable thinking that people is lazy, in this society, in this world, on this planet, ffs we have to work 40 hrs per week per decades and rest after reincarnation, and you want to talk about laziness? Let's talk about how any bit of mental energy is extracted to built other's wealth and then when you are too old to do nothing other than watching work in progress they just spit you out

when I am supposed to fix tech debt? if every week there is another functionality going out that needs to be done yesterday? Do you think that I have to do it in my free time? Why should I even bother existing

>>lnxg33+h1
> when I am supposed to fix tech debt?

Try to lie about how long will it take. Just today I finished* 1-month almost total rewrite of firmware for one of devices at my work. It started as a 1-week small rewrite of part of communication module for a small bug and was scheduled as that. But I've got chill PM and coworkers who will appreciate that now we can actually fix some 8yr old bugs in legacy parts of that code.

* well, now some testing of edge cases and another round of fixes but at least remote code updating works so we can ship those devices...

Edit: "Lie" is call to action here, there were some misunderstanding in comments. Previous start of my comment was "Lie. ..."

>>yetihe+p3
In the same vein, don't tell your boss that you're going to refactor something, add tests, or write documentation. These are implementation details that you bake into your estimates and are part of doing software development. Your boss likely has no visibility into the tech debt in your codebase. Talking about refactoring, tests, and documentation gives the boss the opportunity to say "No, don't waste your time on that".

It's not lying to your boss, it's part of doing quality work.

Of course you shouldn't let perfect be the enemy of the good. You do still need to ship. I'm just suggesting that you don't let your boss know the ways in which you can increase your tech debt by cutting corners.

>>justin+Hk
What we did is to explicitly list bringing any touched modules up to current coding standards as an explicit item on the definition of done. That way team members were expected to include any necessary refactoring and test coverage expansion in their story point estimates.

>>nradov+wV
This is a great way to increase the compliance to coding standards and test coverage. If you can automate enforcement of this, it's even better. For example, your CI build could fail (or just send out notifications) if it detects that a modified file doesn't pass current coding standards.

Of course, it sounds like you have buy-in from management for these quality standards. For people who don't have this kind of buy-in for the whole team, they'll have to work individually to maintain quality.