Programming

How I Realized I Can't Actually Code

A senior developer with 10 years of experience discovers that knowing frameworks isn't the same as understanding computation, after a single math problem exposes the difference between brute force and engineering thinking.

Yesterday my script hung. The CPU was burning at 100%. I killed the process.

I'm a Senior Developer with 10 years of experience. I write Python, I know Java and plenty of trendy frameworks. But at that moment I realized: I don't actually know how to program. More precisely, I know how to use tools. But I don't understand the nature of computation.

This article is about how one mathematical problem changed my understanding of software development. And why in a couple of years, when AI will be writing all the code for me, this understanding will be the only thing that saves me.

Perhaps it will save you too.

The Illusion of Abstraction

We live in an era of maximum convenience. Need sorting? .sort(). Need face recognition? Plug in an API. Need a model? AutoML.

This is great for business. Time-to-Market shrinks. Products ship faster. Companies earn more. But there's a price: we lose the "feel for the material." We stop sensing the weight of computation.

A junior developer writes a nested loop over an array of a million elements. Feels no pain. The processor "eats" it all in a second.

Then that code hits production with 10,000 concurrent users. Servers crash. The business loses money. The CTO screams at the team. And the junior doesn't understand what went wrong. After all, it worked fine on their laptop.

The difference between a junior and an engineer isn't knowledge of syntax. It's the ability to sense a catastrophe before hitting "run." And here's the problem that taught me that sense.

The Problem That Changed Everything

Imagine a triangle of numbers:

   3
  7 4
 2 4 6
8 5 9 3

The rules are simple:

  • Start at the top (number 3)
  • Move down, choosing the left or right neighbor
  • Goal: find the path with the maximum sum

In the example above, the optimal path is: 3 → 7 → 4 → 9 = 23.

A triangle with 15 rows can be solved by brute force in a second. But what if the triangle has 100 rows?

A Developer's First Reaction

"I'll write a recursive function that checks all paths and picks the best one."

def find_max_path(triangle, row=0, col=0):
    if row == len(triangle) - 1:
        return triangle[row][col]

    left = find_max_path(triangle, row+1, col)
    right = find_max_path(triangle, row+1, col+1)

    return triangle[row][col] + max(left, right)

Ran it on a 15-row triangle. Got the answer in a fraction of a second.

Excellent! Now let's run it on 100 rows. Waited a minute, five, ten. The process hung.

The Mathematics of Catastrophe

Let's count what's happening. At each step the path splits in two. We have 100 steps. The number of possible routes = 2⁹⁹ ≈ 6.3 × 10²⁹. A number with 30 zeros.

If we imagine a supercomputer checking 1 billion routes per second, it would take 20 billion years.

At that moment I understood: the problem isn't Python. It's not memory. It's not the processor. The problem is how I think.

My algorithm is mathematically doomed, no matter how powerful a server I rent.

The Paradigm Shift

The solution requires a fundamental shift in mental model. Instead of standing at the top and guessing which path to take (looking into the future), you need to start from the end. Go from the future to the present.

Look at the second-to-last row:

  2 4 6    <-- Current row
 8 5 9 3   <-- Base

Take the number 2. It has two children: 8 and 5. If we ever reach point 2, we'll definitely go to 8, because it's more profitable. So the real value of cell "2" = 2 + 8 = 10.

Take the number 4 (in the middle). Its children: 5 and 9. Best choice: 9. Value of cell "4" = 4 + 9 = 13. And so on.

Now the second-to-last row has become:

10 13 15

The last row is no longer needed. It has "collapsed" into the second-to-last. The triangle is one row shorter. Repeat the process 99 times, climbing to the top.

# Go bottom-up
for i in range(len(triangle) - 2, -1, -1):
    for j in range(len(triangle[i])):
        # Add the best option from the row below to the current number
        triangle[i][j] += max(triangle[i+1][j], triangle[i+1][j+1])

print(triangle[0][0])

Three lines of code. Instead of 20 billion years of computation (O(2ⁿ)), the processor solves the problem in 0.002 seconds (O(n²)). This is the triumph of engineering thinking over brute force.

Where This Works in Real Life

This logic governs the world around us. When Photoshop compresses a photo and leaves the face untouched (Seam Carving) — it's the same triangle, only searching for the path with minimum energy.

When traders price options (Binomial Pricing) — they collapse a probability tree from the future to the present.

When autocorrect fixes a word — it computes Levenshtein distance through a dynamic matrix, rather than searching the entire dictionary.

One principle, thousands of applications.

How to Develop This Sense

But how do you learn to see these patterns? How do you develop the intuition that screams "Stop!" before you write O(2ⁿ)?

Engineering thinking is a skill. And like any skill, it needs to be trained.

That's exactly what Project Euler exists for — a platform with over 900 problems of varying difficulty. I absolutely love it.

This isn't LeetCode with pattern memorization. This is a trainer for computational intuition. Each problem is brilliantly simple in design: it looks solvable by brute force, but is carefully chosen so that you don't have enough time or resources to compute the answer directly. You're forced to invent.

Pick up a pen and paper. Find a mathematical pattern. And only then touch the keyboard. After solving each problem — pure joy. Not because you beat the system. But because you saw something that was invisible.

You start to feel the weight of a loop. When you see O(2ⁿ), your heart clenches.

Systematic problem-solving levels up your programmer IQ — the ability to see inefficiency before running the code. And this skill will become critically important very soon.

What Will Remain When AI Arrives?

In a couple of years, AI will write all the code for me. What will remain then?

  • The ability to understand that a problem is unsolvable by brute force.
  • The intuition that whispers: "Start from the end."
  • Engineering thinking that turns 20 billion years into 2 milliseconds.

What Will Remain Forever

Tools change. Yesterday it was jQuery. Today it's React. Tomorrow it's something generated by AI. But O(2ⁿ) complexity will forever remain O(2ⁿ) complexity.

Project Euler brings you back to the fundamentals. It reminds you: behind every beautiful interface there is always hardware and mathematics.

And understanding how to turn 20 billion years into 2 milliseconds — that's what distinguishes a real engineer from an IDE user.

Yesterday my script hung.

Today I know why.

Tomorrow, when AI writes code for me, I'll still be able to tell it: "Your algorithm is doomed. Start from the end."

Reading time: 8 minutes.
Computation time saved: 20 billion years.

P.S. On the other hand, why should I level up my engineering IQ if ChatGPT can check complexity and write the optimal solution? Why solve Project Euler problems if Claude will do it for me?

Further reading