Any developer who's been in this profession for any amount of time will relate to this story. I was working on an application integration using a vendor's REST API. The purpose of this integration was to manipulate metadata across several different customer sites and the documents contained within. My initial uses of the API went well. I was able to query the main list of sites and then I was able to get a list of the documents for each site. The only problem was that once I tried to access documents beyond the first site in the list, I received an HTTP 403 error. This error is a security access error that says the current user doesn't have proper access to the requested resource.
This was strange. The account I was using to test was a Site Administrator account with full access. It was a head-scratcher. So I started doing what all developers do when faced with a difficult challenge. I went fishing for ideas (AKA trying stuff). My first thought was to set up an account with different rights. I gave that a try only to be foiled by licensing. There were no licenses available, so I was going to need to go a different route. I did what all good developers do: I consulted Google and came up with a few loose threads, but for the most part, it was no help.
Back to the drawing board. I decided to return to the code to try to reproduce the error and see if there was any additional information I might have missed. With a few tweaks, I was able to reproduce the error. It returned the same vague error. Okay, now what? I returned to the code and tweaked something to see if I could get a different answer. (It worked with my parents, so why not this API? LOL.) After a few more failed attempts, I finally received a different error value. It read something like: “The current logged in user is not authenticated against this site.”
BINGO! I had a new error to investigate, this time with actionable information. I returned to the documentation to be informed that I needed to authenticate against each site individually versus sharing a single common authentication. I quickly tweaked my code to authenticate with each site individually. Huzzah! This worked perfectly. After this blocker, I was able to finish my application integration in short order. Error-driven development had worked.
I smile at the irony of causing errors (bugs) to find solutions to fixing other errors (more bugs). It's not every day that you get paid to cause a bug. But I digress. What happened here? Was some senior-developer Jedi mind trick used to root out the culprit? Or was it something else?
It was 100% something else.
Let's talk about another development story. Last week, I was working with a colleague who came to me with the following message over Teams: “When you have a few cycles, can you take a look at the data for client ABDC to see why it might not be loading?” I was between tasks, so I took a look right away. This was a new client, so I queried the data warehouse to see if they had their initial setup made. Here's the query:
SELECT * FROM v_clients WHERE code = 'ABDC'
Zero records returned. I returned to Teams: “Hey COLLEAGUE. Are you sure this client was set up at all? Not seeing it in v_clients. Is the spelling proper?” The answer came back immediately: “Doh?!?!? Yeah, that's the problem ABCD not ABDC. Thanks for the assist!” Huzzah! Another victory. Was it my Jedi-level query skills that solved this problem or was it something else?
It was 100% something else.
In each of these situations, it wasn't the micro solutions of error codes and queries that solved the problem. Nope. What was it? I posit that the solution to the fix was applying a different perspective to each given problem. In the former, it was triggering a different error code and the latter solution was achieved by simply having someone else look at the problem. I can't tell you how many times that particular colleague helped me find a bug with laser-like precision in a millisecond just by looking at a block of code for a moment. “There it is!” The old fresh-pair-of-eyes technique seems to always work.
Sometimes you need to step away from a problem to find a different path to solving it. There's an old technique I learned when I was doing professional developer training. Sometime students pose questions that I would find difficult to understand or that just didn't make sense in my mind. My technique was to ask the student this question in return: “Can you ask that a different way?” This required the student to rethink the problem and gave me a few more beats to come up with an answer. This technique was often successful, and I continue its use it today when working on solving problems with other teammates.
So now you have a tool to solve sticky problems. Simply ask yourself: “Can I look at this another way?”
