Nowadays we are not moaning, nor are we complaining. You do not dislike, you just have different opinions. When we have doubts, we can talk in groups and resolve them. Afterward, we give strong feedback. We even invented special meetings for this, called retrospectives. Yet it appears as developers we are just human beings and sometimes we are far less sophisticated than we think. We let ourselves fall into primitive hating. Usually, the reason for our annoyance is the same. In general, we don't like to waste time, especially when you have deadlines, you are stuck with code reviews and your new QA is constantly reporting some minor issues as blockers. So let this article be an anonymous manual called "How not to make your developer hate you".
I know too many developers who claim they have less than 40% of day time for real coding. They waste it on meetings, F2F, surveys or reports. And the thing I hated the most: time reporting.
1. Bureaucracy and Interruptions
It is not easy to manage projects. To organize them, we tend to introduce more and more processes. But I know too many developers who claim they have less than 40% of the daytime for real coding. They waste it on meetings, F2F, surveys, or reports. And the thing I hated the most: time reporting. Once my typical day started with a common standup, then a detailed meeting about my current epic, and then some random call about an urgent bug. Of course between each call, there was less than a 30 minutes gap. I spent 4 hours at work, did nothing but 3 meetings, and was already too tired to code properly. I started to begin work as early as 6 am so there were no interrupts. We need frames, but a good manager must make sure that they don't become our chains.
2. Setting up Environments
The majority of applications have some specific features based on user profile, selected offer, filled forms, etc. I can not count how many times I needed to ask what precise steps I have to take to reproduce some scenario. Then reproduce it several times during development, constantly not being sure if the fix works or the setup is wrong and servers respond with an error. Afterward, you pass this hot potato to the rest of the team. Now when you multiply that by factors like experiments, feature flags, channels, app, and API versions it might become a real pain. Even if you invest in a custom tool to generate the requested environment automatically, it might still be one of the least liked things during the everyday routine.
3. Tasks Overload
Our typical workday consists not only of coding. Our responsibilities often include performing code reviews, resolving reports, answering questions, reporting service outages, controlling our domain, or checking on current rollout. To make our lives easier we created multiple tools. In the end, we have a panel with metrics for this. Logs for that. Links to documentation, pull requests, wireframes, etc. Then you need to follow a calendar, chat, call, and many more. It is just impossible to even remember everything yet make use of it. What we need is to reduce the clutter. Automatizations and integrations of even the simplest tasks may benefit in less stress, smaller silos, better scalability, faster onboardings, and loads of saved time.
4. Poor documentation
Working with legacy code is not easy, but it can become even more difficult when the domain is so robust and old that even project managers don't know its use cases. Almost every subtask begins with endless talks and research before you even start. As time is ticking you don't make proper notes. Instead of one source of truth, you end up with info scattered across chats, wikis, comments, and your brain. Moreover, no one cares that this part of the project is the place you should never visit. They need just "rough" estimations. When you try to explain that you might as well read the tea leaves, they will joke that you are the best and only you can do it. Naturally, later they tend to treat it as deadlines. The only thing that you can do is to make sure you will be the hero who will save the next generations from this chaos.
5. Miscommunication
Coding is just a small portion of work for your next feature. We depend on so many other people like designers, QAs, analysts, translators and others. Each of them has tons of hard, specialistic words and their own project slang. In such conditions It is too easy to understand something differently, which later turns into wasted time and grief. I would love to see more people who actually pay attention to how they describe their thoughts. Tasks should be written in such a manner that literally anyone in the corresponding position could understand them. In fact as time passes it is very likely you will forget context too. We should keep in mind that shortcuts taken now, will be our delay in future.
6. Lack of purpose
They should've warned me that one of the side effects of being a developer is the great need to see sense in what you do. There is nothing more frustrating than going through a task we find useless. That's why it is so important to explain what is the reason for this next feature and why it should be done for yesterday. In a world where coding is almost like magic, and you can create marvellous inventions, wasting time on some dull task without understanding the whole concept might be depressing. Especially when at the end of the process, the feature is cancelled or cut in half. Sounds impossible? We all know it happens a lot.