😈TOP 7 Reasons Why A Developer Can Kiss His Productivity Goodbye✋

Katerina Sand
CheckiO Blog
Published in
9 min readJan 23, 2020

--

Many companies dedicate specific time and resources to increase their employees motivation and productivity. They hire a person to deal with such things, involve workers in certain activities and teach some techniques that supposedly must make their work more effective. For a long time for me it sounded somewhat ridiculous and, as I’ve done more research, I found out that there really was a sound reason for my skepticism.

To be fair, I’m not saying that it’s completely pointless, but the fact is, even though companies’ leaders invest in boosting their employees efficiency at work, they don’t even consider eliminating those things that are most probably destroying that so desired productivity. So, we’ve conducted a list of things that keep developers from doing their best job. And, if you’ll consider the cumulative amount of money spent on developers’ salary and time wasted on motivating them, you might find this information worth your time.

№1. Interruptions, loud colleagues and media alerts 😡

You’ve probably noticed that to do some quality work you have to get into a zone. It’s a specific state of mind when you are 100% focused on the task at hand and the solutions, ideas, alternatives are coming almost effortlessly. You caught a wave and you are riding it. It’s a great place to be, but it’s not that easy to accomplish, if you are constantly being interrupted.

Developers need their space and piece of mind to think and create. That’s why they like headphones so much (I personally can’t do anything without them😂). Each time a co-worker wants to tell a joke or talk about their weekend, it snaps you out of your zone. Each loud discussion involuntarily forces you to listen to it and lose concentration. As well, as when each time you find out about yet another meeting. It makes you feel like you won’t be able to do anything in this period of time, so you never do any actual work.

These disturbances can be avoided. Some by the developers themselves by setting boundaries and informing colleagues, when you’ll be available for discussions that have nothing to do with the work you are currently involved in. Some by the management by scheduling meetings with consideration to the working process of their employees (before or after the lunch break, or first thing in the morning) and keeping them right to the point (more deliberate organisation meetings can be done on Friday during weekly or monthly assessments).

There might be a lot of other interruptions, like e-mail pop-ups, phone notifications, personal calls, social media distractions (you know, Facebook, Instagram, Twitter, etc.). Some companies even cut-of the access to those resources through their computers. I’m not in the liberty to judge those restrictions, since they do nothing to your phone. And noone can refuse you the usage of your mobile, since there’s always the possibility of an emergency call or work related contacts. The only thing that comes to mind is to request switching on the silent mode, so you wouldn’t distract anyone at your workplace with your ring, and switching off the social media notifications, so you wouldn’t be tempted to check them out every few minutes.

№2. Lack of specificity and clearly defined priorities 📢

Every one of you at some point has probably heard from their employee or a manager something, like: “Why have you been working so much time on this task and not the other?”, or “Why did you make this feature like this, when I’ve requested it to be doing a completely different thing?”, or “Why haven’t you fixed that bug yet, since I’ve pointed it out earlier?”. These could’ve been somewhat reasonable questions, but more often than not, they lack specificity.

Management frequently highlights each task as the number one priority, so you can’t clearly understand what to put on top of your to-do list. Everything is important and everything is on fire due yesterday. So, it only adds to the constant stress and irritation, which tanks productivity big time. It can be easily avoided by the leadership itself figuring out the priorities and making them clear to their employees. This way the developer will be more able to organize his time and put more efforts working on the most urgent matters.

The tasks themselves require even more specificity. The feature must be described in more detail, so that the developer wouldn’t have to start all over again each time a new piece of information gets revealed to him. If you want a feature to be doing certain things, be sure to precisely describe it to the developer, so he didn’t have to work blindly playing guessing games. Same goes for the requests, like “there’s a bug, fix it”. Well, yeah, OK. Can you be more vague?!

If the leadership of the company really wants to have more productive workers, they have to ensure that work is being correctly organized on each level with strictly defined priorities and the developers are being given enough information to actually do their job.

№3. Technical Debt Limit🔧

Technical debt refers to a decision of implementing not the best code to release the software faster. These days business has to be competitive and rapidly evolving. If a company cannot deliver products in the shortest possible periods of time, it might not survive on the market. There’s always a need for experiments and fast solutions. In most cases, there’s no time to look for a perfect solution. If you can spend 14 days writing “perfectly good” code, but you can also spend 3 days writing the “good enough” code, then the preference will fall on the latter one.

Note, that writing “good enough” code doesn’t imply writing horrible code not taking into account the possibility of future implementations. But the sacrifices still have to be made. In terms of a good business strategy, it can be a reasonable way to go, especially considering that not all the technical debt will have to be paid back. Anyway, no matter how hard you try to minimize the impact of such decisions, the complexity of code inevitably increases. All of these cost developers their productivity, since they always have to compromise and later deal with a lot of complications, which slow them down, since refactoring is never among the priorities.

Here the compromise has to be made. It’s absolutely understandable that technical debt has to be sometimes leveraged in order to gain an upper hand in the competitive industry. But non-programmers must understand that always moving forward is not the best solution. Sometimes additional time for improvement and development is a justified course of action, if the company wants to save developers productivity and product quality all at once.

№4. Multitasking 📉

If someone will ever tell you that multitasking is the best way to increase your productivity and you must be able to do more in a shorter span of time, don’t listen. Just don’t. They are either superhumans or they have no idea what they are talking about. Various studies have already proven that a human’s brain cannot focus on several things at once. The worst thing you can do for your productivity is to try multitasking. And if your management requires that from you, they won’t be too satisfied with the results.

By multitasking you can create the illusion of archiving a lot of things simultaneously, but the quality of your work will certainly be lost. Trying to do several tasks at the same time is actually interfering with certain types of brain activity, since when you are switching your attention to something else, the process of gathering and absorbing the information gets disrupted.

So, if you really want to be the most productive at work, divide and conquer. Determine which task you are working on at the moment and devote your attention to it. Don’t jump from one thing to the other. If you are running tests, just run tests. If you are working on a solution, work on that solution. By doing this you’ll give your brain the time to concentrate and process what needs to be done much better, and, as a result, your effectiveness will drastically increase.

№5. Relevant Hardware and Good Tools 💻

If the company needs to have the job done, it has to provide resources to those doing it. Of course, a hole can be dug by hand, but the more reasonable way to dig a hole is to use a shovel. (The example is right to the point 😁) Every day developers have to deal with the code, sitting behind their computer screens conducting a lot of different operations. The tools and the hardware that they are given for the job can influence their productivity quite a bit. The better the tools, the more chances that a developer will be able to do his work effectively and in a shorter time. Same goes for the hardware.

If a company asks for better results, it has to provide better resources. The development team has to have the tools they feel comfortable working with. And given the salaries, it’s not the investment that won’t pay off in terms of better productivity.

№6. Seagull Management 🐤

I’ve come across these productivity suckers quite a few times during my research. It’s an interesting phenomenon that appears in more and more companies, but the aftermath of it is not that great.

The concept is very simple. An upper-level manager who has certain authority suddenly appears when he spots a problem and starts to dump all over. Even worse, he doesn’t propose any particular solutions or try to actually manage people. His ultimate goal is to make as much noise as he can and make everyone feel like shit (well, it most certainly seems like it).

This type of management has occurred due to the shifts in the competitive environment caused by changes in the industry regulation and the growing global trade. The companies are unable to react appropriately. The number of managers has decreased, but the number of people they have to overlook increased. So, the managers left cannot keep track of everything that’s happening and be present to deal with situations as they appear. They just swoop-in once in a while and add to the wreckage.

Seagull management, though very popular these days, proves to have a lot of negative effects. The disruption left in the wake of such a manager is huge and the employees are left cleaning the mess he makes. This behaviour brings a lot of stress, frustration and, as you’ve guessed, the productivity goes down the toilet.

The companies have to pay attention to such matters. If they really want to have actual problem solvers and not the angry, depressed and unappreciated developers who can’t get into a flow, because they are being treated like delinquent girls, they have to organize better management.

№7. Unrealistic Deadlines 🔨

Deadlines are part of the development process in every company and they are, undoubtedly, needed. But having a deadline has a dual effect.

Deadlines can have a positive influence, like motivating developers to work faster, produce better results, control the amount of work done in a certain period of time. But it happens only if the deadline is reasonable. It can be tight, but still r-e-a-s-o-n-a-b-l-e. And there the problem lies. Very often developers present estimates that the manager requires to lower as much as possible. Then those estimates are being presented to the company leadership as the agreed deadlines. As a result the development team is being pressured to meet those deadlines. This creates a lot of unnecessary tension and stress. If this pressure is constantly present, productivity drastically lowers. Developers can’t concentrate when they are overwhelmed all the time. There’s no need to mention creativity under these circumstances, ’cause it’s nonexistent.

Putting pressure on employees isn’t a problem. Development team needs a little kick from time to time. But when the pressure is too high and the deadlines are borderline insane, it won’t do any good. Let your developers freedom to create and function. If you want to actually have a reasonable deadline, ask the developers to track their activity and calculate what time on average they need to finish particular tasks. Based on those results they can create a schedule and analyze their performance against it. If there’s a need for improvement, make amendments.

Conclusion 😯

So, we went over the reasons that I believe are the most common destroyers of the developer’s productivity. Companies and their leadership have to consider the human factor and attention to the needs of their employees.

What do you think is the worst thing killing productivity at work?

--

--