Both programming and debugging involve feedback. In programming this feedback is often instant, reliable, and structured. This is a kind learning environment. It’s one in which all information required to make inferences about what is happening is readily available. Using the repl or writing a unit test both involve contexts in which there is a clear path towards making effective decisions.

Wicked learning environments have no such guarantees. Information available is limited and partial. Decisions in these environments are difficult as there is inherent ambiguity and gaps that must somehow be accounted for. Debugging typically presents such a case. Errors that arise in the day-to-day work of a software engineer can emerge from any source, and solving them can demand an experimental approach. Identifying underlying patterns is hard as these patterns may not exist in a conventional form, and feedback is unreliable or not guaranteed.

  • Kind learning environments

    • Using the repl, writing unit tests (most of the time), programming in general
    • Tennis, football, and effectively all sport
    • Playing a musical instrument
    • Learning to program, as feedback on incorrect code is instant and readily available
    • Most environments tackled by machine learning: image classification, tagging, recommender systems

  • Wicked learning environments

    • Debugging obscure OS errors, race conditions, heisenbugs
    • Trading a stock, currency, or financial instrument
    • Playing MTT Poker
    • Learning mathematics, as there is no feedback
    • Most environments tackled by humans: humour, understanding a TV show or book, communication

Feedback in a Kind Learning Environment

Malcolm Gladwell’s Outliers: the story of success made the case for specialisation. Sportspeople like Tiger Woods practiced their craft from a young age with a tenacity and drive that isn’t found in those less successful. This is the now-famous 10,000 hour rule. Deliberate practice and focus on a singular goal is key, and this separates the best from the rest.

People like Tiger Woods, Magnus Carlsen, and Adam Ondra are all exemplar examples of people who are uniquely committed to their craft. Their ability can be orders of magnitude beyond even their elite peers. The 10,000 hour rule makes intuitive sense, and it’s easy to point to concrete examples where it applies.

But the envirionment in which they operate is a kind learning environment. Sport and chess both feature rapid, reliable, and predictable feedback that tells players how well they are performing, and provides clues on how to improve. This does not mean that improving is easy, but that the environment for doing so makes this unambiguous.

Debugging is a Wicked Learning Environment

The case against specialisation has many guises. David Epstein points out that most successful athletes and nobel laureates tend to possess a broader range of skills than is commonly appreciated. Gaining expertise outside your domain can help to augment your skills in ways that are not possible through continued specialisation.

Debugging presents a case where the problem domain is ambiguous and solutions are best sought through a variety of mental models. In this context, breadth of sufficient knowledge beats depth. It provides more tools to deal with the situation at hand, and more ways to use those tools effectively. Debugging is problem solving, and feedback on progress towards solving this class of problem is often unreliable or misleading. Divergent thinking can be the best approach to navigate these situations.

I’ve personally found diving into different parts of software engineering helpful. Learning about Linux and shell use in depth has been immensely useful while debugging tools failing on the frontend. Likewise, I’ve found a huge amount of transfer from a somewhat unconventional background in the field.