Live data from Hacker News

The programming talent myth

lwn.net

31–40 of 354 posts

Re: The programming talent myth

#31

>>Part of the problem there is the lack of a way to even measure coding ability. "We are infants in figuring out how to measure our ability to produce software", he said. What are our metrics? Lines of code—what does that measure? Story points? "What even is a story point?", he wondered. Indeed, what is programming talent? What is a 'good' programmer? What is a 10x rock star? These notions are similarly ill defined.…

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.

Re: The programming talent myth

#32

That programming is a talent is not a myth, and while my life is currently devoted to developing a platform to encourage more people to learn the basics of computer science, I will certainly never say "anyone can learn how to code" any more than I'd say "anyone can become a concert pianist" or "anyone can become a master painter." Good programming is an art, and requires talent on the part of the programmer. There's…

>> I will certainly never say "anyone can learn how to code" any more than I'd say "anyone can become a concert pianist" or "anyone can become a master painter."

So learning to code is equivalent to being a master painter or concert pianist? Which both are amongst the top 1% of their field probably.

Anyone can learn how to paint or play a piano, the level they'll achieve won't be the same everyone, but anyone can do it, just like anyone can learn how to code.

Re: The programming talent myth

#33
post #17

It's not that programming skill (whatever that is) is bimodal, it's the effectiveness of the engineer in a typical development scenario. That stems at least partly from the fact that programming is hardly ever a one-person endeavor, contrary to running. Since scaling a team increases friction and overhead, a small number of highly skilled engineers can be absurdly more effective than a set of teams, which also makes…

It also doesn't count for how low skill (inherent, trained, etc.) can have a negative impact on a project by incurring vast amounts of technical debt that will have to be repaid that outweigh any positive contributions made.

Re: The programming talent myth

#34
post #32

That programming is a talent is not a myth, and while my life is currently devoted to developing a platform to encourage more people to learn the basics of computer science, I will certainly never say "anyone can learn how to code" any more than I'd say "anyone can become a concert pianist" or "anyone can become a master painter." Good programming is an art, and requires talent on the part of the programmer. There's…

>> I will certainly never say "anyone can learn how to code" any more than I'd say "anyone can become a concert pianist" or "anyone can become a master painter." So learning to code is equivalent to being a master painter or concert pianist? Which both are amongst the top 1% of their field probably. Anyone can learn how to paint or play a piano, the level they'll achieve won't be the same everyone, but anyone can do…

And you don't have to be at the top 1% of your field to be a valuable asset to a company.

Re: The programming talent myth

#36

That programming is a talent is not a myth, and while my life is currently devoted to developing a platform to encourage more people to learn the basics of computer science, I will certainly never say "anyone can learn how to code" any more than I'd say "anyone can become a concert pianist" or "anyone can become a master painter." Good programming is an art, and requires talent on the part of the programmer. There's…

I believe that, in theory, 99% of everyone can learn to code. However, some people will take prohibitively long to do so. These people may have other talents, but they will struggle in learning how to code and probably only achieve minimal success.

Of course, that's using a completely vague and arbitrary assessment of successful coding. I teach an intro coding course for non-majors at the undergraduate level. So my numbers are based on the performance assessment we use.

Re: The programming talent myth

#37
post #8

That programming is a talent is not a myth, and while my life is currently devoted to developing a platform to encourage more people to learn the basics of computer science, I will certainly never say "anyone can learn how to code" any more than I'd say "anyone can become a concert pianist" or "anyone can become a master painter." Good programming is an art, and requires talent on the part of the programmer. There's…

to be a great concert pianist it is 5% talent 95% hard hard work... If you dont train your fingers every day and if you dont play for at least 1 hour everyday since your 10 or younger you wont become a great concert pianist... you can say the same for coding. it is 5% talent but the rest is coding coding coding coding... If you have talent the start will be easier but at some point talent wont help anymore just study…

The thing about "coding" is that it's simply the means, not the end. The configurations you can program a Turing complete device with proper hardware into are, for practical purposes, boundless. Being a concert pianist can intersect with many fields as well (acoustics and music theory alone can get quite deep), but ultimately the immediate direction is much more narrow.

In fact, I would argue that just "coding coding coding coding" won't get you all that far alone. There's plenty of "reading reading reading reading" so you can actually have the skills and knowledge to write what's intended, and then there's all that lesser visible knowledge out there that is just as crucial, but hidden in (relatively) obscure references or papers - unless you intend on reinventing lots of square wheels.

Re: The programming talent myth

#38
post #14

Earlier quoted context omitted.

I think you can break it down further into four groups. People who, when presented with FizzBuzz on their first day of learning programming would: (1) Not even try, because it's "too confusing." (c. 90% of the population). (2) Be able to finish only with significant assistance from others. (3) Be able to finish on their own through trial and error. (4) Finish quickly, and wonder why they were asked to solve such a bo…

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.

Re: The programming talent myth

#39

There is a myth, but the myth propels reality. Take this line in the article as a reason: > That leads people to be working crazy hours at work, to be constantly studying programming topics on their own time, and so on. This attitude will create ninjas/rockstars/whatever, even if the original notion isn't true. Folks who spend every waking hour thinking about and learning about something are going to be better than t…

This attitude will create ninjas/rockstars/whatever, even if the original notion isn't true. Folks who spend every waking hour thinking about and learning about something are going to be better than the folks who don't do that level of effort.

It will create people who believe themselves to be something special, sure, but that's all you can say for certain. Where are the results that prove it is deteministic? For every startup full of rockstars that succeeds, there are 1000 who worked just as hard and sunk without a trace.

Re: The programming talent myth

#40
post #30

Earlier quoted context omitted.

Having worked on several systems like that, I can say there are definitely passionate developers behind any serious code. An "old guy" I know that has lead development on several extremely high volume payment processing systems has the most extensive personal CS library I've ever seen. No one is writing high performance code without deep knowledge of what they're doing.

That is true. But also noone is writing critical systems staying up all night drinking Red Bull. Look at other engineering disciplines. Where are the bridge and dam building rockstars? Where are the nuclear power ninjas? I wonder what "rock stars" are going to do when they discover other uses for their time, hobbies, families, sports, travel and so on. Resign?

I think you're talking about two different things:

1. People that are dedicated to their craft, write A LOT of code and self-study in their free time.

2. Red bull drinking Valley stereotypes.

People from camp 1 don't live up to the stereotype of the "rock star" but definitely work way more than 9-5. Where work is defined as studying languages, domain specific knowledge, low-level code...

Post reply on HN