The problem is that a lot of us have lives outside of work, and work is proprietary software. I hit this problem in my latest job search. I had a limited presence on github and a rarely updated blog... if you'd asked me 4 years ago, I'd have nothing. Which doesn't mean I'm not a good coder. It means I have a wife and a family and non-coding hobbies, and I'm not 25 with the ability (or desire) to code until 2am every night. Luckily I had enough of an online presence that I was able to do a weekend coding project to prove to my (now current) employer that I'm worth hiring.
I think it's pretty safe to say that most professional software developers work for companies that do not open source their software. So, the majority of your time coding is hidden away. For anyone with a family, the rest of your time is pretty much taken up. To get work done on side projects, I get up at 5:30am... and haven't been able to do that since the birth of our second child.
Now, I 100% understand why people would hire #2. He/she is a known quantity. The other one, well, who knows? It's famously hard to figure out in an interview who will be a good coder and who will not... and it's incredibly expensive, both in time, opportunity cost, and actual dollars, to hire a bad developer. Not to mention the bad code that might infiltrate your codebase. So, playing it safe with #2 is usually not a bad idea. But, at least give the other guy a chance. If you like him in the phone screen and preliminary interview, give him some coding homework and see how he does.
What I don't quite understand in this discussion is the either/or nature being suggested here and elsewhere in the thread. There are plenty of opportunities to contribute to OSS in the context of proprietary software. Even if you write proprietary software, you most likely use open source software (I know that's not true of everyone-- more on that below). And when you use it a lot, you find bugs or missing features, which you can fix as part of your job. When I was less experienced and there was no Github, I shrugged my shoulders and worked around problems I found, which usually just led to more pain. Now, I grok the code and make a pull request. It helps the proprietary project I'm working on and helps, almost incidentally, all of the other users. And ultimately, I suspect that's where a huge portion of OSS code comes from: people who need it and are thus willing to contribute as part of their proprietary software jobs, not from dedicated OSS developers volunteering their time, forgoing sanity and a paycheck. That's why there's so much good OSS infrastructure software.
With that in mind, let's imagine a manager hiring engineers for a project built on top of an OSS stack. Sometimes that stuff won't work right, and sometimes--I'd argue usually--the right answer is to just fix it. And you're looking at a developer with experience doing just that and someone who hasn't. One has taken the initiative to learn their way around the internals of the tools they use and the other may or may not have. Who do you pick? Contributing to OSS is not just a badge of honor here; it's what's left behind by good development work.
Sure, some jobs don't have that. Maybe it's a video game built on some proprietary toolkit, maybe it's a low-level library written from scratch. But surely those aren't the employers who care so much about your Github account, right?
Comments
The problem is that a lot of us have lives outside of work, and work is proprietary software. I hit this problem in my latest job search. I had a limited presence on github and a rarely updated blog... if you'd asked me 4 years ago, I'd have nothing. Which doesn't mean I'm not a good coder. It means I have a wife and a family and non-coding hobbies, and I'm not 25 with the ability (or desire) to code until 2am every night. Luckily I had enough of an online presence that I was able to do a weekend coding project to prove to my (now current) employer that I'm worth hiring.
I think it's pretty safe to say that most professional software developers work for companies that do not open source their software. So, the majority of your time coding is hidden away. For anyone with a family, the rest of your time is pretty much taken up. To get work done on side projects, I get up at 5:30am... and haven't been able to do that since the birth of our second child.
Now, I 100% understand why people would hire #2. He/she is a known quantity. The other one, well, who knows? It's famously hard to figure out in an interview who will be a good coder and who will not... and it's incredibly expensive, both in time, opportunity cost, and actual dollars, to hire a bad developer. Not to mention the bad code that might infiltrate your codebase. So, playing it safe with #2 is usually not a bad idea. But, at least give the other guy a chance. If you like him in the phone screen and preliminary interview, give him some coding homework and see how he does.
What I don't quite understand in this discussion is the either/or nature being suggested here and elsewhere in the thread. There are plenty of opportunities to contribute to OSS in the context of proprietary software. Even if you write proprietary software, you most likely use open source software (I know that's not true of everyone-- more on that below). And when you use it a lot, you find bugs or missing features, which you can fix as part of your job. When I was less experienced and there was no Github, I shrugged my shoulders and worked around problems I found, which usually just led to more pain. Now, I grok the code and make a pull request. It helps the proprietary project I'm working on and helps, almost incidentally, all of the other users. And ultimately, I suspect that's where a huge portion of OSS code comes from: people who need it and are thus willing to contribute as part of their proprietary software jobs, not from dedicated OSS developers volunteering their time, forgoing sanity and a paycheck. That's why there's so much good OSS infrastructure software.
With that in mind, let's imagine a manager hiring engineers for a project built on top of an OSS stack. Sometimes that stuff won't work right, and sometimes--I'd argue usually--the right answer is to just fix it. And you're looking at a developer with experience doing just that and someone who hasn't. One has taken the initiative to learn their way around the internals of the tools they use and the other may or may not have. Who do you pick? Contributing to OSS is not just a badge of honor here; it's what's left behind by good development work.
Sure, some jobs don't have that. Maybe it's a video game built on some proprietary toolkit, maybe it's a low-level library written from scratch. But surely those aren't the employers who care so much about your Github account, right?