Ninja Problem Solving

by Ara T. Howard

Recently this email went out to our technical team. I thought I'd share it un-edited.

problem solving is the number one service we provide.  over the years
i've developed some high level ideas about it that i've found
consistently leads towards good solutions, of which there are always
many.  you may or may not find these ideas useful but i wanted to
share them regardless:

- understand the problem completely.  if there is even a small lack of
clarity ask questions and dig deeper.  in fact, all problem solutions
stem from ruthless application of just this one principle.  that one
small word the client or manual mentioned you were embarrassed to ask
about - ask about it.  that one small line in the code you didn't
quite understand is likely the source of your problem, don't ignore

- talk about the problem *out loud* with someone else.  it's
surprising how often framing a problem in english, outside mental
constructs, will automatically suggest a solution.

- never debug alone.  buy someone coffee or beer.  call a team member
up.  it's nearly always a waste of time to debug by your self.  a
corollary: stop whatever you are doing and help if it looks like
someone else is stuck on a problem.

- when there is a problem check these things, in order, *every single
time*: read the code, read the manual, google it.  this is the
opposite of what most people do.  put another way "check the highest
quality sources first" because low quality sources lead to further
confusion.  i cannot stress strongly enough the importance of becoming
a religious code reader.

- never take the low road.  if you think "this is a hack but..." stop
and ask for help.

- don't fight the future.  a solution doesn't have to be complete but
it should at least take one single step towards being complete.  track
partial solutions with #FIXME, #TODO, a card in redmine or a
conversation with a co-worker.

- leave turds.  if your work doesn't make artifacts that people can
either re-use or re-edit it's probably a band-aid and not a solution.
making re-editable code is quite a bit easier than making re-usable
code.  avoid solutions that are neither like the plague.

- don't get angry.  your brain shuts down if you get mad at a problem.
 nothing we do has lives hinging on it so lighten up.  so you trashed
the data.  have a laugh and then get back to recovering it.

- avoid early adoption by being an early adopter.  the way to
understand the sweet spot between bleeding edge and crufty stability,
ironically, is to ruthlessly explore and understand new solutions.
you have to be an early adopter to understand when you should avoid
it.  FUD (fear uncertainty and doubt) should never be a motivator to
avoid new and shiny, but a deep understanding of technical flaws
*should be*.