You may have noticed that your developers are grumpy when you come to discuss a project. Recent research suggests that increased cognitive load leads to difficulty controlling impulses. Developers spend their entire day working complex problems and have to keep a mental model of thousands of lines of code for months or years.
Sometimes this leads to bad behaviors like eating terrible food, overconsumption of caffeine, playing a few extra games of Mario Kart instead of getting back to work, or having knee-jerk emotional responses.
Most people don’t interact with developers on a daily basis, so getting defensive push back every time you walk in the room can be a major turn-off. Developers are people too, and they can be manipulated for a more favorable response.
Here are some common reasons developers might get huffy and how to work around it:
Everything’s a Fire
People tend to think their own needs deserve prioritization over others, so requests to developers come in hot and are often worded as though the world is ending. When everything that comes across your desk is on fire, it’s easy to start freaking out about everything and being hostile toward any request.
The truth is, when you tell us that everything is important, you’re really saying that nothing is important.
Consider how critical your issue is and match the wording of your request to the actual nature of the issue. Save talk of impending doom for real points of impending doom so you don’t have your developer constantly feeling like a trembling chihuahua.
A Barrage of Requests
Developers work on a lot of projects. It’s rare that a launched project results in the developer never touching the code again. There is always maintenance to be done and retainers to fulfill.
When you come in with a seemingly simple task, the developer may feel overwhelmed as they are fielding many other requests across multiple code bases, and your developer may react negatively. To combat this, approach your developer with an understanding attitude.
Underestimated Difficulty
Most of the time, it takes a developer to know how much work is involved in a development task. Approaching a developer with a line like, “this should be easy” or “this should only take a few minutes,” especially when a timeline based on these perceptions has been promised to a client, can be maddening.
Instead, ask your developer what they think about the difficulty of the task, and especially consult with a developer before setting a timeline.
Working on Really Old Code
When a project is under active development, most developers are able to keep a mental map of the code. Making changes can be quicker because the developer likely remembers the file the code is in and the developer will know how a change might affect unrelated parts of the project.
Six months later, though, the developer has moved onto another project and has a completely new code base in his or her head. After a year, that original code base might as well be a paper you wrote in high school.
Finding and changing a specific sentence is no trivial task and can be scary since it may introduce a cascade of unintended issues. When requesting work on an old project, provide ample time for the developer to research.
Not My Project
Once a team reaches a certain size, it becomes more likely that projects will be split amongst the team. Not every team member will have any real knowledge of the project, and with complex code bases, there is a huge potential for things to go wrong if a change is rushed, which is stress-inducing.
While developers understand that there may be circumstances where they will have to work on other people’s code, we try to avoid it. If the circumstance allows for the original team to complete the work, try your best to book the original team to make updates. When you can’t, make sure to provide ample time for your developer to get familiar with the conventions of the code base so that a rush job doesn’t end up causing several weeks of additional cleanup.
Wrong Person for the Job
Developers have unique skill sets. Some developers only work on front-end code, while others mainly work on back-end code. Some developers are very advanced while others are still learning. Asking a person to go outside of their specialty can be very stressful.
Know your team and try to find the right people to work on the right task.
Add A Parking Garage On The Roof
Developers build code-structures that function in specific ways, much like a construction crew builds buildings to function in specific ways. How a roof is constructed will be different depending on whether people are intended to walk on it, for example.
So when you want to put a parking area on top of the house that wasn’t even going to have people standing on it, you’ve introduced a big challenge. The mind of the developer immediately begins to spin due to the sheer size of the changes it will take to make the house support a parking area and all the potential vehicles you may want to park up there, and it’s really hard to keep from freaking out.
When you’re faced with introducing this kind of change request, be prepared to give your developer time to think about the problem before actually coming to talk. Email the developer that this change will need to be made and tell them to think on it for a while. Once the developer’s head settles down, they will be better able to articulate the challenges and requirements of the change request.
In the End, It’s All About Empathy
Just like working with any human, soft skills matter. Understand your developer is under a lot of pressure and is pretty much constantly afraid that their entire body of work will implode at any moment. Empathy is key, so think about how you would want to be approached if you were in a similar mindset, and act accordingly.