Technical Pedantry

Definition of pedant

1. one who is unimaginative or who unduly emphasizes minutiae in the presentation or use of knowledge
2. one who makes a show of knowledge
3. a formalist or precisionist in teaching

Pedantry in software teams comes from people providing technically correct information at times when it is more distracting than useful.

This seems a small thing, but knowing how to avoid being "that person" in your group conversations is necessary to moving into the more senior technical positions inside any organization.

Starting with a story #

I once walked into a big client presentation that I was responsible for delivering. The contents laid out the details of our proposed system design for a new product that the client wanted to bring to life.

This was a big prospective client and a big opportunity for our company. The client was part of a highly regulated industry and had high expectations around resiliency, scalability, and security.

The presentation started off well, with high level review of our SDLC and plans for how we would anticipate integrating into the client's current systems. I was in the middle of outlining the approach to implementing an SSO mechanism when I am cut off unexpectedly:

"That's authorization, not authentication."

It came from a senior person on the client internal development team. It was so unexpected that I had to pause. I had to think back to what I had said. I believe it was something like: "At this point, the user will be authenticated to perform this action".

The person took my pause as an opportunity to further expand on the difference between the two. As others joined the discussion, my presentation was on the verge of being derailed. I had to step in, politely thank them for the correction and agree that it was in fact authorization, and moved on.

Being technically correct #

The person from that story was 100% correct. Authentication and authorization are two separate things. Authentication focuses on identifying a person, authoriation on allowing them permission to access resources and perform actions.

They were technically correct. Regardless of the situation, what they said was objectively true. However, there is a difference in the information being right and it being valuable in context.

Success comes from the when, why, and how #

I'm not sure why that person decided that was relevant to the current conversation. It rubbed me the wrong way, certainly. It was a distraction that didn't help align the group on the system design.

It caused me to reflect on past times where myself or others I've worked with have done the same. It made me ask a lot of questions:

• Why do you think it's important to correct someone?
• When is that useful versus harmful?
• At what point is providing additional information valuable versus distracting?
• Why is changing the specificity of a conversation almost always negative?

The wrong reasons #

All problems are interpersonal problems, we're all human beings with emotions and shortcomings. It's always important to reflect on your intentions and goals going into any conversation and make sure you're intentional.

First, let's talk about scenarios where the intention behind technical correctness can be damaging to you and others in conversations:

Bad reason #1 - Your want to prove your own expertise #

It feels oddly universal that you can tell when someone is trying to show off. Companies that have highly competitive structures internally encourage this behaviour, causing people to constantly be on the lookout for any opportunity to show capability.

Business conversations are for information sharing and making decisions that move a group forward. When someone is only listening for keywords that they can jump on like trivia night at the local sports bar, it becomes obvious extremely quickly. They come across as someone that doesn't really care about the group's goals at all other than how it can help them flex.

Showing value #

Information should only be provided with the intent of helping the conversation achieve it's goals. Often when trying to show capability a person will go onto tangents or unnecessary details.

If you are able to consistently provide information that is relevant and moving the conversation forward, you will be proving yourself both technically and as a person who can see the bigger picture.

Bad reason #2 - You want to challenge someone's expertise #

Let me be clear: attempting to discredit or knock someone down a peg is never going to ever work out in the long term. Especially done in a group setting. There is no faster way to errode a team.

If you think it's truly an important mistake, really evaluate the time and place to give that feedback. It's always better to provide critical feedback or correction in private if possible.

However, there are times where someone saying something incorrect could have significant impact and lead the group to the wrong decision. It's even more important to handle this gracefully.

Disagreeing with grace #

If you are in a position where you believe someone else is wrong, follow these 3 rules:

• Criticize the idea, not the person: this is old advice, but good. "I don't believe that is right" over "I don't believe you are right".
• Share information as an experience: say something like "last time I used that package it wasn't able to do that, maybe it's changed?" or "I didn't think that was how it worked, my understanding was that it worked like this".
• Leave room for mistakes on both sides: always leave room for you being wrong, and give them the same. Asking for clarification is better than disagreeing if it saves everyone some embarrassment. Using hedging language is controversial, but tossing in a "maybe there is a disconnect in our understanding?" never hurts.

Building up rather than tearing down #

As you become more senior in your roles within software development, you are expected to have an ever increasing area of impact. Lifting up peers through collaboration and knowledge sharing is often the first indicator that a developer is ready to move to the next level.

When you can identify gaps in someone's knowledge, know when and how to use that information in a positive way, and have the grace to ensure that the person is open to improving and feels empowered? Your own career is well on it's way.

Right reasons, wrong time #

Say you do have the best interests of the group in mind and actively want to help everyone get better so the whole company succeeds. Does that mean that it's always the right time to provide information, correction, or feedback? Unfortunately no.

When discussing software, you are often talking at a very specific level of precision. This allows decisions to be made at the right level, and keep the discussion focused on the specific problem you're trying to solve.

It's always important to know what the goal of any conversation is, specifically what decisions are trying to be made. It's easy to believe that any decision made now is one that doesn't need to be made later.

The same could be said for information: theoretically more is always better, and the more you can give people information and at higher frequencies, the better off everyone is.

When the difference matters #

Say I asked a fellow developer directly "what is the difference between thing X and thing Y?" they would likely provide a detailed and precise answer.

If asked "when does the difference matter?", that might catch them a bit off guard. We often automatically apply knowledge in situations it's needed.

Getting deep in the details might be fine when looking at specific implementation details, but becomes more problematic the more high level and abstract conversations become. The more high level a decision, the more people are impacted. The longer a decision takes to be made, the more people who are left waiting.

At this point not only do the details not matter, moving the conversation into the weeds by trying to dial in on decisions that don't need to be made yet actively pushes everyone back.

Right information, right time #

In software development, focus is always extremely hard to maintain both at the individual and organizational level. Information at the wrong time is a distraction, information at the right time is momentum building.

You can see when the right conversations are happening at the right levels, and when they are not, by the ability for decisions to be made quickly and hopw they impact the overall velocity of an organization.

If you can be one of the people keeping those conversations on track, and providing useful information at all times, while also not being an asshole? You're doing the most with the information you have.