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.

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: