How to Find Joy in Problem Solving

A special thanks to our guest writer, Renée Mineart for writing this blog article. 

Someone asked me recently what I enjoy most about being a Developer and Tester, and I thought what a great topic for a blog!

So, here we are…

For me, pretty much everything I do comes down to one of two motivations: either creating something new or solving a problem. Often, the thing I’m creating is designed to solve a problem, so most things really come down to solving problems, which is one of my passions in life.

In my IT career, I have held 1st, 2nd and 3rd line Tech Roles, been a Manager for 1st, 2nd and 3rd line Technicians and have even set up brand new Service Desks in green field sites. What I loved about all those roles is that they were largely about being the hero for someone with a computer problem. As a 2nd line Tech, I’d often walk into someone’s office who was pulling their hair out because they couldn’t print or couldn’t save a file or something. I’d sit down at their desk and in five or ten minutes (usually just waiting for the computer to reboot) I’d fixed their problem and be hailed as a hero. Then, I’d go to the next office and repeat. What a great job! All that was missing was the cape with a big letter S on it and the occasional ticker tape parade!

As I moved into development and testing, the nature of the problems changed. I was now either developing code that solved a problem or debugging it so it would work. It was still problem solving but on a whole different level. My job morphed from being everyone’s hero to being much more about solving the problem and that being its own reward.

Debugging for me is a lot like solving a Sudoku puzzle, something else that I love. Both sorts of puzzles, Sudoku and buggy code, have a way of sucking me in, drawing in my full attention on a mission to find the solution.

What I love most about solving problems, is when I successfully solve something that other people say was impossible or had given up on. This is the greatest accolade on the planet if you ask me. When someone says, “that can’t be done”, is when I roll up my sleeves. If you’ve read my ‘But That’s Impossible’ or ‘The Fine Art of Problem Solving’ blogs, then you’ll understand what I mean.

I also tend to look at problems from a different perspective than most people I’ve encountered. If twenty people are admiring a statue, I’ll be the one person who walks around behind the statue of a General on a horse to get a photo of the twenty people looking at it. Then, I’ll focus my lens on the old guy wearing a heavy coat with a walking stick, feeding the pigeons in the distance.

Why? Well, I figure if twenty people are all taking pictures of the guy on the horse, a statue that hundreds upon hundreds of people have already taken pictures of, then that’s a done thing. In fact, it’s overdone and boring. What’s interesting, is the guy in the distance no one notices. He might be the great-grandson of the General on the horse and he comes here every day to feed the pigeons in his great-grandfather’s shadow. Or maybe he poured the concrete pedestal supporting this glorious statue. Regardless, I want to tell his story. He is what interests me. Not what everyone else is doing and has been doing since the statue was erected. That’s how I approach problem solving. Everyone is trying to fix the problem with hammers and I pick up a screwdriver.

An example of this- I wrote a white paper several years ago on the First Time Fix Conundrum with this ‘look at things from a different angle’ approach. I was at a company where we were trying to define, measure and improve our Service Desk’s first time fix rate; the number of tickets we resolve while the customer is still on the phone. I came up with the idea that we can categorise every call we get into one of three categories: Yes, No and Maybe.

• Yes category of calls were things we could 100% of the time fix over the phone e.g. a password reset.
• No category were those things that we could never fix over the phone e.g. a paper jam.
• Maybe category were things we could technically fix over the phone, if we had the training and access rights to do so.

I then surmised that if a task was beyond a person’s ability to do because of the nature of their job role, then it shouldn’t be counted against them in their KPI. So, the entire 'No' category of calls was removed from our KPI objectives. The 'Yes' category formed our skills matrix; if someone couldn’t do something in the 'Yes' category, we trained them on it. The 'Maybe' category then formed our overall training objectives and the measurement of our Service Desk’s maturity. If we as a team couldn’t fix something, we went to the people who could and asked them to teach us how. It was a brand-new approach to Service Desk management and solved a problem in a way other people hadn’t even thought of. That’s what I love about problem solving.

Writing, one of my other passions, is also problem solving of sorts. How do I convey the message I’m trying to get across within a certain word limit (there’s always a word limit), while drawing the reader in and entertaining them to one degree or another? It’s a puzzle to be solved. Just like with writing code, in storytelling every word is important. Every comma or semi-colon has meaning.

How does the saying go? Necessity is the mother of invention. In other words, all great inventions fix something, and all great inventors, developers and testers are problem solvers.