There’s a lot of positive things you expect from your job, to make it feel fulfilling – like what we discussed a few posts back. But it’s hard to enjoy your fulfillment and professional satisfaction when you get up every day and want to quit your job because it’s driving you up the wall. We asked our developers what annoys them the most.
Of course, there can be many reasons why a programmer quits his or her job. Maybe they’re bored with the product they’re developing? Maybe they want to move to the mountains and make goat cheese for a living?
Or maybe your company is doing one of these things:
#1 Doing Agile wrong
Working at a software agency, you get to cooperate with a lot of different teams. Each team has people who think a bit differently and work differently than others. There is no standard dev team or a standard project.
And yet, many project managers insist that there is just one standard or right way to do agile development.
Michał Kosyk: In one of the most frustrating projects I worked on, they were trying to fit an obviously non-agile team into a small “agile” box. That is the exact opposite of agile. If your way of doing things doesn’t work, change it. Even if it means giving up “agile” processes.
In one of my previous jobs the waterfall model would have done perfectly fine, because in order for agile to work, everyone has to be in it. If you have part of the process – in this case, design – separated from the agile dev team, it just doesn’t make sense. You’re trying to test and iterate, but you can’t, because it takes a month to have the design team redo their part, and they weren’t even participating in stand-ups.
#2 Pointless meetings
Wojtek Ryrych: Meetings have a reputation for being a waste of time. But that’s only true if you’re doing them wrong. Meetings should be short, relevant and to the point. So it’s important that everyone comes prepared to every one of them.
It’s also inefficient if you have daily stand-ups with too many people. Even if all those people are on the same team, they’re probably working on different parts of the project. It’s much better to have two meetings simultaneously and only talk about what’s relevant to everyone present.
If you hire developers and you don’t trust them to do their job – why hire them? If you have one single dev working on a project and they don’t need to communicate with the team – does it matter whether they’re sitting at the office or sunbathing on Madera? If they’re getting their job done – does it matter if they’re at the office from 9 to 5?
Wojtek: I believe that the best way to manage creative and smart people is to have a flat, decentralized structure. For one thing, there is just no way for one person to control everyone and everything in the team, so you shouldn’t even try. Instead, hire people you can trust and give them enough autonomy to manage themselves and cooperate. You’ll be surprised how much faster people can work when they don’t have to run everything by the manager. They will also be much more satisfied with their job because they have a sense of ownership of their work.
By micromanaging someone, you send them a message that you can’t trust them, so they become passive and lose interest in their work.
#4 Unclear requirements and acceptance criteria
This is also especially relevant for working at a software agency. When clients give you a task but they don’t know what they expect, and they don’t know when it’s done.
Sure, unclear requirements can be discussed, but that should be done by a project manager before work is started. Not left for the developer to decide on their own, and then discarded when it’s finished and turns out not to be what you wanted.
#5 Having to negotiate with stakeholders
In general, what application developers want is to develop good applications. So if instead of focusing on doing the best work they can, they have to negotiate with client – you have an unhappy developer.
Bogusz Kaszowski: Something that always annoys me is when a client tells me how to work. Namely: faster. They want to pay less, so they pressure me to put in less billable hours, and they don’t care if it forces me to cut corners. And then they’re surprised that the code they asked me to write in half the required time doesn’t work and I have to rewrite it. And bill them for more hours.
#6 Being out of the loop
When all important decisions about the company and milestones happen behind the scenes and you’re not included in them – you feel like you are not important. So nobody will notice when you’re gone.
Programmers also like to know that their products work for their users – ultimately that is why they build that stuff. So giving them positive feedback – from the users and the team leaders – is a good start to make their coding work feel meaningful.
#7 Doing pointless work
Developers are problem-solvers. They can’t do their best work if they don’t know what problem they’re actually solving.
Getting tasks assigned without knowing their context forces developers to work with unnecessary uncertainty. Programming is not about creating random features. It’s about building good products that serve a need. If you don’t let developers fully understand the point of their work, you’re wasting their potential. And developers get frustrated because it feels like you either don’t trust them to make good creative decisions, or you don’t know what you’re doing either. Either way, it’s hard to be satisfied with your job when you don’t know what it’s for.
#8 Technical debt that’s badly managed
Technical debt piles up every time you neglect updates and accept sub-par work from developers. When you make bad top-town development decisions, when you follow tech fads or refuse to adapt to new good practices, or rush through QA.
It happens to the best. But the best dev teams actively manage tech debt on a regular basis.
If your team doesn’t have discipline in refactoring and doing regular codebase maintenance, that codebase is going to grow into a monster that developers run away from into the safety of another job.
You’re gonna miss them when they’re gone
We have a simple rule of thumb when it comes to giving developers the basics of a good working environment:
Are we getting in their way when they want to do a good job?
Writing good code is what every good developer wants to do. So when we get in their way by making them work hours when they’re unproductive, or follow rules created to micromanage them because we don’t trust them – essentially hurting their productivity – of course they’ll be unhappy. And when you get several job offers a week, why would you stay in a company that is holding you back and doesn’t even treat you like an adult who can make good decisions?