Why GitHub is not your CV

[1337]

Two days ago, Ashe Dryden published an article I’ve been desperately wishing someone would write for months: The Ethics of Unpaid Labor and the OSS Community. It’s a detailed, well-researched take-down of the seemingly quite popular myth that open-source contributions are a useful way to screen candidates for software jobs. She covers the reasons why using OSS as a hiring filter biases your selection process toward white men, and the excuses we use to tell ourselves everything is A-OK. This should be required reading for anyone involved in hiring programmers. If you’re after a tl;dr for this article, here it is: go read Ashe Dryden.

I’m not going to retread the material in that article but I would like to cover the debate I’ve been having with people over the last day or so. This is more about principles and practicalities, and if you want evidence and stats I refer you to Ashe’s article.

So, I’ve been saying for months that using open-source software contributions in general, and GitHub profiles in particular, as a hiring filter is bad for our industry. This has been in response to the seemingly increasingly popular notion that GitHub is your resume now. I increasingly see companies’ job ads asking for GitHub profiles, and have recruiters ask me for mine, or tell me they are contacting me having already seen it. The logic goes that interviewing software engineers is really hard, and anything to make it easier must be great, and looky here there’s this one giant website full of code we can read to figure out if people are any good or not. There’s even entire new recruitment companies springing up to take advantage of this assumption. Our job of finding new people to join our companies just got a whole lot easier!

It’s a beguiling story to tell ourselves, after all, hiring is hard, trust me, I’ve been there, and what could be a more objective way to screen candidates than to just look at their code? And software is meritocratic, right? It must be, we got it printed on the carpets.

Well, ignoring for one minute the fact that the term ‘meritocracy’ comes from a political satire, open source is anything but. As Ashe has documented at length, the demographic make-up of open source contributors is even more skewed toward white men than the software industry is, which is saying something. But if a bunch of research on demographics and discrimination won’t sway you, let’s try something more utilitarian:

GitHub profiles simply don’t tell you what you think they tell you.

There is really astonishingly little value in looking at someone’s GitHub projects out of context. For a start, GitHub has no way of customising your profile page, and what is shown by default is the projects with the most stars, and the projects you’ve recently pushed to. That is, GitHub picks your most popular repos and puts those at the top. You have no say about what you consider important, or worthwhile, or interesting, or well-engineered, or valuable. You just get what other people think is useful. Aside from which, GitHub displays a lot of useless stats about how many followers you have, and some completely psychologically manipulative stats about how often you commit and how many days it is since you had a day off.

So really, your GitHub profile displays two things: how ‘influential’ you are, and how easily you can be coerced into constantly working. It’s honestly about as relevant to a decent hiring decision as your Klout score.

Second, even if GitHub allowed you to control its presentation of your work, it still wouldn’t be a good signal. Various people have made the case that it’s your portfolio, in the sense that artists and designers use the term, that you should have a body of work to show off to employers (people like to make empty and easily falsifiable analogies between software engineering and other disciplines, mostly, as far as I can tell, to make themselves feel all warm and tingly). Here’s the thing: it’s not. A portfolio is an edited collection of professional and personal work that someone working in the visual arts uses to present their best face to possible clients. It’s a visual CV, and just like a CV its editing is tailored depending on who you’re trying to impress. GitHub is not this at all. GitHub is all the public work you’ve ever done, unordered, unfiltered and unexplained. It tells no story and provides no context.

And context is incredibly important. The reasons people put things on GitHub are many and varied: they just want a backup (git is literally the only software that has yet to lose my data), they want to collaborate, they like the issue tracker and pull requests, they want a hosted page for their project’s docs, it is their employer’s policy that all code is public. Personally, I use GitHub as a place to host serious long-term projects, as a sketch pad for experiments, as a backup system, and as a place for people to file bugs. Some of my projects are ‘normal’ practically useful software, some are build tools that support said projects, some are experiments that went nowhere, some are experiments I’m still working on, some are study projects, some are flights of intellectual curiosity, some are demos, some are instructive projects, some are jokes, and some are not even software. Some of my most-forked software took a week to write, and I’ve spent literally years on projects almost no-one cares about.

If you don’t know me and my work, I think you would have a hard time telling which is which. As an extreme example, people occasionally ask for the ‘real’ source code to Berliner, assuming the aforelinked file is not what I actually sat down and typed out. The most widely adopted project of mine isn’t even under my username any more.

The nature and quality of the stuff in my profile varies immensely, and you can’t tell where and why. I can’t tell you that the Canopy metagrammar is the most interesting program I think I’ve written. You might decide that this method in jstest is terrifically ugly, not knowing how much work it took to build a run-anywhere JavaScript test framework with optional async interfaces that deals with async errors that can’t be conventionally caught and that caters specially for Node error conventions.

Those are two extremes: elegant, mind-bending, truly self-documenting code in a project I rarely use and did half for fun, versus extremely ugly code in a codebase I use every single day to build open-source libraries that are deployed on dozens of companies’ web apps. You can’t see how any of this stuff interacts, it’s just text on a page, all looking the same, with no story of why it looks the way it does. Most times that I’ve found myself thinking a bit of code looks really weird, on talking to its author I’ve found out there was some engineering constraint, be it the target platform, the problem domain or the project deadline that explains why it is the way it is.

And that’s just it: you can’t judge code without talking to its author. You can’t judge it without knowing the constraints it was written under, knowing whether it even solves the intended problem, how expensive it was to create, what knock-on effects it had on systems that depend on it. Without context, it’s not a program, it’s just text, and at best you can say whether it agrees with your pet style guide.

And no, checking it out and running the tests does not tell you if it solves the problem. Most non-trivial software is also non-trivial to build right, and a failing test suite doesn’t tell you anything beyond the fact that the project has tests. It could be work in progress. It could be an experiment or no-longer useful project that doesn’t build against new versions of its dependencies.

If you want to find out whether someone’s worth hiring as a software engineer, their code is of very limited value compared to talking to them, discussing design and architecture, previous engineering constraints they’ve faced, and what they’re like at solving problems and anticipating new ones. Reading their code in a vacuum does not tell you much if anything about those things.

Programmers love talking about separation of concerns, right? Well when you use GitHub for hiring you’re taking a tool that people use as a collaboration space and backup service, and using it for an unintended purpose: judging whether people are any good or not. Knowing that that’s what it’s used for now can be significant factor in people not using it at all, even people with no intention of using it to advance their career. You want to to judge me by perusing my backups? How about I just give you my Dropbox password while we’re at it.

So, on a practical level, you’re doing yourself a disservice by using it to filter people. There is no evidence to suggest there is any correlation between programming ability and open source contributions, unless you count ‘willing and able to work for free’ as ability. Several people have told me they only use it as a ‘positive’ filter, a final bit of cake-icing to tip the balance between candidates. Well guess what? You still used someone’s OSS work to decide not to hire someone else. The only way something is ‘not a filter’ is if you literally don’t consider it at all when making decisions. If a filter wasn’t somehow involved, it wasn’t really a decision.

But in the bigger picture, you’re doing our industry and our society a disservice. Our political leaders love to talk about social mobility and aspiration, but are not doing anything about the fact that entire industries are completely inaccessible to anyone but the wealthy due to the expectation of unpaid work in the career ladder. Whether that’s unpaid internships (which really ought to be illegal), or the expectation that people will have done the job on their own time, expecting people to work for free before getting a ‘real’ job means that only people that can afford to work for free will end up in those jobs. Thankfully, programming is still a way off where some professions are on this front, but the GitHub-as-CV meme is pushing us in that direction. Technology is constantly being billed as the job of the future, to the point where we’re finally putting computer science on school curricula, but we’re creating a filter that means only people with copious leisure time and no other hobbies or commitments will end up in these jobs.

Which brings us to our next sticking point: passion. Employers love to talk about passion. You must be passionate about problem-solving, or testing, or agile methodologies, or whatever this week’s 9-factor NoData cargo cult is. We don’t want to work with anyone who’s not passionate.

Now, I don’t actually know what people mean exactly by ‘passion’, so I asked around, and the gist seems to be that it means you have an enthusiasm for your work that extends beyond your working hours. That you don’t switch off. That you can’t stop thinking about work because you’re just so gosh-darned pumped about it. In other words, that you will put in unpaid overtime on demand and without question, because your job is your primary source of emotional fulfilment. (Or, you’ve been emotionally blackmailed into this frame of mind by abusive and over-expectant bosses.)

(By the way, you ever notice how the web industry is crammed full of 20- and 30-somethings? Guess who’s got copious free time to spend on hobby projects and is inexperienced enough to fall for your pay-to-play hiring policies? Bingo!)

If you think I’m being paranoid about employers expecting free work both before you arrive and after you join, you could do worse than check out what Microsoft is peddling right now. “Office workers want technology to help them get things done anywhere, sunrise to sunset,” it boldly proclaims before detailing how many people have spent time working on the toilet, on their commute, on holiday, at their children’s sports games, on dates, at home and in bed. (The graphic for that last one is particularly sadistic.) It’s even called ‘Office 365?. But it’s fine, because it’s what employees want, it’s all about personal empowerment. This is marketing material.

I’ve watched too many friends get burned out and exhibit serious mental health problems due to this working culture, in tech and in other fields. It’s true that for creative people, work can happen anywhere. You never know when you’ll get your next bright idea, or the insight to solve that tricky problem. But keeping people on call 24/7, their brains constantly chained to their job, stops them having those ideas, and stops them being able to focus on their life, their families, their other responsibilities and resting their minds. We are particularly bad at taking holidays, doubling our workload before and after a week off under the pretence (due to insufficient staffing or outright lying) that we are ‘indispensable’.

I’ve also been fortunate to work at two companies that actually had healthy attitudes to work/life balance, but even they couldn’t stop people feeling guilty about taking holiday. This obligation to work is so ingrained in our culture that people feel bad about taking a break, even when explicitly encouraged to do so. When you ask for free work you are playing on those expectations. When you tell people your company is “not a 9 to 5, people love it so much they don’t want to leave,” you are playing Microsoft’s game. I know you think you’re having fun, and I get that people doing hiring tend to be senior enough to be emotionally invested in the company, but when you push that expectation onto employees you create a recipe for burn-out.

The assumption that start-ups are all 80-hour work weeks is so widespread I’m genuinely worried I’ll accidentally walk into such a job now that I’m going the contractor route. And it’s not a myth: I was given a heads-up by a friend that one company I’d been talking to had core hours of 8am to 7pm, and was almost certainly overshooting those due to being in pre-launch mode. I have no idea how companies can expect people to work so much they only just have time to eat, sleep, and come back the next day. And if you think I’m being spoiled, here’s what happens when I don’t get enough sleep: I have panic attacks, and end up in A+E. Enough days over-working and I’m spending four hours in some hospital in the middle of the night with no idea where I am and no sleep to see me through the next day of crunch mode.

Our society is stacked in favour of this behaviour: the Prime Minister wants more emphasis on capitalism in schools, but no mention of the labour union movements that brought us such luxuries as the weekend, sick pay, and many other employment rights. One of those rights, known as the Working Time Directive, says people must not be made to work more than 48 hours a week. Employment contracts regularly ask employees to waive this right, since they want you to be on call for as long as possible, and then it’s your fault for signing your rights away.

And if you’re not careful reading your contract, you know all that open source work the company wanted to see before hiring you? Well now it’s theirs, and so are all the ideas you have and build while employed there. (If a company tries to make you sign something like this, it may be a genuine mistake caused by using a stock programmer employment contract. I have asked to have such clauses removed in the past and been successful.)

Still not convinced that ‘passion’ as supposedly demonstrated by open source is a way for companies to squeeze more value out of you? The very genesis of the term ‘open source’ was about ultra-libertarians getting corporate interests to adopt free software, and part of how it has done this is through the Open Source Initiative approving licenses that let businesses off those nasty copyleft obligations in the GPL. Oh and by the way, the guys who started open source even went about calling it ‘peer reviewed’ software, trying to imbue it with an objective, meritocratic glow under the guise of it being somehow scientific. And to top it all off we have our racecar-driving leaders telling us that trying to get your hobby projects funded is not omakase.

Now, yes, I realize this doesn’t apply to everyone. If your company cares about the software ecosystem enough to give its employees time to do open source, to give something back for building its business on it, then great. But you are a vanishing minority, and among your number are companies that still use open sourcing their work as a way to get free bug fixes. Remember that the opportunity you’re affording people is a very rare commodity, and most people aren’t going to be able to show you code they wrote at another company. Don’t punish job candidates for their employers’ policies, and don’t assume that a lack of public code demonstrates a lack of interest, or care, or competence. People have plenty of valid reasons not to spend their spare time on their job, and certainly most of the great programmers I’ve worked with aren’t big-time GitHubbers.

Programming is one of a small number of jobs that people can practise outside the framework of an industrialised workplace. Yes, I’m sure you can quote me many other examples, on the basis that there simply thousands of kinds of jobs out there. But programming is almost unique in two ways: first, you can do professionally-scoped work that isn’t feasible in other hobbyist situations. I’ve written code on my sofa, while enjoying a glass of wine or two, that is now deployed on dozens of web apps with international user bases. Second, you are able to put the work itself – not a picture, or a description, or a review, but the literal work itself – online for anyone to see. Companies want to see your GitHub because they think it indicates skill and passion, but really, they simply want to see it because they can. You don’t see sysadmins or QA people or project managers being asked for the literal output of their past endeavours, because it simply isn’t transferable in the same way code is.

But James, I hear you cry, you do loads of open source stuff! Why are you complaining?

I’ve got it easy. I’ve led a very privileged life, never had to really worry about money, was given a good education, and have generous parents who made sure I didn’t need a job while at university, so I could spend the resulting leisure time teaching myself to program. I also have the advantages of being white and male on my side, so I don’t have to put up with receiving death and rape threats when I put my code online or say things like this. (Yes, this happens.)

I’m also kind of obsessive, which helps with churning out code but can have bad side effects on your social life, relationships and mental health. I never realized there were barriers to open source until I asked a few people who don’t participate. Plus, you want to know why I started, and why this blog exists? When I got my first job, I didn’t know any other programmers, and all I could see of my industry was the hero worship of famous JavaScript and Ruby people and I assumed that to get anywhere, I had to be like them. That’s the message our trade media sends out. Fortunately, turns out I enjoy writing code and blogging and it’s worked out rather well for me, I’ve just learned not to judge other people for not being as obsessive as I am.

Fine, but how are we supposed to hire people?

The hard way. Sorry everyone, but it’s the best we’ve got. People’s problem-solving ability and reasoning can’t be surmised from reading the end result of those processes, you have to talk to them. You’d get a much better idea of my ability from reading my article about Vault’s design process than from reading its source code. I know it’s hard, I’ve interviewed people, and it’s one of the hardest things about building a company. But hiring decisions are also some of the most important ones you’ll make, and using shoddy evidence to make those decisions doesn’t help anyone, least of all you.

If you want to choose wisely, and fairly, stop demanding free work from people.

Sursa: https://blog.jcoglan.com/2013/11/15/why-github-is-not-your-cv/

Mi s-a parut interesant articolul, astept pareri.