How I Approach a Problem Before Writing Code

I used to be a "feature factory"—churning out code the moment I got a ticket. But I quickly realized that velocity without direction is just speed towards a cliff.

Over the years, I've developed a rigorous mental protocol that I run before I even type git init. Here is my exact process for breaking down complex engineering problems.

The 4-Step Engineering Protocol

Visualizing the Architecture

When I'm in the "Paper Phase" or setting up my mental model, I often visualize the codebase structure. It helps to see the "shape" of the application.

This visualization represents how I mentally group concerns—separating logic, UI, and state management before connecting them.

From Abstraction to Reality

Let's look at a practical example. Say we need a function to retry a network request.

The Plan (Pseudocode)

Try request. If fail, wait X seconds. Increase wait time. Try again. Stop after N tries.

The Implementation

typescript

async function retry<T>(
  fn: () => Promise<T>, 
  retries = 3, 
  delay = 1000
): Promise<T> {
  try {
    return await fn();
  } catch (error) {
    if (retries <= 0) throw error;
    
    // Log the retry attempt
    console.warn(`Retrying... attempts left: ${retries}`);
    
    // Wait for the specific delay
    await new Promise(res => setTimeout(res, delay));
    
    // Recursive call with exponential backoff
    return retry(fn, retries - 1, delay * 2);
  }
}

Conclusion

Coding is an art of translation—translating human problems into machine instructions. The better you are at understanding the human problem, the more elegant your machine instructions will be.

Next time you get a task, resist the urge to code. Think first.

---

Ready to debate this? Drop a comment below or cheer if this resonates with your workflow!