25 ways to piss off your devs

1. Assume they’re all Marvel loving cave-dwellers
2. Expect bug-free code
3. Punish failure
4. Ignore diversity hiring
5. Call them “Rockstars”
6. Sidestep their request process
7. Interrupt their Deep Work
8. Micromanage them
9. Stop checking in
10. Be indecisive
11. Ignore their career goals
12. Lose sight of their business impact
13. Exclude them from brainstorming and decision making
14. Ask them to brainstorm or make decisions
15. Make them use deprecated or inappropriate software
16. Assume you’re on the same page
17. Waste their time in pointless meetings
18. Ignore the project scope
19. Cancel 1:1s
20. Hire inexperienced Agile coaches
21. Give them too much/little work
22. Give them unfulfilling work
23. Assign dueling mentors
24. Give them unrealistic deadlines
25. Take them for granted

What really pisses off software developers? Grinds their gears? Crashes their code?

To build a healthy, productive culture for your devs, it helps to first identify behaviors that can have a negative impact. Here are 25 things you should not do if you want to have a happy, successful dev team.

1. Assume they’re all Marvel-loving, cave-dwellers

People make a lot of assumptions about software developers. If you’re looking to piss them off, really lean into those stereotypes. They work with technology, so of course they can fix your uncle’s smart TV. They code by day and hack by night, working alone in dark, cave-like basements. And all devs are huge Marvel nerds who pay for everything in crypto.

Does that describe your devs? Maybe. But software development is more diverse than ever. You can’t put all your devs in one bucket, and they won’t like it if you try. This is a great point to kick off our list, as it sets the stage for the next 24 items. Remember that these are a compilation of many dev opinions. There is no one way to treat your devs, and you should customize your approach to each individual.

2. Expect bug-free code

What a great way to stress out your devs. When perfect code is the expectation, they become more worried about messing up than building a successful product. You’ll be putting them on a fast track to failure. Nice work!

Bugs and broken code are normal parts of the development process. In fact, they’re expected when dealing with tight deadlines and expedited delivery. In most cases, the “wrong” line of code delivered on time is better than the right line too late.

That being said, technical debt can become a real problem for dev teams as more interest builds. One study found that the average developer spends 42% of their time on tech debt, with the cost of bad code coming to $85 billion annually.

So you shouldn’t expect perfect code, but you also can’t afford to let the tech debt build up. That may mean increasing headcount or adjusting expectations about what your team can deliver within a given timeline. Look for improvement opportunities in your process rather than just expecting perfection from your devs. There will always be mistakes, but they’re a necessary part of innovation.

3. Punish failure

To recap the point above, failure is a necessary and inevitable part of the software development process, and it helps developers learn from their mistakes. So if you want to discourage that kind of growth within your own team, then you should set a hard line between failure and success. Punish those who stray into failure — set an example for your other devs. They’ll stop taking risks, and you’ll stop seeing the rewards. They may even quit.

Or instead, you can welcome failure as a learning opportunity. It shouldn’t be ignored or sugar coated, but it should be embraced. A culture of transparency, trust, and safety is more conducive to meaningful developer growth. Give your devs autonomy, but keep them accountable. Devs should feel safe enough to fail and encouraged enough to keep trying.

4. Ignore diversity hiring

You’re probably aware of the diversity gaps that exist in software engineering — and the tech industry as a whole. If not, here’s a quick snapshot:

• Women make up only 19.7% of software devs in the U.S.
• 54.7 percent of U.S. devs are white.
• Only 5.4 percent are Black or African American.

Ensuring diverse representation is a deliberate, ongoing effort, and it starts with the interview process. Our devs suggest hiring from boot camps instead of just sorting through a bunch of computer science degrees. It shows that your company is willing to put in the time to interview candidates from a variety of backgrounds. That doesn’t mean you should exclude devs with degrees. Rather, try not to limit yourself at all. Developers walk many different paths. Having a wide ensemble of experiences can only help your team.

Just be mindful and intentional about how you ensure Diversity, Equity, and Inclusiveness (DEI). Surface-level diversity hiring — done to fill a diversity quota or present an image — will only frustrate your devs. But what really irritates them is when diversity is promoted as a key tenet of the company by a C-suite of entirely homogeneous execs. It shows you aren’t invested at all levels of the company.

Allaya Cooks-Campbell at BetterUp writes that diversity hiring isn’t about hiring candidates that make a workplace look more diverse. “Diversity hiring is the development and implementation of a strategy that corrects for bias while attracting, and retaining, qualified candidates.”

5. Call them “Rockstars”

“Software Developer” sounds too straightforward. There’s not enough oomph, no danger or mystery to it. Instead, try treating dev titles like Top Gun call signs — Rockstar, Ninja, Guru, and Wizard are classics that your devs are sure to hate.

Our devs can’t stand being called any of those offbeat titles. It’s not that they don’t want to be appreciated for their work or acknowledged as high performers. They’re just tired of leadership romanticizing the myth of a “best” developer. Did we learn nothing from point number two? Perfection doesn’t exist. Not in nature, and not on your development team.

“If the perfect developer does exist, they’re probably insufferable.” – Love, our devs.

These titles can be especially damaging in your job outreach. Who is actually searching job sites for ninja or rockstar gigs? Not only are these postings easier to miss, they can actually turn away top talent — especially minority candidates — and make it harder for you to filter out those with less experience. It can also read as out of touch (“What, you think there’s such a thing as a 100x developer — other than maybe Linus Torvalds?”). Or even exploitative (“I know you’re not paying 100x for a 100x developer”).

6. Sidestep their request process

If you want to quickly get on a dev’s bad side, go to them directly with work requests. They likely have a process for such things, but you can ignore it — just insist that it’s easier to talk to them directly. You don’t like creating Jira tickets or waiting for responses anyway.

This kind of behavior sends a signal to your devs that your time is worth more than theirs. If you need to put out an immediate fire, make that clear to the team, and thank them for the quick response. But if it can wait, go through the appropriate channels. There’s a request process for a reason, and bypassing it can feel disrespectful to your devs. It can also pull them away from other projects, cutting into their Deep Work. More on that in the next way to piss off your devs.

7. Interrupt their Deep Work

Here’s another pro tip for angering your devs: interrupt them as much as possible. A bug, “quick” question, or new request — even minor interruptions can have a big impact on productivity. Wait until a dev is in a groove, writing some of the best code of their life. Then tap on their shoulder or ping them in Slack. Don’t stop until they respond. And if that doesn’t work, planned disruptions like meetings are a surefire way to pull your devs away from other work priorities.

When starting or resuming a task, it can take some time to get back into the swing of things. This is especially true for software developers, who are more impacted by interruptions than other professions. It can take them even longer to regain context and resume a previous activity. The constant change in focus can also leave devs feeling drained of energy. We call this context switching, and it can really hurt your team’s productivity.

That’s why it’s so important to protect Deep Work time. Devs need uninterrupted time throughout the day to solve tough problems and build amazing features. Without it, they are more likely to adopt unhealthy work habits, ultimately leading to burnout. We recommend at least two-hour blocks for Deep Work.

8. Micromanage them

Devs want to be trusted to do their jobs. And what’s the best way to erode that trust? Micromanagement! Devs crave autonomy, so make sure you’re constantly hovering over their shoulders. It can put a real strain on dev productivity and happiness, but that’s the price you pay for absolute control.

Or instead of micromanaging your devs, you could set clear expectations, provide the tools and information needed to fulfill those expectations, and trust your people to get it done. That goes for you too, product and design teams. Devs are often told what to build and how quickly to build it, with little discussion about what it will actually take to get it done. Trust that your devs know the best way to make something work, letting their knowledge help guide your projects. That doesn’t mean trusting them blindly. It’s okay to check in with them to verify the results and stay connected. Which brings us to the next way to piss off your devs.

9. Stop checking in

Your devs want autonomy, so that’s what you give them. You step back entirely and let them do their thing. Now you barely remember what your devs look like, and you’ve forgotten most of their names. But you just assume everything is going according to plan without ever talking to them. That way, when things go wrong, you can just blame your devs for not filling you in. They’ll hate that.

You may think that autonomy means leaving devs alone and never checking in with them. In reality, that can cause feelings of isolation, lessen visibility, and increase knowledge silos. Some of our devs want leadership to just get out of the way. Others want more active guidance on team processes and individual growth. (The latter is more true for junior devs, as our seniors tend to fall into the “get out of my way” category.) Work with your team to find out what autonomy means for each dev, adjusting your communication to their style.

10. Be indecisive

Gray or dark gray. The question has plagued your mind for weeks, annoying your devs in the process. If you’re in the business of pissing off developers, this indecisiveness is a good sign. It means that by the time you make a decision, they’ll have much less time to do the work. How could they not get upset?

If you care about your devs’ time, make up your mind and get to the point. Don’t drag out changes. Need to change a color? Just write a ticket that says, “change color.” Devs don’t need long essays or back-and-forths. They just want to know what needs to be done.

11. Ignore their career goals

Assuming that your devs are happy right where they are is a great way to upset them. It’s unlikely that their current role is fulfilling their life’s purpose, but don’t let that be your problem. Show them you have better things to worry about than their growth and success.

Or you can choose to invest in their futures instead. Devs have goals beyond their next coding assignments. Find out what those are and how you can help them get there. That could mean setting them on a management path, but don’t assume that’s what they all want.

“Some devs don’t want to be managers. It’s up to leadership to carve out new paths that better align with their goals. Knowing where my devs want to go helps me better support them as they take on more responsibilities. This also means adjusting to their individual pace.” – Brian Park, Engineering Manager at Uplevel.”

12. Lose sight of their business impact

This one’s for those who prefer the long game for angering their devs. Start by isolating them from the world beyond their code. The longer they stare at code on a screen, the more disconnected they’ll become from your business objectives. In time, they’ll start seeing things in components and PRs, unaware of how they’re contributing to the product.

Though many devs are content just living in the code, they also want to feel like part of the “big picture” and see how their work is contributing to team and company success. You have to show these devs that their work matters. Failing to connect their efforts back to business and team goals could leave them feeling isolated, unfulfilled, and probably a little upset.

Try to find a healthy balance between tedious tasks and projects that feel more meaningful. Recognize work on things like bug fixes and their crucial role in keeping the business running, while providing additional opportunities to work on projects with more visibility.

13. Exclude them from brainstorming and decision making

Devs want to be included in conversations about their work. So to really get them angry, you should instead surprise your team with sudden scope or deadline changes. Don’t bother consulting with them beforehand. That would ruin the surprise!

By making changes without consulting your team, you risk alienating them. They might feel like they lack control and that their voices don’t matter in the process. Including developers in early project discussions gives them a say in the amount and type of work they’ll be doing, which helps keep them accountable. It also gives them an opportunity to point out hidden implementation costs, design challenges, and synergies with other projects. Be as transparent as possible throughout the process to make your devs feel included.

14. Ask them to brainstorm or make decisions

“But you just said …” Yes, we just stressed the importance of including your devs in brainstorms and decision making. But on the flip side, we heard from some devs who want absolutely nothing to do with that. If you want to create a nightmare scenario for these devs, just ask them to come up with new features or help guide the direction of the company.

“I just don’t care about being involved in decisions. If you want to talk about the Agile process for an hour and a half, do it without me. I don’t like getting too into the weeds. Just tell me how you want to run the team, and I’ll do it. Involving me in the decision-making just bogs me down, taking me away from my work.” – Uplevel dev

These devs don’t mind contributing to the conversation, but they feel pressured when asked to write down their ideas. They loathe post-it note brainstorms — too much time spent writing on post-its instead of having real conversations. Leave them out of it! The discussion and follow-through is the important part.

15. Make them use deprecated or inappropriate software

Here’s a surprise: Dev’s don’t like using deprecated software. Who knew? So if you want to make them mad, think of ways your technology can slow them down. Imagine trying to build exciting innovations using dial-up internet. Or power your servers by crank. Wait until the tech is so old that it becomes difficult to replace, creating more of a disruption to upgrade than just getting by with legacy tech.

Some software deprecation is expected — it’s kind of part of the gig. What’s worse is forcing inappropriate/difficult software on your devs. There may be a great reason your team is still using the SOAP framework, but if they’ve made it clear they prefer REST, overriding them could cause problems.

Forward-thinking organizations should have forward-thinking tech. Don’t make a dev’s job harder than it already is. Give them the tools they need to build the tech you want. You shouldn’t upgrade your tools too often, however, as technology churn can also become a problem.

16. Assume you’re on the same page

When you’re juggling multiple teams and priorities, information can get lost in the shuffle. You can forget what you said, how you said it, or who you said it to. To piss off your devs, just assume that they understood it the first time and will follow through.

For those who prefer a more successful approach, repetition is key. Send them a clear, consistent message that you don’t mind repeating over and over. It may feel a bit redundant after a while, but it’s important to create clarity and alignment.

“A friend of mine once paraphrased David Gergen, saying on the subject of repetition,’If you want to get your point across, especially to a broader audience, you need to repeat yourself so often, you get sick of hearing yourself say it. And only then will people begin to internalize what you’re saying.’”

Jeff Weiner, Former LinkedIn CEO

17. Waste their time in pointless meetings

Your dev team has a planning meeting next week to establish project timelines. So you schedule another meeting this week to put together a plan for that meeting, taking up more of their precious time. You throw in a few irrelevant all-hands meetings for good measure — that’ll grind their gears alright.

It’s difficult for devs to fit in Deep Work when their calendars are clogged with meetings. Some meetings are necessary and serve real value, but others can drag your devs through hours of meeting hell. It’s not the meetings themselves that they can’t stand — it’s the waste of time. Consider the following tips to keep your meetings relevant and minimize workday interruptions:

Avoid “FYI” meetings for your team. If they don’t really need to be there, or you can give them the notes afterward, then don’t invite them.
Limit cross-team/all-hands meetings, and rotate members so not everyone has to attend.
Truncate meetings by five to 15 minutes. It will give your devs time to transition between meetings while helping create a culture of brevity.
Remove short fragments. Schedule meetings closer together to avoid gaps and free up longer blocks of time for Deep Work.

18. Ignore the project scope

Here’s a great way to kick your devs while they’re down. When they’re already struggling to deliver scoped work, throw them a curveball. Flip the project plan on its head to make some unplanned changes — but don’t update your budget or deadlines. Just ask your teams later on why sprint projections are always off.

If you’re shifting priorities, making mid-sprint design changes, or adding work after planning is complete, you risk angering your team and throwing off their work. Scope creep also puts pressure on your devs to get through a higher volume of work, which can compromise quality and lead to bugs.

Sometimes it’s necessary to make mid-sprint changes. And if you must, make sure to adjust the project scope to account for them. You may still upset your devs, but at least you’ll be following the scope change process.

19. Cancel 1:1s

If you want developers to feel like less of a priority, cancel your 1:1s. Catch up on the fly instead of scheduling regular time with them. A quick status update is just as good as a 1:1, right?

As you rethink your meetings and get rid of those that aren’t serving a purpose, consider this tip from our devs: don’t touch the 1:1s. Done well, weekly 1:1s provide a valuable forum for career planning, roadblock removal, and big-picture thinking. They should be held regularly to establish a greater sense of rhythm and importance. If you need to cancel, make sure you reschedule. Just don’t write them off as less important or come unprepared. Work with each dev to set an agenda prior to the meeting.

20. Hire inexperienced Agile coaches

Thinking of hiring an Agile coach to keep your dev team effective? Here are three ways to choose the wrong one:

1. Pick a coach who exists just to tell your team they aren’t doing Agile. These so-called experts are more focused on what it means to be “Agile” than actually helping your team.
2. Choose someone with no development experience to coach your team. That’s like someone who can’t swim giving you pointers on your backstroke. They may know the fundamentals, but your team will question their ability.
3. Make sure they spend a lot of time in design, slowing the flow of your development process.

Poor coaches will prescribe a one-size-fits-all solution. On the other hand, a great coach will have the right experience and set clear goals for the training. And they’ll establish a dialogue with each individual team to explore needs, process adoption, and more.

21. Give them too much/little work

To anger your devs, create imbalance among your teams. Overload half your devs with too much work while giving almost none to the other half. Devs don’t want to be overwhelmed with work, nor do they want to be bored. Too much work can wear them down, eventually leading to a drop in productivity — and worst case, burnout. Too little can leave devs feeling like they’re just wasting their time — also leading to burnout.

Indeed, your devs don’t have to be overloaded with work to burn out. Feeling like they’re not doing enough to make an impact can also leave them depleted and apathetic. Try giving your devs more say in the amount of work that they’re doing. Including them in early project scope conversations can help them feel more empowered and accountable.

22. Give them unfulfilling work

Most devs want to work. But they want that work to be engaging and purposeful. If you’d rather keep them unfulfilled, give them the opposite. Assign them nothing but low-impact work with no visibility. Then call them lazy for not making enough of an impact.

You won’t get a dev’s best effort if they’re only working on bugs or lights-on activities all day. You have to balance these often less desirable tasks with more meaningful, high-impact work. Create opportunities for them to get more involved in projects they care about. They’ll be better engaged and grow in the process.

23. Assign dueling mentors

Picture a bright-eyed dev making their first foray into the world of software development. To quickly bring them up to speed, a senior mentor is assigned to show the junior dev the ropes — the right tools, best practices, and overall ins and outs of the team.

After a couple weeks, teams are shuffled and the junior dev is assigned to another senior member of the team. The problem is, the new mentor does things very different from the former. They’re two very different people with different ways of working, and each is used to being the smartest person in the room, which puts them at constant odds. The junior dev gets caught in the middle, trying not to take sides. Who cares which library they use?

Inconsistent mentorship can be very frustrating, especially for junior devs. When done right, mentorship can have a profound impact on a dev’s future. In fact, those who receive mentoring are five times more likely to receive promotions than those who don’t. Trusting your devs to find their own managers risks them ending up with no mentor at all. Instead, try implementing a voluntary mentorship program, pairing willing junior and senior devs based on common responsibilities, interests, and other similarities.

Bonus tip for pissing off your devs: Assign overworked mentors. If their plates are already full, pile on some mentorship responsibilities. That’ll work out well for your junior devs as well. There’s nothing like being ranked as a lower-priority by a senior member of the team.

24. Give them unrealistic deadlines

Of course you want it tomorrow — everyone wants everything right away. And if you want to anger your devs, unrealistic deadlines are a good way to go. To add fuel to the fire, force them to cut previous estimates to fit those tight deadlines.

Or you can make things easier on your devs. Between the meetings, messages, new dev interviews, and more, something has to give. Rather than it be your devs’ health, you may want to rethink your deadlines. Ask your developers what they think is realistic. Either extend your deadlines to give them enough time, or create space on their calendars by replacing unnecessary meetings with Deep Work blocks. You can also cut scope by deferring some of your product features or other work.

25. Take them for granted

Even in tough economic times, qualified devs are in high demand. If you want your devs to join the 75% of developers either actively looking for a job or open to new opportunities, you should definitely take them for granted and never show appreciation.

Or instead, you could check in with them to make sure they’re still getting the most from their work, and have open, honest conversations about their impact and goals for the future. You can’t stop all of your devs from leaving, but you should still try. Don’t make the mistake of thinking they won’t leave or don’t have other options.

Want to retain your devs and keep your teams efficient? Now you know what not to do. Follow these 25 tips and you’ll be well on your way to dev burnout, attrition, cycle time delays, and an overall unsuccessful team.

Or you can take steps to avoid pissing off your devs and build a culture of happy productivity. Some are straightforward changes, but others can take some planning. See how Uplevel’s data-driven insights can help you meet your product release goals, without burning out your team.