[kamaal]

>>Here's another percentage what percentage of women and men didn't waste a thought on how they looked in their teenage years because they where so obsessed on how computers worked?

Most people are not in the job because they like create things or build things. They are there because they want a job and nothing more. And they want a job where (unit of money)/(unit of work) has a higher value.

That means they have to either figure out a way to make more money or do less work, or both.

Therefore the question of early interest or passion is meaningless to most people. So as far as they are concerned, it rarely matters how set of people of identity A got to it. They think regardless of that if set A got it, other sets should get it too.

This also creates other problems. Set A is likely to do side projects, write programs and hacks out of personal interest. Other sets looking at job as a return/effort metric will likely see why they are expected to do anything all all apart from working 5 hrs a day between 9 - 5.

The problem is merit is heavily at the side of A and other sets want the reward to not go with merit, but rather with participation itself.

[zaptheimpaler]

So true.

People didn't give two shits about the nerds and the tiny useless portion of the world known as computing they occupied 20 years ago - back then it was less glamorous and less money involved. They scoffed at the morons who not only did computers at work but continued to think, write and do "work" after work!

Now theres money involved everyone wants in! Now those same leeches demand to be given the same roles/money as those who worked much harder for it , because its so unfair that people who put have more experience and passion are rewarded while they are not!

[linkregister]

So true.

People didn't give two shits about the ladies and doing the tiny useless portion of the world known as software they occupied 50 years ago - back then it was less glamorous and less money involved.

Yes, women used to dominate software development. Until the money and prestige started coming in, then men started dominating the profession.

http://www.smithsonianmag.com/smart-news/computer-programmin...

[in3d]

The article you cite is fluff and doesn't support the statement that "women used to dominate software development." It mentions the "Computer Girls" article from the 1967 Cosmopolitan, but here is what's in it: "At one point the author speculates, seemingly without irony, about the “ the chances of meeting men in computer work. ”(The conclusion she comes to is that these are “ very good, ” as the field was currently “overrun” with men.)"

http://homes.soic.indiana.edu/nensmeng/files/Ensmenger2010-M...

Apparently, the best guess is that between 11% to 50% of programmers were women back then.

"Mandel suggests that one out of every nine working programmers was female. This is probably overly conservative. The exact percentage of female programmers is difficult to pin down with any accuracy—even figuring out the total number of programmers in this period is difficult—but other reliable contemporary observers suggest that it was closer to 30, or even 50, percent.3 The first government statistics on the programming profession do not appear until 1970, when it was calculated that 22.5 percent of all programmers were women—an estimate more than twice Mandel’s.4"

"Of course, computing itself is a very broad term covering a multitude of occupational categories, including high - status jobs like computer programming and systems analysis as well as low - status jobs such as keypunch operator. Women tended to congregate in the lower end of the occupational pool in computing"

[linkregister]

Thanks for providing this alternate perspective and invalidating my source. I will reconsider my position.

Can you account for the significant amount of women computer scientists making ground-breaking discoveries? Grace Hopper, et. al. Were the outliers?

I'm asking because I genuinely am unsure.

[kamaal]

Not justifying anything. But wasn't early programming two distinct tasks?

1. Writing the Program(On Paper).

2. Feeding the program to the computer.

People in 2. were called 'Programmers' because that is what they did literally- 'Program the machine'. Also early programming had all sorts strange situations where a large part of programming was actually getting results by plugging values in largish math formulas. So there were a range of people who did just that. Generating graphs, being the human equivalent of source control etc.

The 2. part wasn't exactly a very glorifying role and was more like borderline stenographer.

By some definition that is still true. Notice how many programmers there are who probably write MVP web apps for a living copying code from stackoverflow/internet, but there are also people doing all the real work thinking about stock markets, security, medical devices, writing compiler patches, building tools.

I've always thought as coding as a mere ritual the real work always happens on the paper.

[AjithAntony]

This was my understanding too. Women were given the the enormous and tedious task of transcribing programs onto punch cards and such. It required a large "typing pool", much like secretarial pools preparing letters dictated by others.

[sidlls]

I don't know what's more funny (or sad): that you think engineers are no longer as looked down on or compensated at a lower rate than their "work" should otherwise merit or that you seem to have completely missed the part about "equal experience" in your haste to poohpooh them that desire equal treatment for it as inferior.

[zaptheimpaler]

Thanks for the condescension sensei.

I think your position is equal work experience should merit equal pay.

You seem to have missed my point also - experience outside work also counts as experience. And millions of things besides experience determine your salary. So we should not be so quick to assume that 2 people with the same years of experience "should" merit equal pay - its obviously false.

If all people with equal work experience are simply equal in the value they bring to the company then why do we conduct interviews or ask for resumes or anything? Lets just set everyone's salaries to "$100K + 10K * (years worked)" no?

[linkregister]

Are you saying that the plaintiffs in this case didn't do side projects?

[watwut]

Well, majority of software developers don't do side projects, especially not those in high paid difficult positions. Those people put all strength they have into work itself. Employers don't even care all that much about side projects. So, it is safe bet.

This whole thread is stupid red herring. It has nothing to do with reality of working in corporation. It has zero to do with skills required in those high positions - just about only reusable from teenage years is linux internals.

It is basically assumption that a.) women are surely lazier b.) since they are girls they did not played with boy toys c.) if you discovered tech as part education instead of in playroom you can't be good.

[kamaal]

>>Well, majority of software developers don't do side projects

Most do. The fact that bulk of the software infrastructure from tools to top notch production software is open source says something.

>>especially not those in high paid difficult positions.

If its really about money, then there are better ways to get paid in a software company.

>>Those people put all strength they have into work itself.

Which is often a placeholder for a side project.

>>Employers don't even care all that much about side projects. So, it is safe bet.

But doing these projects does make you a fairly good programmer, and you tend to gravitate towards valuable work and hence good pay.

>>just about only reusable from teenage years is linux internals.

Bad news. Starting early matters. Want to build a good retirement fund? Want to play big leagues sports? Want to be a concert musician? Want to be a doctor? In fact want to be big in anything? Most certainly you have to start early.

>>It is basically assumption that...

Nobody made such an assumption. We only said a particular group A(mostly nerds) starts early and works hard. What the other group is for them to decide.

Note, Nerds is a group of people irrespective of gender, race, or other identity(even nationality or religion).

It just comes down to one thing. You can't progress beyond a point without work. Reservations only take you that far.

[linkregister]

Thank you for getting to the crux of the issue. It is simple gate keeping.

Indeed, startup founders and great engineers get absorbed in their work and spend time on it.

[kamaal]

>>that desire equal treatment for it as inferior.

The kind of equality that you are aiming for is meaningless, it doesn't exist and attempts to create this have lead to far bigger problems than they have tried to solve.

This is the equivalent of asking why we don't handover gold, silver and bronze medals to the people who came last in the race instead of the top 3. This isn't discrimination. The sheer concept of effort vs reward in human psychology is designed such that "Humans are unequal by merit of our actions"

Also the fact that some people are better than others is here to stay and not just restricted to software. Most of us are not going to be Neil Armstrong or Richard Feynman. That's not discrimination.

There is only equality of access and opportunity. Outcomes are not going to be equal.

[linkregister]

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.

I have never seen any multiple-data-point evidence presented to support it. Sure, various prominent entrepreneurs used computers as hobbyists (Gates, Zuckerberg), but does that apply to the typical programmer?

We all encountered students in classes who didn't study yet completely grokked their mathematics and algorithms coursework. Why is it so hard to believe that those quick learners use their time effectively at work?

Additionally, a multiplier to good engineering is strong communication and organizational skills; those can be enhanced through social recreational activity, and diminished by spending leisure time in solitude.

I'm not claiming either method is better, and intuitively the passionate engineer should win, but we shouldn't take it for granted until we get some actual information.

Edit: there seems to be some belief that I don't value experience. It is extremely important. We just shouldn't take it for granted that programming at home is as valuable as work experience.

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

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

[kamaal]

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.

[linkregister]

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.

[kamaal]

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

[flukus]

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.

[kamaal]

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

[willchen]

Citation?

[vt100]

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.