Three ways to hack your brain to notice the small details

Last week I was working on an application where I needed to integrate with Stripe to accept payments and it’s fair to say testing did not go to plan.

As part of the integration I’d configured a webhook endpoint and written code to kick off certain actions when key Stripe events occur (like a successful checkout).

Everything worked perfectly in development and initial testing, so after a few days work I arrived at the all important live test. The idea was to make a purchase, then check everything was updated as it should be (off the back of a successful webhook call).

I filled in the payment details, hit Purchase and eagerly switched over to my inbox (fully expecting to see a welcome email from our API).

I didn’t see any email so I hit refresh a few times, but still, nothing arrived.

On checking further I discovered that literally nothing had worked as expected.

No records had been updated, no emails had been sent. There was no evidence anything had fired at all.

So I checked Stripe and sure enough, all the webhook calls had failed with a status code of 400 (returned from my webhook endpoint).

At this point it became very clear I didn’t have enough detail to diagnose the problem, so I set about adding more logging to the relevant code.

A few changes and a deploy later I tried re-sending the failed webhooks.

Same result. A 400 error code and weirdly, no logs. My changes hadn’t affected a single thing.

Not to be beaten, I went back and added more logging and tried again.

Same result, nothing in the logs.

At this point I started to suspect something was seriously wrong with the logging configuration for the live API.

After an hour or two of trying to figure out what the heck was going on I took a break to clear my head.

It was then, as I made a coffee and pondered whether software development was in fact the job for me, I had a thought.

Maybe, just maybe I should double-check the webhook endpoint I’d configured in Stripe.

On first glance it all looked good.

But then, as I stared at it further, I suddenly realised the full extent of my own stupidity…

I’d configured Stripe to send the webhook payloads to an endpoint at https://practicaldotnet.io/

But guess what? My API doesn’t live at https://practicaldotnet.io/

It lives at https://backend.practicaldotnet.io

I updated the webhook endpoint, re-sent the failed webhook calls and…

Everything worked, exactly as I’d expected it to in the first place.

Lessons learned

I’d love to say this is the only time I’ve made a mistake like this but, just like you and every other developer I know, these things happen from time to time.

It’s inevitable, in a world full of small, but important details, that sometimes you’ll miss something obvious.

A typo, a misconfigured URL or a missing letter in a connection string.

These are easy mistakes to make, and often difficult mistakes to spot because your brain tends to gloss over the small details.

But this experience reminded me of a few important tactics for debugging problems like this when you encounter them.

• Take a break
• Check the evidence (challenge your assumptions)
• Get someone else’s input

Take a break

It’s sooo tempting to keep banging your head against your desk when you encounter a problem like this.

To keep plugging away until you get it fixed.

But it’s amazing how often solutions emerge when you stop thinking about it.

Your brain is a massively clever and complex asynchronous processor and a short break gives it chance to process in the background, running multiple cycles to try and solve the problem you’ve presented it with.

A few years ago I used to work at an office about an hour away from home. I lost track of how many days I’d be stuck on a problem, only to solve it in the car on the way home.

Sometimes you’ve just got to step away from the keyboard.

Check the evidence

Your brain, generally, doesn’t want you to be wrong.

This is why it’s so hard to proofread your own work, because your brain tends to skim over the words instead of really analysing them to spot potential issues.

But sometimes you’ve got to challenge your assumptions. After all, it’s more likely there’s a typo in your code than a significant bug in the framework.

Rubber duck debugging is useful.

Odd though it might seem to get help from an inanimate object (especially one made of rubber and designed to resemble a duck), in practice it’s really useful to try and explain the problem to something that doesn’t know as much as you do.

Simply by trying to explain it, verbally, you’ll find yourself paying more attention to the details, translating technical concepts into simpler terms and slowing down as you go.

It’s amazing how often this process works, but you do have to live with the strange looks if you work in an office, with other people!

Get someone else’s input

As useful as rubber ducks are, they can only help you so much.

In the end, nothing beats being able to turn to a supportive, helpful colleague when you’re facing an unexpected challenge.

As with the rubber duck you get to slow down, explain things you might otherwise gloss over and check those all important small details.

But you also get a real, living breathing human being who will deliberately look for things you might be missing, or ask you to explain your problem in a different way.

If you have colleagues who you can turn to when you get stuck (without feeling embarrassed or silly for even asking the question) then you have a priceless commodity indeed.

But, if you’re holding back from asking a question because you don’t want to appear silly, or stupid, then this might be the time to give it a go anyway.

If you can find someone approachable in your team, try running the problem past them.

Most of the time people are only too willing to help and you might just save yourself a few hours of frustration.

Failing that, there’s always that rubber duck to fall back on.