10 things that tick off software developers

Have you noticed that your software developers seem a bit cranky lately? If you’re a project manager, their boss, a recruiter or a QA professional, you might be the reason. That’s according to new data from devRant, an online community built to encourage bonding, knowledge-sharing, networking and, yes, ranting, between software developers.

Co-founders David Fox and Tim Rogus, both software developers themselves, founded the devRant community in March 2016, and since then have had approximately 15,000 software developers post more than 25,000 “rants.”

To better understand the issues and challenges their profession faces, Fox and Rogus searched the community for common keywords, and then factored in the occurrence of “heated” language and swear words to determine which issues really set developers off.

“Admittedly, our methods weren’t incredibly scientific, but overall we feel we have a solid sense of the most common annoyances developers face, especially since the same things kept coming up over and over again. What companies should take away from this — besides a few chuckles — is that it’s important to listen to what your developers say, to make them feel heard and understood and do what you can to address those issues,” says co-founder David Fox.

Here, based on the number of rants on the topic that included “heated” language and swear words, are the top 10 issues that are ticking off your software developer teams.

*Slide statistics are rounded up.

Developers as a general rule don’t like being told how to do their job, and since product/project managers often oversee developer teams, they often have to do just that, says Fox. That can create friction.

“What I think it really comes down to is product/project managers are, in a lot of ways, the owner of these projects and processes without understanding the obstacles and challenges developers face on a daily basis,” Fox says.

Just like product/project managers, development managers or engineering managers have to direct the activities of developers to make sure projects are completed on time and under budget.

“In some companies you can also run into situations where a developer’s boss is a contributing member of the team, or have been promoted from a developer role, and that introduces extra conflict,” Fox says.

Developers don’t have to be actively looking for a job to be bothered by recruiters; in such a tight talent market, it’d be tough to find a software developer or engineer who hasn’t been approached by a recruiter looking to poach them, Fox says.

“The persistence of recruiters is a big problem. They call, they email, they just won’t leave you alone, even if you’re not looking for a job. This gets really annoying. If you are looking for a job, the most annoying things about recruiters tend to be sending developers completely irrelevant job openings, or positions that don’t fit your requirements — like a job that’s completely across the country when you don’t want to relocate,” Fox says.

[ Related story: How to look for a job while you’re still employed ]

Developers complain when there’s no documentation; they complain when there’s too much documentation; they complain when they have to write documentation; they complain about how others have written documentation — there’s no getting around this one, Fox says.

“Documentation’s one of those issues that all developers can agree on: They want well-written, accurate, concise documentation, but they don’t want to write it,” he says.

This is a problem for everyone, not just developers. Unnecessary, tedious, lengthy meetings aren’t anyone’s idea of a good time, Fox says. “There are even mugs and ribbons available that say, ‘I survived another meeting that should have been an email,'” Fox says.

With the advent of the agile methodology, “flat” organizations and the emphasis on collaboration and teamwork, open office plans are the norm nowadays, especially for software development teams. It can be difficult, if not impossible, to get any work done in these types of office, though, according to data from devRant.

“There’s so many distractions; co-workers stopping to talk, overhearing meetings and phone calls. There’s also a multitude of complaints about things like the office coffee and the amenities — or lack thereof,” Fox says.

[ Related story: 3 ways annoying coworkers kill productivity ]

This one’s self-explanatory. Everyone’s got that particularly annoying co-worker who makes office life dreadful; for software developers, though, the most consistent complaints tend to be about the quality of a co-worker’s code or their oversized ego that doesn’t match up with their skills, Fox says.

When developers do look for a job and get past the recruiter stage, there are a few consistently annoying aspects of interviews they tend to complain about, says Fox.

“We see complaints about being asked stupid questions, being asked to solve tech and coding problems that they’d never encounter in the real world, and having the interviewer not understand exactly what it is they do,” Fox says.

Software developers deal with bugs and errors on a daily basis, so it’s a bit surprising that they’re not first on the list. Fox has a hypothesis about the issue; for developers, bugs and errors are often resolved in a positive way, so there’s not much of a reason to complain.

“Most other issues don’t have such a positive resolution, but bugs and errors are solvable and it feels good to do that, so the rants we do see are pretty positive,” he says.

[ Related story: Stop your workers from quitting in their seats ]

Quality assurance (QA) is a critical part of software development, but QA engineers are subject to the same criticisms many developers level at product/project managers, says Fox.

“QA gets a crack at the product after the developers and engineers have finished it, so often times they don’t understand the project’s constraints, the work-arounds, the challenges and obstacles the developers ran into when they were building it. We also see a lot of complaints about QA asking developers to go back and rework parts of the code that they [the QA team] should be able to handle themselves,” Fox says.