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