Tag Archives: Knowledge

The Power of a New Voice

TL; DR

Too often the person with the least experience is ignored. This is a shame because they are often the person who can lead us to the most significant insights. They will see things we overlook or have become accustomed to. They can help us question the things we have started to not question. They are a powerful voice for improvement.

A new perspective can help us question the things we have started to not question. Click To Tweet

Question Everything

Like @WoodyZuil says: “Any method or practice we use without question should be questioned.” https://twitter.com/WoodyZuill/status/881711076089384964

The problem is if we are practicing something without question, we can often be blind to the fact that we are practicing it without question. A new set of eyes can see these things, but we must encourage them to point them out. If not, we risk that they too will become accustomed before we have gained benefit from their newness.

Intimidation

The problem with capturing input from someone who is new, is that most people do not feel comfortable giving feedback while they are new. This means that we must be extra careful to foster that feedback. It is something that must be intentional.

The first step is listening. When a new person offers input, listen. Use both Active Listening and Comprehensive Listening. Do not interrupt, and take a moment before replying. This shows respect for what they have to say, and consideration of their point.

The next is to treat the comment and question as if it is valid, and wanted feedback. They may not understand all the context to the thing they are questioning. That is the point. Do not explain to them how they are wrong, instead explain to them how they are right. That does not mean that you do not explain your context, but instead use it understand what they offer.

What if they are wrong?

They will often be wrong. The suggestion, or question, will be wrongly worded. They will most likely not understand what it is that made them feel the way they felt. Don’t let the fact that what they say is wrong stop you from learning. Instead, examine the situation. There will be truth there, and that truth will lead to improvement.

At the worst case, if they are utterly wrong then you will have provided the opportunity to learn in a way that makes them feel appreciated. This learning will be retained longer. It will encourage them to voice more, and thereby learn more. Eventually they will teach you something, because they are willing to voice what they don’t understand.

The Warning of a Silent Voice

Pay attention to what is happening regarding the new voice. If that voice is silent, this is a waring. It means that there is something that is causing that person to fall silent. It means that the team is not welcoming that person’s insights, and not listening and accepting of what the new voice offers.

This is the loudest indicator you will often get to small problems on a team. These problems can- not always, but definitely often enough- grow into big noisy, and explosive problems if not handled at this point.

In Closing

It is hard to listen to the point of view of a new person. That person may not know the social norms, or the current environment. It is easy to just brush off what they say, as they do not know better. However, when we do ignore the “new voice” we lose a lot of valuable insight.

Listening to the new perspective is not always natural but it is crucial. Click To Tweet

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.

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.

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.

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.

I don’t know

“I don’t know” gives us a lot of power. Using these words open pathways for communication and understanding. Too often though we ignore this phrase and start by jumping to answers that feel right rather than those based on fact.

Those three little words pack a whole lot of punch. In American society saying I don’t know is often very hard to do. In fact at least one study shows that even our children have trouble saying those words. The same study suggests that our very schooling rewards us for figuring out possible answers rather than admitting we do not know.

There is often a perception that logic should be enough to eliminate the uncertainty of not knowing. We should be able to extrapolate from known data to arrive at a logical conclusion as an answer to a question. That is a great technique to gain insight and guidance. The trouble starts when we take that extrapolated point of view as fact.

Fact is something that is. A fact is solid and unchangeable. A fact is also temporal and because things change, what was true before may not be true now. That does not change the validity of the fact or make the fact mutable. Logic can lead us to facts, but does not guarantee them.

Logic is good at leading us to hypotheses. A hypothesis is an idea based on known information. It is not a fact, but may represent one. A hypothesis must be tested and observed before it can be treated as a fact, and in truth it may sometimes never become a fact. That does not make the hypothesis of any less value. The real value of a hypothesis is that it gives us something to learn from.

I bring this up because understanding these differences helps relieve a lot of problems in software development and life in general. If we know what we have is a hypothesis then we can test it for validity. We can discuss it and research it. If we cannot prove it is a fact we can at least prove that it is valid enough. Knowing its validity means we have gained insight and can make a better decision.

Recognizing that we have a hypothesis instead of a fact is an admission that we do not know. This is a very powerful situation to be in. If we do not know something we can learn it, we can change it, and we can grow it to where it needs to be. I am not saying that not knowing something allows us to change the underlying facts, but instead allows us to realize that there may be a different course than we thought when we started. The facts may be different than perceived or even that the facts we thought mattered don’t. Only by testing and researching our hypothesis can we gain this knowledge.

So do not be afraid to say “I don’t know.” Use the power of those three words to unleash potential, find new avenues, and spark creative communication. Repeat after me: “I don’t know.”