If glibc maintainers choose to make their own repository which Stallman has has no right demand anything they are free to do so. And then it becomes distributors freedom to choose who's repository they prefer.

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.

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!

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

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"

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.

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.

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?

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.

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.

Moreover, even if open source would be written as side projects mostly, it is still just a tiny part of all software out there.

You assume they are lazy, for no reason. No, not just nerds work hard. No, not all nerds work hard - many spend majority of time playing with something easy they like. In particular, many nerds are unwilling to learn what they don't like.

As for your bad news starting early matters, it don't. I am old enough to have seen where people ends. Many men stared later or changed career and it was no disadvantage after initial year or so.

I personally have all the things you talk about as necessary advantage. They are not and that is not even bad thing. The only difference is that I am not as bitter as rest of thread who want reward for being associated with them (I bet they were not young geniuses they want themselves to be) while real world does not work like that. The other annoying thing is that you would assume I don't have them, cause I am women whole dudes who changed careers yesterday are assumed to be interested since childhood no matter what facts are.

Open source isn't always someone's side project. Lots (most?) open source is professional paid work.

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

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

Who play with dolls and who plays with action figures or cars is even moremember irrelevant.

High paying computer jobs are not filled with nerds nor high funstional autistic while we ate at it too.

I beg to differ

Of course it might be that I have missed it or it is hidden somewhere. I hope it really exists somewhere in the repository, but I didn't find it. I might be too tired to find it and someone else has better luck.

A) In system price there are many components and that makes ultra cheap CPU:s in other vice identical configurations not so good price-performance.

B) Performance is really the performance differential from what you upgrade. And even more importantly the performance differential years from now to systems of that time, if you upgrade to a system that lasts 5 years before you upgrade or to a system that lasts 7 years before you upgrade is significant in terms of price/performance because later means you get the high performance early and price last longer.

C) Significantly higher single threaded performance compared to Ryzen 7 the main contender. There are still many tasks that are single threaded, especially if you run legacy code.

D) AVX-512 I doubt the review benchmarks are in AVX-512 but some legacy code. AVX-512 increases both width of vector and fraction of code and algorithms that can be parallerized significantly. Once compilers are well tuned to use AVX-512 the code compiled with AVX-512 optimizations turned on should be significantly faster than what it was before hand. Simply being able to do 8-16 times work per cycle in large variety of tasks is significant advantage even if that is for a good fraction of time instead of all the time.

Personally I7-920 has given me far better price-performance compared to people who bought dual core at the time simply because it has lasted LONGER so it had superior price/(time between CPU upgrades) measurement. Right now in that same measurement I7-7820X is the king.

So in conclusion I7-7820X is faster in both real legacy code and the future code, and gives good enough performance longer simply because code that you run when you would start considering upgrades run much faster on it simply because of extensions.

Lots of keys combined with Meta(alt)+Control key, the optimum keybinding for window manager, those two keys are always unused in user programs. Its really perfect for emacs, no-one has imagined to use those two keys with some random key, on any of emacs packages or modes.

Poor me have binded my windowmanager commands with Super(windows) + (what ever command key I use for it.

It can give you ideas on how to delegate more.

Secondly figure out how to retain developers. If it causes you stress and hiring is real expense then you should invest in fixing it. Make developer work environment as good as possible and maybe pay slightly above market pay.Your job is to fix the environment to reduce turn over to compensate the boring product with other factors they value.

Specifically, this experiment eliminates (much of) the problem that earning a few hundred euros will cut your unemployment benefits by the same amount. It allows people to take part-time jobs without being penalized. It's not perfect for the reasons you give and more, but it might be significantly better than what is currently in place.

The premise that one can find some universal income amount X and do away with all other types of benefits is a pipe dream anyway. For some, X will be enough to scrape by. For others, X will not be enough for their medical care necessary to survive for two weeks. There will always be a need for some extra needs-based benefits.

Finland (like much of Europe) has universal healthcare and a national health insurance plan; this is not an issue. There already is an 'X' that people can (adequately) survive on when on welfare. If basic income is something that a state wants to research in earnest, these kind of experiments provide valuable data and can be seen as a tentative first step towards a national basic income plan.

That is why this a useful basic income experiment - regardless of whether the program itself is classified as basic income in its current form or not.

Not really, because (i) tax credits and other proposed "welfare trap" reduction methods have been around and studied for a while and (ii) it doesn't attempt to study any of the features of BI widely believed to have negative impacts such as the cost of extending welfare to millions of people not currently [interested in being] eligible for it, possible social effects of decoupling benefit entitlement from any indication of desire/need and net income reductions to some current welfare beneficiaries if other programmes such as housing entitlements are cut. As a general rule, experiments which don't test any of the perceived negative effects of a proposal generally mislead more than they inform in debates about whether it's an improvement on the status quo.