Blog

When I opened my first pull request to WooCommerce, I chose an issue labeled “good first issue.”

Not because it looked exciting.
Not because it was high impact.

But because I wanted a safe way to enter a large and unfamiliar codebase.

That choice taught me more about real world software engineering than I expected.

---

Why I Picked It

The issue was about replacing WooCommerce’s custom accordion block with the WordPress core accordion block for WordPress 6.9 and later.

It was tagged as a good first issue.
There were no open pull requests.
No one had said they were working on it.

My goal was not to make a big impact. My goal was to understand how WooCommerce is structured and how its blocks are built.

Looking back, that was my first real engineering decision: focus on learning, not visibility.

---

Setup Problems Are Normal

I cloned the repository and followed the README to set things up locally using wp-env. It did not work right away. Docker needed changes. File sharing settings had to be adjusted.

That was my first reminder that setup problems are normal in real projects.

Once everything was running, I started exploring the block structure. Each block had:

• A PHP part for backend behavior
• A React part for the editor interface
• Separate behavior for editor and frontend rendering

Even though the issue was labeled “good first,” it touched several parts of the system.

That was my second lesson: “good first” does not mean easy. It means limited in scope.

---

My First Mistake

When I ran into problems, especially with tests, I searched online and asked AI tools how to fix them.

Some answers helped. Some did not.

What I ignored at first were the README files inside the project’s test folders. They had clear instructions written for this codebase.

I wasted time because I looked for general answers instead of reading the project documentation.

In real software projects, local context matters more than generic advice.

---

When It Finally Worked

After updating the PHP and JavaScript files, I tested the block in the browser. It did not work at first because I forgot to rebuild the project.

After rebuilding, it worked.

That moment felt small, but it mattered. It was the first time I changed something inside a large open source product and saw it working in a real interface.

But seeing it work in the browser was not enough.

---

Tests Are Part of the Work

When I opened the pull request, many GitHub Actions workflows ran automatically. Lint checks failed first because my formatter did not match WordPress coding standards.

Instead of fixing each issue by hand, I set up my auto formatter correctly. It took more time at the start, but saved time later.

Then integration tests failed.
Then end to end tests failed.

Running E2E tests locally was difficult. A welcome modal blocked execution, and I could not match the CI behavior exactly on my machine.

So I made a trade off.

Instead of perfecting my local setup, I opened a pull request on my fork and used CI results to guide my changes. Feedback was slower, but it matched the maintainers’ environment.

That helped me keep moving.

Sometimes it is better to make steady progress than to aim for a perfect setup.

---

The Bigger Lesson

If this pull request had never been made, WooCommerce would have kept its own accordion instead of using the WordPress core version for newer installs.

It was not a flashy feature. But it reduced duplicate code and kept WooCommerce closer to WordPress core.

That is something I understood only after working through the change.

Much of real world software engineering is not about building new features. It is about reducing future maintenance work and keeping systems aligned.

---

What a “Good First Issue” Really Taught Me

It taught me that engineering is not only about writing code.

It is about:

• Reading the project before changing it
• Understanding how backend, frontend, and tests connect
• Making trade offs with limited time and knowledge
• Improving your tools so future work is easier
• Accepting feedback and improving
• Thinking about maintenance, not just implementation

The label said “good first issue.”

What it gave me was my first real experience working inside a production level, community driven codebase.

Real world engineering is less about solving a problem once, and more about solving it in a way that fits the system, the team, and the future.

I was employed for the first time in my career in the second quarter of 2022. At that time, I was the only developer working in the company. The first company in one’s career is an important step, as it is where you gain a lot of experience from old developers, which is not what happened with me.

Dealing Directly with Business Owners

Being the only developer in the company means I don’t just implement tasks, I create them. There were no developers or product managers who understood business needs to divide that into smaller tasks and assign them to me. I was the one who talked with the owners to understand the goals of their business, suggested how the system can help achieve those goals, and implemented that system.

The ‘I Know How to Do It’ Trap

This environment was a perfect example of one that can produce a bad engineer who implements everything in the wrong way. Any problem I face, I have a way to solve it, but it does not take long to realize that this is the way engineers were solving it twenty years ago. I learned that I have to search and learn how those problems are solved, even if I have an idea for solving them that looks brilliant.

Nobody Understands What I Am Doing

Business owners are only interested in what the end result is. If I leave a significant issue in the code, such as a security vulnerability, there is nobody to discover it. I had to be the reviewer of my own code, and make sure that the code I deliver is the best I can do, even when the owners can’t see that. There were also situations when I face a complicated problem, but simply nobody cares. They only see that I have been late, and didn’t deliver the product in time. I learned that I have to be dedicated to what I am doing even if nobody understands it. Stopping and listening to them would just make the situation worse.

Over time, all of these experiences changed how I was approaching problems and learning as an engineer. I realized that I don’t know everything, or actually that I know very little. I have to always learn, even when I think I know the topic.
A quick search will not take much time, but may change the whole approach you take.

In other words, confidence without continuous learning is dangerous, and responsibility doesn’t disappear just because no one is watching.

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:

1. Understanding beats rushing
    Taking time to research saved weeks of wrong implementation.
2. Naming the problem is a superpower
    Once you know the name, you can find decades of prior solutions.
3. Trade-offs are the real engineering
    Sometimes good enough is more valuable than perfect.
4. 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.