I just thought of another perverse incentive introduced by salary negotiations - they promote territoriality.

Negotiating 102: Deal from a position of strength. How can an employee get the upper hand? By making themselves essential. It’s not good for the company to have essential employees. Employees get sick. Employees go on vacation (or try to). Employees get pregnant. Employees have children, which is a whole world of conflicting priorities. The company needs to be able to run smoothly while they’re away.

If employees have to bargain, they’ll strengthen their hand by hoarding information. You become an essential employee by not sharing knowledge. You become “the only person who knows …” In tech companies, it’s pretty easy to be the only person who understands a critical piece of code, or knows how to configure specific servers. You generally have to work to not find yourself in that position. But almost anyone can do it. You do it by not writing things down. You don’t document requirements, decisions, client requests, lessons learned, policies and procedures, or the reasons behind them. You keep it all in your head. You prevent it from becoming institutional knowledge.

The people who write everything down, the ones who work up procedures that everyone can follow, write code that everyone can read, and explain all the whys and wherefores of what they do? These are the ones who really create value for the company in terms of institutional knowledge. And if they’ve done a really good job of it, you can replace them at a moment’s notice. Again, the ones who are the most valuable are the ones you can pay the least. But which do you want to encourage?

Once upon a time, I got into a… heated discussion with an unspecified head honcho about salaries. Not mine, mind you. I didn’t think we were paying one of our guys what he was worth, what he could make in the marketplace. Head honcho argued that his job was to keep costs, including salaries, down. If this guy wanted better money, he should bargain harder. At the time, I knew that this was totally wrong-headed, but I couldn’t explain why on the spot. So this argument has festered in the back of my head since then.

Employees, particularly skilled, creative workers (as we programmers flatter ourselves to be) should not have to negotiate against our managers for pay and benefits.

This isn’t some sort of hippie socialist crap - there are two real, clear business reasons for this. The first is that it introduces a perverse incentive. I’m speaking in economic terms - this has nothing to do with anyone’s sex life. Not directly. The second, which is sort of related, is that it’s shitty for morale. If that sounds fuzzy-headed to you, you shouldn’t be managing anyone who’s smarter than a chimp and doing anything more complex than stamping out license plates.

The perverse incentive is simply that salary negotiations set up a system that rewards people for not caring about their jobs. Negotiating 101: The most important factor in any negotiation is the willingness to walk away. You go to buy a house, and that’s the first thing anyone tells you. Don’t fall in love with it. If you aren’t willing to walk away from it, they can take you to the cleaners.

So the people who don’t really care about their jobs, the clock-watchers, the ones who can take it or leave it, who haven’t really bonded with their co-workers, who don’t really believe in the product or take pride in their work? They’re the ones who can walk away. The only thing keeping them there is the cash, so it’s going to cost you more. The ones who aren’t like that, who are emotionally invested in the company? You’re turning that against them. You can’t imagine that’s going to make them happy when they find out.

Now, that part applies to everyone. Technical staff in particular have another disadvantage: The personality traits that make them good at their jobs work against them at the negotiating table. It’s not just through lack of people skills or anything - in order to be good technicians, they have to be bad at selling themselves.

Allow me a brief digression here. Technical staff actually operate in a different universe from the business side of the house. They’re “reality-based” in the disparaging way that our current administration uses the term. Put simply, shit will either work or fail based on the properties of the observable universe. No amount of personal motivation or focus-group work will let a spare, obsolete PC handle a million page hits a day. There’s math there. You can prove things.

On the business side of the house, to an alarming extent, believing things makes them true. If the sales guys are confident and self-assured, if they really believe that they’re great salesmen and they have a great product, people will trust them and buy stuff from them. If the managers believe that the current project is destined for success, and can keep everyone enthusiastic and focused, it’s much more likely to be successful. By contrast, once people start believing it’s doomed, they don’t work as effectively, maybe they leave, and the project fails. (This is that morale thing I mentioned earlier.) It’s all unsettlingly self-referential.

These traits which managers and sales people need to be effective are actually bad for technical folks. Arrogance means you overlook things. You miss subtleties that you’d catch if you were more cautious. Two heads are always better than one; three or four better still. (Okay, yes, there’s a limit to this.) But any technical solution will be better if you can put your ego aside and plunk your idea down in front of some other folks for a good, harsh critical review. Being able to sell them on it by force of personality doesn’t make it better. Being aware of your own failings and limitations makes it better. Being able to let go of your proprietary defensiveness makes it better. Learning to value the people who will poke holes in your designs - the ones who are “not team players” - makes it better. A considerable amount of humility is called for here.

This all makes you pretty easy meat in a salary review.

So, point two: Shitty for morale. Yes, we live in a capitalist economy. Companies compete against each other, often fiercely. But within a company, you need to cooperate, to work together, and to trust each other. Without that, a lot of energy gets wasted on internal politics, turf wars, and jockeying for position.

This is particularly acute for tech workers. Technology is complex and huge. People tend to be experts in a very narrow field. Odds are that you’ll have to cross a lot of boundaries to get anything done. Competition - feuding between fiefdoms - can slow everything to a crawl.

Also, it’s one thing if you’re managing guys who stamp out license plates. You know how to stamp license plates, you can watch them doing it, and you can measure their work by the number of license plates they stamp out. Tech guys, not so much. Much of the time, management has no real idea what these guys are really doing. Even if you could watch them all the time, it might not do you much good. It can be hard or even impossible to distinguish between smart, hard-working guys and slackers. Is the problem really hard, or are they just lazy? Is the system running well because your admin set it up right and maintains it carefully, or is he just lucky so far? Maybe he automated the crap out of everything, and now he just has to sit around, waiting for alarm bells to go off. No way to know. (A hint: If you ever have to choose between the guy who puts in 12-hours days doing everything by hand, and the guy who has a bunch of programs doing his work for him, you want the programmer. Brains scale better than brawn.)

So you have to trust these guys. You’re best bet is to put a bunch of them together and hope they’ll keep an eye on each other. That’s still a lot of trust, and why should they look out for you if you’re not looking out for them? If they think you’re chiseling them on pay, they’re likely to chisel back. It’s pretty easy to goof off and look like you’re working, particularly if you program for fun. At best, they’re not going to put a whole lot of brain power into figuring the best way to do things. The surest sign that this has happened is that the really good ones, the ones with a work ethic and motivation, will leave. They have better things to do than put up with this bullshit.

Don’t go down that road. Keep an eye on the market and pay your folks what they’re worth.

I was having coffee with my friend Simone the other day. We were sort of chatting about work stuff, and we’re both at the point now where we’re being put in charge of other people. She came up with a really good metaphor for explaining the various issues in tasking junior staff.

It’s like you’re asking them to hang a picture for you, but they’ve never done it before. You understand what you need done - the trick is getting them to do it. In fact, it’s so obvious to you that there are constraints and expectations that you don’t even think to explain. So you’ve got some junior guy working for you, and you say, “Go hang this picture over there. Let me know when you’re done.” It’s obvious, right? How could he screw that up? Truth is, there are a whole lot of things he doesn’t know that he’ll need to learn before he can hang that picture. There are also a surprising number of things that you can overlook.

First off, there’s the mechanics of how to do it. What tools does he need? You know that there’s a hammer and nails in the back of the supply closet. He doesn’t, and it’s fair of him to assume that you wouldn’t have asked him to do something he didn’t have the tools for. He looks around his desk, and he’s got a stapler and a tape dispenser.

There are two ways he can do this. He can make lots of little tape loops, so it’s effectively double-sided, and put them on the back of the picture. This is the solution that actually looks alright, and it’s not until the picture comes crashing down that you find out he did it wrong. The other possibility is that he takes big strips of tape and lashes them across the front of the picture, stapling them to the wall for reinforcement. This solution may be worse because it actually sorta fits the bill - the picture is up, and maybe not too badly obscured. With enough staples, it’ll hold. It’s just ugly, and not what you intended. And if you don’t put a stop to this now, he might keep hanging pictures this way.

There is also another way this can go wrong, particularly with a certain breed of eager young programmer. You find that he’s gone down this path when your boss comes by the next week to ask about this purchase order for a nail gun. So you talk to your guy and discover that he’s spent the last week Googling, reading reference works, and posting to news groups. He’s learned that you hang pictures on a nail driven into the wall, and that the right tool for driving nails into walls is a high-end, pneumatic nail gun. If you’re lucky, you can point out that there’s a difference between picture-hanging nails and structural nails, and that a small, lightweight hammer like you have in the supply closet is really the right tool for the job. If you’re not lucky, you have a fight on your hands that goes something like:

“Why can’t we get a nail gun?”
“We don’t have the budget for it.”
“So we can’t afford to do things right?”
“There’s nothing wrong with driving nails with a hammer.”
“But aren’t we trying to do things better and faster? Are we going to keep using hammers just because we’ve always used them? It’ll pay off in the long run.”
“We don’t spend enough time driving nails around here to justify buying a nail gun. We just don’t.”

And ends with him sulking.

Now you think you’ve pretty much got that tool issue sorted out. He’s got his hammer and nails, and he goes off. The trouble is, he still needs to know how to use them efficiently. Again, it’s obvious to you because you know how to use a hammer. To someone who has never seen one before, it probably looks like it’d be easier to hit something small like a nail using the broad, flat side of it. You could certainly do it with the butt of the handle. And you might even be able to wedge a nail into the claw part and just smack it into the wall, instead of having to hold it with your hand while you swing at it with something heavy.

This sounds pretty silly from a carpentry standpoint, but it’s a real issue with software tools. Software tends to be long on reference documentation and short on examples and customary use. You can buy a thousand page book telling you all the things you can do with a piece of software, but not the five-page explanation of how you should use it in your case. Even when you have examples, they don’t tend to explain why it was done a certain way. So you plow through all this documentation, and come out thinking that a nail gun is always the right tool for the job, or that it’s okay to hit things with the side of the hammer.

I ran into this when I started working with XML. I’ve seen all sorts of references that say, “Use a SAX parser for reading XML files, not a DOM parser. DOM parsers are slow and use too much memory.” I finally caught some guy saying that, and asked, “Why? Is the DOM parser just poorly implemented?”

And he said, “Well no, but why load a 10 megabyte document into memory when you just want to get the author and title info?”
“Ah, see, I have 20 kilobyte files, and I want to map the whole thing into a web page.”
“Oh yeah, you’d want to use DOM for that.”

There may also be tool-data interaction issues. Your guy knows how to drive nails now, and the first thing he does is pound one through the picture frame.
Ooooh.

“No, you see this wire on the back of the frame? You drive the nail into the wall, and then hook the wire over it.”
“Oh, I wondered what that was for. But you only put in one nail? Wouldn’t it be more secure with like, six?”
“It’s good enough with one, and it’s hard to adjust if you put more in.”
“Why would you need to adjust it?”
“To get it level.”
“Oh, it needs to be level?”

Ah, another unspoken requirement.

So now we get into higher-level design issues. Where should the picture go? At what height should it be hung? He has no way of judging any of this, and again, it’s not as obvious as you think.

You know it shouldn’t go over there because the door will cover it when open. And it can’t go there because that’s where your new bookcase will have to go. Maybe you have 14-foot ceilings, and the picture is some abstract thing you’re just using to fill space. Maybe it’s a photograph of you and Elvis, and you want it to be smack at eye level when someone is sitting at your desk. If it’s an old photograph, you’ll want to make sure it’s not in direct sunlight. These are all the “business rules”. You have to take them into account, but the way you go about actually hanging the picture is pretty much the same.

There are also business rules that affect your implementation. If the picture is valuable, you probably want to secure it a little better, or put it up out of reach. If it’s really valuable, you may want to set it into the wall, behind two inches of glass, with an alarm system around it. If the wall you’re mounting it on is concrete, you’re going to need a drill. If the wall itself is valuable, you may have to suspend the picture from the ceiling.

These rules may make sense, but they’re not obvious or intuitive. A solution that’s right in some cases will be wrong in others. It’s only through experience working in that room, that problem domain, that you learn them. You also have to take into account which rules will change. Are you really sure of where the picture’s going to go? Is this picture likely to move? Might it be replaced with a different picture in the same position? Will the new picture be the same size?

Your junior guy can’t be expected to judge any of this. Hell, you’re probably winging it a bit by this point. Your job is to explain his task in enough detail that he doesn’t have to know all this stuff, at least not ahead of time. If he’s smart and curious, he’ll ask questions and learn the whys and wherefores, but it’ll take time.

If you don’t give him enough detail, he may start guessing. The aforementioned eager young programmer can really go off the rails here. You tell him to hang the photo of your pet dog, and he comes back a week later, asking if you could “just double-check” his design for a drywall saw.

“Why are you designing a drywall saw?”
“Well, the wood saw in the office toolbox isn’t good for cutting drywall.”
“What, you think you’re the first person on earth to try and cut drywall? You can buy a saw for that at Home Depot.”
“Okay, cool, I’ll go get one.”
“Wait, why are you cutting drywall in the first place?”
“Well, I wasn’t sure what the best practices for hanging pictures were, so I went online and found a newsgroup for gallery designers. And they said that the right way to do it was to cut through the wall, and build the frame into it. That way, you put the picture in from the back, and you can make the glass much more secure since you don’t have to move it. It’s a much more elegant solution than that whole nail thing.”
“…”

This metaphor may be starting to sound particularly fuzzy, but trust me - there are very real parallels to draw here. If you haven’t seen them yet in your professional life, you will.

The key thing here is that there’s a lot of stuff, from the detailed technical level to the long-range business level, that you just have to know. Your junior guy can’t puzzle it out in advance, no matter how smart he is. It’s not about being smart; it’s just accumulating facts. You may have been working with them for so long that you’ve forgotten there ever was a time when you didn’t understand them. But you have to learn to spell things out in detail, and make sure your junior folks are comfortable asking questions.

I remember when I was in high school, there was some bold statement made in the press that soon, Children In Our Schools would have to learn three languages: English, Spanish, and Computers.

At the time, that struck me as a typically idiotic bit of punditry. This was clearly some yutz who didn’t know anything about computers. Learning C or Basic wasn’t like learning a foreign language. I’d sat through enough Spanish class to know that.

Let me put this in context a bit. This was in the early 1980s. People in general didn’t have computers. There were a handful of Apple I computers (not Mac - Apple I) in our school computer lab. One of my brother’s friends had one. We had an Atari 800, I think - a game machine that you could plug a BASIC cartridge into. Computers were very new and strange and misunderstood. And people said stupid things like referring to “computers” as a language.

I woke up thinking about that this morning, and I realized that maybe it wasn’t that stupid after all. There’s some insight to be gleaned from those words - just not in the way the speaker intended. I’m sure they were talking about computer programming, and they were wrong.

There were wild projections at the time that, given the current rate of growth in the computer industry, in 20 years or whatever, everyone would be a programmer. I think it was even pointed out at the time that the same prediction had been made about telephone operators in the middle of the century, and had come true after a fashion. You can see in old movies, when telephones first came out, you just picked up the receiver and asked a live human operator to connect you to a number. The operator would manually (by plugging and unplugging wires in a switchboard) connect your phone line to the one you wanted. As telephones surged in popularity, the demand for switch operators boomed. But then they automated it - they added a dial to your phone and you became your own operator.

These days, there are still a lot of people who program for a living, but they’re relatively few compared to the number of people who use computers for a living. Everyone from supermarket checkout staff on up uses computers. They don’t program them; they use specific programs to get their jobs done. They control the computers, but only up to a point - their actions are limited. Put another way, some programmer has built them an interface - a mini-language - for talking to the computer about their work.

Now, let’s take another look at that “computers as a language” idea. When you study a foreign language, you learn more than just the language. Or the language is more than just grammar and vocabulary. It’s culture. And maybe that’s a better way of putting it. When you say you have to learn the language of computers, you really mean the culture of computers. Not so much the specific programming languages, but language in the broader sense of how to interact with computers.

The building blocks of this language are not the programmer’s building blocks, like if statements, for loops, and procedure calls. The building blocks of this language are files, directories, trash cans, drop-down menus, radio buttons, search tools, configuration dialogs, wizards and so on. They’re the concepts and metaphors you need to understand in order to get the computer to do what you want.

It’s also a general understanding of what’s possible and what’s not - knowing, in the culture of computers, what’s expected and appropriate behavior. You know that no matter what program you’re dealing with, there will be a way to load files, save files, and set options. There will be ways to cut and copy and paste, and the difference between cut and copy. There will be a way to search and print. And if you screw up, there’s normally a way to undo it, though the fine print on that changes.

All of this, you learn like a foreign culture. You’ll only get so much of it from reading books; you really need to go there. You can be an occasional tourist: You go there at the nice times of year, and stay in hotels that are friendly and accommodating, if a bit expensive. You learn to order food and maybe ask directions in the local language. In computer culture term, you surf the web, read email, edit documents, and maybe learn a shortcut or two. Really, this is all that most people need.

Then there’s the business traveller. Knows their way around, but only in the business districts. Has colleagues there. By analogy, has a set of applications they use for work. Maybe knows a bit about Word document formatting, making presentations. May be adept with spreadsheet software, creating formulas and macros.

Next, you get the foreign office - ex-pats. Folks who have been living there for a while. They know the local language and a bit about the culture. They may spend most of their time with friends from work, fellow homelanders. These are the application administrators, DBAs, integrators. They are comfortable in the environment for all practical, day-to-day needs.

Finally, there are people who have gone native. They live there, speak the language fluently, and are well-versed in the manners and customs. Most of their day-to-day associates are natives. They actually feel a little uncomfortable around folks from the old country. The old manners and customs may seem odd or nonsensical, and they’ve lost some of the idioms of their mother tongue.

These are programmers. They’re not down with the drag and drop, the clicky and the double-clicky. They use command lines. Neal Stephenson has explained this in a far more engaging way than I could hope to in a short book/long essay called “In the Beginning was the Command Line”. Go read that. The short of it is that to programmers, all that graphic interface stuff just gets in the way.

Imagine you’re in Tokyo. Tokyo is very tourist-friendly in one particular way: Its restaurants have graphic interfaces. You got into most any restaurant in Tokyo, and the menu is all photographs of food. You see something that looks tasty, and you point at it. You can get pretty far as a tourist in Tokyo just pointing at things you want.

But if you were actually going to live in Tokyo and work there, you’d want to learn the language. It’s a lot of work, but once you know it reasonably well, it’s the most efficient way of doing things. And you’d probably be annoyed by the tourists who fumble through ordering lunch, holding up the line and complaining loudly about how Japanese doesn’t make any sense to them. Dumb-asses. It makes plenty of sense to the Japanese.