Know What You Want to Say
Plan what you want to say. Write an outline. Then ask yourself, “Does this get across whatever I’m trying to say?” Refine it until it does.
Know Your Audience
You’re communicating only if you’re conveying information. To do that, you need to understand the needs, interests, and capabilities of your audience.
Form a string mental picture of your audience. The acrostic WISDOM, show below, may help.
What do you want them to learn?
What is their interest in what you’ve got to say?
How sophisticated are they?
How much detail do they want?
Whom do you want to own the information?
How can you motivate them to listen to you?
Choose Your Moment
As part of understanding what your audience needs to hear, you need to work out what their priorities are. Make what you’re saying relevant in time, as well as in content. Sometimes all it takes is the simple question “Is this a good time to talk about…?”
Choose a Style
Adjust the style of your delivery to suit your audience. Some people want a formal “just the facts” briefing. Others like a long, wide-ranging chat before getting down to business. When it comes to written documents, some like to receive large bound reports, while others expect a simple memo or e-mail. If in doubt, ask. Remember, that kind of feedback is a form of communication, too.
Make it Look Good
Your ideas are important. They deserve a good-looking vehicle to convey them to your audience.
Involve Your Audience
We often find that the documents we produced end up being less important than the process we go through to produce them. If possible, involve your readers with early drafts of your document. Get their feedback, and pick their brains. You’ll build a good working relationship, and you’ll probably produce a better document in the process.
Be a Listener
There’s one technique that you must use if you want people to listen to you: listen to them.-if you don’t listen to them, they won’t listen to you.
Encourage people to talk by asking questions, or have them summarize what you tell them. Turn the meeting into a dialog, and you’ll make your point more effectively. Who knows, you might even learn something.
Get Back to People
If you ask someone a question, you feel they’re impolite if they don’t respond. But how often do you fail to get back to people when they send you an e-mail or a memo asking for information or requesting some action? Always respond to e-mails and voice mails, even if the response is simply “I’ll get back to you later.” Keeping people informed makes them far more forgiving of the occasional slip, and makes them feel that you haven’t forgotten them.
It’s Both What You Say and the Way You say It
E-Mail Communication Tips
Your Knowledge Portfolio
An investment in knowledge always pays the best interest ——Benjamin Franklin
Your knowledge and experience are your most important professional assets.
Unfortunately, they’re expiring assets. Your knowledge becomes out of date as new techniques, languages, and environments are developed. Changing market forces may render your experience obsolete or irrelevant. Given the speed at which Web-years fly by, this can happen pretty quickly.
We like to think of all the facts programmers know about computing, the application domains they word in, and all their experience as their Knowledge Portfolios.
Building Your Portfolio
Invest Regularly in Your Knowledge Portfolio
Here are a few suggestions.
It done’t matter whether you ever use any of these technologies on a project, or even whether you put them on your resume. The process of learning will expand your thinking, opening you to new possibilities and new ways of doing things.
Opportunities for Learning
….and somebody asks you a question. You don’t have the faintest idea what the answer is, and freely admit as much.
Don’t let it stop there. Take it as a personal challenge to find the answer. Ask a guru. Search the Web. Go to the library.
If you can’t find the answer yourself, find out who can. Don’t let it rest.
The last important point is to think critically about what you read and hear. You need to ensure that the knowledge in your portfolio is accurate and unswayed by either vendor or media hype.
Critically Analyze What You Read and Hear
Care and Cultivation of Gurus
Finally, please be sure to thank anyone who responds to you. And if you see people asking questions you can answer, play your part and participate.
As Ed Yourdon described in an article in IEEE Software, you can discipline yourself to write software that’s good enough-good enough for your users, for future maintainers, for your own peace of mind.
Before we go any further, we need to qualify what we’re about to say. The phrase “good enough” does not imply sloppy or poorly produced code. All systems must meet their user’s requirements to be successful. We’re simply advocating that users be given an opportunity to participate in the process of deciding when what you’ve produced is good enough.
Involve Your Users in the Trade-Off
The scope and quality of the system you produce should be specified as part of that system’s requirements.
Make Quality a Requirements Issue
Often you’ll be in situations where trade-offs are involved. Surprisingly, many users would rather use software with some rough edges today than wait a year for the multimedia version. Many IT departments withe tight budgets would agree. Great software today is often preferable to perfect software tomorrow. If you give your users something to play with early, their feedback will often lead you to a better eventual solution.
Know When to Stop
In some ways, programming is like painting. You start with a blank canvas and certain basic raw materials. You use a combination of science, art, and craft to determine what to do with them. You sketch out an overall shape, paint the underlying environment, then fill in the details. You constantly step back with a critical eye to view what you’ve done. Every now and then you’ll throw a canvas away and start again.
But artists will tell you that all the hard work is ruined if you don’t know when to stop. If you add layer upon layer, detail over detail, the painting becomes lost in the paint.
Don’t spoil a perfectly good program by over-embellishment and over-refinement. Move on, and let your code stand in its own right for a while. It may not be perfect. Don’t worry: it could never be perfect.