If I was to define a software developer in short it would go like this: the one who solves problems. That’s right, developers face problems everyday i.e. creating scalable architectures, fine-tuning complex algorithms, persuading managers or a broken coffee maker. But – admit it – the most annoying are the trivial ones!
The problem in these problems is that they are not that trivial when you stumble on them first time.
Who hasn’t experienced himself wasting ages to come up with an obvious answer eventually? Remember the last problem you were banging your head against and suddenly got smacked by the “A – ha!” idea? “It worked yesterday” type of problems can be sometimes funny but face it – it can also harm yours and your development teams’ productivity.
Although there’s no simple remedy for this issue, I’m going to show you 3 methods you can leverage to reduce it a bit.
Though it might not come across as something serious, the rubber duck debugging is a powerful tool. It owes its popularity to Andy Hunt who described it in his bestseller The Pragmatic Programmer.
The idea behind it is simple – when you face a problem try to explain it step-by-step to e.g. rubber duck. The process of expressing the issue in oral form activates different parts of your brain and helps coming up with the correct answer or at least leads to provoking further insights. Defining the problem in a way someone can understand it, helps you to break it into smaller chunks and to get the root cause eventually.
Obviously you aren’t limited to the rubber toy. There are several ways of so-called thinking out loud triggering the same brain parts to deal with your tricky question. Also Jeff Atwood reports mounting evidence, that in number of cases just an easy exercise of writing an issue down helped StackOverflow authors figure out the answer for their own problem.
Ask why, 5 times
Another worth considering way of problem solving is a simple question-asking technique based on deductive reasoning. 5 whys originated in Toyota Motor Corporation as a pillar of well-known Lean Management. The concept is pretty straightforward. You track down the relationships between cause and effect to filter out the problem’s symptoms and to discover the underlying root cause. As you may have guessed, you do that by asking “why” 5 times in a row.
Again as in the previous method, you can consider visualising to squeeze more out of it. Let me show you an example of how we use this technique to improve our retrospective meetings.
Our distributed team complained about the feedback from QA unit. Here is the cause-effect path we outlined to find the source.
Another simple way of nailing down the core issue and coming up with respective action points.
Many times the key to problem solving lies in finding different ways of looking at it. And I mean more than only different – I’d say wacky! Have you ever tried to consider software architecture puzzle in terms of your body? Have you used somebody as a model to deal with deadlocks?