January 1, 2008

Five Management Strategies to Hire and Retain Great Programmers

Filed under: Programming Professionally — bnsmith @ 3:55 am

And they won’t cost you a dime…

DISCLAIMER: I’m still an underling, and so I haven’t actually had the opportunity to put these ideas into practice. I base my theories on experiences that I’ve had working on various teams over the course of my career, and how these experiences affected my own decisions. Although I’m convinced that the ideas are sound, I can’t offer any proof. Use at your own risk!

1.) Cultivate a Casual Work Environment

I love throwing on jeans and a T-shirt in the morning. It’s not just the convenience though; it’s all part of the uber-geek ego-trip. If you try to make developers wear shirt-and-tie to sit in their cubicle and code, don’t expect to retain anyone besides those that aren’t good enough to get hired anywhere else.

This assertion probably seems a tad extreme, given that all we’re talking about is a useless flap of cloth wrapped around the neck. Still, I think of it this way: managers who enforce a dress code are forcing needless, arbitrary complexity on their developers. Dressing up in a special costume doesn’t make developers more productive or NP-complete problems less difficult. So what’s the point? Even worse, managers who make bad decisions about clothing are equally likely to make bad decisions about technology and architecture, and these decisions would be vastly more painful to a great programmer.

The only possible exception that I can see to this rule would be for organizations with fat, bloated, governmental bureaucracies that force the dress code, but also incredibly cool technologies that a geek can’t play with anywhere else. I think that the best example of this would be NASA. Of course, once commercial space companies really start to take off, this situation won’t last for long.

2.) Let Your Developers Choose Their Tools

Have you just read the most fascinating article/advertisement in your favorite management magazine about the amazing new integrated version control system that will double the productivity of any developer? Stop right there. If you haven’t committed any changes in the last six months, then you are not in a position to make an informed decision. Try to realize this fact, and listen to what your developers tell you.

This doesn’t only apply to version control. The more control that you give your developers, the better.

If you’re hiring Java programmers, then let them develop on a Linux or BSD box instead of Windows, if that’s what they want. Java is multi-platform anyway, right? You might have to tell them to test on Windows extensively, if that’s your primary market, but your programmers would still be grateful to be able to work on the desktop OS of their choice. Perhaps the IT department might not like it, but are you going to let them stop you from building a first rate development team and thus creating fabulously successful software? This important benefit will help you attract and keep more talented programmers than you might otherwise get, and it costs nothing.

3.) Allow Your Developers to Connect with your Clients

I bet this is another controversial suggestion. Do you really want your shabbily-dressed (see point #1), Unix-hippie (see point #2) developers to be talking to your valued clients?

I would say yes.

Think of it like this. Your developers are smart people, and as long as you express your needs, you should be able to trust them to behave properly. If the customer has a particular dress-code, tell your developers what it is, and tell them that they will need to follow it in order to go there. In this case, it isn’t an arbitrary decision. You don’t have any control over your client’s rules, and so your developers won’t resent it.

But would developers actually want to see the clients? I think that most would, as long as you are careful not to take it too far, and make your developers feel like they are first-line tech support. Developers appreciate being able to see how real-life customers use the software, and how it helps to make their lives easier. If you have some people working for you who have never once seen a client-site, spare them a thought and ask them if they would like to tag along and see the sights. If you’re going to be driving over there anyway, why not? This is especially important if the client-site is something that a geek might find interesting.

4.) Offer Benefits Like Flex-Hours and Telecommuting

I don’t use an alarm clock. I wake up in the morning, generally about 8:00 am, roll out of bed, get dressed and go to work. But if I wake up at 8:30 or 9:00, I don’t have to worry about it. Nobody is keeping track of exactly the hours I work, as long as I get things done. If I was forced awake at 7:00 am every morning, I’d probably be an unproductive, coffee-chugging zombie for the first couple hours of each day. Is that really a worthwhile price to pay to maintain the same nice, rigid schedule for everyone?

Why even show up at all? If there are no meetings scheduled and a lot of solitary development to be done, there’s no reason that a developer can’t be equally productive from home. And of course, nothing makes me appreciate telecommuting like waiting at home for the FedEx guy to deliver a new tech toy.

Also keep in mind that telecommuting shouldn’t cost anything to implement — at least for programmers. If we were talking about marketing or sales people, then you would need to buy an expensive VPN appliance to give them access, but for any programmer worth their salt, all they should need is SSH. A little port forwarding magic is all it takes.

5.) Promote Ceaseless Learning and Discovery

Next Monday morning, as your developers arrive at work, hand them each an envelope containing a first-class ticket to Chicago and vouchers for a penthouse suite at the Drake Hotel so that they can attend PyCon 2008. Oh, wait… I promised that these strategies wouldn’t cost you a dime, didn’t I? Well, in that case, try this on for size.

Ask your developers what technologies they’re interested in. Ask them what they’re learning about in their spare time. Ask them how the technological landscape will shift in the next five years. Listen to their answers, and suggest that they each plan a short seminar on their favorite subject, so that they can share it with everyone. Friday lunch is an ideal time for such an activity. If you decide that you might be willing to part with a few dimes for this exercise, then perhaps you could even offer to order pizza for your crew. Who knows? You might even learn something.


Offering a high salary is a good start for finding top talent, but you will eventually run up against the law of diminishing returns. An extra thousand dollars added to the salary likely won’t be as big of a draw as a thousand dollars of well-thought-out perks. And when it comes right down to it, sometimes the best perks in life are free.


November 1, 2007

Practical Applications of Searle’s Chinese Room

Filed under: Programming Professionally — bnsmith @ 2:18 am

Consider the following:

A paper with Chinese characters is passed into a closed room through a slot on the door. The room’s occupant picks up the paper and examines it briefly, but he can’t read Chinese characters, and so he shrugs and sets about his task. He brings the paper over to his desk and opens a hefty volume containing thousands of rules describing a complex procedure. The rules themselves are written in English, but they are extremely tedious and dry, and so the man feels no enthusiasm for the dull task that he now begins to execute. The book tells him to look at first character, painstakingly copy a few of the inscrutable Chinese characters onto a new piece of paper, and then proceed to follow the rule on page three-thousand, four-hundred and ninety-eight. The rules are extremely detailed, providing a course of action for any possible set of characters. After several hours, the instructions tell the man that his task is complete, and that he should now take his new sheet of paper and pass it back out through the slot in the door.

A native Chinese speaker then retrieves the resulting sheet of paper and reads it, likely with some surprise, for the sheet of paper contains a coherent response to the letter that she had written and slipped into the slot earlier in the day. The volume of rules is a remarkable piece of work, indeed. It describes a completely mechanical process by which any suitably meticulous person can appear to understand the Chinese language.

The situation that I have just described is a thought experiment known as “Searle’s Chinese Room.” The philosopher who originally described these events used it to show that even if a computer seemed to understand Chinese (or English, French, Spanish or any other human language), it wouldn’t neccessarily mean that the computer was sentient, as you and I are.

Of course, this is all common knowledge for most computer programmers. However, you may not have realized that a variation on Searle’s Chinese Room has been adopted by many large software companies.

The “Large Software Company Room” method begins when a software team-lead passes a piece of paper through a slot in the door and into the sealed room. The piece of paper contains a list of character strings, mostly made up of English letters, but with the odd number thrown in as well. For example, character strings such as WTL, DB2 or UDP sometimes appear on these lists. The occupant of the room examines each string on the list, and compares it to the character strings on a stack of other documents. If he finds that one of the other documents contains one or more of the character strings on the list, he places that document into a separate pile. Once he has finished sorting the documents, he takes the pile of documents that contained at least one of the desired strings and passes the pile back out through the slot in the door. The software team-lead outside of the room may then select one of the resulting documents, called “Resumes,” and contact the person who wrote it. What I have described as the “Large Software Company Room” is more commonly referred to as the “Human Resources Department.” In practice, the list of desired strings will frequently also contain other qualifiers, such as the number of years of experience in using a particular character string.

Sometimes this system can have undesired consequences. If a software team-lead asks for “Resumes” containing “Java,” then all resumes that don’t contain “Java” but do contain strings like “J2EE” and “JDBC” will be discarded. The obvious advice would be for the software team-lead to simply be sure to include all character strings that could possibly indicate a desirable candidate. However, I doubt that this is really a workable strategy. For example, even if I’m looking for a Python developer, that doesn’t mean that I would automatically eliminate a candidate with no Python experience. If they had experience with Scheme, Erlang, Haskell, Ruby, Smalltalk, Perl or any number of other interesting tools and technologies that have piqued my interest, then I might decide to invite that person to an interview. The only way to really know for sure is to see the Resume myself.

I understand that this may not always be possible if a company receives ten thousand resumes for a single opening, but how often does that really happen? I don’t object to HR departments helping to take some of the burden of hiring away from technical people, but the help should always be optional rather than being forced on resentful software developers by arbitrary corporate policies.

Create a free website or blog at