-------------------
Being precise
2020-02-06
-------------------
One of the most important skills: being precise with language
Most tech literate people will have experienced the following:
A friend or family member asks you for help, their internet
connection does not work. They describe it as "my internet is
broken". But what does this mean? Does a specific website not work?
Do they get 500 errors? Some proxy error? Does the computer have
networking at all? Are DNS lookups borked?
Of course one would not expect a user to describe any technical
details, but the generic "it's broken" does not help at all. A bit
more detail could be provided by any user. My experience is, they
simply have not learned the relevant skill. Which is to be precise
in wording and description. I think most people never had to learn
this skill as they do not need it very often.
Human language (with exceptions, i am sure) is full of implicit
meaning and ambiguity. Many things only make sense or are useful
in context. In contrast, engineering disciplines rely on exact
phrasing, so no ambiguity is left and no interpretation is
possible. If it's describing a software feature or designing an
electrical circuit, precision is key.
My perspective is software, where lack of clarity can mean
implementing the wrong feature or, as I have often experienced,
waste of time. Often a project manager writes a feature request as
pages and pages of definition. Which in itself is a good thing, and
a huge step up from the horrifying "development by hollering" where
everything is ad-hoc and nothing really is thought through. Despite
the verbosity of such documents, I many times find myself picking
apart almost every paragraph and coming back to the author with as
many questions.
This is not meant as a bashing exercise, and I do not expect a
product manager to excel in this skill. Even as they have the
expertise in the domain in question, or at least should have, they
do not necessarily realise the ramifications of some of the
details. Which means that as the engineers, we have to be even more
vigilant in finding all the ambiguities and clear them up.
Being precise is useful in all kinds of different things. The one
already discussed is asking the right questions the right way. To
be precise in this area means expressing a question in a way that
the person answering knows what exactly you want an answer for.
"What do you mean with this sentence?" becomes "I think you mean x,
but based on the rest of this document, this could also mean y or
z. Which one do you refer to?"
Since asking the right questions is itself an important skill,
being precise with them is pretty damn important.
Describing problems is the other big one. We have all seen the bug
reports of the form "it's borked", like in my example above. Since
we are engineers we should strive to do better. Never spare the
time or effort to research, double-check and cross-check your
problem. Narrowing down the space with negative tests and the
process of elimination brings us pretty close to describe the
problem in sufficient, precise detail, and, again, ask a good
question.
Doesn't really matter if it's an issue on some bug tracker or the
request for help from a colleague in the office. Or simply writing
documentation. I find myself regularly rewriting and rearranging
documentation for the work I do. Describing the test cases I came
up with, technical docs or information for users and colleagues. It
takes considerable effort to make them as precise and useful as
possible. Of course this means that writing such documentation with
care is time consuming, and in my experience underestimated all the
time.
Terminology is another factor that gets often overlooked. Every
domain has it's own set of special terms, often with more than one
meaning. Or two words mean the same, but only in a special context.
Being precise here means always use the exact right word, even if
another would mean the same in this context, but not in another.
Reducing inconsistences is vital. Explain the specific meaning of a
word in the current context if it can have more than one. Be
careful with the language your non-technical users or clients use.
I write software for a big multi-national corporation. What one
department calls something, another calls it differently. Or they
use the same words, but for different things. Always disambiguate.
This skill can always be improved on, and as I continue to learn
I'll try to become better at it. If you have a junior under you
wing, try to educate them on this. It'll make both your lifes
better.
