-------------------
 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.