Last year at Lone Star Ruby Conference, Abraham Sangha gave a great talk entitled TDD for Your Soul: Virtue and Web Development. In that talk, he used the four classical Cardinal virtues as a framework to talk about how to make yourself a better developer and person. I really recommend watching the video and thinking about the things he says.

I’m going to take page from Abraham’s book and use those same four virtues as a framework. But instead of applying them at a higher level as he does, I’m going to focus in on our day-to-day programming activities and the code we write.

According to Wikipedia, the four Cardinal virtues are Prudence, Justice, Temperance, and Courage.

Before I carry on, I’ll mention that “Cardinal” here doesn’t refer to a high official in the Catholic church; rather, the term derives from the Latin word for “hinge”. Thus, we can thing of these virtues as being pivotal.


We don’t hear this word much these days, but it can also be described as Wisdom: the ability to judge between actions to determine what is appropriate in a given context.

When we’re writing software, we encounter many situations every day when there is more than one way to solve a problem. In each of these cases, we need to apply wisdom in order to judge which choice will be best.

Which choice will keep our code the most changeable in the future? Is it worth introducing another layer of abstraction here, or would that add too much complexity? Do we really understand what we’re trying to accomplish? Are we feeling rushed and trying to cut corners? Are we incurring technical debt that will hurt us later? Are we spending too much time polishing the code and not enough time making progress?

How do we gain this wisdom?

According to Will Rogers:

Good judgment comes from experience, and a lot of that comes from bad judgment.

That’s not very encouraging. How about Confucius (also quoted by Abraham Sangha in his talk):

By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest.

That’s better.

We can think, learn, and reflect to gain wisdom. We can also learn from others, imitating the more experienced people around us as we learn to see what they see. And yes, we will obtain the bitter learnings of our own experiences. The important thing is to take time to reflect on our mistakes so that we can learn the lessons they’re teaching us.


We think of justice as meaning fairness today. I really like how it is said on Wikipedia, though:

Justice is the moderation or mean between selfishness and selflessness.

An interesting application of this term is to the building blocks of our application.

Is this object doing all of the work? Is this other function doing anything useful at all? How balanced are the responsibilities among the various modules? Is this method too interested in the internal state of that object over there?

Perhaps thinking of these kinds of code smells or design issues through the lens of Justice can give us new insights into how to resolve them.


Here’s another word we don’t use much any more. More common words might be Restraint or Moderation.

I can think of a couple of ways to apply Temperance.

First, we probably want to show some restraint in bringing in extra dependencies. There have been a couple of recent articles about this. Mike Perham wrote Kill Your Dependencies. And then Elle Meredith wrote a very balanced and thoughtful piece, To gem, or not to gem.

Second, I think Temperance relates to the Extreme Programming tenet known as YAGNI (You Aren’t Gonna Need It), which helps us remember not to build features into our applications before their time.


Given that I’ve named this blog Courageous Software, you’d think I’d have one or two things to say on the topic. And indeed I do. Here’s what I wrote more than three years ago when I launched this blog:

Courageous Software is about having the courage to Do Our Best work in every circumstance; to make the software we write the best we can make it. It’s about stepping out of our comfort zone to learn new things and grow; to Make Our Best Better every day. And it’s about Helping Others, our fellow developers, do the same.

Google defines courage as:

  1. The ability to do something that frightens one.
  1. Strength in the face of pain or grief.

In our software, and in our careers as software developers, we need to be able to make progress in the face of all kinds of fear, pain, and grief. Courage is what allows us to do that.

Courage is also one of the values of Extreme Programming (XP), which I’ve been doing since before the first books came out. In XP, courage supports simple design, refactoring, and many of the other practices. It is not recklessness, but rather the ability to push through the fear to make things better.

I hadn’t reviewed this page for some time, but I think it still stands up.

Courage can also help us write code that is confident and not paranoid. Avdi Grimm wrote an entire book on this subject called Confident Ruby. Highly recommended, even if you’re not a Ruby programmer.


Sometimes, it is valuable to find a different lens with which to examine our work. Trying thinking about your day-to-day programming through the lens of the four Cardinal virtues and see what kinds of insights you can gain. Let me know what you learn.

Thanks again to Abraham Sangha for his inspiring talk.