15 Bugs That Said Everything Was Fine

A database told me it had saved my data.

It had not. The write was rolled back. No error. No warning. No exception. Just the word "success" and an empty table.

That bug is now fixed, in Microsoft's Entity Framework Core, because a student in Lahore reported it and wrote the patch.

I have had 15 contributions merged into open-source projects: Google, Microsoft, Apache, the OpenJS Foundation, Red Hat. Together those repositories have more than 890,000 GitHub stars. Twenty-one more of my fixes are waiting upstream right now.

I have never met any of those maintainers. None of them know what I look like. They read the code and merged it.

Here is what I have learned, and how you can start.

THE PATTERN: THE WORST BUGS SAY NOTHING IS WRONG

When you start looking for bugs, you look for crashes. Crashes are easy. Something breaks, a red message appears, everyone can see it.

The dangerous bugs do the opposite. They fail, and then they tell you everything is fine.

Look at the ones I found:

A database said "saved" when nothing was saved.

In EF Core's SQLite provider, two common commands reported success even when a later statement had failed. A busy commit was retried in a way that answered "OK" after the first attempt had already reported the problem. Result: your write is gone and your program is happy. That fix went into release 12.0-preview1.

A build said BUILD SUCCESS when nothing was built.

Apache Maven's concurrent builder was catching one kind of failure but not another. A step could throw, the build could produce nothing, and the screen printed the green success message. A reviewer reproduced it and found a second path to the same problem.

Fields vanished from saved data.

In Google Gson, a list declared with a wildcard type was written out using the declared type, not the real one. Subclass fields disappeared. A list of strings came out as [{},{}] — empty objects where your text used to be. No error. Just quietly less data than you put in. It was merged after passing Google's internal test suite.

A crash that had been waiting since 2022.

Also in EF Core: reading a stream from a certain kind of column passed three nulls into a native SQLite call, which answers "you are using this wrong," so the read threw as soon as another computed column shared the query. That issue sat open for over four years.

A program could die while cleaning up.

Pruning an idle pooled SQLite connection could take down the whole process, because a cleanup hook was cleared through a handle that was already closing.

There is a lesson in that list.

Anywhere a system reports success, ask who checks that the success is true.

That question, asked patiently, has found me more real bugs than any clever technique.

THE OTHERS

Not everything is dramatic. Good contributions come in all sizes:

Jest (45.5k stars): an import path starting with # was being read as a web address fragment, so a whole category of package imports broke. Shipped in v30.5.1.

Microsoft GitHub spec-kit (138k): a command name containing a hyphen could not be reached at all. Three people submitted fixes; mine was chosen as the canonical one. A second fix made a missing file fail early with a clear message instead of late with a confusing one.

Playwright (96.5k): a filter control was a plain div, so keyboard users could not reach or open it. An accessibility fix, and one I care about personally.

Quarkus (15.9k, Red Hat): request filters were reordered so their priorities ran backwards.

BenchmarkDotNet (11.5k): you could not pin a benchmark to any CPU above the 32nd, and one case crashed with a raw overflow error instead of a normal message.

LangChain (146.8k): a documentation block that contradicted itself.

That last one is a documentation fix, and I list it on purpose. It counts. Every big project has wrong docs, and fixing them is the easiest honest way to get your first merge.

WHY THIS MATTERS MORE THAN A CERTIFICATE

I could not get an internship at Google. I do not have a degree from a famous university. I studied at the University of Central Punjab in Lahore.

But my code is in Gson, which Google maintains. My fix shipped in Jest. My name is in the EF Core release history. Anyone can check.

Here is the quiet truth about open source: nobody asks where you are from.

There is no CV screen. There is no interview. There is a patch, and a test, and a maintainer who decides whether your reasoning is right.

For people who get filtered out early by everything else, that is the fairest door in this industry.

HOW TO GET YOUR FIRST MERGE

This is the part I wish someone had written for me.

1. Do not start by looking for a project. Start by using one.

Use a library, hit something strange, and follow it. Every fix I have listed started as "wait, that is weird."

1. Read the issue tracker, sorted by oldest.

Old open issues are gold. They are real, reproduced, still broken, and everyone else got bored. My EF Core stream fix had been sitting since April 2022.

1. Reproduce it in the smallest possible program.

Before you write a single line of the fix, write the twenty lines that prove the bug exists. Maintainers live by reproductions. A good one makes them want to help you.

1. Find the real cause, not the place it hurts.

The error appears in one place. The mistake usually lives somewhere else. Read the code path backwards until you can explain why, in one sentence, out loud.

1. Make the smallest change that fixes it, and add a test.

Your patch is competing with the maintainer's time. Big patches look expensive. A tiny patch with a test that fails before and passes after is easy to say yes to.

1. Write the pull request like a short story.

What happens now. What should happen. Why. What you changed. How you tested. No drama, no essay.

1. Expect silence, and do not take it personally.

Some of mine were merged in days. Some sat for months. One was superseded by someone else's patch, and the fix shipped with my name as co-author. Twenty-one are still open right now. That is normal. It is not rejection.

1. Be polite when a maintainer corrects you.

They know the codebase. You do not. On one of my Maven fixes, a reviewer found a second failure path I had missed, and the final fix was better than my original. That is the system working.

START THIS WEEK

You do not need permission and you do not need to be an expert.

Pick one library you actually use. Open its issues. Sort by oldest. Find one you can reproduce. Write the twenty lines that prove it. Then read the code until you understand why.

That is the whole method. I have used it fifteen times.

The first merge is the hardest one. After that you will never again wonder whether you are a real programmer, because the answer is sitting in someone else's release notes.

Huzaifa Iftikhar is a software engineer in Lahore, Pakistan, and a 2026 Computer Science graduate. His merged contributions are at github.com/HuzaifaChaudary.