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

331–340 of 354 posts

Re: The programming talent myth

#331

Post by sokoloff »

webnrrd2k wrote: post #309
seabee wrote: post #244

Earlier quoted context omitted.

Unless I misunderstand your point, how do you create complex data without complex code? I agree with the sentiment, but priority queues don't organise themselves. It seems more like its about the abstractions you use.

It's more of a general rule, a rule of thumb, and the difference between data and code can be very fluid, depending on the situation... But as a general rule it's worth paying attention to. Just a quick example -- I need to get going -- Say I have a bunch of data in a database I need to do something to once or twice, like validating imported data. It's easier to use a complex select to get it in an easy to process fo…

I agree with your choice in the example, but I think of your select as code, not as data. So, you're moving the complex code closer to the data, but it's still code IMO.

Re: The programming talent myth

#332

Post by sokoloff »

lolatu54 wrote: post #215
vonmoltke wrote: post #25

Earlier quoted context omitted.

> Look at fizzbuzz as an obvious, if not entirely complete, example. I am not entirely convinced this is not partially a resume screening and talent pipeline problem. Has anyone ever given Fizzbuzz problems to everyone who applied to a position? If you haven't, have you ever considered that your screening process may be broken in the sense that you are passing too many liars who then bomb the Fizzbuzz portion, but wh…

We give fizzbuzz style tests to all our candidates. Most fail, but it's not an indicator of experience at all. Some of the quickest to pass just got out of GA and never worked in the industry before. It really tests aptitude at a specific type of problem. Because of this it does not make or break the interview. We also look at their portfolio/code samples as well. After interviewing many candidates I've found the one…

> Because of this it does not make or break the interview.

You mean that you continue the interview process for a coding position with someone who failed FizzBuzz algorithmically/structurally (not for a trivial syntax error)?

At a prior game company we gave what I felt was a FizzBuzz-level task on paper: in C, given a string of characters representing a hex number, return the long it represents. (basically, write strtol(input, NULL, 16); without using strtol)

I was appalled at the number of people who couldn't come close (not subtle bugs or mis-handling case issues, but rather: show someone else their code and have that person guess what function the person was trying to write).

When the Fizzbuzz blog post(s) came out, representing a much simpler problem, I couldn't believe that someone would bother to shower and leave the house to interview for a programming position and be unable to do Fizzbuzz. So I gave Fizzbuzz to a few candidates, often in a joking sort of way (so as to not offend any qualified candidates). Results were predictably shocking and dismaying. It's a problem simple enough that you either can do it or not; there's precious little middle ground. (As other posters mention, these are the people that interview over and over, so hopefully the actual employed population of programmers is overwhelmingly able to do it.)

Re: The programming talent myth

#333

Post by mannykannot »

vectorpush wrote: post #95
platz wrote: post #79

"Formal logical proofs, and therefore programs – formal logical proofs that particular computations are possible, expressed in a formal system called a programming language – are utterly meaningless. To write a computer program you have to come to terms with this, to accept that whatever you might want the program to mean, the machine will blindly follow its meaningless rules and come to some meaningless conclusion.…

The findings of this study have been formally retracted by the author. http://www.eis.mdx.ac.uk/staffpages/r_bornat/papers/camel_hu...

I see that section 4 contains a reference to another study offering an alternative explanation for the 'double hump': if a teacher sets the pace by the progress of the fastest learners, you can end up with a group that kept up and a group that was left behind early and so never learned much. I guess this is more likely to happen if you have several students, rather than one or two at most, who already have had some exposure to the material, and that this is more likely in programming than in, for example, actuarial mathematics.

Re: The programming talent myth

#334

Post by zimpenfish »

lolatu54 wrote: post #190
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…

I agree with you. This article is incredibly, just woefully dead wrong. I have interviewed hundreds of programming candidates. Reviewed thousands of lines of code. Programming is an aptitude that requires passion. The only programmers who are good are the ones who love to do it. If you don't enjoy it, find another profession. Because all the things he said aren't true are. If you don't want to be constantly learning…

I don't stay current (fads fade and I've seen too many to care); I have little passion for programming after 20 years; and yet I'm still hired with high contract rates to help people out of development holes.

The plural of anecdote, however, is still not data.

Re: The programming talent myth

#335

Post by cafard »

JoeAltmaier wrote: post #283
cafard wrote: post #281

Earlier quoted context omitted.

I have programming dreams from time to time. But I'm not sure that "programmer" is the first word I'd find for somebody dreaming about debugging his children.

I think its a good word for somebody that has a head so full of programming, that it leaks over into other parts of their thinking. Like musicians that see a rainstorm and think of music.

That was too snide of me. But I would be slightly troubled to have such a dream, though as I say I do have programming dreams from time to time.

Re: The programming talent myth

#336

Post by crucini »

Kalium wrote: post #123
shubb wrote: post #71

Earlier quoted context omitted.

I find this idea that there are lots of fake programmers kind of nuts. Presumably, when you do a resume sift, you look for people with either a qualification or work experience. Either they somehow faked it through those, or your test is bad. Fizzbuzz actually tests if you know what % does. Is that critical knowledge for a webdev?

> I find this idea that there are lots of fake programmers kind of nuts. I don't know about "lots", but there are definitely people out there who claim to be programmers but lack the basic competencies they claim. I've encountered several. A couple of years ago, I was part of a battery of interviews for a candidate who claimed a Master's in CS. Their resume said they had done advanced work in parallelization of video…

To be fair, they are kind of separate problems. In Clojure, for instance, you can write parallel code and the nuts and bolts are handled for you.

Re: The programming talent myth

#337

Post by zenogais »

collyw wrote: post #328
zenogais wrote: post #225

Earlier quoted context omitted.

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.

Any chance of a two line summary or something similar?

There are two common theories on greatness - (1) it results from hard work (2) it results from natural talent. Both are wrong. Multiple studies show that high degrees of skill are the result of deliberate practice, and that its results eventually override either hard work on natural talent. Much of the book is taken up defining what "deliberate practice" is and how you can achieve it.

Re: The programming talent myth

#338

Post by derekp7 »

rpcope1 wrote: post #316
xkjkls wrote: post #307

Earlier quoted context omitted.

I sometimes see the amount programmers believe they're supposed to enjoy their job as unique to programming. People always talk about pursuing coding projects just for the fun of it outside of work, but that's a pretty unusual trait for other forms of engineering. My father has a PhD in Chemical Engineering and has been doing crude assay work for the last twenty years. He obviously enjoys and gets fulfillment out of…

You know it's funny I agree. When I was working as an EE no one ever gave me trouble because I wasn't building circuits or filters or doing RF design at home and because I didn't want to think about it when I got home. I keep seeing this attitude in the software engineering sphere that you have to totally embrace it and have all sorts of side projects and it's encouraged to more or less dominate your life; I can't im…

I think this is because a lot of computer work isn't just engineering (although there is a large amount of that mindset involved), but it is a mix of engineering and art. One thing to compare it to is woodworking. Many people who are good at it will go into something like cabinet making, but they will still have a lot of personal woodworking tools in their garage. There is something about creating something that, even if the process itself isn't really enjoyable, the final result is.

Re: The programming talent myth

#339

Post by cbd1984 »

JoeAltmaier wrote: post #250
SNvD7vEJ wrote: post #248

Earlier quoted context omitted.

"He wrote them like math formulas, and didn't understand that they got executed in order." So he had a talent for functional programming, then?

Cute, but not quite. Those are still executed in some order. Not like algebra which is a set of expressions that are all true over all time.

Functional means that sequence doesn't matter. Haskell is functional, Lisp largely isn't.

Re: The programming talent myth

#340

Post by Kalium »

crucini wrote: post #336
Kalium wrote: post #123

Earlier quoted context omitted.

> I find this idea that there are lots of fake programmers kind of nuts. I don't know about "lots", but there are definitely people out there who claim to be programmers but lack the basic competencies they claim. I've encountered several. A couple of years ago, I was part of a battery of interviews for a candidate who claimed a Master's in CS. Their resume said they had done advanced work in parallelization of video…

To be fair, they are kind of separate problems. In Clojure, for instance, you can write parallel code and the nuts and bolts are handled for you.

With the tools this person claimed to have used, they very much would have handled all the nuts and bolts.
Post reply on HN