The Benefits of Technical Sparring
How shit posting about future pie in the sky enhancements is good for you and your team.
Engineer C: You know what would be great? If we deprecated the flux capacitor model and instead made the capacitor object more generic so it can handle other types of capacitor types.
Engineer J: I could see the benefits of that. But what if we instead set up an inheritance? I think a parent/child model would be better suited to that structure.
Engineer S: Yeah, but then you’d run into problems with …
Hopefully, we’ve seen these sorts of conversations in our engineering teams. I’ve always viewed them as a sign of good health in an engineering team. These technical sparring matches can signify investment in the work and a passion to do it well.
These are valuable interactions! It may not be apparent to everybody watching, but in between the polite disagreements and the counter arguments, there’s a lot of great things going on there.
You’re gonna eat lightnin’…
If you ever have hung out with martial artists, you know that practitioners will sometimes just randomly start sparring with each other. To those who are new to it, this can seem a bit odd (and possibly scary). But, the experienced practitioners are doing something very purposeful. They are embracing their training and sharing their knowledge.
When engineers propose and counter propose ideas, it is very much the same concept. Idea swapping is a form of sparring. One engineer will throw a proposal out (jab!) while the other engineer finds the faults and produces a refined counter proposal (duck and weave!). The end goal, much like the sparring match, isn’t for one person to knock the other out, it is for all of those involved to walk away with new understanding.
To an untrained eye it make look like a brawl or an argument. It may even be tempting to step in and put the conversation on ice, but letting the conversation play out can be hugely beneficial. Even if there is no intention of allocating time to actually building the idea. Heck, even if the idea has no value to the company, these exercises can be immensely useful.
Don’t be afraid of them!
…and you’re gonna crap thunder!
There’s a ton of things that engineers learn when they collectively shit post about future ideas. Here’s just a few:
Design
Software engineers go from good to great by seeing a lot of different problems. This gives them the ability to do it in a risk free way. It also allows your engineers to explore problems outside of their day to day domain. Additionally, you can manipulate the hypothetical in these problems so that you can examine them from contexts you may not get a chance to as part of your job.
This can give engineers the ability to examine the importance of nuance in their approaches. For example, a proposed solution may work well on the happy path but fail miserably when certain other variations are put into play.
Area Knowledge
There are a ton of tools in this trade. Nobody, no matter how experienced, knows them all. When a problem comes up, being able to openly discuss which ones have which benefits is a great opportunity to brush up on what is out there.
It may be even be that the problem discussed has an existing library that solves the problem really well. That can be a really great learning experience. Sure, there’s less to propose and counter propose, but there is a case study right there for the reviewing.
- How did they solve the problem?
- Is there a more efficient solution?
- Will their solution work for our problem?
- Has anybody used it before? What did they like or dislike about it?
Values
I’ve written about values before. In short, they are the guiding principles in which an engineer believes and follows. These values are intangible things and while all engineers have them, most haven’t put them down in words. Regardless, they can influence the outcome of software greatly.
Values are meant to be shared and reexamined so that individuals are keeping themselves on a constant path of improvement and self alignment.
Having an idea to shit post about is a great opportunity to examine and discuss these values by proxy. Values are often hidden in the “why” behind proposals. They can also be seen in the trade-off choices each person makes.
- “Why did you choose metric over imperial?”
- “Why maintainability over efficiency?”
- “Why do you think we shouldn’t pursue this idea at all?”
I ain’t no bum!
Sparring partners often hit each other with more force or less accuracy than they intend to. There’s a number of times where healthy sparring has left real injuries. New practitioners are not used to this. So they see every attack as if it was personal and life threatening. They have yet to see beyond the strikes and look at the underlying lessons they can learn.
The same can be true with engineers who are not used to these sort of open debates. They can see every correction or counter proposal as an attack on themselves or their experience as opposed to their idea.
Some engineers (men especially) want to “win.” They love their solution and they want everybody to think it is the best. But, that’s not how this works. Winning is everybody learning and growing. Either everybody wins or nobody wins. All of the benefits of these discussions hinge on the engineers answering questions, explaining their views and showing their work.
It is up to the more experienced engineers to cultivate a culture of openness and inclusiveness. If anybody feels personally challenged, acknowledge their concerns and move the conversation more towards knowledge sharing. It is important to reiterate that this is about learning and it isn’t personal.
It is always better to focus on the debate than be entrenched with an answer (no matter how correct you think it might be). Avoid emotionally attaching to ideological debates with clear preferences but no clear winner. For example, you will not solve the Vim vs Emacs debate.
Sparring is intended to be instructional. So use every opportunity to point out the benefits of each proposal. Even bad ideas have aspects to them that are appealing or beneficial. Explicitly talk about what those are! The best sparring partners are ones that acknowledge when their opponents have scored points. They listen and build upon their opponent’s ideas. They can play devil’s advocate or suggest new twists on the existing idea to accomplish this. And when the idea is sufficiently sharpened they’ll advocate for it in other arenas.
But, don’t skimp on talking openly about the trade-offs and disadvantages. Engineering is, at the end of the day, about building something that works in the real world. So, it doesn’t do anybody any good to dismiss the drawbacks. They can and will have real impacts. And while shit posting about future ideas may be a sparring match, you’re training to throw some real punches at some point. That is, after all, what this practice is for!
