[zaptheimpaler]

In every single industry and craft, those with more work experience are typically paid more than whose with less.

There is little difference between "experience programming during a job" and "experience programming for fun". It is the same activity.

So of course those with more experience should be expected (on average) to better than those with less. Of course those who seek out more experience due to passion will (on average) be better than those who don't.

It's not an unusual thing to expect at all. People who care more do better.. in every human endeavor, and this is widely accepted by society. It only seems unusual when newcomers cry "unfair" when they see others enjoying the fruits of their labor.

You can ask for data - great, we don't know the answer. But if I had to guess one way or the other, based on all human experience, yes I would lean heavily towards experience. Its why professors know more than students, why Edison invented a lightbulb after a thousand other failed inventions, it is the basis for the very concept of an expert - its why we appoint a doctor instead of a physicist to run a hospital. Its pretty goddamn fundamental - people get better at things with time, so those with more time tend to be better.

[tbrownaw]

There is little difference between "experience programming during a job" and "experience programming for fun". It is the same activity.

Over of my more recent hobby projects was writing an RSS->IMAP bridge in maybe a couple hundred lines of Python. It has one user (me). This is fairly typical.

Until this year, my primary work project was a toolset for streamlining one-off ETL projects. It has parts written in I think five different languages, it has parts that run on Windows user machines and other parts that run on unix servers, it was built to reduce the annoying parts of a business process, it evolved over the course of almost a decade, etc. It has a couple dozen users (the team I used to be on).

The two are about as different as adding a new attached garage and workshop vs building a dollhouse.

[TeMPOraL]

Yeah, exactly. With the work frequently being the dollhouse.

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.

[kamaal]

This reminds of a situation I faced early in my career. We worked on a network alarm management tool, and some of us used to rewrite the tool or bulk of its features. To a point we finally arrived to invent our own tools to fill up the gaps in the feature set offered by the current tool.

It used to be one of the biggest reasons why we learned so many thing in comparison to the rest of the team(which was fairly big), to a point we could make a lot of very critical design decisions or write an application that could save hours of time for our users.

Its one of those axioms of software development I've learned, in order to do good work you have to do mountains worth of waste work.

[TeMPOraL]

> Its one of those axioms of software development I've learned, in order to do good work you have to do mountains worth of waste work.

It suggests an obvious question though: can we do better? Can we avoid having to do "mountains worth of waste work" before getting to do the "good work", or is the former a necessary prerequisite for the latter?

[brad0]

I believe we can reduce the amount of waste work by doing deliberate practice.

This means really analysing what you did and how it could be better.

Also doing a small amount of work each day is much better than a large amount once a week.

Take a large task and break it down into tiny manageable chunks that you can analyse.

There's tons of material out there that has best practices for mastering anything.

[TeMPOraL]

It's not just about skills, but also about knowing what problems to solve and being in the position to solve them. I wonder if we can side-step having to do waste work in the latter cases.

[linkregister]

> In every single industry and craft, those with more work experience are typically paid more than whose with less.

This isn't true. Those who do more with their work experience are paid more.

We all know engineers who have been at the same company for over a decade, but have practically nothing to show for it. There is an enormous disparity between engineers.

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.

Jeff Dean and Rob Pike aren't good because they've been programming for a long time. They're good because they've developed their organizational skills, architectural skills, communication skills, and excellent public speaking (this is vital as a tech lead and higher). None of those can be developed by programming on something cool on the weekend.

None of what you said actually disputes my statement; we both value experience. I'm just trying to communicate to you that extra hours programming at home might not be as intrinsically valuable as you might think.

[zaptheimpaler]

Well I agree that hours don't always equate to value, in many cases they don't for the reasons you pointed out. Ultimately it matters what kind of experience you have and how valuable that is in a given context.

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.

[kamaal]

>>We all know engineers who have been at the same company for over a decade, but have practically nothing to show for it. There is an enormous disparity between engineers.

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.

[watwut]

Tinkering in teenage years does not give you more professional experience 10 years later. It gives you a bit advantage around early 20ties. It is essentially irrelevant at 26. As technologies change and develop, that get lost and become useless.

Also, imo, important predictor of how good you will be later on is more your willingness to learn tech you don't like in the beginning. If you don't have that, changes will leave you behind.

[MagnumOpus]

Agreed with the latter, don't agree with the former.

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.

[watwut]

The thing is, if it is your job to do crud applications, then having a look at security development at least once a year is a part of job. And at that point, you will learn about sql injection if it is a new thing. If sql injection was something known for 10 years, then you would learn it in the process of learning crud.

All that assuming you take work seriously.

I think that when young people spend their time doing something, it says somethi nd good about them and their environment. However, you can learn the things they learned later on if you have aptitude and study the topic seriously.