After reading Sandra Ordonez’s MediaShift post “7 Ways to Get Programmers to Stop Hating You,” my first thought was: Wow, good advice. My second thought was: How can we programmers get people to stop hating us? After 13+ years of working as a technologist — from a junior developer to the manager of a couple tech departments — I’ve seen first-hand that “tech hating,” to use Sandra’s phrase, is sometimes justified. Put simply: Sometimes techs deserve to be hated.
And so, I offer this list to you, fellow techies, in the name of Office Peace. Let’s show the world that the stereotype of the rude, uncommunicative programmer is as outdated as the 15” CRT monitor issued to me at my first job. Let’s earn some love. (Note: Please don’t think that I’m holding myself up as a perfect example here — these aren’t things that I do every day, although I try, but they are good reminders for all of us.)
1. Add a new language to your resume: Human
Chances are your resume has a list of programming languages you know. As important as they are to your job, the language you use when you communicate with your co-workers is every bit as important. Being able to discuss the ins and outs of tail call optimization or the pros and cons of statically typed languages with regard to metaprogramming might make you a great programmer, but if you’re not able to communicate meaningfully and respectfully with non-technical people, you won’t be a great co-worker. And you’ll be doing yourself a disservice; how are you going to get recognized for the great work you do if you’re not able to explain that work to anyone who’s not a programmer? And how are you going to change anything about the place where you work if you’re not able to turn a complaint into a constructive suggestion? The answer is: You aren’t. So do yourself a favor and start boning up on your human-to-human interface communications.
2. Remember your operating context
Make it your business to learn more than just the technical specifications for your projects. The more you can get a sense of the big picture, the more you can understand the context within which you are expected to make your brilliant technical decisions — and the more likely it will be that those decisions are the right ones for this unique situation. When you’re able to keep the big picture in mind, you become more than just an implementer — you become a problem-solver.
3. Think like a client
No, I don’t mean change your deadlines for no reason, call yourself at 5:00 on a Friday for technical support, or forget your password to the CMS. What I do mean is to try to put yourself in your clients’ (or co-workers’) shoes. Maybe they don’t know the right terminology for everything, but they still need help; maybe they’re under time and budget constraints that you don’t know about (and that affect their decision-making); maybe they have a million things going on right now and the code you’re writing is just one of them. In short, try to remember that you may not know every variable, and that you’re not the only one with a difficult job.
4. The power of positive thinking, or at least speaking
Here’s a ripped-from-the-headlines-of-my-job (well, my old job) scenario: Say your company’s client has already signed a contract with the vendor of a terrible CMS before your project starts. You can say “that was a stupid choice” and await further instructions. Or, you can say “OK, they’ve made a choice that we wouldn’t have advised them to make; now here’s how we can work within that constraint to build them a great site.” Saying “no, we can’t do that” is easy. Saying “yes, we have constraints, and here’s what we can do” is harder — and about a million times more useful.
5. Would you like a side of Value with that?
Let’s face it: Most clients (and non-technical managers) don’t care how elegant your code is as long as that code works. And while truly great programmers are a rare breed, there are plenty of “good enough” programmers who can get the job done — maybe not as well as you can, but good enough that your client can’t tell the difference. So how can you set yourself apart? Ask questions. Specifically, ask the right questions to help you figure out (and build) what your client/boss/teammates really want, as opposed to simply what they are asking for. You probably know about tools, solutions and approaches from your past work that a client (or a co-worker) has never even heard of — here’s your chance to fully leverage your technical knowledge and skills to help them meet their goals in ways they didn’t know were possible. Delivering what someone really wants is a great way to add value and differentiate yourself in a marketplace where any college kid can bang out a Drupal site and call it “programming.”
6. Get Involved
Raise issues and ask questions at the beginning of a project, not when it’s too late. If technical staff aren’t typically included early on in the project process at your company, start making the case for why they should be, because it will save time, money and frustration later on. The more you can involve yourself during the early stages of a project, the more you’re setting yourself (and your co-workers) up to succeed by identifying pitfalls before you’re staring up from the bottom of one. But pointing out danger is only half the battle; use the time at the onset of a project to make suggestions, add value (see above), and demonstrate your worth to your employer. Making that killer feature work right is part of your job; suggesting a way to make it better/cheaper/faster/reusable/etc. is what will make them love you.
7. Mind The Gap
Technical people and non-technical people often suffer from a “failure to communicate” due to the ineffable nature of many tech words and terms. When a non-technical person asks you a tech-related questions, simply coming back at him or her with a string of tech-speak doesn’t actually make you look smart — it makes you look like someone with no communication skills. It pigeonholes you. It reinforces the stereotype of the unhelpful technical person who can communicate well with computers but not with humans. It makes you look less useful, and less useful employees aren’t the ones who get the best assignments — they’re the ones who get cut when times get tough. Albert Einstein said, “If you can’t explain it simply, you don’t understand it well enough.” Explaining something in a non-technical way doesn’t mean dumbing it down, it means proving that you’re smart enough to do your programming job in reverse: Take a set of technical concepts or instructions and turn them into ideas a non-technical human can understand. Brilliant!
Conclusion: Try A Little Tenderness
This list is a good start, but in the end if you still have the attitude that all non-technical staff are idiots, you’re never going to justify their love (and you’re going to hurt your career prospects in the process). You didn’t learn everything you know the first time you heard it, so be forgiving when your non-technical co-workers sometimes ask you the same question over and over again. It’s OK to tell them where to find the answer that you already sent them, but if that doesn’t work, look again: Maybe you’re not explaining the issue well enough so that it sticks. Practice transparency. Provide detail. Put a friendly face on the big, scary technical stuff. Remember that you are an ambassador for techs everywhere. So give us all a good name — and earn that love.
What do you think? If you’re a techie, what do you do in your job to try to keep the haters at bay? Is this list useful? If you’re non-technical, what would you add to this list? What you are you doing to help inter-office relations? Tell us in the comments.
“Mind the gap” photo by Flickr user asparagus_hunter and used with Creative Commons license.
Jordan Hirsch has spent the last 13+ years as a lovable technologist with a focus on content management. Currently, Jordan helps non-profits accomplish great things on the Internet as part of the team at Beaconfire Consulting. He’s also a musician and improviser, and blogs about music and technology at Wired For Music. You can follow him on Twitter at @tfish77, where you can read his thoughts about living in Brooklyn with his pregnant wife and not-pregnant dog.