If you’ve ever encountered an issue that has had you in a tailspin for ages, only to find that the solution was something you never would have guessed, then maybe you’ve been looking at the problem wrong. Maybe, the problem isn’t the problem at all…
At work (which I will refer to by the codename BigSecret), I recently completed a support/feature request that had been hanging around for almost 3 years. It had previously been ignored and dismissed as too difficult, bordering on impossible. As it turned out, it was nothing of the sort. It was a challenging problem, but one with a definite solution. It just took some digging to find.
I came across the request a few weeks back, when it was resurrected by a client for no obvious reason. My colleagues didn’t seem to pay any attention to it, but it caught my eye as something that sounded intriguingly simple, and a totally reasonable and useful request. I was between tasks and, being an intern, my manager was having trouble finding me tasks that were engaging without being too difficult or complex. So I had a bit of time on my hands, and I decided to have a sneaky go at solving this request.
I started off by reading though the whole request history, which was actually quite long, and had a few technical details to point me in the right direction. I then dug myself deep into the source code of the relevant module, trying to understand how it worked, and why it had seemed so impossible to implement this request to the others that had tried. Once I had a handle on it, I just started experimenting and tweaking the code to see what effect I could have on it. Once I was seeing some effects (and maybe even earlier), I went to every programmer’s best friend: Google. This lead me to various forums, chief amongst them always StackOverflow. I carefully read and reread about a dozen or so different StackOverflow post on the subject, and after a bit more experimentation, I had a proof of concept for the feature working in a few hours, all up.
You see, the problem that previous attempters had seemingly faced was that they had gotten caught up on their own understanding of the problem and how a solution should work, rather than seeking the knowledge to find out how the request could be solved. The problem they were having was not the request’s problem but the problem of their own knowledge and understanding. With no prior knowledge and lots of time on my hands to dedicate to finding the information necessary, I was able to overcome the internal stumbling blocks of previous assignees.
I can understand how it can happen. When you have an idea of how something works, it can be hard to let go of that. But when you’re working in IT, where knowledge can become outdated in a matter of months, it just not possible to linger on old understandings. It happened to me multiple time back when I was working at the House. What you need to learn to do is free yourself of what you’ve been told and what you expect. Just observe, and get fresh information. If you’re stuck, maybe ask someone else for their view on the situation. A fresh set of eyes often can see things the most obvious things a stale set won’t.
It also doesn’t help much when you receive misinformation from your clients. Hot tip: It’s always a good idea to attempt to reproduce behaviour described by a client, even if the behaviour is positive. In the case of the story above, the client had based their request on supposed existing behaviour that they claimed was present, but actually wasn’t. In the end, I implemented both the requested behaviour and the assumed behaviour.
Sometimes, the problem just isn’t your problem. Your problem is your knowledge and/or understanding.
What do you think? Have you encountered any problems where your understanding was the issue? Have I said anything you disagree with? Tell me & everyone else who passes through here what you think in the comment below.
To Infinity and Beyond,
Nitemice
Nitemice 