Repositories and recruitment

Signpost pointing to Gift shop, cemetery and gallery

Recently a hiring manager during a call asked me to provide a link to my Github if I have one. They didn’t look it up on their own. So it might be time to talk about writing public code.

Disclaimer: I am a developer with a day job as a developer and I do not work on open source projects as a part of that job. Coding publicly on Github is done during my free time.

Github as it is stands in a weird place with three main purposes, personal portfolios, side project cemetery and place from where we get dependencies for our production code. That’s a lot for a single site.

Personal portfolios

With Github pages it’s easy to have a personal website because people don’t have to deal with hosting and updating it is very easy. So after stitching couple of projects together one can create their portfolio relatively quickly. It may impress recruiters and get you a job.

Unfortunately unless one is a student (university, bootcamp, etc.) or a recent graduate it’s hard to find time to create high quality projects that will show one’s processes which brings us to the next point.

Side project cemetery

Github is a place where projects go to die. We all love side projects. They are awesome for learning and for just having fun. I have often times learned more on side projects than on “real” commercial projects because I didn’t have constraints of certain tech stack, coding standards, etc. and could’ve experimented as much as I liked.

This comes with a price, that price is called imperfection. At my day job I try my best to make things as maintainable as possible, I write tests and when appropriate documentation. On my side projects, not so much.

So, please, recruiters and anyone looking at Github of employed developer, don’t look for perfection at side project cemetery, you won’t find any. You’ll find mixture of decay, innovation and lessons learned.

Source of dependencies

This point is the one that is troubling me the most at the moment. Because of npm/yarn/tink package managers and their ease of use we’ve became a bit careless about the code that runs along ours. In the past when we had “smaller” libraries like jQuery, it’s grown bigger over the years, it was humanly feasible to study libraries that we included into our projects. That’s no longer true.

What is worse, the way we use Github for development is not really sustainable in the long-term unless those who are hiring developers realize that they need to give back. There are number of ways how to give back and some of them will lead to better recruitment.

With regards to recruitment, company that supports open source is sending several messages. My favorite message is that you are actively forcing your people not to remain in your company’s bubble. It takes courage because you will have somewhat independent feedback from outside for free. Personal note: I’ve spent couple of months in an echo chamber and left a company very early after starting a project because it made doubt my skills.

Second message which employees contributing to open source on company’s time send is literally putting money where your mouth is. With this kind of company it’s understandable that they want to see your projects on Github because it’s their core value. And I’d be more than happy to talk to them about my projects on Github.

Third message that you are sending is that your developer’s have higher familiarity with the underlying tech stack, not just how to make it work but also how it works internally. This will make you less susceptible to using packages that could be harmful. It happened to British Airways, so it can happen to you too.

Anyway we need to consider more carefully how we treat repositories like Github because expecting perfect code on side project cemetery will cost you an awesome developer.