As techies we tend to think that communication is someone else’s problem—just tell me what to code and get out of the way. Maybe in some world that will work out, but in this one the best way to ensure that your hard work will turn into a large black smoking hole in the ground is to think of communications as the manager’s problem. Part of your responsibility when you are
a member of a software project is to help with the driving and the only way you can do that is to get your ideas and opinions across to others along with really listening to them. If you ignore that responsibility then you shouldn’t be surprised if your project ends up wrapped around a tree.
With that happy picture firmly in mind, let me suggest five ways that you might ease the journey of your brilliant thoughts out to the rest of your team—and perhaps insure that other people’s ideas occasionally find their way to you.
5) Optimize
I am often called upon to speed up code. Over the years I have revved up printer drivers, database software and, most recently, web services. And I have learned that everyone loves a good optimization project. Get involved in one and you will be the most popular guy (or gal) on the hallway. I’ve had people stop me in on my way to lunch to explain how I can save TWELVE, many even THIRTEEN bytes by completely rewriting the caching system. Or make the code run 0.000353 milliseconds faster by going around the OS. Lately they want me to write my own (presumably faster) web services stack.So why is it that we are so enthusiastic about writing efficient code and so lazy about writing efficient English? Why do we have specifications that could be written up in 20 pages struggling to escape from 200 page tomes? Why do we use big words:
"Fred, could you memorialize the stakeholders' inputs?""Fred, could you write down the customer requirements?"Well here is some good news: if you consistently use small, simple words for the concepts that fit well into small, simple words, you will rapidly gain a reputation as an articulate person. And if you manage to boil that 200 page document down to an email you will be beloved by the people who hate reading 200 page documents. Which is everyone.
4) Email is only good for the things that email is good for
Another way that we sometimes communicate badly is by overusing email. Email has a subtle attraction for the mostly introverted folks that make up software projects. With email, I can send this message out and I don’t have to actually interact the other person. I send an email to Fred and with luck he won’t even see it before I’ve gone home for the day. That way I don’t really have to deal with old Fred, who makes me nervous anyway.The trouble with email is that it is a very narrow communications pipe. Think about it: an email is a static bit of text that you write and send out. The text is all that goes out. Left behind is your facial expression – the big smile that telegraphs that this is a JOKE – and your body language – the tapping foot that says NOW – as well the crack in your voice that says HELP ME! Email also disconnects you from your correspondent in time: you send the message and your recipient will read it some time, perhaps much, later.
Instant messaging is much better for getting across a subtle, confusing or sensitive point. You still can’t see the person at the other end but at least you can interact with him or her in real time. Next in line of immediacy is the phone—I still can’t see you but not only can we interact but I can hear your voice, know if you are laughing or crying, angry or bored. And then there is the oldest person to person technology of all — commonly referred to as ‘talking’ —it involves getting up off your butt and going to
see Fred.
So, if you need to say that you will attend the regularly scheduled meeting, send an email. Got a 200 page spec? Email it. And if you need to leave a paper (or rather electron) trail, then nothing beats email. But if you have something delicate to say, if you need to ask a question that will require a subtle answer, if you need to negotiate anything, then email should be your last choice. Like most things in life, the choice of mediums for your message is a trade-off. You can choose the disconnected but narrow pipe of email. Or you can go for the high bandwidth of an in-person chat at the cost of breaking up your afternoon.
Think about that the next time your fire up Outlook.
3) Don’t clog the channel
One of my current coworkers is a car enthusiast. Whenever the conversation turns to the subject of automobiles you can see him just struggling to hold back a tidal wave of facts and opinions and advice. Sometimes he even manages to keep his enthusiasm in check for up to a full minute before it all comes bursting out. We geeks have a reputation for being shy and reserved, but for most of us our introverted shell can barely contain a roiling, bubbling enthusiasm for AJAX or web services or micro formats whatever the technology or technique of the day is. Anyone who manages to pierce that outer shell had better be wearing eye protection because all of that enthusiasm is liable to come gushing out, broken water main style.Now don’t get me wrong, I love this kind of enthusiasm. In fact I think that that it is responsible for much of the progress of human civilization. The problem with all of this bubbling enthusiasm is that it tends to have a denial of service kind of effect on other conversations. If you have a tendency towards this kind of verbal explosion, do try to keep yourself in check. At least make sure other people and other subjects can get a word in edgewise. Now speaking of that telescope that I’m building…
2) Make sure you know what you agree on
Henry Kissinger, former US Secretary of State and erstwhile college professor once said that academic disputes were so vicious ”… because the stakes are so small.” I’m not sure if the same is true of software projects, but having some severe nastiness break out on a development project is not really all that unusual.One of the best ways to prevent a difference of opinion from melting down into a team shattering nuclear accident is to step back and note the things that everyone agrees on. If the argument is over how exactly to optimize that pesky algorithm, see if you can’t get all sides to realize that everyone does really want it to run faster or smaller. If it is one of those “who will do what” kind of disputes, try to get everyone to agree on exactly what needs to be done.
The idea is not to paper over differences but rather to focus all of the attention on the actual difference. When a disagreement does breaks out, people, software folks included, tend to stop listening, to fortify their positions and proceed on the basis that the opposing folks are morons. Since it turns out that morons are actually less common than you might think, it helps to probe around and see where the boundaries of the disagreement are. More times than not you will discover that the argument is over less than you thought. But no matter if your disagreement is over the big picture or the pixels, it is your job to make sure that the argument is as productive as possible. And that means not wasting time yelling about things that no one disputes.
1) Remember that everyone is different
The civilians lump us all together: to the outside would we are all geeks. The thing that the non-geek world misses is is how many different kind of geeks there are. Yes we all share a love of technology, of making things work, of just plain wanting to find out. But there are almost as many ways of being a geek as there are geeks. I’m as much a geek as anyone who ever owned a slide rule but I am the kind of geek that tends to read a technical book from the middle out towards either end. I am a big picture, let me get the outline before you bore me with the details kind of guy.By contrast, I have a coworker, a certifiable geek who walks around with more technology on his belt than most people will own in a lifetime, who I am sure reads books by starting with the copyright statement and finishing with the price in Canadian dollars on the back cover. We are both geeks, both software engineers, but we have two entirely different operating systems running between our ears.
I have learned that I cannot explain things to my friend the way I need them explained to me. He needs things put to him in enormous and exacting detail, right from the start. Conversely, when he tries to explain things to me I have to keep reminding
him that he needs to give me a feeling for the big picture before diving into the details of subsection 1.1.1.A.i.a.
The point is not that I am some kind of brilliant holistic thinker (though I’m willing to entertain the idea) nor is it that my friend is detail obsessed (though he is, God bless him). The point is that you need to go about explaining things differently to me than to my buddy. When you are talking to him you need to do it in a way that works for him. And whatever that is, it probably won’t work me me.
So there you have it, five ways you can make your project run a little smoother by taking advantage of all of the brainpower. Cause that is what communication is all about.
Russ Olsen is a software architect and writer whose work has been featured on JavaLobby, O’Reilly’s On Java, and the Java Developer Journal website. He writes the Technology As If People Matter blog and is the author of Design Patterns in Ruby which will be published by Addison-Wesley in December, 2007.
(original link - http://geeketiquette.com/archives/2007/09/24/five-ways-communication-skills-can-help-your-software-project/)
No comments:
Post a Comment