-
What I'm Doing
-
My GTD Tool of Choice - Try it!
-
Vote for Topics
-
Recently Written
- My Son Teaches Me about Professional Communication
- How I Use Evernote
- Thing to Remember When Your Kids Are Driving You Frickin’ Insane
- I Have a Ton of Beta Invitations - Want One?
- The Secret to Mastering the iPhone Keyboard
- Parents: You are Their Best Friend
- Web Warrior Tools - Get Your Smart On
- Productivity vs. Social Media
- Friday Fun: Flip Video
- Brand New Site by Cranking Widgets
-
Categories
-
Archives
Just about anybody that works in medium-to-large size company has probably experienced the dreaded IT/Help Desk guy. You know the one I mean - the poorly-dressed, over-confident, slightly smelly guy who knows how to get your deleted email back or maybe get rid of those annoying pop-up windows. Well, if you think that guy is bad, you’ve clearly never had to deal with a programmer…
Before we begin, let me make something clear: this post will be full of stereotypes and generalizations. Not every programmer you encounter will be this way or require the sort of interaction I’m going to describe - but many, many of them will. So I don’t want to get a huge backlash from the “normal” programmers out there, because they know that I’m at least somewhat right about this. Mmkay? Mmkay. Now, a hypothetical situation for you:
You’re hard at work pumping out today’s TPS report when suddenly the TPS report generator (developed in-house by Fred) throws up a horribly cryptic error. You do your best to decipher it, but you’re just not quite sure what an “Unhandled Exception” is or what to do about it. At this point, you have an important decision to make: You can either try to figure out the problem yourself (assuming it’s a situation where such a thing is possible), or you can go find Fred in the next room. What do you do?
Let me make this easy: Always try to solve the problem yourself first. Because I promise you, Fred is going to ask you what you tried to do to fix it when you walk over to visit him (and your answer will directly affect the degree to which he helps you). If all you can say is “Fred, the TPS report generator is broken”, you’ve just shot yourself in the foot.
Now let’s assume that the breakage is something that’s impossible for the end user to diagnose (for example, the application errors out before it even completely starts), or that you’ve done your best to try to resolve the issue yourself. Obviously, you’re going to need to involve Fred. Your success in dealing with Fred quite literally depends on your understanding of 3 truths (incidentally, these are true when dealing with just about anybody, not just the quirky types):
- Don’t Demand Anything - Unless Fred reports directly to you, you’re not going to get anywhere if you crash into his Star-Wars-laden cubicle with guns drawn. The second you start getting pushy with old Fred, the second he’ll “suddenly realize” that your problem is going to take 2-3 days to resolve. So, in short, be nice to Fred and let him steer the conversation. After all, he knows how the system works and you need his help - if anything, bring an extra Mountain Dew along with you to help grease the wheels.
- Don’t Expect to be Coddled - Fred probably isn’t going to hold your hand. He’ll either fix the problem for you or give you some possible fixes that you should try out first. If he goes for the latter, your best bet here is to write it down. There’s nothing that will annoy him more than you coming back 2 minutes later asking “What was I supposed to click again?”. If it’s a multi-step solution, jotting it down will further ensure you execute it correct (and you’re likely to impress Fred in the process). If you can’t follow instructions, expect resolution of your problem to come much slower than if you had. That actually segues nicely into the final point
- They Like it when You Listen - Fred isn’t a magician. In fact, a good programmer is one of the most logical, analytical people you’re likely to come across outside of NASA. So, while many of the details of his work may be Greek to you, his solution (and likely his explanation) are probably pretty logical.
Now, this doesn’t mean that you should sit by and let him talk over your head, because that will likely lead to a violation of truth #2 (you’ll be back in no time asking for clarification). If you don’t understand what something is/means, ask! Many (but not all) programmers love to talk about the elegance of their solutions (myself included, to be honest). A great way to gain rapport with guys like Fred is to ask him to explain a particular concept or idea that’s present in the TPS report generator. You’ll watch a smile emerge and he’ll excitedly describe it, probably using words like “polymorphism”. Again, try to grasp what he’s saying - and know that he’ll like you more because you asked.
In short, just understand that you’re probably dealing with a different type of person than most of your officemates. Programmers are a special breed of people and there could be whole communication courses taught on how to effectively interact with them. While programmers may not be the easiest people in the world to deal with, they can be very handy friends to have when something needs to get done quickly. We’re a terribly loyal lot and appreciate it when users help us help them.
Just do your best to make their job easier (the same courtesy you probably expect from anybody asking you for help) and you’re likely to get, and stay, in their good graces for years to come.
Technorati Tags: programmers, communication, work
If you enjoyed this post, won't you consider a Stumble?
Popular Posts
comments
14 Responses to “How to Talk to a Programmer”
Leave a Reply
Excellent tips… Kind of reminds me of the IT department sketches they (used to?) do on SNL…
I believe you’re referring to Nick Burns: The Company Computer Guy!
Classic, indeed.
#1 is the kicker for me. If someone demands something from me my friendliness disappears. I’ll get their issue fixed, but they are now on my bad list.
[...] over at Cranking Widgets wrote a great piece about how to talk to a programmer. This is my favorite section: Don’t Demand Anything - Unless Fred reports directly to you, [...]
[...] was recently brought to my attention that the image I chose for my recent post ‘How to Talk to a Programmer‘ was actually of a young woman in anguish immediately following (and as a result of) the [...]
[...] How To Talk To A Programmer - [CrankingWidgets] digg_url = ‘http://www.lifehack.org/articles/lifehack/how-to-talk-to-your-it-department.html’; digg_bgcolor = “#”; ( function() { var ds=typeof digg_skin==’string’?digg_skin:”; var h=80; var w=52; if(ds==’compact’) { h=18; w=120; } var u=typeof digg_url==’string’?digg_url:(typeof DIGG_URL==’string’?DIGG_URL:window.location.href); document.write(”"); } )() Author: Craig Childs Posted: Tuesday, March 6th, 2007 at 7:54 am Tags: office, officespace, programmer Bookmark/Share This! Leave a Reply [...]
[...] How to Talk to a Programmer - The Cranking Widgets Blog [...]
“If it’s a multi-step solution, jotting it down will further ensure you execute it correct (and you’re likely to impress Fred in the process).”
Unless you can’t take quick notes, and stop Fred every few sentences to say, “What was that again?”. OR demand that the process be shown to you while you take notes instead of just writing it down and going away and trusting the notes will help.
Programmers and IT people are NOT the same thing. I’m a programmer. I would never ask someone to fix code themselves first. However, if you started demanding apps from me, I’m going to put you at the end of my list, even if it’s important. Your lack of preparation does not constitute an emergency on my end.
This made me laugh:
We have something to this effect tacked up on the wall in the server room. Ours actually says:
Truly brilliant…
[...] productivity site The Cranking Widgets Blog comes “How to Talk to a Programmer” (via Lifehack.org), an excellent how-to for communicating with the “computer [...]
[...] Zen and Computing posted a very nice reinforcement of my recent post regarding talking to programmers. Here’s a snippet: If you master the points set forth in “How to Talk to a Programmer”, [...]
it’s too bad that we go through life and forget that there’s a human side to everything. It’s so sad to hear that we have come to the point where we need to tell people to treat a someone like a colleague(this means respect) in all reality there’s a human side to everything, even software.
http://www.nlearnseries.com/wordpress
s/programmer/tech support/
I’m a sysadmin which is probably what you’re referring to. In my case, I support programmers and engineers .
#1 - I have users that got to my boss 1st. Big no no. You’re trying to make me look bad and it’s good that my boss has the same mindset. Use the help desk. Everyone in my dept gets the notice. My personal email and phone and visting my office directly don’t work well when I’m out of the office/in the john/sick/on vacation. If my coworkers can’t do it, they have my home phone number. Oh, and help desk tickets are tracked by my boss, his boss, and his boss.
#2 - God helps those that help themselves. I’m here to help, but I’m *not* going to clean up your home directory. Do you expect me to tidy up your desk too?
If I have directions on a web page, read them. They save you some time and me lots of time. If you come to me w/o reading my documentation, I’ll point you at them. If they’re broken, I’ll fix them after I help you. If you come again w/o reading them, I’ll read them with you, you big baby!
If there are error messages, read them and write them down. I probably need to know what they are. If I do, I’m sending you back.
Notes are good. There is nothing more annoying then answering the same question again. I write directions that do that. I might even hand you a pad of paper.
If you need a new gadget/application, it is very reasonable of me to ask why. I might have something that 20 other people are using already and I don’t like one offs. I’ve been doing this for awhile and know of many solutions that might be: cheaper, easier to support, faster, etc. Don’t order stuff and throw it over the wall. One group ordered 6 TB of storage w/o IT. It turned out to be incompatible w/ 90% of our systems, doubled our work load and our backup system is a 40GB DLT drive
#3 - In the above w/ the 6TB, the group was on aging storage that was failing. The company that built it was out of business 6 months earlier and we’ve been screaming to switch. When it failed like we said it would, the users were out 6 months of data. I’ve been doing this for years and I have good ideas. Use them. If my boss knows you didn’t listen, he’s not going to make me work weekends because you ignored me.