True Story: “The Code Can’t Do That”

When I was testing at Microsoft, a lot of the developers on our team would get to work around noon, and then work late into the night. Our builds came out around 8:00 am, though, so it worked out really well for me to show up early, and by the time I had most of a day’s worth of testing done, the devs were caught up on their email but hadn’t really settled into their coding. So I’d visit each dev in person and let them know what I’d worked on that day and what bugs I’d found in their features. That way I got the first round of questions and clarifications taken care of *before* I entered bugs into the tracking system, and so when I did enter them, they were clearer, more useful, and much less likely to come back to me as “tester error” or “by design”.

Except for that one guy. Every single time I brought him a bug, his instant reaction was, “the code can’t do that.” Not “are you sure?” or even “it works on my machine”, but a flat, “that can’t happen”. Every time. For dozens of bugs, over a period of several weeks.

The first couple of times, I said, “well, I’ll check it again and get back to you”, but I am and was a pretty careful tester, and I don’t usually report a bug until I’ve seen it repro and have good steps. So pretty soon, I started saying, “Can you come down to the lab with me and show me what I’m doing wrong, please?” which, happily, he was willing to do.

Once I had him in the lab, I went through my repro steps, showed him the behavior, and let him think about it for a minute. Almost invariably, he would say, “I know why that happened” and go fix it (because he really was a very good developer, he just had this problem). Eventually, he got to the point where he’d actually consider my bugs without me having to walk him through them, but only because I’d gone to the effort of figuring out how to overcome his mistrust.

The principles in play here are:
1) Being Right–We had two directly contradictory statements–“the code does this” vs. “the code cannot do that”. No amount of debate sitting in someone’s office can possibly settle a “he-said, I-said” argument, and the more you shout, the more the technical person is going to dig in his heels.

2) Solving Problems–Once I granted the developer the correctness high ground–“please show me what I did wrong”, I put him in the position of being right and of helping me solve “my” problem. It also got him into my lab space, where I didn’t have to rely on my say-so for the existence of the behavior.

3) Control What You Can Control–I can’t make the developer admit there’s a bug. I can, however, show him the bug, and let his own problem-solving tendency take him from “there isn’t a problem” to “I can solve that problem”.

4) Trust And Honesty–Over time (remember, this scenario played out many, many times over an extended period), by respecting his position, by seeking solutions instead of confrontations, and by making sure I had all my ducks in a row before I went to him, I eventually taught the developer that he could rely on me not to waste his time, and not to bring him spurious bugs. Eventually, the trip to the lab became unnecessary unless he actually needed to get his hands on the debugger.

Posted in Stories with Lessons | Leave a comment

The Principles

The story-and-moral format I’m planning for this blog works very well with my writing style, but might make for some difficulty in tracking down the essential principles I work from. So, as with the Lexicon, I’ve created a living post that collects my basic approach to dealing with technical folk. Feel free to suggest additions or request clarifications.

Control What You Can Control
The Principle: Technical people have spent decades building their habits and attitudes, both good and bad. The effort and energy it would take to change them, if it’s possible at all, is so great that it’s almost always more efficient to learn how to deal with the existing situation than to force it toward the ideal.
The Approach: Don’t take it personally when the technical people around you seem like jerks. For the most part, it really doesn’t have anything to do with you. Instead, learn their hooks and handles, and figure out how they need you to work with them. We’re here to get a job done, and the only ego you can keep under control is your own. Do what’s actually possible, and let the rest go.

Being Right
The Principle: Technical people have a great deal invested in “being right”, and in being the smartest person in the room. It’s the primary status marker in the technical social hierarchy. What this means is that every time you suggest that someone is wrong, you are attacking their status, their intelligence, and their place in the hierarchy. Folks can get very defensive very fast, and if you manage to force them to admit that they’re wrong, the resentment can quickly build to the point where the working relationship is destroyed.
The Approach: Judo, or at least the popular conception of judo, is your model here. Never attack. Redirect their defensive pushback into something constructive. Present your findings in an impersonal way, and ask for their help in solving the issue. The difference between a status-degrading criticism and a status-enhancing request is all in your framing of the issue.

Interpersonal Skills
The Principle: There is a very high correlation between technical aptitude and poor socialization. There are a variety of explanations for this. Some people with poor social skills gravitate to fields where those skills are less emphasized. Some people are drawn to technical fields early and just never develop the softer skills. There is a high incidence of self-diagnosed autism-spectrum disorders among technical people, which allows them to tell themselves that poor social skills are not only acceptable but desirable, because they’ve spent their efforts on building the “important” skills instead. But for whatever reason, as you deal with technical people, you are going to run into a lot of them who just don’t know or care how to interact with others in a constructive way.
The Approach: This might be the toughest one of the lot; every person’s triggers and blind spots are different, so there isn’t a generalized approach that’s going to work for all situations. But if you go into the relationship with the attitude of finding the way to work together, and try not to take personally the inevitable bumps in the road, there’s an excellent chance you’ll develop a productive relationship.

Trust and Honesty
The Principle: Facts and concrete results are a technical person’s stock-in-trade. This leads to a worldview that is long on absolutes and very short on shades of grey. If a technical person finds out that you have lied to them once, it is very likely that they will never trust you again, and that working relations will be destroyed forever. Even “sociable” white lies can come back to bite you here.
The Approach: Never make a promise that you can’t keep. If circumstances change and you find yourself unable to live up to a commitment, be proactive in finding the person and explaining what has happened. Be open about difficulties. Never falsify your results. If you have to choose between honesty and sparing a technical person’s feelings, be honest. But remember, there’s a huge difference between being honest and being an asshole. Don’t be an asshole–there is usually a way to present a message without belittling or attacking someone.

Solving Problems
The Principle: Technical people love to solve problems–see above “Being Right”. Give a technical person a nice meaty problem to solve, and watch them go.
The Approach: “Hey, I’m having trouble with ‘X’. Can you help me/teach me/show me what I’m doing wrong?” Pretty much no matter what the problem is, asking a technical person for help is giving them an opportunity to Be Right and show their intelligence. In other words, you’re specifically asking them to build their status.

The Principle: Technical people work harder for people they respect, and who respect them, than they do for people who want to be their friends. And in fact, technical people form stronger friendships where there is mutual respect.
The Approach: You cannot make people respect you. You can, however, treat them with respect, and be the sort of person that they will respect. So, trust them to solve the problems you assign them. Give them honest feedback. Show your own technical ability, no matter what level it exists at–if it’s less than theirs, that lets them help you. If it’s greater than theirs, then they can learn from you.

Actual Harm, Harassment, and Abuse
The Principle: It’s all very well to learn to work around people’s idiosyncrasies; with technical folks, it’s often the only way to get the job done. But there is a line between “hard to work with” and “abusive”, and it doesn’t matter how technically competent someone is if their presence on the team damages the ability of the rest of the staff to do their jobs. Elitism, racism, and sexism are unfortunately endemic to the technical fields, and should not be tolerated there any more than in any other part of society.
The Approach: Watch your people’s interactions with others. To whom do they listen, and whom do they ignore? Do they tend to walk over others and/or belittle their contributions, either to their faces or behind their backs? Listen to your people; if you’ve built up trust and respect on your team, they may come to you with their concerns. Ask your people questions–“So-and-so seemed like they were stepping on what you were trying to say in the meeting; does that happen a lot?” Control your meetings–make sure that everyone who has something to say has a chance to say it, and don’t be afraid to call out someone who isn’t listening to or is actively quelling others’ input. If you find that you’re unable to keep someone reined in, talk to your HR representative if you have one; part of HR’s job is helping you work through these kinds of issues. In extreme cases, remember that at the end of the day, the important thing is getting the job done, and toxic co-workers can and should be replaced.

Posted in The Principles | Tagged | Leave a comment

Request for Requests

Reply to this post if you have a topic you’d like to see me address, questions you’d like me to answer, or a story you’d like me to tell.

Posted in Request for Requests | Tagged | Leave a comment


I use technical terms frequently in my writing, but I know not everyone reading is going to know what I’m talking about, and even when they’ve heard the term before, they may have heard it in a different context or with a different meaning. So in this living post, I will collect the technical terms I use and give definitions for them. If you encounter an unfamiliar term in one of my posts, you can look for it here. If you don’t find it, comment either on the post where you find it or here, and I will both respond to you with the definition and add that definition here in the lexicon.

Black-Box Testing: An environment where the tester has no access to the internal processes and rules used by a system. With black-box testing, initial testing must be exploratory, to determine the response of the system to any given input. (Contrast gray-box testing, white-box testing.)

Gray-Box Testing: An environment where the tester has access to some, but not all, of the internal processes and rules used by a system. With gray-box testing, some responses of the system to given inputs are known, but others must be discovered via exploratory testing. (Contrast black-box testing, white-box testing.)

White-Box Testing: An environment where the tester has full access to the internal processes and rules used by a system. With white-box testing, the expected response of the system to any given input is either known or derivable before testing begins. (Contrast black-box testing, gray-box testing.)

Posted in Lexicon | Tagged | Leave a comment

Rebirth and reinvention

The experiment with an artistic career has been over for years, and that’s why this space has been idle. The idea of a professional blog is still valid, though, so here we go again.

One of the things I’ve seen over and over in the business is managers who really don’t understand their people and how to get the best out of them. I have a lot of ideas about how to fix that, and I plan to share those ideas here. (I’ve certainly made my share of mistakes, so you can expect to see me deconstruct my own disasters at least as often as I call other managers out for theirs.)

My goal is to help people do a better job of hiring, developing, motivating, and retaining great technical people. (To be honest, I believe that most of the things I’ve learned working with techies are generally applicable to working with anybody, but I only have direct evidence for what I’ve done myself.)

Posted in Uncategorized | Leave a comment