[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.