Payson Hall broke onto the software development scene as a maverick programmer, but his penchant for imposing his ideals onto others created more enemies than allies and sometimes detracted from product quality. In this week's column, a more experienced Payson recalls how he exchanged hubris for humility and shares lessons learned during his transformation that help him craft constructive reviews.
My persona and priorities have changed since my debut as a hotshot programmer in 1980. When my career began, I had raw talent, passion for building "quality systems," an ego slightly larger than West Virginia, and no patience for people who were stupid, lazy, or who didn't appreciate my definition of "quality." I'm sure there were occasions when I was more trouble than I was worth. (In fact, I would like to take this opportunity to apologize to people I offended needlessly and to thank the mentors who put up with me and helped me mature as a developer and project manager.)
The graying of my hair has accompanied a shift from programmer to mentor, from architect to consultant, from "doer" to "reviewer." When I participate in technical reviews today, I can't advise techies on subtleties of applying the latest technology, but often I do ask what I think are useful questions about the problems they are trying to solve. There are two aspects to good questions: what you ask and how you ask it. My inquiry skills come from lessons learned the hard way about the nature of systems and about how people respond to questions. My goal this visit is to share some of what I've learned with you.
System lessons that seem eternally relevant include:
- Data that exists in two places will be wrong in at least one place--mechanisms must exist to detect and resolve those conflicts.
- Interface definitions are prone to ambiguity and need special attention.
- Return codes should always be checked.
- Systems designed for maximum efficiency are usually complex, unreliable, difficult to maintain, and ultimately inefficient.
- Systems designed to be simple are frequently efficient, reliable, and easier to maintain.
- It's easy to make things complex.
- It's difficult to make things simple.
- Systems should be designed with testing and maintenance in mind.
People lessons that guide my questions include:
- Most people are doing their best to solve the problems confronting them.
- People don't fail on purpose.
- Most people care about doing quality work.
- There can be legitimately different opinions about what constitutes "quality" in a given context.
- Everyone has an ego.
- No one likes to feel attacked.
The system lessons above may seem obvious; the people lessons are every bit as powerful and are easy to undervalue. I didn't really understand how important these "people principles" were twenty-five years ago, and I broke a lot of glass as a consequence--offending peers needlessly, fighting battles I didn't need to fight, wasting time and resources, and delivering systems that didn't work as well as they might have.
These lessons guide me when I participate in reviews of systems or projects today. Here are some tips about asking questions in reviews that you may find increase your effectiveness.
THE BIG TRUTH: Avoid attacking; it makes people defensive. Knowledge workers put a bit of themselves into every product they create. Consequently, people are naturally sensitive to reviews of their work. I find I'm less ego-involved and more open to new ideas and constructive criticism as I mature, but I still wince when someone harshly criticizes my work. It is easy to confuse an attack on your work product with an attack on you. The harsher the criticism, the harder it is not to take it personally. This doesn't mean we should let bad ideas slide to avoid hurting people's feelings, but it underscores the importance of these considerations when giving feedback:
- It is best to assume there is a legitimate reason for what you see. When you see something that looks silly or wrong, keep your opinion to yourself and try to ask a balanced question aimed at understanding why things are the way they are. Inquire, don't challenge. This approach respects the person whose work is being reviewed and protects you against looking stupid if it turns out there is a good reason that you didn't recognize during your review.
- Don't be condescending or sarcastic. I'm a big fan of humor in the workplace, and reviews are no exception, but avoid humor at the expense of the author.
- Look for unstated assumptions. Some of the most heated arguments I've seen resulted from people who thought they disagreed, but were really working with different assumptions about the problem they were trying to solve. Recognizing assumptions and making them explicit (writing them down) is a vital skill and helps keep disagreements civil.
- Avoid proclamations; ask questions instead. A little diplomacy can go a long way toward focusing on the issue at hand without having to deal with a messy and needless "attack and defend dance." Rather than saying, "This will fail if condition X occurs," consider instead asking, "Is condition X likely to occur? How would the system behave if it did?" This approach makes finding a product's weak points a collaborative problem-solving effort, rather than a contest of one-upmanship.
- Be clear about what constitutes a "bad" idea. Is the product unsuccessful in achieving its purpose? Does it fail to meet a real standard for efficiency, maintainability, simplicity, or style (as opposed to your personal preference)? Debating style preferences can be damaging as well as futile--who cares whether you might have done something differently? If you perceive a slight weakness that is clearly not fatal, consider discussing style choices with the author offline rather than in a room full of people. Be on the lookout for peers discussing style rather than substance and do what you can to help keep the team focused on material considerations.
- Choose your battles. How "bad" is the idea? If each issue potentially escalates tensions and each escalation increases the chance that the review will derail and fail to accomplish its goals, then be judicious in your observations and prioritize your feedback based on the overall goals of the review. It's generally a waste of time to worry about spelling errors in a program's comment block when the focus of the review is to determine whether the program will work and can be maintained.
- Remember the Golden Rule: Treat others as you would like to be treated. I appreciate it when my errors are pointed out, because I care about producing quality work products. I appreciate when suggestions or criticism are offered gently, because I am a human being (despite evidence to the contrary in my early days).
Do what you can to make reviews constructive. Be clear that you are not commenting on the author when offering feedback--you are making observations and asking questions about the work product with the purpose of understanding the choices made and assuring the suitability of the work product for its intended purpose. Always seek to treat the author with courtesy and respect. Keeping this perspective in mind is a little thing that can make a big difference.
Finally, be patient and try to set a good example for any brash jerks participating in the review. With mentoring and experience, they might even become productive members of the team some day.
