When I began working with ColoredCow, I was developing a new feature for one of our healthcare projects. It required me to understand how a certain part of the application works today and build the new feature on top of it.

I was tempted to build the new feature as fast as I can, even dreamt to deliver before the agreed upon deadline. Speed was all I was looking for.

My initial approach was the brute-force way based on intuition and logic. This approach worked so far, with my earlier assignments, because the problems I was dealing with were small and didn’t require knowledge of the entire application. That was not the case this time.

I was missing that I’ve to understand existing code in detail. Understanding another developer’s code can get too complex at times and can feel like a jigsaw puzzle. There was another factor playing against me. I was under impression that I understand healthcare domain well and avoiding efforts needed to know the existing system flow.

Unaware of my own feeling, and without getting desired results, I was thinking that problem is lying somewhere else. I was convinced that problem is not as simple as I thought initially. I started thinking more complex scenarios. Couple of those were

• The previous coder was jerk
• The application is not as great as it appeared initially
• It definitely needs more time to write an elegant solution
• I’ll take more time as I am new to the system

Tired from the futile efforts, luckily, I went to my teammate for help and he gave me a suggestion which is proving to be valuable in all my work now. The suggestion was to visualise the system and make its system diagram based on my understanding. He further introduced me to the problem-solving framework built in-house.

He simply suggested to “think on paper” and “follow a structured problem-solving approach”. Too simple to believe. What about all the scenarios I was thinking? I couldn’t believe that this is going to get me out of the rut.

I resisted but the fear of missing deadline forced me to follow his suggestion. I put effort to understand the feature from the user’s perspective and mapped it to the existing functional flow. This made the big picture clearer. Seeing the application in a simplistic form, I was able to come up with an efficient solution and was able to implement it with a marginal delay. Moreover, I realized that I was having all the things, skills, knowledge, etc, about the problem domain since the beginning. It was the approach to “Think Simple”, I was not believing in.

In hindsight, the solution to the most complex problems can come from the simplest of approaches. Also, I’m glad that my teammate gave me this suggestion and we talked about it rather than just helping me program the feature itself. It pushed me to solve this problem on my own.

Every day is a new learning and I believe this is another chapter in our book on Problem Solving.

My mentor suggested a couple of books on Problem Solving. I am reading or re-reading those and mentioning a couple of my favourites.

• Debugging, Pragmatic Programmer (although the chapter talks about debugging programmes, it is a problem-solving approach guide to me)
• Are your lights on?
• Human Centered Design Toolkit by IDEO

Also, we now make sure to train all our new joinees in this framework and are soon going to launch a workshop in CodeTrek on this.