The Portuguese, besides having some fantastic idioms, have an interesting cultural quirk that makes navigating their country as a foreigner particularly difficult. They will always, without fail, respond to your questions with a literal answer, and will never actually tell you what you actually want to know. Ask a man if that door over there leads to the fire escape, and if it does not, he will answer “no” and then proceed directly to the door that does, leaving you to die engulfed in flames.
Working with software engineers is not quite this difficult, or (barring certain industries, like medical devices and air traffic control) potentially life-threatening. But it can be equally frustrating, if not more so. If you are a project manager, client, business developer, sales rep, recruiter, or belong to any other profession that regularly deals with them, you have your work cut out for you. What follows is my gift to you: a primer on working with software engineers for the everyman with no iPad and little understanding of what they do.
If you don’t have to worry about hiring engineers, you can skip this section and the next. If you’re lucky enough to already have good engineers working for you, you can just skip this section. If you’re in the other 99% of the recruiting pool, read on.
Good engineers are elusive. They’re the best-looking girls at the dance, and if you want a shot at banging them you’re going to have to figure out where they hang out and choose your moves carefully. They get approached all the time by recruiters and startups, and they have very little patience for the bad ones. And even if you do get them to come in and talk to you, they’ll be weighing your offer against the other ten tucked neatly away beside their ergonomic keyboard.
Good engineers are also employed. Even if they’re not full-time, they’re making upwards of $100 an hour contracting to faceless corporations or waiting to cash out a fat equity stake at a boutique startup. They don’t need you, you need them. Make a note of that.
And finally, good engineers participate in the software community. These days, that means github, Stack Overflow, and niche sites like CocoaDev for iPhone and Mac OS X. These sites are your gateway to good people. Use them wisely. Get your best engineers to start actively participating and they will attract other equally talented brains. Post to their job boards, or in the case of Stack Overflow search their résumé database.
Lurk on reddit and Hacker News and see which blogs get regularly linked, then reach out to those people. They probably won’t work for you, but they may know someone who will. Be smart about how you contact them: remember that the usual rules of good public relations also apply to bloggers.
When you find one, email a short, to-the-point summary of what you’d like to offer and what the work will entail. No one wants to hear about money until they know what they’ll be making.
Weeding Them Out
The thing is, Google has a well-known false negative rate, which means we sometimes turn away qualified people, because that’s considered better than sometimes hiring unqualified people.
- Steve Yegge
Of course, for every good engineer there’s 100 bad ones, and the bad ones will come knocking much more frequently than the good ones. If you can’t tell the difference, you may actually get better results with a coin toss.
Watch for red flags. Catch the spammers before they waste your time. Ask them to include the answer to a simple question in the subject line (one coworker sent me a snippet of code that when run returns I PAY ATTENTION). If they can’t do this one trivial thing, cut them.
Check references. Use their software. Ask them to discuss it, the challenges they faced, and the solutions they came up with clearly and eloquently. Good engineers are also good speakers and writers (spelling and grammar mistakes notwithstanding). If they hem and haw, cut them. If they can’t solve a basic programming problem in the language they’ll be working with, cut them.
Ask what blogs they read. How they find answers to problems. How they structure a project from start to finish. Check their open-source code. No public code samples? Unless they worked for Uncle Sam, cut them.
Don’t settle. A good person is much more productive than a bad team.
Dealing with Them
Programmers’ brains are linear. They think slowly and deliberately, are convinced by hard evidence, and loathe having their time wasted. They are not, generally speaking, facile. And while I may get shit on for saying this, I can say from personal experience that spending long, uninterrupted periods of time alone and deeply entrenched in a computer program does not do much good for one’s people skills, so they might not be the best at dealing with you either.
While getting good engineers is tough, retaining them is a completely different challenge. Good people tend to leave quickly if they disagree with the organizational direction or management style, or if they’re given problems to solve that they see as pointless and/or trivial to implement.
It’s a convenient side effect of the engineer’s preoccupation with solving difficult problems that money itself is not a strong motivator. Past a certain basic level of comfort, you quickly hit the point of diminishing returns on salary alone. Give your engineer autonomy and interesting problems, even if only 20% of the time, and he will sleep at the office until you remove him by force and handcuff him to a barber chair.
Try to avoid micromanaging your engineers. Hire a manager who understands what they do, can tell when they’re bullshitting, enforces deadlines and measures their progress ruthlessly. If they’re getting things done, don’t fuck with their mojo.
Keep meetings to a minimum. Engineers like making cool things and despise being told things they already know.
Getting Help from Them
If you want something done right the first time, be clear and spell it out in precise detail. If you’re responsible for the design and/or user experience, leave nothing to the imagination—programmers are not fluent in UX or design, nor should you expect them to be (though they should understand the basics). If possible, make pretty pictures with measurements, detailed type and color specifications and PDF annotations outlining important interaction details. Be thorough. If you don’t ask for it, don’t expect it. Consider all the angles and every use case. A minute saved now could easily cost you a day’s work in a month (put another way, you can get one extra coffee break in exchange for a two-week slip).
If something is broken, try not to get angry with them, as difficult as that may be. Most of the time it’s not due to negligence or laziness, but either a poorly communicated specification or something they rely on not working the way any sane programmer would expect it to work. Software engineering is the white-collar cousin of chainsaw juggling, and the occasional lost limb is unfortunately part of the job.
Email them or file a bug report clearly outlining the problem, when you first noticed it, what hardware and software you were using, what you did before it happened, any similar problems or trends you’ve noticed, and anything else (e.g. screen shots or crash logs) that might help. Most importantly, tell them how to reproduce the problem and make sure you can reproduce it yourself. I can’t stress this enough. It’s very rare to find a problem that can be fixed without a consistent way to reproduce it, and in these cases it’s impossible to know for certain that a fix works unless the cause is known and an engineer can do a mathematical proof (even an informal one) to show that it’s valid.
Finally, if they absolutely cannot reproduce the issue, go to their desk and show it to them. Many programmers will just chalk some bugs up to PEBCK (Problem Exists Between Chair and Keyboard) until they see something happen with their own eyes.
I hope you’ve enjoyed my take on this. Other people have written extensively on the subject, so if you’re looking to learn more, take a look at Paul Graham’s seminal piece on the maker’s schedule, Joel Spolsky’s excellent article on interviewing and Daniel Tenner’s guide to recognizing a good programmer.
You made it to the end! Awesome.
If you're itching for more, follow me on Twitter at @benjaminjackson.