A list of my pet hates - particularly re: management, so I can make sure not to do them should I ever be in that position.
People who prefix every task they delegate with words like 'simple', 'quick' and 'easy'. They rarely are, and it makes you feel like you're constantly under performing when a "simple" or "quick" task takes longer than expected.
Context switching. A productivity killer, and general motivation killer. Creative work (including software dev) takes place when developers are given time and autonomy. Nothing's worse than being pulled off a task just when you've got into the zone.
No team building / social stuff. I'd really love to think that team building stuff is a distraction from getting real work done. The reality is, though, over the years I've noticed it really has an impact. It creates a sense of solidarity that carries through into work, and it's really important. The problem is, it's never the most pressing task; there's never something that will break the next day if it doesn't get done. And, especially as workers get older / have families, it's increasingly less appealing to eg. go out for drinks after work. Still, you have to make team building a priority.
A "bums in seats" mentality. The easiest, and also least effective, way for a manager to determine employee productivity is to count the number of hours they're sitting at their desk. A far more effective way is to gauge general attitude, frequency of screwing up, and what other team members think of working with them.
Putting pressure on you to get a task done ASAP. This is a tricky one. There are certainly times when a "good enough" job is better than a "perfect" job. In general though, the developers themselves are usually in the better position to make the call on what's worth tidying up now, and what's worth leaving for "later" (aka never).
Being tasked my multiple people. The trouble is, then each of the people tasking you don't know how busy you are, or how much work the other "taskers" have given you. There should be a single point of contact managing your workflow (that point of contact can be you, but that means you have to have the authority to turn down tasks, or say that they can't be done for a while, because you've got too much on). If someone requests new work that could be done by you, it should go through that single point of contact, even if the person requesting it is above that point of contact in the heirarchy. (Eg, CEO should ask CTO for a change, as opposed to asking a dev directly. If they ask a dev directly, dev can just pass on to CTO.)
Managers who speak in text speak and leave out joining words or eliminate punctuation etc in their emails, making them harder to read. It gives the vibe of "I'm too busy to communicate clearly".