10. Hide your actual productivity. IE: get done with your coding tasks in half the time, leaving other devs have to fix all the bugs that QA kick back. (This is probably a managerial issue, actually, but perpetuated by devs who do # 9.)
"If it ain't broke, don't fix it; if it is broke, just use duct tape."
A lot of places have infinite budget for fixing things an a patchwork fashion, yet zero budget for planning ahead for the maintenance phase, or for scheduling preventative maintenance. It's the equivalent of never going to the doctor for a checkup, and only going to the Emergency Department at the nearest hospital when an organ explodes. Nobody wants to be in a long-term relationship with an exploding-organ person, and it's the same for code.
---
#10 is an organizational issue. If a dev has "ownership" of a particular domain, they will naturally work very hard in the short run at setting it up so that they may be as lazy as possible in the long run. But if they are continually kicked off their catbird seat of smoothly-running machinery in order to clean up other people's messes, then there is some incentive to exaggerate the effort it takes to clean up their own mess. Or to make it appear as though they have a mess to clean up.
Even worse, if no one has ownership over anything, there is incentive to always drag heels on the current thankless and tedious task just to delay assignment of the next thankless and tedious task. Do the minimum amount of work to fix the current issue, and let the next guy deal with the fallout, even if the next guy is also you. Because if you bust your ass to fix it right, the next guy won't thank you, because there is no next guy. You can only work on the stuff that is broken, and if there's not enough work to do, people get laid off.
And that is the equivalent of under-staffing the POS cashiers, so that none of them are ever idle. That strategy results in fewer customer transactions, because when cashiers are never idle, that also means that there is always a wait for customers to check out, no matter what size the order, and the cashiers have zero individual incentive to complete an order quickly. Monitoring scan rates only covers the problem, which is that employees are implicitly punished for doing their job too well. Go to Wal-Mart, and all the cashiers are always busy, but also always dragging ass, and all the check-out lines are three customers deep. Go to Publix, and cashiers with empty lanes cheerfully offer to check you out the instant you have found everything you need, and will direct you to the correct aisle if you haven't. Idleness is not just doing nothing, but is also customer responsiveness.
When other devs do this, your best tactic is probably just to follow their lead, and possibly collude with each another against management for your own benefit. The org is broken, and you won't be allowed to fix it.
I've seen a couple fresh grads come in with that attitude and get away with it. I think it is more personality type than anything. What I saw usually happen was they were allowed to work on a new feature as kind of a treat for joining, but after when tasked to start fixing issues from legacy, they flat out refused. Even taking it to the head of engineering and making a stink.
The boss can't hire new grads to work on it, because they can smell the manure from a mile away. So as long as you're willing to slap on yet another coat of superficial patches, they'll keep paying you to do it.
That's an equally-bad symptom of the same problem, approaching from the opposite side. The structural problem still doesn't get fixed, because the developers aren't repulsed by it at a visceral level quite enough to kill it with fire or nuke it from orbit. It's just scary enough to scare off the competition.
The technical debt is kept in place, so that people can live off of the technical interest payments. It's not an honorable living, but it is a living.
Every, and I mean every, development shop has some amount of tech debt. But even if the code is generally good quality, you have a subset of devs who think maintenance is below them. That's a bad attitude and people don't want to work with that.