Posts The Things We Say
Post
Cancel

The Things We Say

I want to retire certain phrases from programmer parlance.

TL; DR

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.


Pair Programming Photo by cottonbro from Pexels

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.

Simple

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.

This post is licensed under CC BY 4.0 by the author.