Tag Archives: Structure

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

Reinventing the User Group

User groups are awesome for technology. They accomplish several key goals. First, they give developers a place to learn the standards around their technology. They also give a forum for thought leaders to explain changes and improvements to the technology to those who care. User groups also provide an organized place to network with those within our same field. This is why they are so awesome.

User groups are an old institution, compared to anything else in the field. One of our local user groups has been around for 20 years. The idea of user groups has been around longer than that. Therefore, it is not surprising to see that the idea is being iterated on.

If you have not been to a user group, seriously- go. Let me explain the basic format. The members of the group gather to hear a speaker talk about some topic. The speaker gives a presentation and answers a few questions. Sometimes the group meets for an informal meal or drinks afterward.

I attend two user groups that completely break from this format. This break is not simply to be different, but because they have a different set of goals and they have found a format that enables those goals better.

The first group is the Technology Immersion Group (TIG). TIG’s goals are to give a forum for developers to take a topic and dive deeply into that topic. TIG is structured more like a large study group. There is a panel that functions as subject matter experts, and usually some study material used to guide the group. The panel spends a short amount of time introducing what was supposed to be covered in off-hours and most of the time is given to Q&A. If there is not much Q&A then the panel will explain points of what is coming next.

The second group is the San Diego Architecture Special Interest Group. This group’s purpose is to give a forum for senior developers and architects to discuss things they are encountering at work and get advice. This group’s format is a round table with three rounds. The first round is a problem round. Anyone in the group can ask the group for advice on things they are dealing with at work. The second round is a round table discussion about some specific technology. Sometimes they do a book discussion, sometimes a more open discussion. The last round is a show and tell round. You need to share something that you find interesting. This could be a tool, a programming language, a kick starter or anything. The last round facilitates discovery of things to either help us with what we do, or helps us unwind.

These two groups arose out of a need that was not being fulfilled by current user groups. That does not mean that current user groups are out-of-date, but only that there is space for new user groups to arise, particularly ones that fulfill the specific needs of their users. I hope to see more specialty groups that change the format in different ways. I also hope to see these two groups replicated in different towns. All of this grows our community and improves the industry.