The Five Developer Love Languages
Discover your dev team’s love languages and reduce workflow friction.
When I started my very first job as a QA engineer, I was incredibly intimidated by the developers I worked with. Not only did they have years of experience under their belts that I — a recent graduate of an 11-week coding bootcamp — certainly did not have, but they all seemed to have such interesting personalities and quirks. It didn’t take me long, however, to realize that devs may seem like a different breed of human altogether, but they’re actually just normal people doing pretty complex and complicated jobs. They are the misunderstood misfits of software companies.
…devs may seem like a different breed of human altogether, but they’re actually just normal people doing pretty complex and complicated jobs.
As I gained experience working with programmers, I began noticing that many of the conflicts and issues they had with those in other departments seemed to stem from a few simple needs of theirs that were very regularly overlooked. Non-technical folk sometimes act under the assumption that they understand the mind of a dev, and in some cases that is far from the truth. I started formulating what I refer to as ‘The Five Developer Love Languages’ in an attempt to articulate these needs and help people who regularly work with programmers understand their point of view. These five love languages have helped me in my interactions with the engineers I work with, and have made me love my job even more.
Before I present these Developer Love Languages, I offer a small disclaimer. Not all devs are created equal, and some of these may not be applicable to every engineer. I don’t want to suggest that putting engineers (or any group of people, for that matter) into super generalized categories is ever a good idea. In my experience, however, these have been some of the biggest sources of miscommunication and misunderstanding between programmers and those they work with.
The Five Developer Love Languages
1. Do Not Disturb
Most engineers would agree that their best friend — especially in an open office layout — is a good pair of headphones. Not only are they good for noise cancellation, they send a very clear visual signal to those around them: “I’m in the zone. Don’t bother me.” Though it seems like most people who work with developers should have a clear understanding of this love language, it is often ignored or forgotten entirely.
So an engineer sits at their desk, eyes focused on lines of code, brain fully invested in solving a complex programming puzzle, and they get startled by a rough tap on the shoulder or a wave over the top of their monitor. Begrudgingly they break their concentration and push their headphones down over their shoulders, only to be greeted by some form of “Hey, y’know that thing you’re working on? Is it going to be done soon?” It seems like a small and harmless breach of etiquette, but to a dev buried in Problem Solving Land it can be detrimental. The person who asked the simple question goes about their merry day once they’ve received a satisfactory answer, but the engineer must attempt to reassemble the puzzle pieces of code they were working on, and that can sometimes be complicated. Coding isn’t easy; respect a developer’s time and talents and give them the option to check out of outside distractions in non-emergency situations.
2. Explain Yourself
Developers are like skilled surgeons — diagnosing problems, working with delicate precision, and keeping an active eye on the health and pulse of the project they’re working on. One of the greatest ways to support an engineer is by helping them get to the root of an issue. In a role like Product, Support, or QA, it becomes easy to find an issue or fail a test, then simply throw the problem over the fence to a developer.
“Hey Sarah, the button on the billing page is broken.”
That’s all they get.
It’s the equivalent of going into a doctor when you’re sick and only telling them that you “don’t feel well.” They can’t give a timely and proper diagnosis and work on a remedy if they aren’t clear on what the problem is to begin with.
In order to be more helpful in assisting engineers, you’ve got to become a detective. Learn about some basic tools developers themselves use to look under the hood of a web or mobile app; take some basic programming classes so you can better understand the code structure they’re working with. You can even ask a developer to teach you if they’ve got some available time (see ‘Be Teachable’). Once you’ve got a fundamental knowledge of the tools to use, give as much information as you can to an engineer when reporting or debugging an issue. Providing detailed documentation about things like network responses, console messages, direct URLs, API responses, and detailed steps to replicate an issue will not only help them write up a fix quicker, they’ll be grateful you were willing to dig around to find the cause of the bleeding.
3. Bring Donuts
I once worked with a developer who would get grouchy with me a lot in the afternoon, and I began to assume that his patience for me simply wore off as the day progressed. Once over lunch I mentioned this to a fellow QA engineer who had worked previously with this particular developer. She chuckled, waved her hand nonchalantly and said, “Oh, just bring him a Snickers next time and he’ll be fine.” Turns out the engineer’s attitude had nothing to do with me, and everything to do with the fact that he tended to get “hangry” in the late afternoon. If he seemed irritated with me or with the work he was doing, I’d pop a snack or a can of Mountain Dew on his desk and he’d perk right up. Seems silly, but it regularly helped relieve tension and provided a little comic relief to our interactions.
I don’t say this to imply that everyone should cater (literally) to developers to get on their good side, but sometimes a sugar-filled peace offering is an easy way to break the ice and ease tensions. Generally once every four to six weeks I’ll stop at a local bakery and pick up a couple dozen donuts for our tech team, just to show my appreciation for them. It’s a small gesture but one that can have big impact on team morale. Plus, who doesn’t like donuts??
4. Loosen Up
Though programmers forever have been stereotyped as introverted and anti-social, most of them actually are fairly outgoing and have fun and interesting hobbies. I’ve worked with developers who are athletes, acrobats, carpenters, metalworkers, actors, pilots, beer brewers, mountain climbers, and practically everything in between. Chatting with them about their hobbies — or even participating with them — can greatly increase the camaraderie and rapport you have together. Something as simple as playing a favorite board game over lunch can make a world of difference.
A note here about organizing social events with developers: try to steer clear of what many engineers refer to as “mandatory fun.” Many times engineers avoid large and lengthy team activities or retreats because it takes them away from their work. That may on the surface sound like an unhealthy “workaholic” mindset, but as mentioned above it’s more about being able to stay laser-focused on what they’re trying to build or fix. They’re not anti-social; they just want to be social when it works for them.
5. Be Teachable
In the years I’ve worked with developers, I’ve never had a single one show irritation or frustration when I’ve asked them to teach me something. In general — as long as they aren’t drowning in work — programmers are eager to explain how things work and pass along valuable information to coworkers. Those who work closely with programmers have a wealth of knowledge available to them, and not enough of them take advantage of that.
If you really want to work better with engineers, dip your toe into the world of code. You don’t have to become a programmer yourself, but learning the basics will help you understand how complex coding can be and why issues that may seem simple to fix are actually quite complicated and time-consuming sometimes. Learning from an engineer isn’t one-sided either; while you’re learning a new skill, the developer is learning how to teach. It benefits both of you, and chances are they’ll be happy you asked them for help.
It’s important as we build tools and products that benefit our customers we’re also thinking about how best to interact and communicate with our co-workers. Being more conscious of these things can increase morale and camaraderie in the workplace, reduce friction, and ensure that everyone feels understood and appreciated.
This was originally written for Tech Lady.
