Tag Archives: Why

The Things We Say

I want to retire certain phrases from programmer parlance.


We are not clear in what we say. We use incorrect metaphor. We choose vague terms instead of better ones. Let us trim some of the excess terminology and jargon.

We use incorrect metaphor. We choose vague terms instead of better ones. Click To Tweet

Technical Excellence

This terms vagueness is its undoing. Almost everyone I meet has a different definition of what Technical Excellence means. To some it is a synonym for Extreme Programming. To others it is learning design patterns or continuous improvement.

The above assumes that the person saying the term has good intentions. I have also heard this term used as a passive aggressive way of saying that someone is a poor programmer, by telling them to strive for technical excellence without specific feedback. Calling someone a poor programmer without giving guidance on what needs improvement is useless at best, discouraging and defeating at worst.

Instead of using technical excellence, let’s say what we mean. If that is Extreme Programming, let’s say Extreme Programming. If it is adherence to corporate coding standards, then document the standards and talk about the standards document. If we want to critique someone, take the time to critique them in a way that is helpful. Encourage growth and improvement rather than attacking.


Again, simple is an extremely vague term. What is worse is that we acknowledge how vague this term is by modifying it with: Simple isn’t easy. As if this sound byte could explain what we mean. This suffers from all the problems of “Technical Excellence” and really doesn’t say anything useful.

We spend so much time talking about making things simple and then engaging in a long conversation quantifying what we mean. Why do we do this? The term “simple” just causes confusion, debate and eventually is shortly forgotten.

It is amazing to me how much energy we spend saying nothing rather than what we mean. If we could talk specifically about the types of complexity we want to avoid, we allow for improvement. We start the conversation that moves us into a better place.

Remove confusion, add clarity and forget simple.

Technical Debt

Technical debt was a good metaphor. Past tense. It was created for a specific reason, it was to explain the causal effect of decisions to bankers. It was not created to discuss the state of the code between developers. So, let’s stop using it for such communications!

Instead of technical debt, let’s talk about Anti-patterns or Code Smells. Both have names for specific things that can be addressed. They can be researched and understood. Better yet, there are know ways to move from these potential problems to good patterns.

Lastly if we are talking about the state of code caused by a ignoring problems over a long time, then even the team “Code Rot” is better at describing what needs to be said. There is real meat in using directed language to discuss the state of a codebase between developers.

In Short

Stop being vague right now. Don’t mix your metaphors. Be clear and intentional. If there is better language that can be used to describe what you want to say, then use it. Increase your ability to be understood by thinking about what you are saying.

Stop using 'Technical Excellence', 'Simple', and 'Technical Debt'. Start communicating effectively. Click To Tweet

Three letters that change how you think

Solutions feel so much more comfortable then questions; don’t they? Finding a solution makes us feel good. Solutions have power and people are willing to pay real money for solutions. Questions on the other hand cause discomfort. Questions represent problems that need to be solved and cost our money a lot of times.

So it is only natural that we focus on the solution. We jump to how a problem is solved without first understanding why it needs to be solved. We risk missing critical understanding in order to feel the rush of finding the solution.

I am not using the empirical “we” here, I am very much including myself in that “we”. I like solutions also. I like it when I can tie a problem neatly up with a bow and hand the finished package over to solve all that ails someone.

The solution is emotionally powerful but often the why is so much more important. When we understand the why we can better engineer the solution. The solution we will provide will be the correct one, or at least one that better suites the need.


As a developer and a problem solver how is always foremost in my mind. How can I solve the problem you are having? How do I alter my code to get the desired result? How…? “How” is powerful, it speaks of solutions and gives guidance. It is also the wrong question most of the time.

I have found that the “how” of something is inconsequential most of the time. When we focus on how we optimize for the solution rather than the issues that need a solution. We start fixing before we understand what it is we are fixing. When we ask the wrong questions we get answers that do not map correctly, even when they answer the questions we are asking.

Now if we knew the correct question we could find answers that have more meaning. The problem is that the correct question is often harder to answer. When we ask why we gain understanding of the root cause. The more we know about an issue, or request the better we can address that request. Why is much more powerful because instead of answers and guidance it leads us to understanding.

How follows why, but how is often disguised. For instance, “What would you like to see on this screen instead?” is not asking “what”. It is really asking “How do you want me to solve the issue you are pointing out with this screen?” Another hidden how is: “What if I changed this?” That question is really: “Is this how I solve the problem?”

Understanding that how can be asked many ways indirectly allows us to change the conversation by refusing to be lured in. We can instead rephrase each of the above examples to why questions. “Why do you want this screen changed?” or “What is it that you are trying to solve?” (Yes this is using “What” to hide a “Why”.)

That is only half the issue. “How” is seductive. Not only do we ask “how” when instead of “why” we are often asked “how” instead of “why”. We need to listen for it, and refuse to answer it prematurely. When we are asked “how” questions we need to change the conversation to focus on why first. We need to make sure both the person asking the question, and us, understands why. Once that understanding exists then how becomes important.

So let’s lead with understanding and follow with results. That is why a three letter word can change how, I mean why you think.