The Clean Coder: Saying Yes
This chapter is from the book
This chapter is from the book
This chapter is from the book
)
Did you know that I invented voice mail? It’s true. Actually there were three of us who held the patent for voice mail. Ken Finder, Jerry Fitzpatrick, and I. It was in the very early 80s, and we worked for a company named Teradyne. Our CEO had commissioned us to come up with a new kind of product, and we invented “The Electronic Receptionist,” or ER for short.
You all know what ER is. ER is one of those horrible machines that answers the phone at companies and asks you all kinds of brain-dead questions that you need to answer by pressing buttons. (“For English, press 1.”)
Our ER would answer the phone for a company and ask you to dial the name of the person you wanted. It would ask you to pronounce your name, and then it would call the person in question. It would announce the call and ask whether it should be accepted. If so, it would connect the call and drop off.
You could tell ER where you were. You could give it several phone numbers to try. So if you were in someone else’s office, ER could find you. If you were at home, ER could find you. If you were in a different city, ER could find you. And, in the end, if ER could not find you, it would take a message. That’s where the voice mail came in.
Oddly enough, Teradyne could not figure out how to sell ER. The project ran out of budget and was morphed into something we knew how to sell—CDS, The Craft Dispatch System, for dispatching telephone repairmen to their next job. And Teradyne also dropped the patent without telling us. (!) The current patent holder filed three months after we did. (!!)1
Long after the morphing of ER into CDS, but long before I found out that the patent had been dropped. I waited in a tree for the CEO of the company. We had a big oak tree outside the front of the building. I climbed it and waited for his Jaguar to pull in. I met him at the door and asked for a few minutes. He obliged.
I told him we really needed to start up the ER project again. I told him I was sure it could make money. He surprised me by saying, “OK Bob, work up a plan. Show me how I can make money. If you do, and I believe it, I’ll start up ER again.”
I hadn’t expected that. I had expected him to say, “You’re right Bob. I’m going to start that project up again, and I’m going to figure out how to make money at it.” But no. He put the burden back on me. And it was a burden I was ambivalent about. After all, I was a software guy, not a money guy. I wanted to work on the ER project, not be responsible for profit and loss. But I didn’t want to show my ambivalence. So I thanked him and left his office with these words:
“Thanks Russ. I’m committed . . . I guess.”
With that, let me introduce you to Roy Osherove, who will tell you just how pathetic that statement was.
A Language of Commitment
By Roy Osherove
Say. Mean. Do.
There are three parts to making a commitment.
- You say you’ll do it.
- You mean it.
- You actually do it.
But how often do we encounter other people (not ourselves, of course!) who never go all the way with these three stages?
- You ask the IT guy why the network is so slow and he says “Yeah. We really need to get some new routers.” And you know nothing will ever happen in that category.
- You ask a team member to run some manual tests before checking in the source code, and he replies, “Sure. I hope to get to it by the end of the day.” And somehow you feel that you’ll need to ask tomorrow if any testing really took place before check-in.
- Your boss wanders into the room and mumbles, “we have to move faster.” And you know he really means YOU have to move faster. He’s not going to do anything about it.
There are very few people who, when they say something, they mean it and then actually get it done. There are some who will say things and mean them, but they never get it done. And there are far more people who promise things and don’t even mean to do them. Ever heard someone say, “Man, I really need to lose some weight,” and you knew they are not going to do anything about it? It happens all the time.
Why do we keep getting that strange feeling that, most of the time, people aren’t really committed to getting something done?
Worse, often our intuition can fail us. Sometimes we’d like to believe someone really means what they say when they really don’t. We’d like to believe a developer when they say, pressed to the corner, that they can finish that two-week task in one week instead, but we shouldn’t.
Instead of trusting our guts, we can use some language-related tricks to try and figure out if people really mean what they say. And by changing what we say, we can start taking care of steps 1 and 2 of the previous list on our own. When we say we will commit to something, and we need to mean it.
Recognizing Lack of Commitment
We should look at the language we use when we commit to doing something, as the tell-tale sign of things to come. Actually, it’s more a matter of looking for specific words in what we say. If you can’t find those little magic words, chances are we don’t mean what we say, or we may not believe it to be feasible.
Here are some examples of words and phrases to look for that are telltale signs of noncommitment:
-
Need\should. “We need to get this done.” “I need to lose weight.” “Someone should make that happen.”
-
Hope\wish. “I hope to get this done by tomorrow.” “I hope we can meet again some day.” “I wish I had time for that.” “I wish this computer was faster.”
-
Let’s. (not followed by “I . . .”) “Let’s meet sometime.” “Let’s finish this thing.”
As you start to look for these words you’ll see that you start spotting them almost everywhere around you, and even in things you say to others.
You’ll find we tend to be very busy not taking responsibility for things.
And that’s not okay when you or someone else relies on those promises as part of the job. You’ve taken the first step, though—start recognizing lack of commitment around you, and in you.
We heard what noncommitment sounds like. How do we recognize real commitment?
What Does Commitment Sound Like?
What’s common in the phrases of the previous section is that they either assume things are out of “my” hands or they don’t take personal responsibility. In each of these cases, people behave as if they were victims of a situation instead of in control of it.
The real truth is that you, personally, ALWAYS have something that’s under your control, so there is always something you can fully commit to doing.
The secret ingredient to recognizing real commitment is to look for sentences that sound like this: I will . . . by . . . (example: I will finish this by Tuesday.)
What’s important about this sentence? You’re stating a fact about something YOU will do with a clear end time. You’re not talking about anyone else but yourself. You’re talking about an action that you will take. You won’t “possibly” take it, or “might get to it”; you will achieve it.
There is (technically) no way out of this verbal commitment. You said you’ll do it and now only a binary result is possible—you either get it done, or you don’t. If you don’t get it done, people can hold you up to your promises. You will feel bad about not doing it. You will feel awkward telling someone about not having done it (if that someone heard you promise you will).
Scary, isn’t it?
You’re taking full responsibility for something, in front of an audience of at least one person. It’s not just you standing in front of the mirror, or the computer screen. It’s you, facing another human being, and saying you’ll do it. That’s the start of commitment. Putting yourself in the situation that forces you to do something.
You’ve changed the language you use to a language of commitment, and that will help you get through the next two stages: meaning it, and following through.
Here are a number of reasons you might not mean it, or follow through, with some solutions.
It wouldn’t work because I rely on person X to get this done
You can only commit to things that you have full control of. For example, if your goal is to finish a module that also depends on another team, you can’t commit to finish the module with full integration with the other team. But you can commit to specific actions that will bring you to your target. You could:
- Sit down for an hour with Gary from the infrastructure team to understand your dependencies.
- Create an interface that abstracts your module’s dependency from the other team’s infrastructure.
- Meet at least three times this week with the build guy to make sure your changes work well in the company’s build system.
- Create your own personal build that runs your integration tests for the module.
See the difference?
If the end goal depends on someone else, you should commit to specific actions that bring you closer to the end goal.
It wouldn’t work because I don’t really know if it can be done
If it can’t be done, you can still commit to actions that will bring you closer to the target. Finding out if it can be done can be one of the actions to commit to!
Instead of committing to fix all 25 remaining bugs before the release (which may not be possible), you can commit to these specific actions that bring you closer to that goal:
- Go through all 25 bugs and try to recreate them.
- Sit down with the QA who found each bug to see a repro of that bug.
- Spend all the time you have this week trying to fix each bug.
It wouldn’t work because sometimes I just won’t make it
That happens. Something unexpected might happen, and that’s life. But you still want to live up to expectations. In that case, it’s time to change the expectations, as soon as possible.
If you can’t make your commitment, the most important thing is to raise a red flag as soon as possible to whoever you committed to.
The earlier you raise the flag to all stakeholders, the more likely there will be time for the team to stop, reassess the current actions being taken, and decide if something can be done or changed (in terms of priorities, for example). By doing this, your commitment can still be fulfilled, or you can change to a different commitment.
Some examples are:
- If you set a meeting for noon at a cafe downtown with a colleague and you get stuck in traffic, you doubt you’ll be able to follow through on your commitment to be there on time. You can call your colleague as soon as you realize you might be late, and let them know. Maybe you can find a closer place to meet, or perhaps postpone the meeting.
- If you committed to solving a bug you thought was solvable and you realize at some point the bug is much more hideous than previously thought, you can raise the flag. The team can then decide on a course of action to make that commitment (pairing, spiking on potential solutions, brainstorming) or change the priority and move you over to another simpler bug.
One important point here is: If you don’t tell anyone about the potential problem as soon as possible, you’re not giving anyone a chance to help you follow through on your commitment.
Summary
Creating a language of commitment may sound a bit scary, but it can help solve many of the communication problems programmers face today—estimations, deadlines, and face-to-face communication mishaps. You’ll be taken as a serious developer who lives up to their word, and that’s one of the best things you can hope for in our industry.