Hacker News new | comments | show | ask | jobs | submit login

This is one of those posts that is made, and upvoted, based on what everyone wants to be true, instead of what is true.

The simple, unassailable truth is that having strong contributions to open-source projects is a massive advantage in any resume-scanning and hiring situation. And as a hiring manager, seeing extensive open-source work is better than seeing a resume. That means the advice is ALWAYS good advice. There is never a situation under which the proper career advice is to not do good visible work.

This doesn't mean it's a requirement, or should be a requirement, but it IS a reality. If you choose not to participate, that's fine, but it comes with an inarguable cost. You can try to convince us all that it shouldn't, but it does, and it probably always will.




I'm not trying to convince you of anything.

I am well aware that strong open-source contributions are an advantage. What I find objectionable is not this advantage. It's the fact that failing to secure this advantage is being portrayed as an obvious professional failure that can be simply rectified by working an extra few hours a night on side projects.

It is propaganda from open source people, many of who have achieved considerably less in their open source projects than a casual inspection might suggest. Usually I come away from people's open source projects with a cheerful acknowledgement that this person (a) likes cool stuff and (b) appears to be able to write working code of a kind. This is good - but not that good.

There's a big difference between 'I wrote some code, look at me' and 'I contributed a competitive register allocator to LLVM' or 'I rewrote the scheduling algorithm for major open source FooOS'. The latter are 'strong contributions' and deserve the 'massive advantage' of which you speak. A handful of pet projects constitute a code sample that suggests that the person can form syntactically correct code.


Just being honest here, but both of your posts come off, to me, much more as you rationalizing a belief about what is true based on what you want to be true, and trying to "convince" us that most of this thing that "we" possibly value isn't all that valuable. Minimizing people's work on github as just some trivial side project, that should be ignored, because you don't want to do it, just isn't a reflection of the reality the situation. I freely admit this might be offbase, but it would appear you are arguing against -really- sound advice simply because you don't want the reality that that advice implies we live in. Except we do.

The underlying issue is that from a hiring perspective, all other things being equal, a candidate that can provably show things is ahead of the guy who simple says he can. Even if "we" all sit around and minimize that as some trivial nonsense that anyone could do and that it proves, at best, they can form "syntactically correct code", the fundamentals of the situation haven't changed. Showing is better than saying. It always will be.

There is an undercurrent of a strawman, as well, in this conversation. I don't think anyone out there is taking actual trivial github stuff and basing hiring decisions on it. But I wouldn't be surprised if some superficial github stuff haven't gotten people past a resume screen that they wouldn't have otherwise gotten past.


I concur that there definitely are strawmans and other poor argument tactics afloat. Onan_barbarian says that while some github contributions are really admirable, but some are of zero value, to which you reply by first reconstructing this argument to be "people's work on github is just some trivial side project, that should be ignored.", followed up by accusing him of rationalizing his hopes and making strawmen.

When someone says he did something, a github commit log showing it is definitely better than just him saying he did it. However, the point you actively dismissed was that a commit log of some mundane contributions is much less impressive than a resume describing work requiring a lot of skill.


    'I wrote some code, look at me'
Not that you're totally wrong, but a good open-source project also requires -- documentation, tests, community involvement, real users, gathering feedback from those users, collaboration.

Throwing code over the fence is not what open-source is about. I look at it as -- is this person capable of building a product for other people? Is he a team player?

That's not a skill that comes so easily and requires lots of experience or natural talent at other things than churning out code.


This has been going on forever with Academia, where the right to freely publish profoundly impacts where one chooses to work.

Anyone who dreams of becoming faculty must do work that is publishable, which often means taking substantially lower-paying "research" versus "corporate" internships throughout their younger years.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: