The Art of Problem Solving (For Engineers Who Want to Grow)

Today, I decided to sit for 60 minutes and write. Not because I had the perfect idea. But because showing up matters more than clarity in the beginning.

Earlier today, I read about slow productivity, the idea that we should limit ourselves to one project per day. I think it’s powerful. Not always practical, but powerful. It reminded me of something deeper.

Work is not about doing more.
It is about solving better.

So today, let’s talk about problem solving.

Engineers Are Problem Solvers

At our core, we are nothing more than problem solvers.

The more problems we solve, the better we become, not just as engineers, but as thinkers.

But here’s the catch.

You cannot solve what you don’t understand.

And most of us jump into code before understanding the problem.

Step 1: Understand the Problem

There’s a quote often attributed to Albert Einstein:

“If I had one hour to solve a problem, I would spend 55 minutes understanding the problem and 5 minutes solving it.”

That’s software engineering in a sentence.

Before writing code, you need
Time
Quiet
Space
Written thoughts

Today’s React problem was simple on the surface. We wanted our panel to be global.

But simple problems hide complexity.
The real work begins when you explain the problem clearly.

If you can explain it, you can solve it.

Quietness Is a Superpower

Problem solving requires thinking.

Thinking requires quiet.

Context switching kills depth. If you keep jumping between meetings, Slack, email, and code, you never enter the zone.

At least one hour a day should belong only to you.
No switching. No noise.

That’s where breakthroughs happen.

Write the Problem Down

When you write the problem
Constraints become visible
Assumptions become questionable
Gaps become obvious

Sometimes I type everything into Claude and refine the problem statement until it becomes sharp.

Clarity is earned through writing.

Rubber Duck Method

If you can explain your problem to a five year old, you can solve it.

That’s the rubber duck principle.

Explain
What is happening
What should happen
What is breaking

In the explanation itself, your brain corrects you.

Reading Is Underrated

We underestimate documentation.

If you cannot quiet your brain, you cannot read deeply.
If you cannot read deeply, you cannot understand deeply.

React docs. Architecture notes. Design decisions.
Read slowly.

Depth beats speed.

Talk to People Without Ego

Sometimes the fastest way to solve a problem is humility.

When I told Anuj that he understood the repo better than I did, the conversation changed. He opened up. He shared context I did not have.

Making others feel important gives you access to hidden knowledge.

Ego blocks information.
Humility unlocks it.

Break Problems into Sub Problems

Every big problem is just smaller problems stacked together.

Break it down
What is the UI problem
What is the state problem
What is the architectural problem

Solve the smallest unit first.

Breakthroughs do not come from attacking mountains.
They come from moving stones.

Mini Projects Build Big Engineers

Small side projects are training grounds.

Mini projects
Build intuition
Reduce fear
Increase pattern recognition

Solve small problems consistently, and one day you will build something large that surprises even you.

Ask Why Five Times

Keep asking
Why is this not working
Why is it designed this way
Why did we choose this approach

The five whys method forces you to dig past symptoms into root causes.

Better why leads to better how.

Connect the Dots

Intelligence is pattern recognition.

When you
Read documentation
Talk to people
Build mini projects
Reflect in silence

Your brain starts connecting dots automatically.

That’s when complexity becomes clarity.

Work Smart, Not Just Hard

Hard work gets you somewhere.

Smart work multiplies it.

Smart engineers
Ask better questions
Validate assumptions
Listen more than they speak
Admit when they do not know

Saying I do not know, teach me is strength.


1. Start Every Problem With a “55-Minute Rule”

Before touching code:

Do this:

  • Open a blank doc.

  • Write:

    • What exactly is the problem?

    • What is expected output?

    • What is current behavior?

    • Constraints?

    • What have I tried?

  • Try explaining it in 5–7 simple sentences.

If you cannot explain it clearly, you don’t understand it yet.

2. Schedule One Protected Thinking Block (Minimum 60 Minutes)

Daily rule:

  • No Slack

  • No Teams

  • No context switching

  • Phone away

  • One problem only

Your brain needs uninterrupted depth to connect dots.

You’ve read Deep Work — this is that in practice.

3. Use the “Rubber Duck + 5-Year-Old Test”

Before asking for help:

  • Explain the problem out loud.

  • Pretend you’re teaching a 5-year-old.

  • If explanation breaks, that’s your gap.

Most solutions appear during explanation.

4. Read Documentation Like a Researcher, Not a Scroller

When reading React docs or anything technical:

  • Don’t skim.

  • After reading a section, close it.

  • Write what you understood.

  • Try a tiny experiment.

Reading without implementation = illusion of competence.

 5. Break Big Problems Into Sub-Problems Immediately

Instead of:

“Make panel global”

Rewrite as:

  • Where should state live?

  • Should we use context?

  • Is prop drilling happening?

  • What is current architecture?

  • What is the simplest version?

Breakthroughs come from solving small pieces.

6. Build Mini Projects Intentionally

Every week:

  • Pick one concept.

  • Build a tiny isolated example.

  • No production pressure.

Mini projects compound confidence.

 7. Use 5 Why’s for Debugging

Example:

Why is state resetting?
→ Because component re-renders.

Why re-render?
→ Parent changes props.

Why parent changes props?
→ API call inside render.

Now you’ve reached root cause.

Don’t stop at first answer.

8. Listen More in Meetings

In meetings:

  • Take notes while listening.

  • Don’t rush to speak.

  • Speak only after fully understanding.

Anzo typing while listening? That’s active processing.

Listening deeply reduces rework.

9. Remove Ego When Asking for Help

You did this well with Anuj.

Instead of:

“I tried everything.”

Say:

“You know this repo better than I do. Can you help me understand?”

People open up when they feel valued.

This is smart work.

10. Track Your Context Switching

At the end of the day ask:

  • How many times did I switch tasks?

  • How many uninterrupted minutes did I get?

Goal:
At least 1 true deep hour daily.

11. Research Before Building

Before starting a feature:

  • Search how others solved it.

  • Look at GitHub examples.

  • Check best practices.

Smart engineers avoid reinventing broken wheels.

12. Connect Dots Actively

After solving a problem, ask:

  • Where else does this pattern apply?

  • Is this similar to something I solved before?

This builds architectural thinking.

13. Work Hard → Then Work Smart

Early career:
Hard work builds capacity.

Mid-level:
Smart work builds leverage.

Smart work = asking right questions + validating early.

14. Daily Execution Formula

Here’s a clean system for you:

  1. Pick ONE primary problem.

  2. Write it clearly.

  3. 60-minute deep block.

  4. Break into sub-problems.

  5. Research if stuck 20 minutes.

  6. Rubber duck.

  7. Ask expert (ego-less).

  8. Document learning.

Repeat daily.

Final Truth

Problem solving is not:

  • Speed typing

  • Watching tutorials

  • Switching tabs

It is:

  • Quiet thinking

  • Structured breakdown

  • Deep focus

  • Repeated practice

And you already naturally think this way.

Now just systemize it.


Comments

Post a Comment

Popular posts from this blog

Man ka hua toh accha hai, aur agar man ka na ho toh aur bhi accha hai

Image
I was sitting in an airplane when an old lady next to me said,  "Man ka hua toh accha hai, aur agar man ka na ho toh aur bhi accha hai":  If things go as we desire, it's good; if they don’t, it’s even better. This philosophy by Harivansh Rai Bachchan carries profound wisdom. It teaches us that life is not just about getting what we want, but about trusting the journey, even when things don’t unfold as we expect. When Things Go Your Way: "Man ka hua toh accha" We often associate happiness with things aligning with our wishes, getting that dream job, being with the person we love, achieving a long-desired goal. And when these things happen, we feel joy, success, and a sense of control. But this is only half the truth. Life is not a straight path, and our desires are often shaped by our limited understanding of what’s truly good for us. What we wish for today may not serve us in the long run. Getting what we want is good, but it’s not the ultimate measure of happin...
Read more

Step into the unknown

Image
 Embrace the unknown. There are so many things in life that we fear. Imagine that you fear a particular project, imagine you risk losing something, imagine you risk the loss of a friend, imagine you risk losing love, all of these are risks. But the point is we want to embrace the unknown. What is to life, if we never explore the unknown, if we never know about someone. I feel like it's important to embrace the unknown. It's important to go through the darkest of times together and then come out stronger. It's important to be yourself.  The more you go with the flow of life and surrender the outcome to God, and the less you seek constant clarity, the more you will find that fabulous things start to show up in your life. I love this, so going with the flow of life, and surrendering yourself to the outcome. That is what makes life interesting. Imagine going on a solo trip, you don't really know whom you will meet or how you will stay but with the flow of life you eventuall...
Read more

Psychological Flexibility: The Key to Growth and Adaptation

Image
What is psychological flexibility?  These days a lot of the world is talking about something psychological or mental flexibility. In my mind, flexibility only meant physical and psychological flexibility was an alien concept in my head. However, this article is going to take you through understanding the what of psychological flexibility, the why of psychological flexibility, and the how of it. So before we understand psychological flexibility, let's understand what we mean by flexibility. Flexibility in my understanding is the ability to bend or twist something or move something very easily. For an example, someone doing yoga and stretching both their legs can be called as flexibile physically. So stretching is a part of flexibility in body, then stretching in terms of mind is also a part of flexibility. Just like you stretch your body doing physical exercises, stretching your mind will be called as psychological flexibility. However, when I read the definitions of psychological s...
Read more