A few facts you always wanted to know about Communication For Developers but were too shy to ask

Communication is a two-way street.

When you're a programmer, you get to make beautiful, complicated code from scratch. In addition to demanding preparation and countless hours of practice, it also involves the elements of artistic expression. The way you join many components is entirely your own. With so much of yourself in your work, it might be irritating when someone says, " I don't understand what it does, or I don't see why I would ever use this." You can't force other people to see things your way, but you can train yourself to explain your work in terms others can understand. Since communication is a two-way street, we should focus on both sides. When everything is in place, your target audience will be able to follow along with your work, become invested in it, and recognize its value. And maybe they'll even be excited about it. Who knows?

So bring your desire to look at your work with new eyes and to be empathetic to voices that go against your views. The effort required may be high, but the benefits are far greater than the trouble.

Why can't THEY get it?

It would be much simpler to have conversations if everyone was just like you. Explaining terms like "sprint" and "backlog" would be completely unnecessary because they are understood by all. All of your options would be immediately clear to everyone around you, and lengthy discussions would be cut short. To be sure, not everyone is the same or even similar . These differences between us make the world a more interesting and vibrant place to live in, but they also serve to divide us. As a developer, you need to grasp the finer points of a wide range of technologies, but your expertise goes much beyond that. Long hours of sitting and pondering will inevitably affect you and your health. And yet, desk workers at our made-up hotel would have to be on their feet and interact with dozens of guests every single day.

There is a powerful incentive to maintain the status quo because of the negative effects that change has on people's comfort levels. Your efforts typically hold the promise of change, but they also mean effort in adjusting to this change. As a result, you have a battle right in front of you from the start. Just saying your project is great won't cut it. Excellence must have advantages above and beyond the inconveniences it creates. The viewpoints of programmers are also the results of their education. We are driven to write efficient, dependable code.

. But look at it from a different point of view: the clerk is in front of a customer, and a five-second delay occurs because you implemented a database row locking routine to avoid duplicates. As a result, the cashier may prefer to spend five minutes more, when the client isn't looking, and manually rectify duplicates And what do you say to that? Sometimes, believe it or not, the uglier code is needed. The final point is the usage. Even if you have a UX designer (which isn't always the case, of course), your development choices will bubble up to affect whether or not the desk clerk enjoys using your system daily.

The ups and downs of collective decision-making

There is a lot of advice out there that says you'll be happier and more fulfilled if you hang around with people who share your values. The people united will never be defeated, therefore put all your wood behind one arrow. Also, I'm the last person to disagree, but I think it's important to point out that there are some drawbacks to having a unified front, especially in terms of communication.

Let's pretend you're on a team that has consistently met or beaten its goals, both in terms of timeliness and cost-effectiveness. Therefore, you may rest easy knowing that your team will be designing software for a hotel. You've optimized your process by honing some abilities while discarding others, so you can make use of some of your previous tools and knowledge. Then, an outsider recommends a framework that has already been tested and rejected by your team for past projects; after all, if it didn't work before, why would it work now? It's natural for you to counterattack. When someone else offers an idea, you resist it even more vehemently. It turns into a battle, not of skill but ego . An insider coming out to say "hey, see, maybe they're right" becomes progressively riskier in such a setting. Now, to be fair, your group was recruited because of your expertise in streamlining processes. It's also tough to judge whether an outside tip is helpful or just a distraction. However, there are actions you may take to maintain open channels of communication.

To protect our pride during a dispute, we typically reduce the other party to a caricature. We're all a combination of brilliance and idiocy, though. BUT I insist: take a look at their accomplishments; they did happen! Why not take advantage of their experience, insights, and knowledge even if they are wrong about your project overall? Get feedback from people who have nothing to do with the project. Present both perspectives fairly. The goal is not to win them around to your way of thinking, but rather to pick their brains. If the questions they ask and the language they use help you understand both sides better, maybe you shouldn't even tell them whose side you're on. Once you've done that, return to the table and discuss the project as a whole, not simply your team's role within it. It's possible that your justifications for doing things a specific way don't matter all that much in the big picture. Groupthink can be prevented by emphasizing variety and encouraging openness. Looking beyond your group gives you access to diverse talents, viewpoints, and ideas , while being open to them and altering your mind, makes dialogue fruitful.

How to talk about time and cost

There are some jobs, where what you see is what you get. Retail workers, childcare specialists, baristas, these all have paperwork, certainly. Eight hours on the job is usually eight hours on the job. As a developer, you're well aware that this is not your typical day job. Regardless of how well defined and consistent a project's requirements may be. Moreover, we all know that is not the case most of the time. Tools, frameworks, APIs, and so on could develop flaws. And it's all very time-consuming.

But now, try to see it from the opposite side. Your client approaches you with a requirement and a financial plan in mind. Your value to them depends on how successfully you satisfy that requirement while staying within their price range. They will then apply your efforts to meet the requirements of business partners, employees, and customers within their allocated budgets. They aren't interested in hearing about how inefficient your tools are. This only matters if you can provide what they need without breaking the bank. This creates tension. They demand assurances that are, unfortunately, not always possible to provide.

Here are some ways to get the word out that will let them plan without driving you crazy. Your client's level of familiarity with working with developers is an important factor to take into account. A person with experience will be aware that estimations are subject to change and understand why this occurs. If not, then they need to be taught. Identify some of the "known unknowns," or potential roadblocks, to success. This project, for instance, requires connectivity to the system maintained by your collaborator. How well prepared their system is for integration is therefore crucial. However, it's important to not overlook the big picture. Don't go into detail; just give them the big picture. Unless, of course, they insist on getting even more. When you've spent dozens of hours trying to fix a problem, the temptation to go into detail is understandable. This supplementary material, though, may divert attention away from what you want to say. Avoid using absolutes and instead focus on the likelihood of something happening. To illustrate, you could say something like, "I'm assuming there's a 78% probability that the integration will go successfully." Then they will be better able to control the risks they face. To be effective in one's role as a project manager, one must be adept at estimating.

Relying on commonly understood terminology

“The Event Handler” and “While loop”. You, the Developer, undoubtedly know what these terms represent in their specific contexts. Such expressions allow for the rapid communication of thoughts. They evoke strong emotions, too. Now give those expressions a shot: Bare lie, Biarritz, and Mashie niblick . You have no idea? Professional golf players do. And they also have strong opinions about them.

Such terms are called jargon, and these are extreme examples, but even mild ones can create huge communication gaps. Consider those words, event, loop, and handler. They have other meanings outside of development. So not only might your listeners get no meaning from these terms, they might get the wrong meaning. The first step of the solution is to recognize when you're using words that your audience doesn't understand. That can be hard because you might use the word "event" 20 times a week and never once think of the party. But here are three tricks that I've found helpful. Get a feel for the listener's experience level early in the relationship, and look for cues from what they say and the correspondence they send you. Ask open-ended questions that let them show what they know. For example, you might ask what development methodologies they know and like. That's better than asking a yes-or-no question like, "do you know what event handler means?" Which can sound insulting.

Watch carefully for signs of misunderstanding. Blank looks, questions that don't get a response, or nonsensical responses. These can all be signs of a communication gap . And when that happens, don't just repeat the jargon use words that describe what you mean. This takes practice, but you can do that practice in your head. Go through your materials and pick out potential problem words and then try to think of quick and efficient ways to explain them in everyday language. There's a bonus to that as well. Doing so clarifies your thinking in addition to improving your communication with others.

I hope you have enjoyed part one of our short series about communication skills for developers.

Part 2, for your immense pleasure, coming up soon!