[corrral]

Refactoring and adding tests can be (and very often are) pushed into the backlog, and then never done. "We'll circle back to that after this sprint (narrator: they would not circle back to it) but for now focus on these new features"

Bugs are more urgent.

[digisign]

Disagree. This is a misconception junior devs often have... that you need to ask permission to do your job. (Not unless the boss is dysfunctional, in which case it's time to leave.)

Tests and refactoring should be done as part of every ticket and typically don't need to be explicitly called out. This naturally pushes "done" so you don't run out of tickets early.

[corrral]

Yes, but the point of this was to generate (easy) work that others want you to do so they won't ask you to do other (more time-consuming) stuff instead.

You'll have a very different experience telling the product owner you spent the whole week working on bugs that they noticed and they told you to fix (even if you left them in originally on purpose) than telling them you spent all week refactoring code. The former is an instant "great!". The latter is gonna get a concerned look and more questions.

The topic wasn't correctly doing development work, but finding ways to slack off while looking good.

[digisign]

You don't tell non-technical folks technical details, you deliver finished tickets on schedule, which makes them happy. Would you discuss what algo's you used with them? Database schema? No, then talking about unit tests is a non-sequitur as well. Complete snoozefest for non-geeks anyway.

In fact I'd be disappointed by a dev that constantly introduces careless bugs, it's a dev smell. Most bugs should be unique and result from ambiguous/incomplete specs.

Don't agree it is good advice to build a career being dishonest to others. I'm not even a goody-two-shoes... it's just not necessary in all but the most dysfunctional of places.

[corrral]

I agree it's not a great idea, for multiple reasons, but I get why the poster who brought it up would prefer letting bugs slip through to padding everything with more refactoring and adding tests. Deliver features fast(er than you really should be, probably), then coast on some easy bugs for a bit.

External perception of how well a developer is doing often has very little to do with how good a job they're actually doing. I don't think making refactoring and test-making your "easy work" would have the same effect on appearances as the fast-features-and-some-bugs approach, at least at a lot of places.

[afarrell]

> This is a misconception junior devs often have... that you need to ask permission to do your job

I think this is driven more by junior devs still trying to figure out what their job is.