The Most Surprising Skill You Need To Have As A Developer

The stereotypical developer is someone who sits in their basement with headphones on coding away all alone. Developers are supposed to be anti-social nerds. But, since becoming a developer, I’ve been surprised over and over again to learn that one of the most important skills a good developer needs to have is COMMUNICATION!

Code == Communication

I interviewed a few people last weekend who mentioned they were going through Khan Academy to fill in their gaps in knowledge in math. They wanted a Khan-Academy-like resource for learning to code – something where you can start, the tool can evaluate you, and tell you what to learn next to level up.

While that kind of tool would be very useful, coding is a lot more of an art than a straight-forward math problem. Code is never black and white. There are infinite ways to do things.

So the best code base is one that someone else can read (which is not something that can be easily measured by a Khan-academy-like algorithm). That is why, as humans, we created very verbose programming languages and object-oriented programming.

As the saying goes, “honey-badger don’t care”.

honey badger dont care

The computer doesn’t care if you write your code in 1s and 0s. In fact, that will probably run a lot faster. It also doesn’t care if your functions are super long or if all your variables are named x or y or z. The real reason we have human-readable computer languages is because our code is written for other humans to read.

If you’re working somewhere, and when you leave, nobody can read your code, it doesn’t matter how amazing your logic was when you wrote that code. Someone will have to go in and re-write everything.

Alway Be Selling

Besides writing clear code, developers are usually very integrated with other parts of the business (at least in good businesses). For example, as an iOS developer, I interact with product managers and designers on a daily basis. I would also love to ideally interact with marketing, customer service, and actual users of the product.

A feature that product wants might not be that easy to build, so you have to communicate the challenges to the product manager in a way that she would understand. To do this, you have to understand the bigger picture. How does this feature fit into the bigger goal of the whole product?

Similarly, a designer might design something that doesn’t make sense for the platform you’re building on (e.g. a web designer designing for iOS) or does not conform to other parts of the project. You have to be able to communicate that effectively. At my job, it’s pretty much a rule that as soon as you pick up a new feature or bug, the first thing you should do is talk to the product manager and / or designer.

And if the solution in the feature or bug doesn’t make sense, you have to communicate your concerns. Sure you can code it, but is that really the best solution?

If you’re writing really good code that communicates well, you’ll be able to notice the features or designs that don’t fit well into your application right away. After all, who wants to write yet another if statement for a use-case that is very unlikely to happen?

Having lot’s of custom use-cases makes the code very unreadable, and will likely confuse the user (do you really need 3 action buttons on a screen vs the usual two?). If there are all those use-cases, is there a whole other solution you can implement that can communicate that in a better way (e.g. animations instead of another text box)? If you can communicate that well to all the people involved in the product decisions, your end-product will be much better as a result.

Developers, how do you use communication to make your product better?

Enjoy the article? Join over 14,500+ Swift developers and enthusiasts who get my weekly updates.

  • Matt Luedke

    Cool post! As a developer too I agree, and also would add– this is going to sound weird at first I think– that communication with “yourself in the future” is important. What I mean is that I write code that I have to come back to way, way later… and unless I took good “lab notes,” I might end up going through the same decision processes again. I keep a dated Google Doc with bookmarks for each dev decision I make, so when I encounter that problem again I can have a precedent..

    • Totally makes sense! My future self (even a few days later) sometimes has no idea how I did something. Actually, that’s why I blog about implementing different feature details – so I can google it when I have to do it next time!

      • Brian Douglas

        I plan to do that myself, plus if you share here on your blog then people like me will learn from your mistakes…thats sounds harsh but hopefully its not read that way.