Thanks for asking.
First and foremost, we’re not all alike. Some of us are methodical and detail-oriented; some of us are task-focused and work best if someone else studies integration into the whole; and some of us are hackers raw and simple and make functions happen in base form (and then call you over to show you) and then add polish and details and prefer to debug specifics in response to live bug reports.
I’m good at what I do, and damn fast, jaw-droppingly fast, in my ability to hack out a rendition of what you describe to me as “what you want”. Nine times out of ten I can do it while you’re sitting there describing it to me, edits on the live project, works right now, like that?
Work with my strengths. Respect them, don’t abuse them. Spend a little bit of time thinking through what you want and whether or not having it that way will have repercussions on other things that are either in place or are things you’ll want down the line. I really hate ripping out stuff that works that you requested to be this way, even though I’m fast and can do it, because by now there’s legacy data in the system I’ve got to accomodate, and if you layer change request upon change request that affects the same damn data I’ve got an ugly klunky nightmare of backwards-compatibility to deal with.
If it isn’t me you’re working with, work with the strengths of the person you’ve got. Don’t wrestle with them: if you’ve got a cautious but exquisitely thorough person, don’t scream at them for changes more rapid than they are comfortable making, 'cause when they say they are done the system works and every t is crossed and every i is dotted and it’s all documented and you should praise God or Og or the Great Chip in the Sky;
if you’ve got a hacker like me, by all means come to me and ask me to show you what it would be like if such-and-such were the way things worked, but don’t tell me to roll it out live and then come back to me a week later and ask for changes that’re going to screw up what I just put into place — i.e. if you don’t know for sure and you’re just thinking this would be good, don’t bullshit me and say it’s how it’s gonna be. I’ll’ve built a dozen things on that assumption by the time you reverse course out from under me and it pisses me off. Oh, and don’t begrudge me implementation bugs. Most of my stuff works, but my strength is rapid app dev and I whack out stuff that basically works in hours, not days, and yes sometimes other stuff breaks. Report it, I fix it (also fast). Don’t treat it like a personal insufficiency. You could’ve hired one of those exquisitely thorough folks instead, but you’ve got me. Work with the strengths of the person you’ve got. I’m fast. Damn fast. I get it right the first time 91% of the time and I edit live systems while users are still in them. Tell me about bugs, don’t harass me about them; I can fix them in less time than it takes for you to report them to me; oh, and goddammit, don’t bug me about the ugliness of the fuckin’ graphical user interface when I’m showing you that a process does indeed work. Damn, we’ll slap some pretty on it later, don’t you understand that 3D shading and wider fields and better fonts is NOT something I wanna hear when I’m showing off successful functionality?
If you’ve got what I call a “focus person”, in many ways you’ve got the best of both worlds. You’ve got someone whose output is often going to be more polished than mine would be, developed more quickly than the t-crosser who is perfect but plods along more slowly —but the end result may need to be tested for integration into the whole, and the focus person’s screwups, such as they exist, may be in the interfaces and intestices where this new module meets up with other stuff. Focus people often work well in teams with a project admin who integrates stuff, but only if they are given suitable credit and accorded authority for the subproject that’s been assigned to them, and not chastised for not being better at “big picture integration” or being faster at rapid dev.
And some minor shit:
•I don’t do ties and suits and stuff. I am willing to own a set and wear it on special occasions if the CEO of the parent company wants to see the stuff and you want me to demo it. Otherwise, lose the dress-code shit or lose me. I’ll take a 15% pay cut to escape this kind of bullshit and I’m not alone.
• I hate meetings where we sit around and blab about what we did this week, or put the public spotlight on someone whose work isn’t going as desired. Do this shot mano a mano, not in meetings. Don’t waste my time. I’ll move on to a job not paying any better than this one just to escape stupid freakin’ meetings.
• Don’t even think of restricting what I can do on my computer unless it ties up your bandwidth. I get lunch breaks and I get downtime and there are times when I do my best cogitation of how best to implement your requests while browsing the Straight Dope or Timbuktu’ing a file from the girlfriend’s computer at home. Not your business. Don’t tie me down. If you’ve got a firewall, I want the key to get beyond it. If you don’t trust me not to bollix up your network, fire me. And don’t ever, ever, harass me for how I’ve spent my time. You’ve never ever waited for more than a week, rarely more than 2 days, between a request and an implementation, so don’t act like this is a time-clock kind of activity.
•I will ask for toys sometimes. If you can buy them for me (software or hardware), thanks. I will, at other times, tell you I need something, or that we need something. I will make the distinction. In the latter case, buy the suckers. I won’t ever disguise a “toy requisition” as a necessity. If you balk at equipping the place with what I say we need, I’ll recommunicate more emphatically, then if you stil don’t get it I’m out of here.