Posted On: 2022-07-25
When programming, it is common to run into seemingly insurmountable obstacles: even when everything is designed and implemented exactly the way you intend, you still aren't getting the results you want. While there are a wide variety of ways to deal with such situations*, there are two that I'll be focusing on in this post: to dig in deeper, trying to understand why it's not producing the desired results ("deep diving" into the approach), or to step back and try something completely different (to "pivot" away). Both have advantages and disadvantages, meaning it's valuable to be comfortable with both approaches - even if you unconsciously favor one or the other.
When a program isn't working as it's supposed to, that means there is a knowledge gap for the person designing/analyzing the system. In software (and life generally), how things actually are is the truth, whereas how one believes things are is a predictive model that allows for things like design and planning. When that predictive model is wrong, it can be frustrating and/or painful, but we can always update that model - provided that we get the necessary information to do so. In the world of software, getting that information generally involves careful observation and precise work: poring through logs, stepping through code, running controlled experiments. The goal of such an approach isn't to solve the problem - it's to find the flaw in one's own model, and then update that, before trying to fix anything.
Deep diving into a solution can provide valuable insights into how existing code actually works. It can reveal erroneous assumptions about legacy or third-party code, and it often enhances a developer's own understanding and skills. Unfortunately, it doesn't always lead to a solution: sometimes the underlying problem cannot be fixed (ie. third-party code cannot do what you assumed it would), or the attempt to properly understand the code takes up too much time.
When solving problems, code needs to work correctly. In the context of a misbehaving system, this means that understanding why it's broken is primarily a means to fixing it*. Unfortunately, many times a flawed system has fundamental issues, so even with the knowledge of what is wrong, one would still need to invest time into a fundamental rewrite. Pivoting away from a problem is an attempt to short-cut that process: abandon code that doesn't work, accept that it must be axiomatically flawed (even though you don't understand why), and try to find a completely new approach.
When described this way, pivoting may seem undisciplined, but doing so successfully requires flexing an important programming skill: finding multiple alternative solutions to any given problem. When a problem is narrowly defined, there may be only one solution, but, if you step back far enough, there are always multiple ways to approach things. Consider, for example, the task of changing the text color on a specific word on a page. Narrowly defined, one would focus on changing the text's "color" property, trying to get it to behave as expected. If that doesn't work (ie. the "color" property can only affect a whole sentence, not a single word), there are still other approaches (ie. write a new [correctly colored] word directly on top of the old one, that way the user only sees the correct color, and not the incorrect one.) Pivoting is all about recognizing the variety of approaches available, using the one that seems most promising, but being willing to try the next one if it doesn't work out.
Ultimately, a developer needs to be able to dive deep into some things, and pivot away from others*. No single tactic works for every situation, so practicing both approaches is an important part of honing one's skills. Personally, when I was a junior developer, I had a tendency to dive deep into every problem, and it was only thanks to guidance from my mentor that I learned to pivot. Once I'd grown into my role, I tried to provide that same gift to others who sought my advice: prodding them to go deeper when they were too quick to pivot, and suggesting pivoting to those who over-committed to a single approach.
Hopefully this post about two problem solving strategies (deep diving and pivoting) has been interesting for you. If you happen to be a programmer, I hope you'll think of these approaches the next time you feel stuck - it can be easy to default to only using one of these two, so consciously picking the other may be what it takes to reach a workable solution. As always, if you have any thoughts or feedback, please let me know.