Hacker News Reader

Comment by ddevault | Hacker News Reader

I'll be honest: if you have one person who spends 8 hours a day practicing a talent, and another who spends 10 or 12 hours a day practicing their talent, which is going to be better at that skill? Having lots of open source code to read demonstrates in public the prospect's talent for writing code, has examples of their collaboration with others, etc, but also simply means they spend more time writing code and getting good at it, on a broader variety of projects, with a greater diversity of collaborators.

Yes, it's unfair, and if we're just arguing on a sense of lofty idealism, I agree that you shouldn't have to sacrifice your off-hours. But the truth of it is, people who don't code in their spare time aren't as good at it, and people who do are not only more skilled, but are easier to evaluate.

View on HN

But writing code is only a small part of a software engineer's job (at least that's true everywhere I've worked), so selecting people who have opted to dedicate their lives to only that portion might be a worse idea than hiring better-rounded candidates, when it comes to building real software systems that need to be liked by users.

The law of diminishing returns applies just as much to programming skill as anything else. Most programming work is not that hard; for the vast majority of jobs, the point of diminishing returns occurs well before "works 12 hours a day writing code for fun on GitHub". After that point, other skills start to matter more than sheer amount of code churned out. This is true even for e.g. senior R&D roles, where for those with the necessary programming skill the ability to come up with new techniques is more important than a few more hours spent writing code.

Time invested isn't linear with improved talent. We all have our own thresholds, but we all get diminishing returns after working/practicing so many hours in a day.

It also depends on the quality of time as well as the quantity. I'm a musician, and it's a fairly common trope to talk about practice in terms of efficiency, such as identifying "directed practice" and similar terms. I've experienced it myself: if I'm mindlessly playing the same passage over and over again, I won't improve nearly as quickly as if I stop and analyze why I'm making the mistake rather than just trying to force myself past it.

Perhaps, but this is only important if you need the absolute best coder above all other skills. People do other things during their free time that can build valuable skills that contribute to them being a better programmer and teammate. For example, volunteer coaching makes you a better mentor, playing team sports can make you a better collaborator, etc.

Just being good at code isn’t the only important thing. Programming requires communication and understanding what people want. Sometimes you need to debug the human mind.

My company disallows me from doing open source (without an incredibly rigorous review process that makes it honestly not worth the hassle).

Nice plus? Sure. Near-mandatory? Fuck no.

How exactly do they do that?

Reply on news.ycombinator.com