Developer’s Intuition – Why You Should Listen to Your Instincts

What do you picture when you think of a stereotypical programmer? Probably a dark room, dimly lit by computer screens, the coder is hunched over with his face almost in the screen. You hear wild typing and numbers and letters are flying along the screen. How does our stereotypical programmer approach an issue? I’m pretty sure society hears him spouting off which algorithm he’s going to use or the exact schema that his APIs are going to be using. I’m not going to lie, that’s how I figured I was supposed to be acting – approaching the problem with an analytical approach, using the proper words (although I always got them wrong) and trying to stick to a script. That all changed with what I call *the problem*.

Hunch is a real thing. Who knew?

It’s a late afternoon and I’m wrapping up my day’s work when the voice of Vina pipes up behind me. “Hey Al, I’m seeing some weird behaviour. Can you come take a look?” I glance behind me and notice she’s rather concerned. The look on her face is exactly what you don’t want to see right before the end of a day. I wander over and she shows me a series of steps on the app. It’s not good.

It ends up being a late night, but together, we resolve the issue. I’m annoyed, but not because of the extra work. What really gets to me, is that I had been working on this code base for years. The issue had been present for quite a while, a lot longer than I was there. In hindsight, there was plenty of time to spot it and deal with it, yet I never did. How could that have happened? After all, the signs that something was off were there…

When code seems suspicious, that’s because it is

I remember the first time I noticed something was wrong – I was working on refactoring and wanted to eliminate a chunk of code. Unfortunately, a function I was used to having wasn’t available. Instead, I had to work with some older code that wasn’t doing quite what I wanted. I looked over at my co-worker and asked a quick question. “It’s always been like that,” she said. Although it didn’t feel quite right, the current state of the app was working, and being brand new to the code base, I decided to place trust in the previous coders.

Few months later, I run into the issue for the second time when I was streamlining a major feature of the app. I was consolidating code that was reused in a couple other places in the app to make it more accessible to any future coders. While I was testing my changes, a section of code that I messed up was exposing some unusual functionality.

For about a week, while I worked on the new code, I kept asking “Why does it keep doing X or Y when it breaks? Shouldn’t it be doing Z?” Again, I had that hunch saying something else was wrong, but at the time, there were more important things to worry about. The weird functionality will surely go away once I was done fixing what I was working on, right?

The last time I ran into the problem, we were under the gun to get a release out the door. Our testers had found a series of steps that triggered a curious bug. Once again, I’m sitting at my desk, fixing things and wondering what caused this bug in the first place. Even though I soon resolved the problem, my instincts were telling me that there may be a deeper-rooted cause behind it. This time, we had plenty of other things to get done before the release, so there was no time to investigate. It was probably nothing anyway.

Intuition is a skill, so trust it.

Well, it wasn’t nothing and the issue just kept haunting me. That final bug was eerily similar to what Vina discovered and showed me. Each time I brushed up against the problem, I had that feeling in my gut. It kept telling me something was wrong, yet there was always a good reason not to trust my intuition – I was too new, it wasn’t what I thought it was, or we didn’t have enough time to look into it. Since I didn’t trust myself, the problem existed for far too long when it could have been resolved much earlier. I had plenty of time to fix it.

As developers, we’re naturally rational and analytical. The love for science and math is what got us here in the first place. We analyze a problem extensively and come up with a proper solution. While that’s a great way to approach problems, sometimes we just need to trust ourselves, our experience, and our instincts. You’ve been taught what you need to be a developer; you’ve seen multiple different applications and approaches and been successful many, many times. Trust yourself.