Blame or learn?

man wearing a suit jacket and stripe necktie
Photo by Lukas on Pexels.com

A lot of folks in my homeowners’ association’s Facebook group are angry. Their electric bills have gone up, and they think they know the culprit — and it’s not the excessive heat wave. No, it’s the new meters our electric company has installed. The new meters make their bills higher. The new meters shorted out their air conditioners. Someone needs to pay damages. Should we consider a class action lawsuit?

Maybe my neighbors are correct, and the new meters are a problem. I don’t know. What the incident made me think about was blame. Anytime something goes wrong, we’re so quick to blame someone. Some are even quick to blame themselves, whether justified or not.

I once gave a presentation on Agile methodologies and Scrum to a group of not software developers. When I was finished and opened the floor to questions, the very first question was from an executive who asked, “What do you do when a squad doesn’t meet their commitment?” His tone made me feel his real question was, “When a squad doesn’t meet their commitment, how are they punished?”

Blame in Complex Systems
I’ve been reading The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations by Gene Kim, Jez Humble, Patrick Debois, and John Willis. “DevOps” is a software engineering culture in which the people who write the code and the people who run the servers work closely together instead of being siloed into separate divisions.

The authors make some insightful points regarding complex systems, which are defined in part as a system that “defies any single person’s ability to see the system as a whole and understand how all the pieces fit together.” Examples include many major software projects, automobile manufacturing, or, heck, daily life.

Despite all best efforts, things go wrong in complex systems. Accidents occur in factories. Twitter goes down. Peter fails to fill out his TPS reports correctly. Stuff happens. And after it happens, we point the finger, and we blame someone.

What if there was a better way?

An Opportunity for Learning
The authors of The DevOps Handbook write that in a DevOps culture, “When failures and accidents occur, we treat them as opportunities for learning, as opposed to a cause for punishment and blame.”

Opportunities for learning. Not causes for punishment and blame.

The DevOps Handbook is about software engineering culture, and I can think of a lot of times in my career when I wish I’d have worked more in a culture of learning instead of a culture of blame.

But think bigger. Remember: daily life is a complex system.

What if we all stopped pointing the finger? What if we all stopped assigning blame? What if we all started asking, “What can we learn from this?”

We’d all be a lot less afraid to make mistakes. Don’t we idolize folks who fearlessly pursued and attained lofty goals despite a high risk of failure? Wouldn’t society benefit from more of those kinds of people?

We’d learn a lot more about how to prevent future failures if the people responsible had no reason to feel ashamed, and therefore no reason to hide or obfuscate their actions. Instead, they openly shared what happened — successful or not — in the interest of knowledge sharing, knowing their admissions weren’t going to be used against them.

And above all, it’s kind
There are certainly times when punishment is necessary. No one needs me to list them. But there are far more failures in life that should be treated as opportunities for learning than should be treated as causes for punishment and blame.

A great man once put it this way:

“I’m not trying to win. I’m not doing this because I want to beat someone, or because I hate someone, or because I want to blame someone. It’s not because it’s fun. God knows it’s not because it’s easy. It’s not even because it works because it hardly ever does. I do what I do because it’s right! Because it’s decent. And above all, it’s kind. It’s just that. Just kind.”

A cult of quality

One of my favorite books about software engineering is Peopleware by Tom DeMarco and Timothy Lister, and one of my favorite parts of that book is the introduction of the phrase “cult of quality.” DeMarco and Lister define this as a team that has decided “only perfect is good enough for us.” While most of the world won’t argue for higher quality, members of a cult of quality will “always turn out something that’s better than what their market is asking for.”

It’s my great privilege that in my day job as a senior software developer and team lead, I work in a cult of quality. My company recently published an article I wrote about our cult of quality.

Check it out and let me know what you think. If you’re a software engineer, do you work in a cult of quality? If not, how can you make your environment into one? And if you’re not in software engineering, how can you live a cult of quality in whatever it is you do?

Why NUnit is better than MSTest

My new team uses some MSTest for our C# unit tests, but mostly uses NUnit. Though NUnit has been around a long dern time now, I’ve never found myself in a professional environment that favored it. So lately, I’ve had no choice but to dig into it, and I quickly found it to be far preferable to MSTest for one simple reason: clarity.

Here’s the MSTest version of a simple StringCalculator test:

   1:  [TestMethod]
   2:  public void Add_1And2Returns3_Success()
   3:  {
   4:       var result = StringCalculator.Add("1,2");
   5:       Assert.AreEqual(3, result);
   6:  }

This isn’t bad. But you know what often happens when an engineer uses MSTest’s AreEqual method? The order of the parameters gets changed.

   1:  Assert.AreEqual(result, 3);

Technically, the above still works. But what the code says is, “Assert that my expected value, which is the result of the operation I am testing, is equal to the actual result my code returned, the static value 3.” That’s total nonsense.

NUnit makes the value that is expected and the actual value returned by the method under test much more explicit. You can still reverse the actual/expected order, and like with MSTest it will still work, but the naturalness of the syntax really helps prevent that from happening.

   1:  [Test]
   2:  public void Add_1And2Returns3_Success()
   3:  {
   4:       var result = StringCalculator.Add("1,2");
   5:       Assert.That(result, Is.EqualTo(3));
   6:  }

Remember that one of the three pillars of unit tests is readability. (The other two are trustworthiness and maintainability; see Chapter 8 of The Art of Unit Testing by Roy Osherove.) NUnit is far preferable to MSTest on readability grounds alone.

The Truth is: I am a Software Engineer

When I started this blog, I didn’t know what I was doing. I still don’t entirely, but I do know enough now to recognize mistakes I’ve made.

mask-1305302_640
Photo by John Hain, licensed under CC0 1.0

Here’s a big one: I chose to portray myself purely as a writer, with only one short line of my “About” page revealing the truth that I have a non-writing day job. Why? I felt that a writer’s website — that my writer’s website — had to project the image that the writer did nothing but write. I felt like it would be amateur and unprofessional to portray myself as a guy who works a day job but adores writing and does it on the side as often as he can.

But the truth is I am a guy who works a day job but adores writing and does it as often as I can. That’s me.

I projected this false image even though one of the things I dislike the most in life is phoniness. I crave genuineness in conversation, in emotion, in interaction with others. I spot attempts to cover reality or to put on an act a mile away, and they turn me off, big time. And I was doing just that when I wore an “I am a writer and nothing else” mask.

There was another reason I hid my true self on this blog, and it’s one I only recently realized. Unhappy with my job, I went out and got a new one last month. But upon deeper reflection, I realized I’d been unhappy at my old job for a very long time — probably well over a year. At first, the fact that I worked with some of my very best friends masked my displeasure, but as they left the company, there was nothing to dull the pain. I see now that this unhappiness led me to unconsciously deny “day job me” here on this blog because this is where I write about things that make me happy. Things like writing and stories. And breakfast cereal.

But now it’s July 2016, I’ve published my first novel, and I have a new day job with a new company I love, working with new people I already really like. With this new perspective, I need to declare myself.

There is a press conference scene at the end of Iron Man in which Tony Stark denies he was the guy seen in a high-tech suit of armor. He says he’s not a superhero, and that it’s crazy to suggest he could be one, all before his brain goes all what the hey and he tells the reporters, “The truth is: I am Iron Man.”

Well, the truth is: I am a software engineer. I’m actually a very good software engineer. And I’m not going to hide that on this blog anymore. It’s an important part of who I am.

Andy Weir, David Wroblewski, Ken Jennings… these are some of my brothers in words. Fellow writers. But each of them is (or was) also a software engineer, meaning they are also my brothers in code.

And because I shielded this part of myself for so long, I’ll reveal a little secret. Want to know how each and every engineer imagines himself or herself? We imagine ourselves like this:

Iron-Man-2-transparent-monitors