Top 6 things that demotivate a developer
A developer, software engineer, programmer, (however you like to call them) is usually a pretty unique person. As Alfred once said "Some Men Just Want to Watch the World Burn".
Developers on the other hand want the world to run smoothly, seamlessly... like clockwork.
What drives a developer?
I think comparing to a clockwork mechanism is on point. A developer wants to build small little springs, levers and gears. Set all of these components in a solid housing, apply some tender, love and mineral oil for things to move smoothly. And at the end of the day, the best part of it all, is when a dev can wind that single crown on the side of the clock and watch the entire mechanism come to life.
Each piece moving in sync and unison with another, one gear passing information to another. That is the endgame, that feeling is what a coder expects after hard days, weeks or even months of work.
Over the years of working with devs, being a dev, working with Product Owners and getting familiar with Product Owning I can tell that the business side and the programming side don't usually see eye to eye.
So what kinds of tasks or processes demotivate developers?
And how to avoid them
#1 Redundancy
Imagine working on a wedding cake for at least a week. A large 3 layer cake. with icing and rose petals and handmade figures adorning the top. And minutes before the wedding you are asked to dispose of it. No-one saw it, no-one tasted it. Sure you got paid, but why do the work if it's going to be thrown away.
Unused code is time spent planning, building, testing, while somewhere along the way the higher-ups decide to cancel the idea and never publish the code. This includes code that is used only for a while, as I call it temporary code. Things that are manually added then removed after a certain amount of time. Convert manual work to a manageable and automated version, devs love that.
"Avoid temporary features with existing functionality"
Most of the time temporary code is just a gimmick, an alteration of an existing functionality. Instead of asking a dev to make a new kind of modal, or a new kind of form, just use the existing ones you might already have. Especially if it's something temporary that will expire in a week? a month?
The moment a developer has to type in a start & end date of a feature in the actual code, you know you've gone too far. Automate this. Invest the time to make repetitive events or features manageable and have the content team activate or deactivate them when needed.
This excludes AB testing, that by nature is temporary code. That being said even AB tests should be prepared in an MVP (Minimum Viable Product) or in a "fake it till you make it" kind of way. You are proving a concept, don't build 2 fully functional versions as an AB test. Use the AB test results to build the final version of a feature.
#2 Being in the Dark
Best case scenario is when everyone knows the end picture of the product and everyone has a clear path towards it. But in a real world that is almost never the case. CEO's, PO's, or even clients don't really know what they want and what will bring the most value.
Way too often the development team is not involved in the long term roadmap or plans for the future. With a shortsighted backlog a developer doesn't know how to prepare for the end game.
Bad preparation can lead to redundant code or POCs (Proof of Concepts) that burn before seeing the light of day. See #1 Redundancy.
You'll soon see that most of these demotivators are closely related to each other and they intertwine.
"We need to build a laser that can cut through foil"
A dev gets asked to build a laser that can cut through foil, but only the foil, not anything underneath it. So a developer starts to build it, but somewhere along the way the PO comes back and says we need a grabber too, so the vice can hold the item while the laser cuts the foil.
A month later it turns out a huge machine was built that delicately holds a piece of candy while a laser cuts and extracts the contents from inside. If you told a dev you want to open a candy bar, he'd take it, grab the zigzagged part and just pull away the foil.
This is an exaggeration ofcourse but sometimes thats what requests without knowing where we're going look like.
Involve the dev team, or a representative in roadmap discussions, plan short and long terms plans, have one solid and unified vision of the end game. You will save a lot of time, money and stress. Often there are easier solutions to a problem.
Spend more time planning, and being sure of what you want. Constant spec changes and "slapped on" features are not maintainable
#3 Not enough thought
Closely related with #1 and #2. Some tasks demotivate a developer because they sound wrong, or are badly thought out or are just redundant. In situations like these I bring out the good, old question machine. As a dev just start asking questions, like "should this also be for logged out users" or "what happens if case B, or case C". If you get answers and there is enough data supporting the feature, then maybe the goal was misunderstood.
Usually though the answers are monosyllabic grunts of dismay which force the task giver to go back to the drawing board and figure out all the loose ends. Keep inline with your end game goals.
#4 Pressure over invisible progress
Writing code is not like building a house, where you first see some foundations being poured, then walls being erected, followed by a roof and windows, doors. Often during development of an application there is background work that is being done. The end user or stakeholder doesn't see this and wrongly assumes someone is being lazy or not pulling their weight.
This is more about educating the stakeholders about how code development works. Not everything is done on the frontend, and not everything is always a tangible feature. Trust in your dev team and with proper scrum methodologies the higher-ups can always be up to date with current progress of features.
"House keeping and plain old boring work"
The next 2 are demotivators that popped up often in my polls. But they are more about house keeping. Chores that just have to be done even if it's not any fun. Even in a normal household taking out the trash or cleaning the bathroom is something most people would like to skip. But they still need to be done.
#5 Bugs that can't be reproduced
Personally this one doesn't demotivate me but it is possible that getting an issue ticket that can't be reproduced sucks out your passion. Following the steps the tester used and not getting the same error is somewhat soothing (because it's not happening for everyone), but also frustrating (because you'll need to fix it some day). Knowing there is some kind of combination of actions that cause this can keep you up at night.
Many times it's just bad luck, a network delay or interruption, some other process lagging on the end users device, or on the server, an outdated device or just plain user error.
There is no magic remede for this apart from more tests, QA testing, testing on older and slower devices or traditionally blame it on a fluke and hope there are no more issues of the same nature in the future.
#6 Writing documentation
This is the definition of a chore. Code should be documented and described so that team members and new onboarders have an easier time getting to grips with all thats happening in a project. This has a lot of added value but is often overlooked or ignored either because no-one wants to do chores or #4, its invisible progress.
As boring as it can be, writing documentation is just something developers need to do. And higher-ups need to understand its value in the long term. Along with automated testing it's the easiest components of an application to exclude and save costs on.
Try to share code documentation amongst the team, everyone should be pulling their weight and not have 1 person dedicated to going chores. Documentation can be done in small shifts to make the chore seem shorter and easier to do.
TLDR;
Coding is not a production line
Your software, your developers and your entire organisation should be striving towards making an autonomous machine. IT is not a factory, it's not manual labour. You wouldn't want a watch where you'd need to manually turn a gear every once a while for it to keep running?
A happy dev is one that knows what the end game is, that is well informed and has time to figure out the best path towards a solution.
A good dev can assist in decision making, and can also determine where cost optimisations can be made. A mature dev knows that even the boring tasks, the chores to do around the house are also part of the game and adapts to it, not complains and avoids doing it.
Low hanging fruit and "quick wins" give immediate results but many times also bring tech debt. Give a little thought to the graph in this article.
Image courtousy of https://outfunnel.com/pipedrive-automations/
