Based on the amount of questions I've heard from newer devs about their GitHub profiles in the past year, it's clear they're being used to screen candidates. This is most certainly unfair, as not every good developer has the time to build a public GitHub persona. I don't personally think a GitHub profile is necessary for new devs — though I do think that there is value in having one, as a means to distinguish themselves from the other many candidates.
Assuming you've got the time to build up a public profile on GitHub...what kinds of projects should you put on it? I've heard this question from several newer developers in the past few months, and I think it's fair but slightly misguided.
I actually don't think it matters much what you decide to build — because I think there are better ways to highlight your skills from your GitHub profile.
Share PRs, not projects
PRs are much more digestible than a project. If I sent a link to my training journal project to a job lead....where would they start? The README.md isn't helpful, I hope they don't start there. There is most certainly garbage code in the project. The artifacts of late nights when I wrote code I wasn't proud of just to ship something. That might be the first thing they look at! I don't want that. There's entirely too much surface area in any entire codebase to accurately describe your work.
So...I've been taking a cue from my friend Jon and creating PRs for even my personal projects. Here's a recent example: a PR where I introduced a new feature to an app I'm using to plan and track my workouts. No one's going to review this PR! I easily could have committed these changes directly to main and moved on.
If someone asked to see some of my work, I wouldn't share that project — I'd share that PR. It more accurately captures how I work, how I think, how I solve problems, and what it'd be like to work with me.
There's more value I'll get out of creating a PR like this:
- I can link to it if I decide to write an article about how I implemented it
- I can share it if someone is interested in knowing what it looks like to work with RedwoodJS
- If I need to do similar work in the future, I have an isolated example to look at
- It enforces good commit hygiene, which is really easy to let slide on a personal project
It's a little bit of extra work to create the PR, but that's a lot of good reasons to do it.
PRs are a nice little snapshot of a cohesive set of work. They're great for more than just code review. You should use them for your personal projects.
And if you're not sure what the PR should look like, I've got some suggestions.