A Pragmatic Approach to Working With Computer Nerds – Part 1

In a (surprisingly well-received) post a while back, Working With Computer Nerds, I provided a profile of the typical computer nerd, and some suggestions on general approaches to understanding my clan.  In this post I’m hoping to provide concrete examples of problems that typically arise when working with nerds, an explanation of the misunderstanding leading to the problem, and some idea of how to avoid them.  As with the previous “working with” posts, please consider this a rough sketch rather than a definitive guide.  The target audience is someone who might hire a technical person to do work for them, someone who regularly works with a nerd (or, heaven forbid, nerd*S*) or someone who is friends with a nerd and wants to understand their work better.

Pay by the Job, not by the Hour

As with many things, with computer work I feel you’re better to pay for what you need done rather than by the hour.  By-the-hour work has the inherent conflict of interest that if the person doing the work is less productive, they get paid more.  You won’t be able to get all work done this way (for example, no reputable computer shop is going to agree to fix your machine for a flat-rate, sight unseen), but for most things it’s possible.  If the person doing the work is efficient and gets things done quickly, good for them and let them earn a premium for their work.  Surprisingly, a number of computer nerds are highly-ethical and may give a partial refund (or discount the charge) if the job is easier than expected (I’ve done this).

For jobs, like computer repairs, where you must pay by the hour, I’d recommend trying a few different people then stick with the one you like the best.  Over time you’ll get a sense whether someone is being honest with you or not.

Feature Creep

Software is an unusual product in that it’s so versatile.  As soon as you see it doing something, it’s easy to think of extra things you’d like it to do.  Almost any software product that has a customer base will keep turning out new versions, each one inspiring customers with more things they’d like it to do.

This causes problems with custom jobs, as customers immediately think of new ways they’d like their website or software to work once they see it in operation (and usually convince themselves that their new idea should be included in the original project and delivered within the original budget and time line).  The customer wants better software for a lower price, and the nerd wants to be paid as much as possible for what they’ve produced.  This was one of the big things that got me out of contract programming – I got fed up arguing with customers whether something was in scope or not.  It’s possible that some people view this as a chance to re-open negotiations, but you’ll be driving the nerd you’re working with NUTS if you do this (you’ll be burning goodwill at an alarming rate).

A good computer nerd will write up a specification for a project and carefully go over it with a customer (even if that “customer” is another employee within the same company).  It’s important to take this seriously, as this is what you’ll go back to to resolve whether something was part of the original project or not.  If something important isn’t in the original specification, admit that it’s something new that you want and add it on as an extension to the project (or be willing to allocate more resources to the project to have it included).  Let the specification act as the contract, and if something isn’t in it, then it’s extra work.  Avoid vague language in the specification, as this will just lead to arguments about definitions and meanings.

I knew I’d laid the ground work properly when one client wanted me to do extra, unpaid, work  and they began the discussion with “I don’t want to talk about the contract, don’t even mention it.”  Clearly, they understood that our agreement clearly supported what I was expected (and not expected) to do.

Poorly Defined Problem

Without a specification (or with a bad one), it becomes very difficult to figure out WHAT should be made (and even when something is working, feature creep becomes inevitable without a well defined problem).  Some people approach design work (and sadly software development) with a “I’ll know what I want when I see it” attitude, which is totally unreasonable with computer work.  I’m amazed that people accept this in other lines of work (it seems to be the norm with graphic design).

It’s possible (although inefficient) to work this way with a salaried employee, but when working with a contractor this is guaranteed to end in misery.  When you’ve done the same job repeatedly and it keeps getting rejected without a concrete reason, you’d need to have INSANELY high profit margins to keep going with a customer like that.  I (and many other computer nerds I suspect) prefer to offer people a good price, with the understanding they won’t pull this kind of thing on me.

With people who know what they’re doing and are good at their job, it’s often worthwhile to express your needs and be open to their suggestions.  Just because you’ve heard buzz about Ruby, if someone doing work for you can make a good case for using Java instead, it’s worth hearing them out.  Talk about the problem, listen to their proposed solutions, and hammer down exactly what you’re hiring them to do and what will be delivered.

If the reasons they give for using another technology AREN’T relevant to you (they hit you with techno-babble that doesn’t make any sense), and if they won’t clarify after repeated attempts to get them to put things in terms that are relevant to you, I’d recommend not working with that person.  If they won’t build things with your needs in mind, how could they possibly do good work for you, no matter how brilliant they are?

This post got a little over-sized, so the second half will appear on Tuesday.