There is this old saying when people are getting off track that states “we are getting in the weeds”. The thrust of this statement is to get people back on the bit picture path that they want to discuss and to stay out of the messy bits of a conversation, but let’s take this metaphor a bit deeper.

I used this phrase in a comment the other day, and I realized that this is the one of the issues that people problems have with education. Digging deeper. I will get to the technical aspects of the problem, but the phrase made me think about why this is an idiom at all.

It sounds negative, but the weeds are where the true learning is. What do you find in the weeds that you don’t on the path? When you are hiking, you often walk down the path, sometimes by laws. It might be paved, dirt, rock, mud, etc, but someone has been there, done that, and you are generally safe (hence the laws!) Wild animals steer tend to steer clear of the human made paths. But most of all, you know where the path is leading most of the time.

To the side of many trails are weeds. What is in those weeds is danger, snakes, mice, bugs, bees, etc. None of which want to get in a fight with something 10-20X larger than them, but they will if you encroach on their space.

Only one problem

The weeds are also where to find the interesting things. The weeds hide things people have dropped like rings or money for instance, that they couldn’t find. There might be relics from a time past that have risen to the top of the dirt (a weird phenomenon that I don’t vaguely understand!)

As a technologist, my usual goal in life is to take what the customer wants, and then turn it into software. I focus on databases, both reporting and OLTP, but the same can be said about pretty much any technology. The one thing I know as well as anyone is this: the conversation weeds are where the dangers are hiding.

Sure, some of these dangers are why the phrase “getting in the weeds” in a meeting are so very important, because if you go too far away from the path, you may never make it back on track. If you have ever felt lost in the woods, that is the analogous feeling. You want to find that trail again, but it is no where to be found.

But if you never stray from the path and stick to the simple, obvious things on the agenda, it is likely you never actually find that nugget of knowledge that needed to be found.

A quick side trip

Think of it like buying a car. If a person goes in, says the sales person “I would like to consider a new vehicle”, and the sales person say “Well, let me show you one.” This is not enough detail. And too often this is the level design discussions want to get to. I need a car. I need a customer management system.

There is a proper path when buying a car when the sales person and customer are talking about their needs, their desires in a car, and all of the details of how the car meets their needs. We have 6 kids, I travel for work, I work as a forestry fire fighter, I am not handy with a wrench, etc. Each of those details are important. Without these details, and working like a software team, you might sell this person a small car when they need a rugged SUV or two vehicles for two distinct purposes. Yeah, two vehicles are decided more expensive in the short run, but possibly not over time.

But there is a place where time is just being wasted. “Did you know car tires aren’t made of rubber anymore… probably? And this engine is one of the first of its kind, designed by someone who neither of you will ever really know anything about.”

Walking a fine line

In software development, the weeds are often we border between the customer’s desires and the programming team’s need to get into the really deep weeds and make this happen. As a programmer keeping up with changing skills being thrown at us, we should be regularly taking trips off of the beaten path and see what is beyond our current skills. Sometimes it is just fun to geek out and talk nerdy stuff, but things can easily get too far from the path when talking about technical details needed to build a piece of software based on the customer’s needs.

The customer is always…

Part of the conversation. They are not always right.

Don’t get me wrong, the customer is not always wrong, and isn’t really ever completely right (any more than you are), but when you are the person writing the software, rarely are you building this to suit your needs, or the exact needs of a previous customer that did a similar business.

You are building it for your customers. Never be afraid to get to the weeds, and if the space you are in isn’t the right place to dig in, take it to another meeting. Make sure you have explored all the weeds before you start coding so nothing important is missed, but as in so many things, timing is everything,