Tech is the Future, But How to Learn It? Talking to Developers is a Good Start

It seems that marketers who want to learn the True Digital (secrets of servers, APIs, SDKs and other software artefacts) have no other way than to befriend developers. Although there are no shortcuts here – you need to build and maintain the relationship – I've compiled a few hints on how to lay the foundation for bonding with software engineers. 

And if you’re friends, your tech skill set will grow tenfold before you know it.

Developers’ natural habitat

On the face of it engineers seem like a specific kind. A kind that allegedly needs special treatment, some even say a grumpy kind. I wholeheartedly disagree with this claim. I don't own a master's in sociology or psychology, but I know a thing or two about this. I used to be a software engineer and I've put on a marketer’s hat too. More so, today I live by selling a software platform that helps marketers and devs bury the hatchet. 

So what have I learned about making marketer-dev interactions easier? From the marketer’s point of view, it’s about understanding developers’ natural habitat —  an uncharted territory for people who are starting their careers. 

That’s why I compiled a map of developers’ routines and desires and I hope it’s going to help you navigate them, ultimately leading to a thriving relationship. 

It’s not as easy as it sounds. As developers admit themselves they have a reputation for saying “no”, for debating pedantic details, and thinking we know how to do everyone’s job better than they can. But if you get this right, developers will become your main source of knowledge — as we can learn from Kate, in her story about a digital marketer turned IT product manager.

So, let’s start by addressing one of the most popular obstacles on the way to befriending developers.

Why are developers often grumpy?

The root cause of grumpy reputation of developers needs a longer explanation. If you want to understand it in detail, you should read this long-form by Nicholas (just see how many devs agreed with his claim in the comment section). If you’re short of time, I’ll try to summarize this phenomenon in 8 points:

1. Developers are the translators of your ideas into reality. They make it work. They make it work fast. They make it robust and reliable to your users. Software engineers are the oil of the digital economy.
2. And they are well-paid for this, a unique skill of combining creativity and logical thinking.
3. But they’re often treated by other departments like reproductive builders, not like creators.
4. Calling them builders is unfair. Staying in the construction industry metaphor, developers are actually the architects not builders. Their job is not to physically raise the building (or buildings) but to collect requirements. Requirements in the form of code.
5. Now, imagine the design phase of something as complex as Sydney Opera or Spodek in Katowice but with a slight difference — the stakeholders can change almost everything while the building is long under construction. Despite that developers can still ensure that the building will be used and won’t fall down.
   
6. But where are the actual builders? They are fully automated. Developers have been smart enough to create tools like compilers, continuous deployment servers, or servers in the cloud which make the construction process fast and more important foreseeable.
7. If you ever wondered why developers can’t estimate how long a building phase is going to take, you now see that what you really ask is the architectural phase. You asking how long it is going to take to write software is like saying to a building contractor how long it will take to design every single detail of a city block including gathering all the requirements. 
8. And the actual building part is easy. Once you have the requirements written down, it can be estimated with a second accuracy.

So, software development is actually research disguised as engineering

You should never look at developers as the short-order cooks of the industry. As Nicolas puts it “software engineers don’t get into coding because they want someone to tell them what to do, they get into it because they discovered they could create something useful. Every single software engineer fell in love with coding because she made a small, useful program early on and was hooked.”

Once you grasp this and change your approach towards developers, you’re on the way to be liked by them. 

But getting along with developers is not only a mindset thing. There’s something more practical you can do to get a true developer friend.

Listen and let them ship

The knowledge that developers affect people’s lives is the most powerful driver for developers. Whether it’s an internal script helping marketing teams achieve their goals or a full-blown back-end serving billions transactions everyday, it’s the code working “on production” that makes developers come to the office every day.

Developers love hard work. They can sit for hours in front of the keyboard solving peoples’ problems — especially if the time for a task they estimated is running short (and boy.. they do underestimate, but that’s something for a separate article).

What they can’t stand is change-with-the-wind directives and not shipping.

Developers don’t ship when interrupted. As Nicholas says it occurs when:

• The request is coming late during development and there’s not enough time to fit it in before the deadline.
• The request invalidates one or more assumptions that were made early on in the process to get the project moving.
• The request is a reversal of previous requirements.
• The request otherwise increases the amount of work that has to get done before the deadline.

With this in mind, here is what you can do to let them ship seamlessly:

• Understand engineering constraints early. 
• Be complete with your requirements (these first two is something we want to teach you here in the 200 OK).
• Work extremely closely with an engineer.
• Help them understand how final the design is at any given stage — admit when you’re not sure about something and that you want to test something.
• Be nice — (not only in this case) people often forget about it while analysis commenced by Google found that this is a key to good team work.

All in all, programmers don’t get grumpy without a reason. It’s not that they hate hard work or long hours; they hate when it doesn’t pay off (and I’m not talking money here). So when you let them do their job, they turn less grumpy and become more helpful.