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

111–120 of 354 posts

Re: The programming talent myth

#111

Post by astrocyte »

It's quite simple... There are people who have a knack/drive for understanding the world/universe and its many functions. People who care to understand the root mechanism as opposed to speculating about how the tree and leaves form. This is the base talent behind good software engineers who become great through experience and challenges. If you -truly- understand something, you are good at communicating it in many ways and capable of expressing it in a 'language'. What came first? Language or understanding. What do a lot of institutions teach? Programming. What don't companies want to invest in : Understanding....Mind the gap.

You may be good at a language and still not have any good ideas to express;Programmer

A lot of people fail to see this and go on with arbitrary measures of what makes a good software engineer. Oh nos', you don't know how to craft the perfect general expression for this. Oh nos', your Translation look-a-side buffer calculation was off... And so on.

The typical interview centers on how well someone programs. People write long articles which stirs people into a frenzy and much is lost in the discourse. Mindless interview structures are administered which tests people on their ability to work through leaf problems.

Tress of horrible construction are made and root analyzers are called in to save the day. Since there aren't many who fully understand root construction, such talent is hardly ever understood for its value : Modern software engineering at your alphabet soup of companies.

And here we are. Much will never change because there are few actually looking at the root issues. Few actually care to. It's all about the leaves and low hanging fruit.

Re: The programming talent myth

#112

Post by taurath »

67726e wrote: post #94
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…

Been screwing with computers since 9 or so, and programming since 11 or so. I'm now about 4 years into my professional career and usually get the typical "amazing programmer" remarks, that I'm fast, smart, good code, beyond my years, etc. I think that a lot of things go into it. First, practice, practice, practice. I spent waaaaay too much time in high school writing/designing/building projects. By the time I hit uni…

> Some folks look at a task like "build a web application" and seize up at enormity of the task. Others, start breaking down the problem into it's component parts.

This can be learned by anyone!! This is not a binary idea. The more "complete unknown" concepts in said task the more likely anyone is to seize up - good programmers (or basically any engineer) are just more practiced than most at overcoming a lack of knowledge.

Re: The programming talent myth

#113

Post by kwhitefoot »

bkeroack wrote: post #61
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…

Is speed really the most important metric?

Perhaps not the most important but it is important. Whatever the job, if you can do it faster you have more time available to do it better.

Re: The programming talent myth

#114

Post by hn_ »

dragonwriter wrote: post #53
empressplay wrote: post #3

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" I would certainly say "anyone can learn how to code" in the same way that I would say "anyone can learn how to write", or "anyone can learn to run", or "anyone can learn to play piano". I wouldn't say "anyone can learn to become a concert pianist", in the same way that I wouldn't say "anyone can lea…

>anyone can learn to play piano

Is there a belief that anyone can learn to play the piano? I can't. I struggled for many years trying to learn various instruments. I failed miserably no matter how hard I tried. I tried and I tried, I really wanted to be able to play an instrument, any instrument, but I was unable to. I'm not dumb, I am a programmer, but music was just something my brain couldn't comprehend.

Of course we also have to define what exactly is "able to play the piano" and what is "able to program"? If know how to write "hello world" does that mean I know how to program? If I play a couple cords does that mean I know how to play the piano?

Re: The programming talent myth

#115

Post by exstudent2 »

taeric wrote: post #106
exstudent2 wrote: post #90

Earlier quoted context omitted.

I agree that any talent shortage is likely to be an upstream problem from hiring. I don't agree that eliminating a bimodal model is desirable though. We don't really need more people in the middle of the talent trough because they don't actually add much value and can often detract value (in my experience). Successful programming is the grappling with immense complexity. You really only want the best and brightest do…

I didn't realize I put forth that the bimodal should be eliminated. Just that I don't think it should be taken as a natural fact. It may be that eliminating it is meaningless. It may be that keeping it is meaningless. Consider, do you really care about having the best and brightest doing something. Or just getting the best results. Odds are high that those align at least somewhat with each other. I don't know if it i…

I wish I had the resources to formally test the hypothesis but alas I don't. However anecdotal my experience is, it has been consistent and enough that I'm not willing to risk my career hiring anyone other than the best I can find. It's actually a lot easier to hire mediocre developers so I wish that produced great results. It hasn't for me though.

Re: The programming talent myth

#116

Post by Lawtonfogle »

agentultra wrote: post #80
Lawtonfogle wrote: post #33

Earlier quoted context omitted.

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.

I haven't really seen any evidence that this is true. The talent myth as Adrian describes it is one of stereotyping: there's no data to accurately measure skill in programming so we simplify things in our heads and believe you're either talented or not. This myth appears to directly support your claim: untalented individuals are a cost burden on the enterprise. If this were true there would be far fewer enterprises t…

>The reality I've experienced suggests that deliberate process correlates strongly to quality. In the absence of true talent we can still write great software by leveraging processes and tools to wrangle complexity and manage defects. We see this in plenty of engineering disciplines. Why is software so special?

Because of the entry level.

Think of this joke: What do you call the guy who graduates from medical school as the bottom of his class? Doctor.

The point is that even though there is a worst, they still have to have gotten so far. Even the worst engineer had to do good enough to become an engineer, which is a far greater test of skill than what I've seen in some interviews, especially when those hiring are not technically experienced.

I think many who call this a myth happen to have rarely come across these people in technical roles. At worst they may have interviewed a few, but they were quickly cast aside. They've never met a person who managed to get into a senior position as a cargo cult programmer who can't explain even the basics of the frameworks they are using.

Re: The programming talent myth

#118

Post by altcognito »

jeremiep wrote: post #92
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…

From personal experience, speed has very little to do with productivity. Productivity is a function of knowledge and experience. The most productive programmers I've met almost always had enough experience in what not to use. They have a clear focus on the simplicity of their code and their ability to reason about it. They understand the problem and the hardware as well as the language in a very detailed manner. They…

> 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 care of it, and form it as best you can given a set of restrictions so that your program runs smoothly.

Re: The programming talent myth

#119

Post by nightski »

dragonwriter wrote: post #53
empressplay wrote: post #3

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" I would certainly say "anyone can learn how to code" in the same way that I would say "anyone can learn how to write", or "anyone can learn to run", or "anyone can learn to play piano". I wouldn't say "anyone can learn to become a concert pianist", in the same way that I wouldn't say "anyone can lea…

What is the point of stating that though? It's pretty hard to know ahead of time and talent is rarely worth more than sheer effort.

Not only that but I would say technical lead of a software team that revolutionizes the industry requires many other skills besides writing the best code. In fact, people skills probably are far more important.

Re: The programming talent myth

#120

Post by nilkn »

jeremiep wrote: post #92
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…

From personal experience, speed has very little to do with productivity. Productivity is a function of knowledge and experience. The most productive programmers I've met almost always had enough experience in what not to use. They have a clear focus on the simplicity of their code and their ability to reason about it. They understand the problem and the hardware as well as the language in a very detailed manner. They…

> From personal experience, speed has very little to do with productivity. Productivity is a function of knowledge and experience.

As I wrote elsewhere, it's not just speed. The more talented programmers I referred to write better, cleaner, more performant and more elegant code -- and they do it faster.

> Productive programmers don't really type faster or think faster. They just make far less mistakes to begin with and such mistakes always inflate the development time exponentially.

We can postulate all sorts of different explanations. I wasn't attempting to do that in my previous post. I was just relaying my own repeated observations that some programmers don't just write better code -- they manage to do it much faster too.

Do they think faster? I don't know. They just have a knack for programming. It's obvious to them which data structure to use, so they just use it.

Maybe it just comes down to this. If it's not obvious to someone which data structure to use and they have to spend a significant amount of time being confused about it, not only are they more likely to make the wrong choice, but they're likely to take longer too. Someone who, for whatever reason, has better intuition about how to structure a piece of code is going to be able to write it faster, not because they think or type faster, but because they just didn't even have to think as much in the first place. Consequently, I suppose that frees up mental space for thinking about the cleanliness of the code and other such factors.

Post reply on HN