At my various $dayjobs, I spent most of the time building various flavours of the same CRUD (web CRUD, desktop CRUD) in dumb mainstream languages. At home, I do everything from video games to data processing to AI, in actually productive languages.

The difference I see is that with hobby projects, you're at least free to make something that's actually useful. At work, you might get that if you're lucky. If you're not, you'll be implementing in code some dumb inter-management politicking.

My point was if I had to pick one broad generalization - "value increases as hours increase", "value is independent of hours", "value decreases as hours increase" - it certainly makes sense to pick the first. Extra hours are more likely to make you more valuable than to make you equally or less valuable.

This was what I was replying to

> I find it interesting that HN commenters frequently take it for granted that someone who tinkered with programming at an early age and do side projects is a better performer at work.

Thats why I do take it for granted (on average) that people who do side projects do better than those who don't. With 2 equal resumes I would confidently pick the one who started programming early. Nothing is certain when generalizing like that obviously, but then again no signal ever in any interview is a guarantee of future work performance.

Please note that this has nothing to do with gender.

>>There's a reason why Google and Facebook allow engineers to stay Senior Engineers for an entire career: most don't actually progress beyond a certain point.

Or they have golden handcuffs, and its very hard to get paid that much else where. And throwing away money for some measurement of ethics which no one cares about is foolish.

>>There's a reason why Google and Facebook allow engineers to stay Senior Engineers for an entire career: most don't actually progress beyond a certain point.

Oh they have been. They don't build furniture, they build the machine that makes furniture. So they are valued more.

>>'m just trying to communicate to you that extra hours programming at home might not be as intrinsically valuable as you might think.

Ever heard of the proverb: "Opportunities multiply as they are seized".

To go some where, you might have to travel a lot of distance going nowhere. The destination isn't always visible from where you stand.

Tinkering gives you out-of-domain experience which subtly improves the decisions you take - both architecturally and organisationally. It gives you at least a bit of an insight of what the right tool for the job might be even if it is outside your domain.

If that tinkering is in hacking IT security, and you do CRUD app development (or project management) for a living, your app might just coincidentally avoid SQL injections or obvious buffer overflow errors. If that tinkering is in image recognition and machine learning and you are a business manager, you just might know the difference between "feasible" and "impossible" AI projects (avoiding this XKCD situation: https://xkcd.com/1425/).

Obviously you will also avoid these if you have actual professional experience in IT security or AI - but very few actually can get involved in a dozen fields professionally at once.