The Exceptions We Don't Catch in Technical Conversations

Emin Martinian

Project failures are Sociological

From Peopleware by DeMarco and Lister:

  • "The major problems of our work are not so much technological as sociological"
  • "For the overwhelming majority of the bankrupt projects we studied, there was not a single technological issue to explain the failure."

People Skills

The Zen of Python says: 

There should be one-- and preferably only one --obvious way to do it.
  • I really like that idea in programming
  • People are different; I don't know one best way to communicate
  • Goal: Discuss conversational mistakes to improve conversations

Example Conversation

Speech bubble X-ray part 1: the surface A confident stick figure makes what seems like a straightforward factual comment during a code review. It looks harmless. Layer 1 This code is confusing. Too many class hierarchy levels.

Hidden eval()

Speech bubble X-ray part 2: hidden evaluations revealed The same speech bubble is now shown with an X-ray revealing hidden criticisms. The listener has become defensive - arms up, leaning back. Layer 1 This code is confusing. Too many levels in the hierarchy. I am the authority on class hierarchy Your code is bad/wrong/junk/useless You don't know what you're doing

eval() Really is Dangerous

  • Originally from Ned Batchelder blog post 2012-06-06
    • can produce unexpected behavior on someone else's system
  • … dangerous in conversations too!
  • People eval() our words with different local variables.
  • We sometimes state "facts" that are actually evaluations
    • or depend on local variables the other person doesn't have.
  • These hidden evaluations may contain implicit criticism.

What To Do?

  • Just "be nice"?
  • Need to be able to have honest technical discussions
  • … including disagreements

Alternative: "I Statements"

Instead of using hidden evaluations:

  • This code is confusing.
  • I find this code confusing.
  • More accurate
  • … and more collaborative.

Blame Inhibits Ownership

Weak references part 2: the defensive response The right figure is now defensive with crossed arms, firing back. Both are now blaming each other. Layer 1 your fault Obviously bad code You don't understand your fault

Who Owns The Problem?

Both parties blame the other:

  • I think you wrote badly designed classes
    • implying you have a problem with your code
  • You think I don't understand the design
    • implying I have a problem with my comprehension

Owning the Problem

Speech bubble part 3: the safe alternative with I-statements The speaker uses I-statements instead. The listener remains open and curious. No defensiveness triggered. No hidden eval() Clearly owns my problem "Good question... let me explain" "I find this code confusing. I'm curious why you chose this approach for the hierarchy?" Allows other person achoice to take ownership Speech bubble part 3: the safe alternative with I-statements

Owning a Different Problem

  • "I do not feel comfortable using this code"
  • "I will not accept this pull request"
  • "This is not what I agreed to with the customer"
  • If you must eval() / disagree / argue / yell
    • … at least do it accurately and intentionally!

Autonomy

  • If the other engineer takes ownership, they choose the solution
    • Maybe better docs, not a rewrite
    • Maybe more examples or tests
  • Autonomy ⇒ motivation ⇒ better outcomes
  • Micro-managing a solution rarely works

Weak References to Problems

  • I think you wrote bad code; you think I'm an idiot
  • Neither of us owns the problem; we each hold a weak reference
  • The problem gets garbage collected
    • removed from team memory instead of solved

If you want a problem solved, it needs strong, clear ownership

Is This Formulaic and Fake?

I'm curious ... I'm confused about ... I'd like to know ...

Is this just sugar coating? Yes       ... and No

  • Genuine warmth, empathy, curiosity, etc., are better
  • Ownership & I statements provide meta-data (softer tone)
  • Formulas can reframe thinking: We are what we repeatedly do

ValueError: Expected Curiosity, Got Defensiveness

ValueError: Expected Curiosity, Got Defensiveness

Traceback (most recent call last):
  File "feedback.py", line 3, in deliver
    result = discuss(their_work, tone='blame')
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Invalid tone 'blame' for discuss():
    'blame' produces defensiveness;
    tone must be one of: 
      'empathy', 'respect', 'curiosity'

Legal Case Anti-Pattern

  • Imagining what the other person might say in response
  • Spending hours building an airtight argument with all the facts
  • You can sometimes force compliance, but can't force interest

The Big Red Button

  • Attacking someone presses the "engage defenses" button
  • It doesn't matter how right I am once the button is pressed
    • everything after that is unreachable code
  • Instead: keep the conversation open
    • Ideally get them to be curious about my point of view
    • Start by being warm, respectful, and curious myself

ImportError

ImportError: Cannot Import 'you' from 'teammate'
  • We partner with people who have complementary strengths
  • Then we get frustrated when they are weak where we are strong

Complementary Strengths Example

  • I'm good at architecture but slow/incomplete at writing tests
  • I partner with someone who quickly produces high coverage tests
  • Their test infrastructure duplicates code and not re-usable
  • I think: "Why didn't they just do XYZ? It's obvious!"

"Average Familiarity" (XKCD 2501)

Even when they're trying to compensate for it, experts in anything wildly overestimate the average person's familiarity with their field.

The Trap

  • We easily see other person's shortcomings in our area of strength
  • We're confused and annoyed by it — "Isn't this obvious?"
  • Step 1: Be aware that this cognitive trap exists

Reframing ≈ Refactoring

  • "Why does framing matter? Only facts and reality matter!"
  • Positive thinking doesn't make bugs go away…
  • But reframing is like refactoring code
    • Code that "works" but you rewrite it anyway
    • Express your intent better, improve flexibility, prevent bugs
  • Periodic mental refactoring can prevent conversational mistakes

Zen of People Depends on People

Ideas inspired by the Zen of Python:

  1. Hidden evaluations are dangerous
  2. Explicit ownership is better than implicit blame.
  3. Curiosity is better than defensiveness.
  4. Trying to appreciate other perspectives is one honking great idea.

References

Questions?

Chemical Formula for Olivine

https://www.alexstrekeisen.it/english/vulc/olivine.php

Chemical Formula for Feldspar

By Muskid - Own work, CC BY-SA 4.0, Link
flowchart shape Nicu Buculei Nicu Buculei Nicu Buculei image/svg+xml en miscibility gap Sanidine Anorthoclase Albite Oligoclase Andesine Labradorite Bytownite Anorthite AlbiteNaAlSi3O8 AnorthiteCaAl2Si2O8 Orthoclaseand MicroclineKAlSi3O8 Plagioclase feldsparsNaxCa1-xAl2-xSi2+xO8 Alkali feldsparsNaxK1-xAlSi3O8 Ab An Or 0-10 An% 10-30 An% 30-50 An% 50-70 An% 70-90 An% 90-100 An%

Chemical Formula for Quartz

Si O2 (of course)