300,000 cargo items. 2,000 containers. One scrapped rebuild. This is what super complex combinatorial optimisation actually looks like.
A client walked in with what sounded like a straightforward ask.
“We need a cargo load planner. A real one — not one that approximates, not one that takes minutes, and not one that breaks above a few thousands of items.”
Simple. Visual. Clean.
I said yes. I had no idea what I’d just agreed to.
The Moment I Realised What I’d Stepped Into
I started digging. And the deeper I went, the quieter the room got.
At the core of a cargo load planner sits one of computer science’s most notoriously stubborn problems — NP-hard combinatorial optimisation. Not the kind you Google your way out of. The kind that has decades of academic papers, PhD dissertations, and entire research careers dedicated to it — with no perfect solution in sight.
You’re not just fitting boxes into containers.
You’re simultaneously solving:
- Weight distribution
- Fragility constraints
- Axle load limits
- Delivery sequencing
Across thousands of containers. In real time.
And my target? I didn’t want it to solve in minutes. I wanted seconds.
Go ahead. Laugh. I would have.
Three Months. One Brutal Truth.
Here’s what nobody tells you about hard engineering problems:
The first solution that works will lie to you.
Mine did.
My first approach was clever. Genuinely clever. It handled edge cases gracefully, passed every test I threw at it, and had just enough elegance to make me feel like I’d cracked something important.
Then I put it under real load.
It collapsed.
Six weeks of work. Gone. Not optimised — scrapped. Rebuilt from scratch. That moment didn’t break me, but it humbled me in a way no textbook ever could. Because what replaced it wasn’t more clever.
It was simpler.
And that’s the lesson I won’t give away — because it’s the kind of thing you have to earn by losing six weeks to a solution that felt right but wasn’t. The moment I stopped trying to be impressive and started trying to be correct, everything changed.
The Three Things That Nearly Killed It
1. The Rebuild I Didn’t See Coming
I’ve already told you about this one. But I want you to sit with it for a second. Imagine having something working. Imagine showing it to people. Imagine being proud of it.
Now imagine deleting it.
That’s what this project asked of me. And the only reason I could do it was because I finally understood the problem well enough to know my solution was wrong. Understanding the problem that deeply — that took the first six weeks.
The solution took the next six.
2. 18fps. Then Magic.
300,000 cargo items rendered in 3D.
Naively, that tanks your frame rate into slideshow territory. The browser doesn’t care about your deadlines.
The fix required going several levels below the surface of the rendering library I was using — batching everything into a single GPU draw call instead of thousands. Two days of work. The result: locked 60fps.
I’m not going to tell you exactly how. But I’ll tell you this — the answer was already in the architecture. I just had to stop fighting the GPU and start thinking like one.
3. A Single Missing Line
This one still haunts me.
A WebGL memory leak. Silent. Invisible. It only surfaced after 20 minutes of continuous use — which meant no test caught it, no reviewer caught it, and no amount of staring at the code would have helped.
One missing cleanup call. Holding GPU memory hostage.
30 seconds to fix. Weeks to find.
The lesson isn’t about the bug. It’s about the class of problems that only reveal themselves under the weight of real usage. You can’t simulate time. You can’t test for it. You just have to ship, watch, and stay humble.
What This Actually Shipped As
- 2,000+ containers packed in a single run
- 300,000+ cargo items placed with full constraint accuracy
- 3–5 seconds total runtime
- 60fps 3D visualisation
Not a prototype. Not a demo. Production.
The Uncomfortable Truth About Hard Problems
The best engineering problems don’t come with a solution in the docs.
They come with a blank file, a deadline, and the quiet, slightly irrational confidence that you’ll figure it out.
That confidence isn’t arrogance. It’s a choice. A decision to stay in the room when everything in you is screaming to simplify the requirements, ship something good enough, or just tell the client it can’t be done in seconds.
It can be done in seconds.
But only if you’re willing to throw away six weeks of work when the problem asks you to.
What’s Next
I’m writing more about the engineering decisions behind this — rendering at scale, constraint solving, and the architecture choices that made the difference.
If this resonated with you — whether you’re building at this scale, obsessed with the craft of software, or just love a good story about a developer refusing to accept “impossible” — follow me here on Medium. Find more about me at: https://tararoutray.com/
And if you want to talk shop, trade war stories, or just connect with someone who thinks deeply about hard problems — find me on LinkedIn.
The hardest problems don’t care about your credentials. They only care whether you stayed.
Did this resonate? Drop a comment with the hardest engineering problem you’ve ever faced.
I Solved an NP-Hard Problem in 4 Seconds. Here’s What Nobody Tells You. was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
