Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The programming talent myth

lwn.net

Post reply on HN
Print view View original

221–230 of 354 posts

Re: The programming talent myth

#221

Post by hikz » 

  That means we need to be doing something to get more people into our industry.
Why? What's in it for me?

  The EU has published similar numbers, 1.2 million in 2018—three years
I am a first-year CS student in Denmark and I hope you don't succeed in getting more people into the industry to fill those jobs before I graduate.

The lack of (talented) programmers is going to put young CS/CE grads in an advantageous position both in term of salary and job opportunities. I am happy employers are having a hard time finding people to fill those jobs. That makes life easier and safer for me.

The people screaming for more programmers here in Denmark are people in the government and Dansk Industri (lobby group representing bigger Danish corporations). The government cares about something they call "Denmark's global competitiveness" and the lobbyists in Dansk Industri want to flood the market so they can lower programmers' salaries. I don't care about the former line of buzzwords and the later is a hostile action taken against me as a programmer.

Don't get me wrong. I care about our industry. I will contribute to open source in the summer leave and I am involved in organizing some monthly meetups. But in the end of the day I also want a job.

Re: The programming talent myth

#222

Post by mathattack »

nsnick wrote: post #159
mathattack wrote: post #128

Earlier quoted context omitted.

I agree with most of what you said, except that perhaps the distribution is a little more complex than bimodal. Perhaps it's multi-modal, with various discernible leaps in performance. (There's a big gap between "Green", "Good" and "Rock Star", so I think that there's at least 3)

Any distribution can look multimodal if you under sample.

True. My contention is that learning happens in steps, it's not linear. This is especially true in programming. So rather than a smooth curve of talent, there are plateaus that people reach.

I would love to see data on this. Who knows, I might be wrong. (Wouldn't be the first time - even today)

Re: The programming talent myth

#223

Post by StillBored »

1.5 Million position job gap? Really? I hate when people throw the us labor stats numbers around like that.

Uh, hu, I wish these statistics would be backed up in a more through manner. Like maybe forcing companies to disclose how many applicants they get for a position and why they were rejected.

I say this because, I recently interviewed for a position doing some pretty low level work, where apparently there were a 100+ applicants (or so the hiring manager said). But it was believable because the job was posted on linked-in, and linked in reported that 34 people applied for the job.

So, a lot of people applied for the job, were they qualified? Well, considering I know two people with skillsets that are compatible with the position, and both are unemployed and live within 5 miles of the position, I would really like to see this kind of data industry wide.

AKA, assign each candidate a number (only disclosed to the candidate), and then publicly post the number, and the reason for disqualification. Maybe if someone can figure out how, disclose the skills the candidate says they posses without directly correlating them to the candidates public profiles.

That would give us an idea of where the skills gaps are, or even if they are real. Rejecting a bunch of candidates because "they don't fit the culture", or they don't have 5 years experience with CMVC, or perforce or some other tool not directly related to the specific job requirements needs to be public information. Or for that matter, that someone thinks they will ask for more money than the position pays, without making them the offer.

Re: The programming talent myth

#224

Post by lampe3 »

Lawtonfogle wrote: post #38
lampe3 wrote: post #14

Earlier quoted context omitted.

so lets say if i solve fizzbuzz quickly iam clever. i have solved it but in a shitty confusing way but i have solved it. but someone who solves it through trial and error and learns new stuff about what can go wrong and how it works is not so clever? coding is always trail and error because you cant think of all the possibilities and through error you learn and become better so yeah give me more of 3 then of 4

Because the fast solver has moved on to a harder problem and is learning more complex new stuff.

no the fast solver has solved the problem and is doing nothing ;)

Re: The programming talent myth

#225

Post by zenogais »

zaphar wrote: post #165
nilkn wrote: post #58

My own experience just does not agree with this at all. First, I think we have to distinguish between two ideas here: * The first is the question of whether anyone can learn to program. I think that for the most part everybody can, just like for the most part everybody can learn high school calculus. * The second is the question of whether programming ability is bimodal. This is not related to the first question, and…

The problem with relying on personal anecdotal evidence is that it is inherently biased. The only way to truly answer the question is find a way to reliable measure coding skill. Otherwise you find yourself making the same mistake you think Jacob is making. Using faulty data to back up an assumption. Part of the thrust of Jacob's talk was that there is probably a whole class of developers out there who would be just…

It's part a larger myth that probably needs to die also. See the book "Talent is Overrated" for a thorough and scientific evisceration of the idea.

Re: The programming talent myth

#226

Post by Bjartr »

a8da6b0c91d wrote: post #139
nilkn wrote: post #58

My own experience just does not agree with this at all. First, I think we have to distinguish between two ideas here: * The first is the question of whether anyone can learn to program. I think that for the most part everybody can, just like for the most part everybody can learn high school calculus. * The second is the question of whether programming ability is bimodal. This is not related to the first question, and…

> 99% of people can learn to program A good sixth of people are nearly functionally illiterate. I'd say well less than a third of people could ever write a real program.

Is that because they're unable to learn, or because they haven't been taught?

Re: The programming talent myth

#227

Post by squeaky-clean »

gaius wrote: post #62
Zikes wrote: post #31

Earlier quoted context omitted.

I suspect it will always be a largely subjective measure mostly determined by the respect or accolades of one's peers or the satisfaction of one's target audience/customers. I think StackExchange's "reputation" system is probably the most accurate discrete measure available.

I think StackExchange's "reputation" system is probably the most accurate discrete measure available I would be very hesitant to rely on any metrics coming out of SE. Consider their great programming survey this year, they say the average age of a programmer is 29. The US Department of Labor says it's 49. There are a vast number of people out there, well over 90% of the programming industry I'll wager, who come into…

>I would be very hesitant to rely on any metrics coming out of SE. Consider their great programming survey this year, they say the average age of a programmer is 29. The US Department of Labor says it's 49.

That doesn't mean they're both wrong. The two are just comparing different things. The SE programming survey included 157 countries, not just the US. It also doesn't only include full-time professional developers. 13.6% of respondents classified themselves as "Student". Only 66.3% of respondents listed themselves as "Employed full-time"

Re: The programming talent myth

#228

Post by Sevzinn »

dusklight wrote: post #191

If you started programming when you were 12 and you've been programming for fun more than 4 hours a day every day since then, you are going to be drastically better than someone who starts programming in their first year of college and only does it to graduate. It feels like a bimodal distribution because you then get both kinds of programmers interviewing for jobs at the same age when they graduate from college and…

I'm curious if anybody who starts programming in college would ever write such a message. I think "dusklight" started programming around 12 and programs for fun more than 4 hours a day.

I was doing x86 assembly as a teenager and perform terribly compared to at least one person who started in college.

Re: The programming talent myth

#229

Post by KedarMhaswade »

I think there is a question of progression through your career as well. For talented programmers, (I believe) it is less likely to feel 'stuck' at some point. Over the years, they can handle increasingly more complex challenges with same relative ease. Others have to do significantly more efforts to handle abstractions well enough to ensure 'cruising' along.

Re: The programming talent myth

#230

Post by webnrrd2k »

base698 wrote: post #169
altcognito wrote: post #118

Earlier quoted context omitted.

> They pick the wrong data structures, think about code first and data is an afterthought. It makes me so happy to read this. Data in the grand scheme of things is vastly more important than code. "picking" data structures is a luxury in many cases and thus data structure often dictates the structure and expectations of your code. Data usually outlives the code. Data is effectively the earth in your code farm. Take c…

According to SICP data and code are the same! Interesting concept anyway. http://stackoverflow.com/questions/355406/concepts-that-surp... http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html...

That's like saying all Turing-equivalent languages are the same. It may be true in theory, but is hardly a useful point in most programming language discussions.

As an example of code vs. data, and this is a general statement (so YMMV) I try to structure my code such that, if there is a choice between making the code more complex, vs making the data more complex, I generally choose to make the data more complex. The code is usually harder to reason about, so it's a win if I can use a simpler algorithm.

Post reply on HN