Approaching a Problem…

There is a famous proverb — “How do you eat an elephant? One bite at a time!” Source Unknown (If anyone knows the origin, comment down below)

Before you go furious on me and yell at me by commenting that — How can one eat an elephant? Let me clear it out, it is a metaphor (figure of speech)

Let me explain…

Lately, I have been put in situations where I was given a problem(Raw & Fresh) and I needed to plan it, strategize and decide on which approach would work out best for the given problem.

I was never been in those shoes before, It was all new and challenging. In the process, I learned a few tips on approaching a problem which resulted in huge success in solving the problem.

Let me give you some tips on how to approach an elephant which can be easily solved and could also be scaled later on… Will start from the worst ways to best ways..

The Ugly Approach

One & the worst way of approaching the problem is eating the elephant in a single shot. Swallow the big fat elephant. Yaah! The problem has vanished? Huh, where is the problem now? It is still in your stomach. It is going to create all sorts of the problem the next day.

You got to deal with the next set of problems the elephants create in your stomach. You again sit and solve those sets of issues, which of course increases your work, eventually results in pressure which starts building up from all nooks and corners to solve it ASAP.

So never (ever) try to solve the problems at a single shot. No matter how big (or small) it might be.

The Okay, It’s Solved Approach

People have evolved and so are their thinking patterns. Developers like me need to have a clear picture of the Elephant in order to solve it effectively & that which doesn’t create more problems.

Complex and problems which are too vague to understand are quite difficult to solve. The solve-able way of an elephant is not to thing it as a monolithic. If you think in this pattern, then you go back to the Ugly Approach which must be avoided at all circumstances.

Break it down! Yes (you heard it right). Polylithic is the right approach you must be taking it down to solve the elephant. I have seen in many instances, it takes out workload quicker than you can ever think of. Cut the elephant into 10 smaller pieces (or even better if it is 20 or 30).

You might ask, why this approach works best? I could give you an answer in two pointers

• You could share the pieces of elephants with your colleague. So you can take up at what is important. For instance, Elephant ABC can be split into A, B, C. You could solve A, B so you can hand over C to a colleague to complete the task (just an example for resource allocation).
• Instead of focusing on lots of problem sets, which you can solve but in an improper way. Using this approach You are forced to focus & concentrate on one step of the problem at a time, which results in a better outcome.

Yes, it solved in a better & digest-able way. You solved it, everyone’s happy. The work is done.

But let take it up a notch, shall we? How do you solve the same problem effectively & quicker consistently and maintain the quality of work?

The Stupendous Approach

So you are still here to know the secret, huh? That’s the interesting part, we need to spice things up a little to hit the right spot. Take the hint from the next proverb.

Give me six hours to chop down a tree and I will spend the first four sharpening the axe — Abraham Lincoln

You got it now (I think).

First thing, you sit down with a piece of paper & pen. Understand it & Grasp it to the full extent. Scribble, jot down points and gather these informations.

Next Step, Apply Polylithic method. Break it as tiny as possible, segregate it by functionality-wise, design-wise, miscellaneous-wise (very important). As they say, the devil is in the details.

The Spice — is in the strategy. Think clearing! Remember the ABC problem? A, B, C you just don’t do A, B by yourself because it is just important or it is easy. You must do it because you are best at it.

The next important detail is the timing of the task you take & solve. You could solve A or B first. If B is dependent on A and you still take B first, that’s stupidity. This analysis must be done on the first step of this approach.

Run multiple threads for each task, keep it short & as simple as possible. If at any given moment you feel that the thread has lots of jobs working on the background. Break it up, and you will be able to see the exorbitant amount of time saved for yourself and the team.

To wind things up — Take, one step at a time. Smash the elephant into tiny pieces. Run it concurrently and never do multiple task simultaneous(even if you are good at it)

Also, let me know about the ideas which I have thrown at you. Do tell me about your approaches to a problem.

And… Don’t forget to smash that clap button.