When I was 19, I joined a company in Egypt that built a mobile application used by thousands of people in the uPVC industry. The app helped workshops calculate the exact cuts and measurements needed to manufacture windows and doors.
During my first weeks there, the team asked for a new feature they weren’t sure was even possible:
automatically generating optimal cutting plans to reduce wasted material.
They didn’t know the name of the problem.
I didn’t either.
But something about the challenge made me want to understand it deeply.
Finding the real problem
The first thing I learned was that the difficulty wasn’t in coding the feature. It was in figuring out what the problem actually was.
After a few days of reading forums, digging through academic papers, and searching for what this type of optimization belonged to, I finally discovered the name:
the Cutting-Stock Problem, a well-known problem in operations research.
That moment changed something in me.
Until then, I assumed every feature request in a job had a straightforward implementation.
This was the first time I realized that naming a problem correctly is half the solution.
My process: research first, code second
Once I understood the problem type, I spent a week studying classic solutions:
• First-Fit Decreasing
• Dynamic Programming
• Linear Programming approaches
• Different heuristics and trade-offs between speed and optimality
I didn’t have anyone to ask in the company. I was the only developer there at that time, so I had to build my own understanding from scratch.
This forced me to slow down, take notes, sketch ideas, and think like a researcher instead of a feature implementer.
Choosing a realistic approach
At first, I planned to implement everything completely from scratch. I quickly realized this would be extremely difficult and not the smartest way to solve the problem.
So I shifted direction.
While exploring different approaches, I found a Python implementation using Google OR-Tools. It explained the idea clearly and showed how other people modeled similar constraints.
I studied the logic carefully, understood how the solver defined the variables and constraints, and then recreated the same algorithm in C#.
This approach wasn’t about taking a shortcut. It was about understanding the model deeply and rebuilding it in a way that fit our system.
You can see the C# version I built here:
https://github.com/AbdullahAymanMSRE/cutting_stock_problem_cs
Designing the solution in C#
Even with OR-Tools guiding the direction, I still had a lot of decisions to make:
• whether to aim for perfect optimization or acceptable optimization
• how to structure the input to match real workshop needs
• how to design the logic so it ran fast on normal machines
• how to let users tweak parameters without overwhelming them
The first version wasn’t perfect.
The second one was much better.
And the final one was good enough to be used daily by thousands of people.
Publishing the core logic later felt important, because I knew someone out there would be searching for the same thing I had searched for.
Trade-offs I had to navigate
One of the biggest lessons was understanding that there is no best algorithm. There is only the best algorithm for a specific situation.
Some trade-offs I had to consider:
• Speed vs accuracy
• Memory vs clarity
• Perfect engineering vs shipping on time
This was my first exposure to real engineering constraints.
The surprising lesson
The technical part was interesting, but the biggest impact on me came from something else:
I learned how much I don’t know.
When you suddenly discover an entire field like operations research, you start wondering what other fields you’ve never heard of yet. That mindset has stayed with me ever since.
Today, before jumping into a new task, I ask myself:
Is there a known name for this problem?
Has someone already solved it in a different field?
Am I choosing this approach because it’s best, or because it’s the only one I know?
That experience taught me that being a good engineer has less to do with typing code fast and more to do with understanding the problem deeply before touching the keyboard.
How this shaped my engineering mindset
Looking back, this project taught me four things that influence how I work today:
- Understanding beats rushing
Taking time to research saved weeks of wrong implementation. - Naming the problem is a superpower
Once you know the name, you can find decades of prior solutions. - Trade-offs are the real engineering
Sometimes good enough is more valuable than perfect. - Curiosity outperforms confidence
Once you think you know enough, you stop being creative.
Final thoughts
I didn’t realize it back then, but solving this feature shaped how I think about engineering more than any tutorial or course ever did.
It taught me to be curious, to research widely, to question my assumptions, and to never rely only on what I already know.
And it reminded me of a simple fact that I still repeat to myself often:
you don’t know what you don’t know.
Leave a Reply