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.
Leave a Reply