Your Web News in One Place

Help Webnuz

Referal links:

Sign up for GreenGeeks web hosting
September 7, 2022 04:00 pm GMT

Logical Communication (for Devs)

Disclaimer: This is an article about communication between developers, and its discussing communication in light of American culture Your mileage may vary.

As a programmer I strive to be logical. Logic, after all, is a key component of being a good software developer. In good software development, theres no room for guesses or emotional decisions only logical decisions make good software.

Because logical thinking yields such good results when developing software, it makes sense to apply it in other parts of your job. After all, it becomes almost innate after a while. Were programmers. Were always logical. Its just what we do. So, communication, documentation, testing, business analysis, design and all the other aspects of the development become logic driven. Usually, this isnt a problem, in fact, its usually a benefit.

However, part of being a good software developer (unless you work entirely for yourself) is interacting with people. Writing emails, discussing on calls, sending chat messages, or even face-to-face conversation, if youre a developer who still goes to an office with other people in it. (Your pet pomeranian who sits in your lap while you work at home doesnt count.) It can be easy to just approach job-related personal interactions like we would anything else: with logic. This can be good, but its often imperfect. Logic should be tamed, with two other attributes: tact and humility.

Ah, tact! The (seemingly) unachievable, oft-ignored aspect of communication that makes decent communicators better communicators. Lets take a common scenario: youve tested your code on dev and it works great, so you move it on into the QA environment, where its inexplicably broken. After half an hour of exasperation, you discover that one of the web services your code relies on is returning 500s in QA. Well, no wonder your changes wont work! Somebody else pushed broken code to QA! You logically concoct an email to your unfortunate coworker: You broke service such-and-such on QA. Ive tried multiple times with these parameters, and it only returns 500s. Please push a fix ASAP. This isnt unkind (we even said please!) its just logical and direct. However, theres a funny quirk of developers that makes this kind of communication less effective than it could be: We developers tend to be very personally involved in our code. Remember, code is logical, so, if someone criticizes our code, theyve effectively criticized our own ability reason logically! This can come across as something of a personal affront.

Theres really two big things to change about the message: first, take away the personal aspect. Notice that message says you broke service such-and-such on QA. That you is a problem. This seems like youre criticizing the individual, which just naturally makes us humans less receptive. A simple statement of fact is less abrasive. For instance, consider this version: Service such-and-such is broken on QA. Ive tried multiple times with these parameters, and it only returns 500s. Please push a fix ASAP. This is better, but it still comes off a bit accusatory, hence, a second revision is needed. Let me explain.

This is where the second aspect I mentioned comes in: humility. You think the problem is that someone else broke the such-and-such service on QA, but, in reality, as logical as we all think we are, theres still a possibility that we got it wrong. Humility is difficult its not innate to some of us. If its not, you may have to learn to fake it until you make it. (Wait! Dont shut this article down because I just adapted a painfully overused clich!) Its best to phrase your communications with humility, rather than an air of certainty. This does two things: one, it makes your message a little more palatable to the receiver, and two, it saves you some embarrassment if you do turn out to be wrong. Frankly, lifes just easier with a little humility.

Lets try one more revision of our message, this time applying some humility: Im having issues with service such-and-such on QA. Ive tried multiple times with these parameters, and it only returns 500s. Do those parameters look correct to you? Any thoughts on what the problem could be?

This is a much less antagonistic request, and is more likely to get a fast, helpful response than our original logical statement. The main thing weve changed is to write the message with the assumption that we could still be mistaken, and be at fault in the issue. This required a few changes. First, were removing the command at the end (Please push a fix ASAP.). If the developer investigates the issue and finds out that they were the ones who broke service such-and-such, they certainly can figure out that they need to fix it. The directive really doesnt do anything other than put them on the defensive, which really decreases the likelihood of our getting some timely help. Secondly, weve put the blame on us. Notice: Im having issues and Do those parameters look correct to you?, implying, I may have gotten the parameters wrong, which could be causing this issue. These lines put the blame back on to ourselves, and is just much easier to read as the recipient. (Go ahead try reading the original to yourself, and then the latest version we just developed. I think youll see theres a big difference in the tone, and how you feel about the message and the messenger.)

Astute readers may notice I added one more question Any thoughts on what the problem could be?. While this doesnt directly fit into our key points of humility and tact, this is a hint to get the recipient to think about the bigger problem. We dont want the developer were messaging to see only the question Do those parameters look correct to you?, check the parameters, confirm theyre correct, and stop looking into it! (After all, were pretty sure that the issue really is with the change they pushed to the such-and-such service, and that the parameters really are correct.) Hopefully, this will prompt the recipient to look a little further into why the issue is occurring, and help us fix it. This gentle nudge is still phrased as a question though remember, you want the recipient to feel consulted, not accused.

But wait!, I hear you cry. Why cant I just be logical, and respond to messages without all this overhead, and dancing around the issue?. The truth is, I believe this method of communication actually is the most logical, in that it is the quickest, most efficient way to get help from co-workers (admittedly somewhat anecdotal, but well-backed by research and the experiences of others, I think). If communicating issues to people in the direct, logical way with which we began achieved the best results, it would be the most logical, but that just doesnt seem to work with people. At the end of the day, communication is about working with people, not computers (yes, developers are people), and people are more complex, and have varying personalities that can affect the way they perceive a message a little tact and humility goes a long way that is, in my humble opinion.

What are your thoughts? Have you found purely logical messages to work the best? What about other approaches altogether?


Original Link: https://dev.to/simplegeek/logical-communication-for-devs-548n

Share this article:    Share on Facebook
View Full Article

Dev To

An online community for sharing and discovering great ideas, having debates, and making friends

More About this Source Visit Dev To