The magic words

There are, famously, no silver bullets in software engineering. Computer programming is hard and although some people are really brilliant at it, there are also a lot of people out there making their career in this field who are not. This is one reason why a lot of software sucks¹Source: I own a computer..

Another reason is the inescapable complexity of the digital world. There is simply no “one size fits all” approach to a domain that covers everything from IP over pigeon to autonomously piloting a helicopter on another planet. We have a huge and constantly growing number of frameworks, tools and technologies available and many of them are the best for their own little niche – this is because there are so many niches.

But the good news is that there is something that any software engineer can do with no extra training, at no cost, immediately, that will make them a better developer, and that is to judiciously invoke the magic words.

“Yes, but why?”

“Why” questions are unbelievably important and can be applied at pretty much every stage of the jolly old Software Development Life Cycle (or SDLC if acronyms are your T). During requirements analysis and design, a good ‘why’ can bring the focus back onto the problem if discussions start veering into solution space too early, help trim extraneous requirements and get towards the fabled MVP, saving time and effort later on. ‘Why’ questions during planning can tease out priorities, inter-dependencies and build a shared understanding of the task and solution. ‘Why’ questions during development form the basis of a good peer review, help with construction of tests, and are essential for getting to the root cause of bugs. And a good understanding of ‘why’ is super important before you can start asking the ‘how’ questions for QA, deployment and maintenance.

However, constantly asking ‘why’ can start to sound negative and even hostile. Unless your team is completely dysfunctional, when someone comes to you with a problem for your input they will have already done work on it, potentially a lot of work, and to ask them to re-examine assumptions which might be quite fundamental to what they’re doing is potentially disruptive and patronising. Two heads are certainly better than one but not if the first head ends up punching the second one for disrespecting their years of knowledge in the subject area. Phrasing is so important for these conversations.

This is where we can take a leaf out of the improv playbook. The “Yes, and…” rule is a famous method used in improv troupes to keep the momentum going and avoid conflict. Basically you accept what your teammates are telling you and build on it, rather than querying the basis of the idea. Now, in the world of software it’s completely possible for the basic idea to be wrong, but it’s so much more respectful and collaborative to accept your coworker’s reality even while you’re probing into their ideas.

“Yes, but why?” isn’t always the perfect phrasing, of course – you’ll likely need to find your own words. But the basic principle is to be positive, encouraging but constructively questioning – no solution is perfect but every solution can be better understood, even it it can’t be improved.