“Don’t Worry”

How two words and once sentence made me who I am today.

Ten years ago the team sat down in a boardroom with expectations to plan the next major release of our software.  The entire team was there.  Release managers, business managers, engineers, testers, & documenters.  The business managers gave the “here’s what we’re going to build” pitch.  The release managers outlined the strategy.  Everyone else asked questions until we were clear on the general aspects of the release.

After the preliminaries we were instructed to provide estimates for our forthcoming work.  At the time it made sense.  They needed to know how long the project would take so that they could see if the work could be completed before the expected release date.  One manager stood at the whiteboard and walked through the various features and core components of the product.  For each work item he suggested a coworker who could work on it.  After some discussion, the assigned worker would provide an estimate in number of days.  We would log the estimate and then continue to the next item on the list.

This was the first time I had seen this done.  I was a new engineer to the company, as were most of the engineers on the team back then.  The manager had lots of experience and was guiding the flow of the meeting as seasoned managers should.  In the two years since I joined the company I had never seen this done.  We had meetings before to discuss the plan and how long it would take, but never with the entire team, and at that point, never with such detail.  I remembered I was excited.  I thought “We’re going to do great this time”.

Then something interesting happened.

Eventually it was my turn.  The manager stated that the preferences module needed some work and suggested that I take it on.  I agreed.  It was an area of the product that I had little knowledge of, so I was happy to do the work.  Then he asked “How long so you think it would take”?  I thought about it and asked some questions about the work.  I received answers and then I asked some more.  After a few more minutes of Q&A I could see some people in the room were getting annoyed.  Everyone had provided answers in a few minutes, and I was taking longer.

Eventually another engineer joined the manager at the whiteboard in an attempt to hurry the conversation.  I was resistant to provide any estimate because I had never worked in the code before and was not comfortable given the information I was provided.  I said “How can I give a number for something I haven’t seen before”?  To this day I have never forgotten the reply I received: “Don’t worry.  It doesn’t matter.  Just give a number”.

My heart felt like it hit the floor, everything else in the room faded, my eyes glazed over, and I blurted out a number.

There are two things I remember about that day.  The first was the disappointment in me for providing an estimate for something I knew nothing about.  The second was my reaction.  It was so sudden, vivid, and all encompassing.  Going forward I attributed my reaction to ‘just being angry at myself’.  It would not be until recently that I truly understood why I reacted the way I did.

—

Two years ago, the team was undergoing a new exercise.  We were exploring the thoughts and opinions of each other to understand our strengths, weaknesses, personal brand (how other see us), and our triggers (what enables us).  The goal was to understand each other so that we could improve ourselves and how we worked with each other.  It was a fun series of exercises that opened my eyes to my coworkers.  I learned as much about them as I did myself.  As we explored the subject of triggers, I thought back to that day when I provided my estimate, and after some thought, I finally realized what enabled my response.  It was not the fact that I was disappointed in myself.  It was something more obvious and mundane.  It was the word ‘”Don’t”.

It seems kind of odd that a single word could trigger such an acute response.  Then again, my coworkers described similar responses to things that triggered them.  They would become blinded to other influences, focused on the thing or person that triggered them, and emotionally involved themselves with what caused the trigger.  Triggers are neither good nor bad.  They are simply the things that enable us.  Understanding our triggers helps us understand why we react to certain influences the way we do.  The benefit in our coworkers knowing them is that they gain insight which helps them work more effectively with each other.  We can understand why we do and say the things we say.  In other words, we understand each other.

While I know that “don’t” triggers me, I am not clear on why it does.  My theory is that “don’t” is a limiting word, kind of like a virtual wall.  I am the kind of person who likes to challenge the status-quo and look to new and improved ways of accomplishing things.  Perhaps I see “don’t” as a barrier to be broken.

Overall I find that my triggers are very helpful.  They enable me to find alternative routes, identify root causes, and locate opportunities for improvement.  The down side is that there are days when I encounter so many triggers that I go to bed exhausted.  In my opinion, it is a small price to pay.

———-8<—————————————————–

I have learned that there are three things that instantly trigger my attention: two words and one sentence:

1. Can’t
2. Don’t
3. and people who complain but do nothing

What are your triggers?

‘The’ Lifetime Activity

Why the approach to code reviews is all wrong.

Today we perform code reviews before we check-in to the source repository.  It was not always been that way.  I can remember when code reviews were first formally introduced to the company.  The response from the team was generally skeptical.  Team members were concerned that it would slow down development, not produce measurable improvement, & act as a distraction from other high-priority activities.  I support Demings idea that “an organization does not simply need good people, but people that are improving with education”.  The team came through on this point because today we cannot imagine any team not leveraging code reviews in its day-to-day activities.

The other day I was thinking about our practices regarding code reviews and why we execute them the way we do.  After repeatedly asking myself many questions that started with ‘why’ & ‘how’, it occurred to me that perhaps our perspective on code reviews is narrow, misguided, and thus limiting new opportunities to improve the team & code base.

Allow me to explain.

There are many different types of code reviews:

There is the ‘shoulder check’ where a couple engineers informally review changes in the code and asks questions while providing feedback.  This is the most common type of review in our company.

From time to time we also have ‘formal reviews’, where a group of engineers simultaneously review code as the author walks them through it.  Typically this is reserved for large scale changes in critical areas of the code and is very time consuming.

Occasionally we participate in ‘paired programming’ where code reviews happen on-the-fly as the code is written.  This is the fastest way that I know of to remove defects as they are created.

There are other varying types of reviews, and my goal here is not to list them all, but to provide some insight on their nature.  Code reviews are formal or informal, fast or time consuming, on-the-fly or planned, executed by the individual or in groups.  It is no wonder that when people hear about code reviews for the first time that they are apprehensive.  Depending on what kind of review you practice, your experiences and opinions may be different from your team mates.

Given such variation, I think that the common premise, that code reviews are mechanisms to locate and remove defects, is inaccurate and limiting in perspective.  While the outcome is less defects and improved quality, this is merely a side effect of the true nature of code reviews:

“To learn”

Ask any engineer or manager today what the goal of code reviews is and they will likely respond “to find and remove defects”.  In reality, code reviews are much more than this.  Not only do we want the code to be improved, but we also want the participants to improve as well.  If improvement did not occur, the same type of defects would manifest again and again.  Then, as the code base grows, reviews become longer because the ratio of defects per line of code increases, and the business suffers due to the increased effort to identify and remove defects.

This is not a desirable outcome.  We want those we work with to learn and understand why a change is needed.  This growth improves not only the individual, but also the team, and eventually the company.  People who regularly learn about how to avoid certain errors, will write better code.  People who write better code can pass those learning’s on to others through other code reviews.  Eventually, the network reaches everyone, and productivity is improved.  But to do this, you must have the mindset of a learner and not a teacher.

Teaching is a natural outcome of a learning mindset.  If I approach a code review with the mindset that I will find all of the defects, then I make statements like ‘This code should be extracted in to its own method and because of this reason’.  If I have a learners mindset then I ask ‘Can you tell me about how this code works in this context?’, or ‘Are there any opportunities to refactor this code?’.  The difference is subtle, but powerful.  Instead of directing to the solution I think is the best, I engage in open-ended conversation.  This allows the author of the code to provide his or her perspective, which is different from my own.  In turn I gain insight and understanding, which may or may not, sway my initial assessment of the code.  We exchange comments and ideas, and perhaps the code is changed to remove a defect.  Perhaps my assumptions are challenged when I learn something new.  More importantly, we walk away from the review more knowledgeable than when we started.  One or both of us have learned something that we can carry in to our next code review.

Not all code reviews will be that cut-and-dry.  That isn’t my point.  I wanted to point out the contrast between a review with the aim to find defects, and one aiming to learn from each other.  You will find defects and have the author correct them, but does the author understand how not to introduce the same defect again?  How do you know the author was attempting to express an idea, one that would have taken the code down a different and better path than the one you stated?  Don’t get me wrong.  You will have successful reviews with a ‘find the defect’ mindset.  I’m saying that you and your team won’t be as successful unless you adopt a learning mindset.

Code reviews are about learning, and learning is a lifetime activity.