You learned to program without a degree to wave and without a bootcamp logo on the LinkedIn headline. This page is the first specified merge as proof of work: a public review thread that is not a tutorial you followed alone.
It is not the career-switcher article. That URL assumes a course or bootcamp you just finished and uses that stack as the default. See career switcher: your first open source PR if that is you. It is not a student semester plan. That is open source contributions for students. It is not how to format the PDF or pin repos.
Self-taught here means: no institutional brand doing the introducing. The merge has to introduce the work.
Proof of work is a merge, not a curriculum
A folder of completed courses is private practice. A personal clone of a tutorial is still you assigning yourself the spec. Employers who care cannot tell whether you fought a real constraint or paused the video.
A merged pull request on someone else’s repository is different:
- They wrote the issue (the spec is not yours)
- Someone else reviewed the diff
- The change is still in the default branch
That is the artifact. One is enough to start. It will not get you hired by itself. It is the first public loop you can walk through without saying “I finished a Udemy section.”
Do not wait for a certificate that “unlocks” GitHub. If you can install the project and change a file the issue names, you can try. If you cannot install it, pick a smaller project in the language you already write.
You do not owe anyone an origin story
Skip the essay about how you started. In the PR, write the issue, the change, how you tested. In an interview, same. “I’m self-taught” is context, not a pitch. The thread is the pitch.
Do not:
- Apologize in the PR body for not having a CS degree
- Ask maintainers to be extra patient because you are self-taught
- Submit a PR that is your learning journal
Do:
- Follow CONTRIBUTING
- Keep the diff on the ticket
- Answer review like any other contributor
Maintainers are not a replacement university. They will not design a syllabus for you. They will merge a small, asked-for change.
Pick the language you already write, not a prestige stack
Self-taught paths are messy: a bit of HTML, a Python script, some JavaScript. Use the one you can run and edit without a new course.
If that is HTML and CSS, stay there. Docs and UI nits on a real issue still go through review. HTML and CSS issues exist for a reason.
Do not pick a language because job posts list it and you have not written it yet. The first merge is proof you can finish a loop, not proof you sampled a trendy runtime.
Avoid “I’ll contribute to the Linux kernel to show I’m serious.” Setup will eat the month. Pick a repo whose README you can follow in an evening. Best projects for beginners is a hub, not a logo wall.
First issue: specified, small, still wanted
You need:
- A written issue (label helps, spec matters more)
- Recent maintainer replies or merges
- A change you can see without understanding the whole architecture
You do not need:
- A famous name
- A paid mentor to “introduce” you to a repo
- A perfect local setup identical to a company’s
Read how to find good first issues and how to pick an issue that will get merged. Claim cleanly: how to claim a GitHub issue.
If code in a foreign repo still freezes you, take a named documentation or test gap they already filed. Documentation-first contribution. That is still proof of the workflow: clone, branch, review. It is not a substitute forever, but it is a real first merge. Random typo farming is not; it teaches the buttons and nothing about their problem.
What this is not
Not a bootcamp capstone replacement. There is no cohort deadline. You set the finish line: merged or you close and pick another issue. When your PR is ignored.
Not a degree-shaped portfolio. You do not need twelve labs. You need a thread you can open. After merge, you may add a Projects line. That is open source on your resume — later, not this page.
Not “build in public” as a substitute. Streaming your tutorial does not create a reviewer. The reviewer is on their repo.
Not a career-switcher week-one plan. Switcher copy assumes you just left another industry with a course still warm. You might have been writing scripts for years with no title. Start from the language you actually use, not from “the stack the program taught.”
After the first merge
Stay on the same project for issue two if the repo is alive. After your first open source contribution. Two reviews with the same maintainers beat a new identity on a new org.
If you are job-hunting with no degree, do not stop at one forever — but do not spray either. A small set you can narrate is the whole game. Five merged PRs if you want a hiring-shaped target. How hiring managers read GitHub for what they click.
You still have to apply. A merge is not a backdoor into every company that listed “CS degree or equivalent.” It is the equivalent you can actually show.
FAQ
I only have tutorial repos. Leave them. Fork a project that has issues. Your tutorial folder is practice. It is not the first contribution.
Do I need a personal brand or blog first? No. You need a PR.
What if I get a harsh review? Answer the comments or close with a note. How to respond to code review. Harsh and specific is usable. Silence is worse.
Should I mention I am self-taught in the issue? No. Mention the repro, the patch, the test.
I have no job and no school calendar. Then you have more hours, not a different kind of PR. Still one issue, still their spec. Do not fill the hours with empty commits.
The job of this page: one specified merge on a repo you did not invent, in the language you already write, with no degree or bootcamp doing the introducing.