Asking versus telling

One of the biggest challenges when working with legacy technology or established teams is challenging the deeply held beliefs in the code or the people (usually both). The naïve thing to do (which many of us do early, and even, embarrassingly, later in our careers) is to tackle it head on. We see something we think is wrong, and we firmly blurt out the “right” answer. Sometimes we even dismiss the other party as “ignorant”, “stubborn” or otherwise unhelpful. Usually the result is predictable - the other party digs in, fights back, and doesn’t listen - everyone gets defensive when challenged directly. If it’s code, you may easily find yourself lost in edge cases and complications that arise from the assumptions you are challenging being reflected in the rest of the system. All of this makes it harder to get change to happen.

The answer, of course, is listening. But that’s not really super helpful - if you just passively listen or passively read the code, it’s not really going to change anything, right?

Instead, there’s a form of listening that’s more active, and can actually be used to advocate in some ways - usually referred to as “Socratic questioning”, but it goes under other names, like “the five why’s”. This involves asking questions that really take the other perspective into account and are honest inquiries.

Ok - we’ve all heard of that, so let’s stop reading, right? Actually, wait! The real trick here isn’t do ask questions that are obviously biased, aggressive, leading, or otherwise hostile (the “When did you stop beating your dog?” kind of question). The real trick to this is to cultivate genuine curiosity and empathy in those questions - which means you have to really be listening, and be willing to change your mind if you learn something new.

Usually when something seems wrong to you, you’ll have mentally skipped ahead to an outcome that you think will happen from the decision you think is wrong. Try to ask genuinely curious questions that lead to that outcome, rather than simply jumping to arguing about it. Think a particular approach won’t scale? It’s not useful to just state that - but it might be useful to ask questions like “how does this system work when there are 100M users? What’s the bottleneck? Why do you think this is the most important design principle?” etc.

This approach works with code too - there was intent, and “dogma” (even if it’s just the dogma of laziness) when code was written. Interrogating it honestly can help you understand what problems the coder was trying to solve, and what is feasible to change.

None of this is perfect, of course - people can be stubborn, code can be irredeemably broken. But conversations that start with a genuine desire to listen and learn, and have some genuine empathy, are much more likely to make progress. Very few people do things that they consciously think don’t make sense - everyone has a context and goals, implicit or explicit, that constrains and informs their behavior and beliefs, and everyone is solving that set of constraints in a way that makes sense to them. Trying to invalidate that context only makes them angry and insecure (they have to deal with that context too - maybe they don’t like it, maybe they strongly identify with it, so saying it’s not valid isn’t helpful in any case). You have to understand the totality of the reasoning that got them to their position, not just the end position itself. Listening and understanding and trying to problem solve within that context at least gives you a chance to change minds.

And I think this is true beyond just code.