Hacker News Reader

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.

> 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.

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.

>>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.

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.

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.

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.

> 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?

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.

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.

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.

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.

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.

Its not necessarily starting early in programming. Its being in general being good at 'scoring marks' vs 'doing projects'. The former and latter take very different skill sets, and their returns too are often very different.

If you are good at doing projects. Along the way you learn a lot of other very important life skills. Things like resourcefulness, persisting at things, immunity to failure, trying many times etc. And these come handy and are usable to to many things that actually matter in the real world. That is building things.

These things are harder to gain at a later stage in life because expectations from one's life at that time are different and you have to worry more about monthly payments and putting food on the table. You don't have 10 - 15 years lying around to do what other programmers have done in their early years where it was cheap to that in terms of time.

You are also discounting the accumulative effects of these things. After a while due to years of practice, early starters are likely to get very good at things in a far more disproportionate way than those who come later.

Would participation in athletics or math competitions fulfill your requirements for early hard work and adversity? I do agree with your premise. I just don't see where you actually disagree with mine.

I'm not discounting anything. I'm just saying that it shouldn't be a given that engineers who got into the field late are automatically less able.

> early starters are likely to get very good at things in a far more disproportionate way than those who come later.

We think that but it's not actually demonstrated. Entering a field at the age of 18 or 20 isn't actually late. Until we actually have evidence that people who programmed before college have better outcomes, we need to stop talking about it as if it's a known truth.

>>Would participation in athletics or math competitions fulfill your requirements for early hard work and adversity?

Yes, but in School and a little higher- math is about learning heuristics and ready made procedures to solve problems in algebra and plugging numbers in formulas to get answers. And that is one of the biggest reasons why Nerds go onto to do things like projects to bail from the what is largely a useless academic exercise that gives you nothing real at the end.

Sports has a binary distribution, you either make the big league money or you don't.

>>I'm just saying that it shouldn't be a given that engineers who got into the field late are automatically less able.

They won't be treated as such. They will be evaluated on the same grounds as the long slog people. And that is precisely the problem. Somethings come only with time.

>>Entering a field at the age of 18 or 20 isn't actually late.

Its isn't late in absolute terms. But everything in the world is comparative.

The world is essentially a stack ranking system. You can do anything at any age you want. But there are costs associated with starting late, and they are in comparison with people who are long there.

It would be a hard study to do, many of the non-tinkerers will never enter the industry in the first place. For a fair evaluation I think you'd have to look at first year comp-sci students and then see where they are in 10 years.

Personally I think the correlation I've seen personally is strong enough that I'd be shocked if a study proved it otherwise.

>>It would be a hard study to do, many of the non-tinkerers will never enter the industry in the first place.

They will if there is enough incentive. They won't other wise. For example: CS definitely sees more diversity than mechanical engineering, simply because its easier to get paid and higher in CS.

Even in CS a lot of people eventually hop to MBA as that is even more better in terms of making low-effort big-money.

Citation?

If we did manage produce a study with multiple-data-point evidence supporting it, then should we legislate to compel all businesses to adopt the conclusions and recruit the same way?

The free market already allows founders and backers to back their theories with money and compete in the marketplace.