The problem with this is that it doesn't let my personal projects be Play. If I'm writing something for myself, it's not going to be as clean and documented to the level it would be in the workplace. And why should it? It's supposed to be for me.
And if I'm learning a new technology, I'm going to be sloppy. I'm going to make mistakes. That's the very nature of learning-by-doing.
But in the real world of managers and companies looking for reasons to say "no hire", I have to assume that every public checkin I do is another potential "no hire" justification. Which means if make all my checkins public, I have to treat my personal projects as Work, not as play. Which is an excellent way to burn out.
Or I just give you a curated look at the final product. Which ought to be enough.
Actually I hold myself to a higher standard when writing open source - A) because I know everything is open to the world, and B) because I'm not under tight time constraints.
Nonetheless, there's no perfect project, and any employer that looked at a github project and was needlessly, ridiculously picky or made a presumption that there shouldn't ever be mistakes would end up just not hiring anybody at all.
>And if I'm learning a new technology, I'm going to be sloppy. I'm going to make mistakes. That's the very nature of learning-by-doing.
Only idiots expect a perfectionist. Thus if you try to make every commit an exercise in perfection you're only selecting out the idiots.
I'd actually far rather see incremental improvement (in code quality, documentation clarity & commit messages) than sheer perfectionism.
Also bear in mind that no matter how interested the employer is in you, the chances of them taking anything but the most cursory glance at anything beyond HEAD is very small.
But still, there must be one project that the candidate considers his best work, one he/she is proud of, one where he/she has motivation to do best. If the employer can just ask the candidate for that project, and the candidate can show that project in a public or private repository, this would give really important insights to the employer about the candidate which would be beneficial for that both.
Also, this doesn't mean that the candidates who doesn't have public repository to show have any disadvantage, they are at the same point. Its just that the candidate who is able to provide a project of his choice through public repository would be a few points ahead other candidates.
For an experienced developer, that would be a workplace project, which you probably could not see. Indeed, it _should_ be a workplace project; would you hire a professional developer whose best work is their personal project?
But if what you're saying is that the mark of an ideal developer is one who has produced a personal-time product of professional quality, where every checkin is to workplace standards, and has developed the project from conception all the way to release, again all on personal time, then what you're asking for is not a developer who also codes as a hobby, but a developer who (at least part of the time) works two actual jobs. One of which they do for free for portfolio development. I don't find that to be a reasonable expectation, even if it would give employers "important insights".
Were I to have such a project that I could show to people, it would be for a company that I had founded and as such despite my having the ability to show it, I would have absolutely no incentive to do so.
Basically if I had EXACTLY everything you purport to want in an employee I would be entirely unmanageable. Someone who has not only the skill and ability to turn out such a project but the motivation to do so on their own time is probably the definition of a founder. And founders are often terrible employees.
So while you're right that it would theoretically be better for candidates to share their codebases with potential employers, in practice I suspect that it rarely happens.
Then either start one or resign yourself to not getting the best possible tech jobs out there?
As a discriminatory practice it's probably one of the most benign. There's a low bar to putting open source code out there. You can write a simple project and put it out there in a couple of weekends. That alone puts you ahead of about 80% of candidates.
It's a way better discriminatory practice than the current default assumption that the best developers out there are white, male twenty-somethings.
don't you think that there's a higher proportion of white, twenty-something people who would have public projects (because they tend to have the most spare time)?
Don't you think that the over-worked CRUD programmer at an obscure insurance company wanting to get out because they are in a difficult situation (may be financially, may be race/background etc), would find it hard to have time for a public showing of their coding prowess?
No one is saying don't use public projects, but i would only consider them after other aspects, and certainly wouldn't cull people because of it.
Like I said: the amount of time you realistically need to get something out there is about a couple of weekends.
If you don't do public projects, then you start a few steps behind the other candidates. This isn't insurmountable, but the error bars are wider, making you a somewhat greater risk.
> I think open source development is virtuous and is something that I want to promote and encourage
Then pay them for it.
Though, even if it didn't mean I was getting a view into how they actually work, I'm okay with preferring public-minded people who give things back and make the world a better place through it. I try very hard to live by the motto "pay it forward" and I find it to be rewarding and pleasant to work with those who do likewise.
> Then pay them for it.
My last two employers did exactly that. Should I need to hire directly for my consulting adventures, I'll do it there, too. I mean, this reply makes no sense to me: why would I not?