It took me about 2 months to learn this after getting my first job. Nowadays I intentionally add minor bugs that turn up during demos so I have stuff to "go back and fix" later.
That sounds... unnecessary. There is always stuff to refactor, and tests to add, folks showing up at the last minute with new requirements. Or you can just wait a day to push commits, etc. More honest, I think.
The point is, that if you demo something and it's perfect, someone in the room is more than likely going to opine about a way it could be even better. Likely not another dev, but a product or biz person. Even if you deflect by saying "that wasn't in the story, but we'll add it to the backlog" that still takes time and unnecessary discussion.
If you leave or introduce some trivially fixable but noticable flaw in the demo, that will (hopefully) get noticed and everyone can feel that they are doing their jobs without needing to make up something.
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"
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.
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.
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.
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.
The only tests we have are some for a project I worked on that I wrote to prove it could be done. Automated testing might as well be dark magic to my coworkers.
It took me about 2 months to learn this after getting my first job. Nowadays I intentionally add minor bugs that turn up during demos so I have stuff to "go back and fix" later.