Why Do I Do the Things I Do?

I’ve been around software development for quite a while and have trained others in many different activities. Here is one of the most important questions I’ve learned to ask myself when telling someone how to do something: Am I telling them “my way” or “the way”?

Sometimes what I am telling someone is simply “my way” of doing things. In these cases, it is important to convey the true goal of the task, and that my way is simply one way to meet the goal. Other approaches are fine, as long as the goal is met. While I like to think that “my way” is the best way, the truth of the matter is that frequently “my way” is tailored to my particular strengths and weaknesses, and might not work for another person at all.

On the other hand, sometimes I am telling someone “the way” to do something. This really is a best practice, only way to meet a policy, or maybe even a legal requirement. In these cases, it is important to convey the importance of following the method presented.

There’s one other benefit of asking myself this question: sometimes when I realize the approach I am using for doing something is simply “my way,” I find a better way of doing it or the person I’m teaching suggests one.

Here are some examples:

• “My Way.” I often get into a situation where I am going to create a new document by editing a copy of an existing document. When in this situation, the first thing I do is open the existing document in my editor and perform a “save as” to a new name for the new document. The need here is to not overwrite the existing document with the edits. Knowing that along with all of my wonderful strengths, I am also absent-minded, I save the file under a new name first, so that I won’t absent-mindedly save my edits to the existing file. People who are not absent-minded like me don’t need a procedure that guards against this problem. They know they will rename before they save (I don’t really know how they accomplish this, but I’ve seen them—they do!).


• “The Way.” The general rule of defect reporting is one defect per defect record. The purpose is clear resolution of defects. Each defect is typically prioritized, fixed, and re-tested. Some are resubmitted because they fail re-test. Some have even more states they go through. If there are multiple defects in a record, tracking and determining the prioritizations and states of the defects becomes time consuming and confusing. It is much easier to have priority and status fields which apply to the defect record. Thus, the best practice is one defect per defect record.