rickgaribay.net

Space shuttles aren't built for rocket scientists, they're built for astronauts. The goal isn't the ship, its the moon.
posts - 302, comments - 180, trackbacks - 35

My Links

News

Where's Rick?


AgileAlliance deliver:Agile 2019- 4/29
Desert Code Camp, PHX - 10/11
VS Live Austin, TX - 6/3
VS Live SF - 6/17


About Me
Hands on leader, developer, architect specializing in the design and delivery of distributed systems in lean, agile environments with an emphasis in continuous improvement across people, process and technology. Speaker and published author with 18 years' experience leading the delivery of large and/or complex, high-impact distributed solutions in Retail, Intelligent Transportation, and Gaming & Hospitality.

I'm currently a Principal Engineer at Amazon, within the North America Consumer organization leading our global listings strategy that enable bulk and non-bulk listing experiences for our WW Selling Partners via apps, devices and APIs.

Full bio

Note: All postings on this site are my own and don’t necessarily represent my employer's position."



Check out my publications on Amazon Kindle!





Archives

Post Categories

Published Works

Monday, June 15, 2020

Words Matter (Now, more than ever)

It’s been a while since I posted here. This is likely due to laziness coupled with the fact that since joining Amazon over 5 years ago, most of my writing has become internally facing. Historically, this blog has been technical in nature. A place to share my learnings with the community and talk about the technologies I’m passionate about. I’ve bent this rule once. On the topic of Type 1 Diabetes in order to raise awareness and promote the work of organizations that are working hard everyday to find a cure.

I’m going to bend that rule again today, right now to talk about my learnings as pertains to the words I’ve used in the context of technology and how this words may have been, and continue to be hurtful to others. Before I go much further, I want to be clear that my goal with this post is not just to do my part as “another white dude” to help myself feel better or demonstrate that I’m somehow doing my part. Instead, in the spirit of this blog, and it’s relationship to technology, I want to share my personal struggles, growth and learnings over the last two weeks and encourage others to dig deep and consider doing the same.

“I feel like I’ve heard a lot of these from you.”

Last week, I got an instant message from a colleague I have worked closely with, respect and consider a friend. It shared a link to an internal wiki with a string of words: “I feel like I’ve heard a lot of these from you.” Anxiously, I clicked on the link to reveal a page created by one of our device UX teams entitled “Alternative Phrases”. It presented a table of terms commonly used in tech, a reference to the etymology and or article that explains how and why the term is offensive to some and a column including suggested alternatives.

Some of the terms in the table were unsurprisingly controversial: “Black List, White List”, “Master, Slave”. Terms I, like many others have used to describe how we might filter access to features or experiments or how to configure peripherals on a motherboard. For example, to allow traffic to a resource, we might build a “white list” to determine who can see the feature by account and consider anyone else on the “Black List”. In hardware architectures, when you would share a channel say for a hard drive and a DVD player, the “Master” device, say the hard drive would control when the “Slave” device, the DVD player could use the channel.

Within a minute, I replied back to my friend: “Wow. Yeah, need to do better.” To which he replied “Not trying to call you out or anything… I didn’t know a lot of them either.”

But that was it. I knew this was a moment and the task I had left to put a bow on my week would need to wait. I sat by myself in thought. I felt a mix of guilt and defensiveness, maybe some denial.

To be honest, I’d never quite thought about these terms as they have been so pervasive in software and computing. However, I need not think too hard about why “Master/Slave” would be insulting or offensive to many Blacks or African Americans who need only go back to their grandparents and great grandparent’s generation to realize the sting of this terrible scourge on our country’s history.

Regardless of how obviously or non-obviously controversial the terms are, the reality, and what I’ve had to reflect on and admit is that I used these terms anyway. Why? Because I never really thought much about them. I can make excuses that they were so commonly used and “didn’t mean any harm” but that’s no excuse. Words Matter. I’ll come back to this shortly.

“Whatever” you might be thinking. These are obvious. You sound like “just another white guy” [1] trying to join the conversation.

Here’s where it got hard, awkward and uncomfortable. While given the luxury of hindsight, these terms now seem like “duh”, there were a few other terms that really stood out to me: “Brown Bags”, “Tribal Knowledge” and, the one that really strung “Broken Window”. I struggled with each of these reflecting on my own mental model for these phrases.

  • “Brown Bag” to me simply referred to the sack lunches I took to school in middle school and high school once I’d outgrown my lunchbox. I had no idea that it referred to being “brown bagged” wherein servants/butlers would gauge a person’s whiteness by comparing their skin tone with a brown bag before determining if they could enter a private residence.
  • “Tribal Knowledge” is a phrase I’ve used countlessly in coaching teams to embrace documentation to avoid depending on their empirical knowledge and help them scale on particularly complex or esoteric topics. Also, as I get older, my “Tribal Knowledge” has been overwritten multiple times and docs, notes are key to make up form my middle aged brain :-)
  • “Broken Window” is a term I use so often that I even wrote an internal blog post just this February encouraging teams to catalog their technical debt so that they can reason about and pay it down in future sprints.

Reflection

Already, that internal wiki page had done its job. It made me stop and think. It made me uncomfortable.

I made a pact with myself right then and there that I would do better and embrace the alternative phrasing wherever possible and speak up when I heard them from others.

But, as importantly, I recognized that there was a related and equally important conversation to have. As I reflected on the suggested alternatives to “Broken Window” I was OK with all of them except for one: “Bug”. This was another moment where I recognized that if I was going to be true to myself, I would need to have this conversation.

First, a bit of background. In their excellent book “The Pragmatic Programmer: From Journeyman to Master” first published in 1999, the authors quote a Quarry worker's creed:

We who cut mere stones must always be envisioning cathedrals.

That preface had an impact on me before even getting into the wonderful book that really shaped my career. That quote was a reminder that my profession matters and the decisions I make, often encoded and interpreted by compilers matter. Having pride in your work maters. It also spoke to ownership and responsibility of me as a craftsman. The book goes deeper into the importance of thinking about trade-offs and taking ownership for those trade-offs and how not doing so leads to the accretion of technical debt that over time can be debilitating for a team to deliver customer value early and often. This can all be summarized with the following tip: “Don’t Live with Broken Windows: Fix bad designs, wrong decisions, and poor code when you see them.”

Taking it one step further, I encouraged teams to catalog these decisions as broken windows including teams at Amazon and clients I worked with previous to Amazon. In fact, I led the Engineering Excellence program at Neudesic and built guidance for field engineers including guidance docs and posters and mouse pads that summarize the guidance, all of which used or referred to the concept of broken windows and technical debt.

Words Matter: A Simple Rule

Now, I knew that “Broken Window” theory was rooted in criminology. This is described in a great interview here with the authors of the book. In short, the “Broken Windows Theory” is rooted in an article published in 1982 by social scientists which was rooted in an experiment done in 1969 by Philip Zimbardo, a Stanford psychologist. Zimbard performed an experiment by which he placed a car in the Bronx, NY and another in a suburb in Palo Alto, CA. The car in the Bronx was damaged within minutes of being “abandoned” and within 24 hours was dismantled, with anything of value removed/stolen and the remains damaged and destroyed beyond repair. Conversely, the same car in Palo Alto sat untouched for a week until Zimbardo smashed a window with a sledgehammer. Soon thereafter, the car followed a similar fate as the one in the Bronx.

Zimbardo observed that a majority of the adult "vandals" in both cases were primarily well dressed, Caucasian, clean-cut and seemingly respectable individuals. It is believed that, in a neighborhood such as the Bronx where the history of abandoned property and theft are more prevalent, vandalism occurs much more quickly as the community generally seems apathetic. Similar events can occur in any civilized community when communal barriers—the sense of mutual regard and obligations of civility—are lowered by actions that suggest apathy.

This seemed useful enough. Teams that don’t demonstrate strong ownership, value clean code, refactoring become apathetic which leads to technical debt.

However, what I never realized was that the Broken Window Theory had unintended consequences when it was was more broadly applied in New York City and other cities. As the theory went, if you want to prevent large crimes from happening like burglary and murder, you have stop the smaller, more petty crimes before they take root. The result is a culture of NYPD “sweating the small stuff” like assuming that where there is graffiti, there is the risk of larger crimes, or smoking/possessing marijuana publicly sufficient evidence for stop and frisk, jail time or worse, murder. One tragic example is the story of Eric Gardner who was killed by police in 2014 after being confronted for selling lose cigarettes on the street.

So, it turns out that this theory that shaped policing doctrine for 30+ years has resulted in unnecessary harassment, jail time for no cause or petty crime that has at times ultimately led to the death of otherwise innocent Americans in areas that are disproportionally (>52%) non-white. It turns out, this term is not just pervasive in my little niche of 1st world software design problems. It is part of the lexicon of many others that have been disproportionately and often unfairly affected by it.

This learning is enough for me to be mindful of this phrase and stop using it in the context of engineering and technical debt. It’s not because I’ve learned that it might be politically incorrect. It’s because it’s hurt people and because other’s find it offensive as  result. The extent by which I defend it or keep using it doesn’t make me smart, well-read or articulate. Now that I know that people find it offensive, and have taken the time to understand why, it’s a simple rule, a simple choice: If the actions you take or the words you use are hurtful to others, stop.

If the actions you take or the words you use are hurtful to others, stop.

Have the Important Conversations & Let Go

Sometimes this can be easier said than done because ego gets in the way. That may not make you a bad person or a racist, but it won’t help you or your community either. You see, I had a deep relationship with this particular term and now it was time to give it up.

However, in so doing so, I felt it was critical to have the conversation with the wiki author and share my concern with the term “bug”. It was uncomfortable for a number of reasons not the least of which was the risk of showing insensitivity by being overly picky or “in the weeds”. I started by thanking her for putting together this resource, sharing my own journey and learnings in processing it. Getting to the point in my email, I shared why I disagreed with the term “bug” as alternate phrasing and suggested she drop the term and use “trade-off” as well.

You know what happened? She replied within an hour, late on a Friday afternoon. Thanked me for my feedback and let me know she’d updated the wiki with my suggestion. But that’s NOT the important part. What’s important is that the conversation happened. Two Amazonians had a conversation rooted in facts, data that left the resource in a more valuable state. We both showed empathy, respect and accepted that we both learned. It was a great way to end a very heavy week.

If we are going to affect the change and healing that is so clearly desperately required, we must take the time to reflect, understand that words matter, have the tough conversations and then let go. I think of this as an important cycle in healing that starts with listening and learning, deep reflection and then doing something different. And, as you can see from my story, all of this is possible while still remaining technically accurate.

[1] I was born in Mexico City. My paternal grandfather was Hispanic. My maternal grandparents are German and Hungarian Jews. While I identify in many ways as Mexican culturally, I am what you call a “Mestizo” and most people would relate to me as simply White.

posted @ Monday, June 15, 2020 11:26 AM | Feedback (0) |

Powered by: