From Bootcamp to First Pull Request: A 30-Day Plan

Most bootcamp grads finish able to build a todo app from a blank file, then freeze the first time they clone a repo with 40,000 lines they didn’t write. The gap isn’t syntax. It’s the work of finding one tractable change inside a system you don’t understand and shipping it without breaking anything else. This is a 30-day plan that ends with a merged pull request to a real project. It’s split into four weeks, and each week ends with a checkpoint you can verify yourself — no mentor required to tell you whether you passed.

Week 1: Pick a project and read it before you write anything

The instinct after a bootcamp is to start coding immediately. Resist it for seven days. Your only job in week one is to choose a project and understand how it runs.

Pick something you already use and that accepts contributions. A CLI tool, a documentation site, a small library in a language you know. Avoid the giant frameworks — React and Kubernetes get hundreds of PRs a week and your first patch will sit in a queue for a month. Look for a repo with 200 to 2,000 stars, commits in the last 30 days, and an open issues list that isn’t a graveyard.

Once you’ve cloned it, the test for week one is mechanical: can you get the project running locally and can you run its test suite? That’s it. If the README’s setup steps fail — and they often do — fixing those steps is itself a legitimate first contribution. Keep a running note of every command that didn’t work and what you did instead.

By day seven you should be able to answer three questions: How do I run it? How do I run the tests? Where does the code that does the main thing actually live? If you can’t, you picked too large a project. Swap it now, while swapping is cheap.

Week 2: Find the smallest real change you can make

Week two is a scavenger hunt, not a coding sprint. You’re looking for a change small enough that you can be confident it’s correct, but real enough that someone wants it merged.

Start with labels. Most active repos tag issues with good first issue, help wanted, or documentation. Filter for those, then ignore anything that’s been open for more than a few months with discussion — those are usually harder than the label suggests, which is why they’re still open. You want a fresh issue, or one nobody has claimed.

If the labelled issues don’t fit, generate your own. A typo in the docs. An error message that doesn’t say what actually went wrong. A function with no test for an obvious edge case. A broken link in the README. These feel too trivial to matter, but a maintainer would rather merge a clean one-line fix than triage a sprawling refactor from someone they’ve never seen before. Your first PR is as much about establishing that you write small, correct, reviewable changes as it is about the change itself.

The checkpoint for week two: you can describe your intended change in one sentence, and that sentence touches fewer than 20 lines. “Add a test for the empty-input case in parseConfig.” “Fix the install command in the README that points at the old package name.” If your sentence has an “and” in it, split it into two PRs and ship the smaller one first.

Week 3: Make the change on a branch and prove it works

Now you write code. Create a branch named for the change (fix/readme-install-command, not patch-1). Make the edit. Then do the part that separates a contribution from a guess: prove it works.

For a code change, that means a test. If the project has a test suite, add or modify a test that fails before your change and passes after it. Run the full suite, not just your new test — your job is to show you didn’t break the other 300 tests while fixing one thing. For a docs change, “proving it works” means following your own instructions on a clean checkout and confirming they actually run.

Write the commit message in the project’s style. If their history is fix: correct install command, match it. Small signals like this tell a maintainer you read the contributing guide, and they make the difference between a review that takes two minutes and one that gets ignored.

Week three’s checkpoint: git diff main shows only the lines your one-sentence description promised, and the test suite passes locally on your branch.

Week 4: Open the PR and respond like a professional

Push your branch, open the pull request, and fill out the template. Most projects have one — it asks what the change does and how you tested it. Answer both. Link the issue you’re closing. Keep the description to a few sentences: what was wrong, what you changed, how you verified it.

Then wait, and watch how you behave during the wait. Maintainers are volunteers; a response can take a day or three weeks. Do not bump the thread after 24 hours. When review comments arrive, treat every one as a request, not an attack — even the blunt ones. If you disagree with a suggestion, say so once, with a reason, and defer to the maintainer if they hold the line. It’s their project.

If the PR gets merged, you’re done — that’s the whole goal, and you now have a public, verifiable contribution with your name on it. If it gets closed without merging, that’s also a result: ask politely what would have made it mergeable, and apply the answer to your next attempt. Either way, repeat the cycle. The second PR takes a third of the time, because you’ve already paid the one-time cost of learning how one project works.

The plan works because it inverts the bootcamp habit of building from scratch. Reading before writing, shipping the smallest correct change, and proving it works are the actual day-one skills of a working developer. The merged PR is the receipt.