This article first appeared @zigi' blog
Written by Aleksander Kubista, Android Engineer, Poland.
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. Afterwards 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”.
1. Bureaucracy and Interruptions
It is not easy to manage projects. To organise them, we tend to introduce more and more processes. But 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. 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
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 error. Afterwards 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 everyday routine.
3. Tasks Overload
Our typical work day 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 documentiations, pull requests, wireframes etc. Then you need to follow a calendar, chats, 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 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 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.
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 marvelous 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.
There is nothing wrong that our work environment is not ideal. The only problem is when we do not improve. So often we fall into the vicious circle of rushing to the next task, because we have no time as we were delayed with the previous task. Why? Of course we had trouble with legacy code, or we had to fix bugs which our tests did not cover. That is why recognising and fixing technical debt is crucial. And by debt I understand more than just poor code. It is also hidden in our processes, pipelines and tools. We all began our new work with passion and energy, but overtime if there is no sign of progress we get grumpy again. Yet there is a hope that after reducing our daily pain you might end up with a highly motivated and happy team.
Top comments (0)