undefined | Better HN

0 pointscorrral3y ago0 comments

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.

0 comments

digisign3y ago

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.

corrralOP3y ago

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.

j / k navigate · click thread line to collapse