Occasionally during my career I have been surprised by new insights. One of the things I found remarkable was how quickly I thought up a new explanation for what could have caused a problem when the previously expressed explanation was proven wrong. After awhile I stopped finding it remarkable and found it remarkable how long it took me to figure out that this happened.
I discovered this as I programmed software applications. You constantly have code fail to run as you expect and so get plenty of instances to learn the behavior I described above. While I probably added to my opportunities to learn by being a less than stellar coder I also learned that even stellar coders constantly have to iterate through the process of creating code and seeing if it works, figuring out why it didn’t and trying again.
The remarkable thing is how easily I could come up with an new explanation. Often nearly immediately upon what I expected to work failing to do so. And one of the wonderful things about software code is often you can then make the change in 10 minutes and a few minutes later see if it worked (I am guessing my brain kept puzzling over the ideas involved and was ready with a new idea when I was surprised by failure).
When I struggled a bit to find an initial explanation I found myself thinking, “this has to be it” often because of two self reinforcing factors.
First, I couldn’t think of anything else that would explain it. Sometimes you will think right away of 4 possible issues that could cause this problem. But, when I struggled to find any and then finally came up with an idea it feels like if there was another possibility I should have thought of it while struggling to figure out what I finally settled on.
Second, the idea often seems to explain exactly what happened, and it often feels like “of course it didn’t work, what was I thinking I need to do x.” This often turns out to be true, doing x solves the problem and you move on. But a remarkable percentage of the time, say even just 10%, it doesn’t. And then I would find myself almost immediately thinking, of course I need to do y. Even when 10 seconds ago I was convinced there was no other possibility.
Once I got the clear feedback my “only possibility” was wrong a new idea was immediately available.
Dinosaur Comics – “programming is for folks who are thrilled when a computer reminds them they’re missing a bracket or a semicolon.”
I think software development brings this aspect of how many of us think into focus much better than other attempts to solve problems. I think the main reasons are that, first, it is so obvious that it is a problem and second, you get many problem solving attempts every day. You want to add a new feature, the code you added didn’t work. It is much harder to say well: “my solution is good, it is some other factor that causes the results not be be what we want. We need to have those other people fix that other issue; my solution was right.”
In software development you often get almost immediate feedback and it normally is not subtle. I try my idea. It fails. Ok, change this. It fails again (maybe differently). Ok, change this. It fails again (maybe differently again). Ok, try this. Yay, now it works. You do this many times a day.
What I learned from this was to question what is the explanation going to be if this attempt fails? This can provide a good idea for something to address right away. It doesn’t always work; but I was able to think up more possibilities more easily this way. I actually found this thinking less useful for software development than other problem solving efforts. With software development it is often so fast to just change and try and see what happens that you can just do that. With other problem solving efforts though this question can be extremely useful.
When problem solving attempts are going to be expensive or time consuming thinking of several options becomes even more valuable. Spend a bit of time asking yourself what would your reaction be if this attempt failed. Occasionally you will be able to jump right to a better solution than if you just experiment based on your initial thoughts.
I’m sure others talk about this idea but like so many good ideas that exist we don’t apply them. We either never learned about them or have forgotten about them. It seems like some pretty basic psychology – our brains largely focus on what we decide they need to focus on, if we accept a suggestion our brain can turn to other matters.
The truth is occasionally software development will also run into issues that are mainly about interaction with other parts of the system (they are not limited to just the code you are writing). But I find the problem solving involved in coding can be much more easily isolated.
It is possible, for example, some system administrator has made a modification that means some aspect of the underlying system doesn’t respond as you expected. But software developers try to create code in a way that conventions are followed and as long as we comply with the accepted ground-rules things will work as expected. And in general the underlying system constraints are understood by those involved (occasionally this communication doesn’t work perfectly, however).
An Application Programming Interface (API) can be seen as one way programmers try to assure things will function as expected. And few organization have nearly as concrete an idea of the requirements of their processes as an API provides. Some other processes would be pretty well understood in great detail such as the processes to manufacture drugs or chemicals.
Related: Mistake Proofing Deployment of Software Code – Baking in Quality to Software Development – Interruptions Can Severely Damage Software Developer Performance – Improving Software Development with Automated Tests
