Most software engineers, being rational people and averse to legacy, hate management– a set of legacy processes that were necessary over the concave, commodity work that existed for 200 years, but counterproductive over the convex stuff we do as software engineers. No, we don’t hate managers. They’re just people. They have this job we dislike because it seems to require them to get in our way. We only covet their jobs insofar as we wish we had more control over tools and the division of labor– we have this impractical dream of being managers-who-code (i.e. exceptionalism) meaning that we’re full-time programmers who have managerial control, even though the real world doesn’t work that way and most actual managers find their time spent mostly in meetings– but mostly, we think what they do is unnecessary. That’s not 100% true. It’s about 97% true. Resolving personnel issues, mentoring new hires, building teams and looking out for the health of the group– all of these are important tasks. The “do what I say or I’ll fire you” extortionist management that exists when bosses prioritize “managing up” and stop giving a shit about genuine leadership and motivation is the problem. I’ve said enough on that to make my opinions well-known.

A typical inefficiency that we perceive, as engineers, is the fact that most of the work that “needs to be done” doesn’t. It’s fourth-quadrant work that exists only because people lack the ability to refuse it. We’re rationalists and careerists, so we doubly hate this. We realize that it’s inefficient, but, more to our dislike, that it’s individually bad for us to work on low-yield projects. Why is there so much nonsensical dues-paying? And why does Corporate America feel more like the Stanford Prison Experiment than a group of people working together to achieve a common goal? I believe I can answer that. We need to understand what “business” is to non-rational people. It’s emotional. Judgments are made quickly, then back-rationalized. Decisions are made without data, or on sparse and poorly audited data, which is why an error in an Excel model can be such a big deal. So let me get to the one question that non-technical “businessmen” ask about people when evaluating them. It is…

Do they stink when they break?

Some people drop to 0.9 (that is, they lose 10% of peak productivity) under managerial adversity. (A few might go up, with a 1-in-1-million effective-asshole manager like Steve Jobs. So rare I’m ignoring it.) Some drop to zero. Some go to -10 as they cause morale problems. Managers want to see what happens ahead of time so they can promote the first category, mark the second as non-advancers, and fire the third. People are sorted, then, based on the rightward side of their decline curve. The reason this is fucked-up and morally wrong is that, if management is at all decent, that extreme territory is never seen. So a lot of what management tries to do is probe people for those tendencies in little ways that don’t disrupt operations.

Rationalists like engineers don’t like this. We look at the affair and say, “Why the fuck are you trying to break people in the first place? That’s fucking abusive and wrong.” We try to build systems and processes that fail harmlessly, do their jobs as well as possible, and certainly never break people. We like things that “just work”. Some of us are glory whores when it comes to macroscopics and “launches”, and we have to be that way for career reasons but, on the whole, the best endorsement of a product is for people to use it and not even know they are using it, because it works so damn well. When we look for weak points in a system, we work for technical issues and try to solve those. Non-rationalists don’t think that way. They look for weak people and, when there are none, they make one up to justify their continued high position (and as an easy blame eater).

When you deal with a non-rationalist, the first think you need to know about him is that he’s trying to figure out how bad it smells when you break. If you’re loaded up with 80 hours per week of undesirable work for two months on end, will you bear it? Or will you quit? Underperform? Make mistakes? Whine and cause morale problems? Grind to a halt, get fired, and demand severance not to sue? Sabotage systems? Non-rationalists want to find peoples’ failure modes; engineers want to build systems that are tolerant of human failure.

I think that this stink-when-breaking matter is one of the fundamentals of negotiation, as well. When you stink, you lose all negotiatory power. You whine, you make messes, you get people pissed off, and you end up in a position of weakness. You prove that you’ve been broken. You might have worse kinds of stink up your sleeve, but you’ve put your managerial adversary into damage-control mode and lost your element of surprise. The best way to extract value from a non-rationalist is, instead, to leave him not knowing whether you’ve broken yet, which means you have to minimize your smell (of defeat, resentment, hatred, or adversity). Are you intact, or is your stink very mild? You just can’t stink, if you want to negotiate from a position of strength, no matter how badly you’ve been broken. Breaks will heal; stink is permanent.

Okay, we now have an understanding that allows us to understand the non-rationalists that we either answer to, or answer to people who answer to. That’s a start. Now I’m going to talk about the bane of programmers: impromptu status checks. I’m not talking about necessary communication, as would occur during a production crisis, nor about planned standups (which are painful when poorly run, but at least scheduled). I’m talking about the unplanned and involuntary games of 52-Card Pickup that managers inflict on us when they’re bored. Mention status pings to a software engineer, and it’s like you just uttered a racial slur. We fucking hate hate hate hate hate those with a +8 modifier to Anger. I call it “email syndrome”. Email can be checked 74 times per day with no degradation to performance. Making the same assumption about a person is a terrible idea. For an engineer, one impromptu status ping per day is an order of magnitude too much (during normal circumstances). If you really need daily status information (and you shouldn’t; you should trust people to do their jobs) then run a scheduled standup for which people can prepare. It’s just disrespectful to put people on trial, constantly, without their having the right to prepare.

I used to take a Hanlon-esque approach to status pings. (Hanlon’s Razor is “never attribute to malice what can be explained by benign incompetence.”) Now, my attitude is more cynical. Why? Because the first thing you learn in Technology Management 101 is that engineers can’t fucking stand impromptu status pings. Our feeling on this is simple: if you really don’t trust us with hours and days of our own fucking time, then don’t hire us. It’s that simple and, not only that, but most technology managers know that programmers hate these utterly pointless status checks. If we wanted to be interrupted to feed babies, we’d have our own.

So what’s the real point of an impromptu status check? You know that Carlin-esque phenomenon where you look at your watch but don’t read it, then have to look again because you didn’t catch what time it was? That’s exactly how managers’ impromptu status checks work. It’s not actually about project status. No one has any clue how long things “should” take anyway; on that, the world is split between people who know they don’t know and people who don’t know that they don’t know. It’s about making a manager feel secure. You have two jobs. One is to make the manager feel important; the whole reason he is interrupting you is because to establish that he can, and your job is that of an actor. The other is to make him feel like you are not slacking, and that aspect of it (lack of trust) is goddamn insulting. Again, I’m not talking about a production crisis that might actually merit such a fast audit-cycle. I’m talking about 2-20 status pings per week during peace time. It’s painful and wrong and the context-switches drop productivity to zero.

Why don’t managers intuitively understand this? I’m going to paint management in the best possible light. They’re salesmen. That’s not a pejorative. Far from it. That’s a valuable function, especially because while trust sparsity is horrible as a matter of policy, it tends to be somewhat inevitable, and salesmen are the best people at breaking down trust sparsity. They sell their superiors on their ability to deliver a project. They (if they’re good) sell their reports on the value of the project to their careers. All day, they’re selling someone on something. So they’re in Sales Mode constantly, and that is their flow. For a manager, a status ping is a welcome break: a chance to have someone else do the selling (i.e. prove that he hasn’t wasted the previous 3.37 hours of working time) to them. For the programmer, though, it’s a sudden and unexpected jerk into Sales Mode, which is a different state of consciousness from Building Mode. Both kinds of flow have their charms and can be a lot of fun, but mixing the two is both ineffective and miserable, especially when not by one’s choice.

If these status pings are so horrible, then why are there so many programming environments in which they’re common? Well, most managers are non-rationalists, and non-rationalists are all about emotion, perception, and superficial loyalty. Again, remember that question, and that test: does this guy stink when he breaks? Is his attitude (that he’s feeding an impulsive toddler) evident? Does his face show a look of enmity or defeat? Does he make eye contact with the boss or with the computer screen? What’s his posture? What’s his tone of voice?

Of course, it’s these status checks have negative value as an assessment of project progress, because the signal is going to be opposite of the truth. Employees pass these impromptu status checks when they’re prepared, and that means they aren’t doing any real work. They fail (because they’re pissed off about the interruption) when they’re actually getting something accomplished. That, however, is not what they’re really about. The manager will forget everything you told him, 15 minutes later. (That’s part of why status checks are so fucking infuriating; they’re about social status, not project progress.) They’re about not stinking when you break. It doesn’t matter what you got done in the past few hours, but you need to show an ability to communicate progress without getting pissed off about the indignity of a tight audit cycle and hope, for fuck’s sake, that either he’ll start to trust you more or that you’ll be able to get a different manager.

What’s the solution? Well, there are two kinds of status checks. The first kind is the simple kind that doesn’t involve follow-on questions. I think the solution is obvious. Write down a sentence about what you’ve accomplished, every 30 minutes or so. Maybe this could be integrated with the Pomodoro technique. Now you have a story that can be read by rote and don’t have to you don’t have to deal with the social and emotional overhead of a sudden switch into Sales Mode. You’re prepared. That will work as long as there aren’t follow-on questions; if there are, then it’s the second kind of status check.The second kind is the cavity search that comes from a manager who just has nothing else to do. I think the only solution in that case (unless it’s rare) is to change companies.