GitHub Is Your Resume Now

With the advent of GitHub and the ability to more easily show your work, I think the need to maintain a resume is slowly dwindling.

Personally, I will not miss the poorly formatted, badly designed Word templates filled with mostly irrelevant information, all carefully massaged to inflate skills and accomplishments. What someone has built and how they built it seems like far more useful information.

Even if you don’t think the resume is going anywhere, I think we can probably agree that appearances and first impressions do matter, and most programmers don’t seem to have really considered what their GitHub account looks like to someone interested in working with them. Your GitHub account is public and people are looking at it whether you’re showing it to them or not, so it’s worth spending some time to make it better.

Here are some common problems I often see that if fixed would go a long way to improving a first look.

Too many forked repositories

A fork sends a signal that you are actively contributing to a project, regularly contribute to a project, and/or need to maintain a fork of the project for some reason.

Having a lot of forks that are years out-of-date is like leaving laundry on your floor or keeping expired food in your fridge. Clean up after yourself and get rid of any forks you’re not actively using.

Yes, I know you can filter out forks by selecting “sources” from the dropdown. It still doesn’t look great to keep forks around unnecessarily.

Sharing anything and everything

I notice some people have a tendency to try and fill out a GitHub account by adding lots of repositories, as if having only a few repositories is a bad thing. Endless toy apps you made in school and the koans you did to learn a new language are not particularly useful.

If your GitHub account actually had something interesting in it, someone might be unable to find it in all the noise. Be judicious about what you add and use it show off your best work. Aim for quality over quantity.

Dead projects

Most projects will eventually be abandoned and die. Very few projects will live for multiple years. When the project is no longer a representative of your current skill, remove it or make it private. If it’s dead but still represents you well, then archive it.

Missing or poor descriptions and READMEs

Every project should have a clear, concise description, and ideally a well-written README. No one wants to go spelunking in your code to figure out what your project does, why it exists, and how it works.

I think a well-written README is arguably even more important than the quality of your code. Good code can be highly-subjective, but good writing is far less so. Show off your communication skills and write something great.