Top 6 things that demotivate a developer

Is your development team feeling unmotivated? Learn the top six things that might be preventing developers from doing their best work and how you can start finding solutions.

jalokim__a_photo_of_time_managment_at_the_office_a7405061-97e1-41b8-b320-313329bcde91

jalokim__a_photo_of_a_small_yellow_rubber_duck_on_a_modern_offi_6757b9f2-153d-49c1-b2cd-bf52d2e6069a

A developer, software engineer, or 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 it 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, and 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 moves 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.

jalokim__a_photo_of_a_girl_iOS_programmer_at_the_office_shot_fr_997d2223-8910-4f88-900e-67bf16c7fbe8

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 will be thrown away?

Unused code is time spent planning, building, and 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 are manually added and then removed after a certain amount of time. Convert manual work to a manageable and automated version, devs love that.

jalokim__a_photo_of_a_frustrated_programmer_in_his_deep_dark_ba_b80d7968-a731-4fea-ae7a-68f06fee5bde

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?

When 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, which 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

The best case scenario is when everyone knows the end picture of the product, and everyone has a clear path towards it. But in the 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 intertwin

jalokim__a_photo_of_a_laptop_that_is_glitching_out_in_a_white_o_64973e39-d616-49cf-a545-40b1b162eec0

We need to build a laser that can cut through the 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, of course, but sometimes that's 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, and 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, 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.

jalokim__a_photo_of_a_young_person_holding_a_smarfone_in_the_ur_bded1e37-4805-42ff-b894-df46be7f41a6

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 in line 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 the 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 front end, 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 the current progress of features.

jalokim__a_photo_of_a_frustrated_programmer_in_his_deep_dark_ba_6512e53c-dace-408f-ba52-8f4b0fd2e40e

Housekeeping and plain old boring work

The next 2 are demotivators that popped up often in my polls. But they are more about housekeeping. 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 someday). Knowing that 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 user's device or on the server, an outdated device or just plain user error.

There is no magic remedy for this apart from more tests, QA testing, testing on older and slower devices, or traditionally blaming it on a fluke and hoping there are no more issues of the same nature in the future.

#6 Writing documentation

This is the definition of a chore. The code should be documented and described so that team members and new on-boarders have an easier time getting to grips with all that's 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 component of an application to exclude and save costs.

jalokim__a_photo_of_a_whiteboard_full_of_sticky_notes_edee4aa8-4607-40e9-93ec-3a4911cede68

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 in a while for it to keep running.

A happy dev is one that knows what the end game is, 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 often also bring tech debt. Give a little thought to the graph in this article.

geeks_and_repetitive_tasks_02_1024x622_1_1_b5e19901e0

Image courtousy of https://outfunnel.com/pipedrive-automations/

Written by: Miki, on February 1, 2023

Tags:

Teams

Learning

Developer Experience