Advice to improve programmer communication skills

Question

What single piece of advice would you give to a programmer who can write decent code, but has trouble communicating relevant details of his work to colleagues and users?

Answer 1

Consider joining Toastmasters International. This is an internationally-renowned organization that helps people build public speaking and leadership skills.

I am personally working through the advanced manual on technical presentations.

Answer 2

To team up with some person which is good with people and can still program well enough to be useful part of the team.

Answer 3

Drawing flow-chart/diagram types things will help me understand a concept. I guess it might depend on what you're trying to communicate to someone, and how the best grasp a concept.

Answer 4

Eye contact and Enunciation.

It's the same skills that non-technical people need to learn to progress in life. For some reason, some programmers think they don't need to speak to people once they are in front of a computer.

Answer 5

So, there are lots of ways folks can work on being better at communicating, but at a minimum, I'd say organize your thoughts and jot them down if necessary - I do.

Answer 6

This can be tough. I would say find a way that they are good communicating and strengthen it. Don't necessarily force them to do it someone elses way. If they are good at writing formal docs or maybe making posts to a wiki then help them do that better. The idea is for them to communicate something others need to know right? Find a way so that that people get what they need reliably and it makes the programmer comfortable. It will depend on knowing the programmer though.

Answer 7

As with anything, it takes practice.

Practice explaining things (technical or otherwise) to your friends and relatives, especially children.

Apart from that you have to know your audience - what are the people you're talking to likely to want to know? what do they already know?

Answer 8

If its just you, the only advice I could give is to have even MORE interaction with your colleuges/users. All it really takes is time to be able to start communicating effectively. If you look at it from an agile perspective, you start to communicate in a mutual lingo eventually. Technical enough for you, not too technical for users.

Answer 9

There are several things you can do.

Take a communication class to start. Those can help.

The biggest thing I found to help me was to practice. I would keep trying different ways to explain something till I found a way that seems to work. It took me some time and a few mistakes but I am better than I was at it. Make eye contact and be ready to draw a lot of pictures. I realized I could explain better to people when I drew it out on a whiteboard. Having something to see helps anchor other people and gives them something to work with other than words.

And above all? Practice, Practice, Practice

Answer 10

To start with, start small. Focus on one-on-one skills. Try to get a sense of what each person values, and specialize your case / arguments to that perspective. At some level, this will be affected by the role (e.g. if you talk to the manager, making a case of saving money, time, or resources will likely help), but also by personality (e.g. carefree or a curmudgeon).

Practice too, with friends or in the mirror if need be.

Answer 11

I would advise said programmer to learn two things.

The first, terminology, for example in OOP, learn about object instances, members, fields (instance variables), methods, properties (getters/setters), superclass, subclass etc. Use these terms appropriately.

Secondly, learn design patterns. This provides a high level common language to communicate ideas about the design of software. For example, the Listener Pattern allows an object to register with another object so that the latter may notify the former about interesting events.

I would also advise that the programmer try writing their thoughts down on paper before attempting to communicate them. This helps better formulate the information the programmer wants to communicate.

Answer 12

A good MBA program will include lots of presentations, people and leadership skills! Martial Arts classes are also a good way to bring people out of their shell.

Answer 13

It depends on what, exactly, the trouble is.

For better communication of technical details with colleagues:

• Ensure the code is well documented.
• Communicate with idioms from a common language like the UML.
• Having easily accessible sample client code (test cases) helps too.
• Use some persistent storage (like a wiki) to save useful communication.

For help speaking to a group:

• Some companies provide classes that help with speaking to a group.
• Toastmasters helps with speaking to a group in general.

For help with garbled email:

• After composing the first draft of an email, don't send it immediately. If possible clear your head (do something else), and then proof-read it before sending it.

Answer 14

Breathing.

Seriously. Many people talk too quickly, or get flustered when they can't explain something the way they want to. Talking too quickly or becoming a little flustered can make your breathing shallow or erratic. Perhaps not so much as to alarm your listener, but enough to lower the amount of oxygen getting to your brain and reinforcing your sense of stress. By slowing down a little you not only give yourself more time to prepare your words, but also more time to let the listener take in what you are telling them. Thus they understand better and if necessary can ask better follow-up questions.

Answer 15

In my workplace I have found the most successful for of communication is usually written. Be it a word document or an email. When our group was first formed we would run in to communication problems and honestly personality conflicts. People's tones and inflection in their voice rubbed some the wrong way, when nothing was really intended.

To resolve this, in important information that needs to be communicated to others on the team is not sent via email. We still communicate verbally, but now it is more asking if a person if they received the email and if they had questions.

While it may seem impersonal it has made a huge difference in our workplace. Plus with email there is always a trail of communication, and you will never here "Nobody told me about that!" when something doesn't happen.

I also like the idea of a wiki of some sort, but we couldn't go that route.

Hope this helps.

Edit: Also meant to say that I found people's written skills were better than their verbal. While I know this is not always true, people at least have a chance to reread what they wrote before unleashing it on the group. So they can make sure it is makes more sense (most of the time).

Answer 16

• Practice composing your ideas clearly -- the more writing you do, the better you get at this.
• Be tactful and criticize ideas rather than criticizing people.
• Try to let go of assumptions and instead ask more questions to better discern what sort of information the person you are communicating with is looking for

Answer 17

I would ask that person to keep a laboratory notebook (my personal favorite is the Avery Dennison 43-648), bring it to every meeting, keep it nearby while developing /designing and write in it all the time.

The notebook will become a useful tool for plenty of reasons but, for practicing communication, I would advise that person to practice writing down what they need to communicate with the goal of being able to explain all the most important points in a single sheet of paper.

I find that this nicely bookmarks the communication problem: there's only so much detail that you can jam onto a single sheet before it becomes unreadable, even by the person that wrote it. With the notebook, you can also refer back to your previous thoughts, draft your thoughts several times and never worry that you're going to lose something important. It's on paper, after all.

Assuming that the face time is a fairly informal and friendly audience, this person now has a cheat sheet that they can use up at the whiteboard or can copy for the team. Diagrams can be redrawn / embellished up at the whiteboard. Key talking points are write there on the single sheet. Best of all, the audience can tell the this person has prepared for the discussion and is going to be naturally more accepting of any hiccups in the presentation. If nothing else, the audience (and the presenter, if they have trouble with public speaking) know that the meeting will only be so long: it's only a single sheet, after all!

Answer 18

In dealing with users, the one thing that programmers (and other IT professionals) often do that drives users crazy is talk down to them as if they were stupid because they don't understand our technical specialty.

They are not stupid, they are interested in some subject other than ours. (Well mostly, I admit there are some hopelessly clueless people, but really far fewer than most of us seem to think.) They know more than you do about their own technical specialty. It pays to treat others with respect.

Comtempt is shown often through word choice and tone of voice and body language. Be aware of how you project these things to others.

Understanding that non-programmers are worthy of being treated as respected colleagues is the first step. If you aren't sure if you treat non-programmers badly, ask one of them or listen to yourself the next few times you talk to users and ask yourself how you would feel if someone talked to you that way. Consider other people's perspective as well as your own. Try to use your knowledge of their specialty to help explain technical concepts. Be friendly, ask about their families to make them feel more of a connection to you. Remembering family details the next time you see them is nice too. (Many people in other fields are far more extroverted than many IT people. Unfortunately since extroverts outnumber introverts by a good bit, it is up to the introverts to learn to communicate with the extroverts not vice versa.)

Be approachable, then listen, really listen, to what they are saying. If they are talking to us on a work level, then likely there is some sort of software issue or perceived bug in the system. Even if the system is working correctly according to the spec, try to understand why the correct function is not working for their particular situation.

When trying to convince them to do something you want to do, remember that the decision maker has a different set of priorities than you do concerning the project. They don't care if the project is interesting and fun to work on or if it uses the newest and coolest technology. They care that payroll goes out on time and is correct or that customer service reps can help the customers on the phones without the system hanging up or how much is this going to cost and how will it benefit the business or the decision maker personally. Use their needs and interests to sell your ideas.

If you tend to get angry with users or take what they say as a personal affront, think before you speak, "How would I respond to that if I knew that person had just lost a spouse?" Would it make a difference in how you perceive what they just said? Often when people miscommunicate - there are other factors at work beyond the obvious. Try to give people the benefit of the doubt. (This helps me tremendously with road rage too, when someone is driving like a crazy person, I say to myself, "Maybe he is on the way to the hospital to see his dying mother." and the anger just drains out of me.)

When talking to other programmers, most of us appreciate a presentation that doesn't waste our time (most of us do always seem to have that looming deadline). However, if you are discussing why you took a particular approach, it might turn out to be helpful to say whay you didn't take an alternative approach. Sometimes that discussion will bring up factors they hadn't considered (or even that you hadn't considered) and need to consider in doing their part of the project.

Answer 19

Steps like these have shown me where my explanations lacked something:

• Write and explain the details step by step (in notepad, Word, OneNote, ...).
• Print it out, take it away from the computer.
• Read it somewhere else, on the bus, after reading something else, for example an article in a paper. Does it make sense there?
• Make notes on the print-out with questions and corrections to your own explanation.
• Rewrite the explanation.

Answer 20

My one piece of advice is to pay attention to building relationships, not just communicating technical information. A resource that helped me is "The Relationship Cure" by John Gottman. He's done decades of careful research into how people interact (which appeals to the geek in me). He talks about "bids", which are offers of relationships. This could be as simple as, "How about those Blazers?" People make tens or hundreds of bids every day. If you want a relationship with someone, how you respond to their bids is critical.

In response to a bid people typically turn towards ("Yeah, that Brandon Roy sure is a hot shooter"), turn against ("Why do you waste your time on professional sports?"), or turn away ("The next release will be ready for production Friday"). Turning towards builds relationships. Turning against inhibits them. Turning away destroys them.

What is important is the balance of your responses to other people's bids. If you generally turn toward someone's bids, you build up "relationship capital" that sustains the relationship during conflict.

Once I learned about bids I began to realize just how much of the time I turned away. I'm still not great at relationships, but at least I'm aware of my incompetence now and I think I'm slowly improving.

Such a complicated topic doesn't fit well into an SO answer. Once you're on your way to building relationships, then it helps to pay attention to how the other person can best hear your idea--stories, analogies, visuals, statistics, etc. My advice is to get started on the relationships and work on presentation later.

Answer 21

Sounds silly: Try to improve your listening skills, and after that try to improve your communication skills.

If you don't understand your colleagues or users it's impossible to help, provide solutions.
I expect in this case that language is not the barrier.

So how can we improve our listening skills?
I start an incomplete list
1. Improve your multitasking :-) take notes while listening
2. Ask questions
3. Don't assume something, ask
4. Try to get to the root problem, if there is one

More comments are welcome

Answer 22

How to Win Friends and Influence People has some good suggestions for anothe way to consider how you interact with people.

Fundamental Techniques in Handling People

1. Don't criticize, condemn, or complain.
2. Give honest and sincere appreciation.
3. Arouse in the other person an eager want.

Six Ways to Make People Like You

1. Become genuinely interested in other people.
2. Smile.
3. Remember that a man's Name is to him the sweetest and most important sound in any language.
4. Be a good listener. Encourage others to talk about themselves.
5. Talk in the terms of the other man's interest.
6. Make the other person feel important and do it sincerely.

Twelve Ways to Win People to Your Way of Thinking

1. Avoid arguments.
2. Show respect for the other person's opinions. Never tell someone they are wrong.
3. If you're wrong, admit it quickly and emphatically.
4. Begin in a friendly way.
5. Start with questions the other person will answer yes to.
6. Let the other person do the talking.
7. Let the other person feel the idea is his/hers.
8. Try honestly to see things from the other person's point of view.
9. Sympathize with the other person.
10. Appeal to noble motives.
11. Dramatize your ideas.
12. Throw down a challenge & don't talk negative when the person is absent, talk about only positive.

Be a Leader: How to Change People Without Giving Offense or Arousing Resentment

1. Begin with praise and honest appreciation.
2. Call attention to other people's mistakes indirectly.
3. Talk about your own mistakes first.
4. Ask questions instead of directly giving orders.
5. Let the other person save face.
6. Praise every improvement.
7. Give them a fine reputation to live up to.
8. Encourage them by making their faults seem easy to correct.
9. Make the other person happy about doing what you suggest.

Answer 23

When speaking remember two things: Connotation, and Intonation

Connotation A subjective cultural and/or emotional coloration in addition to the explicit or denotative meaning of any specific word or phrase in a language, i.e. emotional association with a word.

Intonation the pattern or melody of pitch changes in connected speech, esp. the pitch pattern of a sentence, which distinguishes kinds of sentences or speakers of different language cultures.

What you say, and how you say things are huge. Think about the feelings associated with words, and use them. In most cases the best thing is to make other people feel good about their interaction with them. Perhaps instead of stupid users, they're just uninformed. The english language has the advantage of having a word for everything, including subtle variations of the same thing or concept.

Next listen to how you say things, if you sound bored while talking, most likely your audiance will be bored. Now that doesn't mean you need to sound obsessed with everything you're saying, just be interested. This can go the opposite direction as well, if somebody is speaking to you they likely have a reason, so listen. You never know when it might come up again.

All of this being said, I only speak english, so I'm sure that not all of this applies to all languages.