The Programming Talent Myth (2015) • Hacker News Board

Re: The Programming Talent Myth (2015)

#131

Post by allthenews » Wed, Apr 11, 2018, 9:40 PM UTC

geezerjay wrote: post #84

allthenews wrote: post #77

Earlier quoted context omitted.

I don't think programming ability is measured by the number of APIs/libraries one has committed to memory.

Knowing APIs cuts down the time you take to implement something, and also helps you understand what and how you can achieve a goal. Between a guy who needs to spend 5minutes googling for a class/module/function and someone who prompltly writes it down, there is no question who is a more capable programmer.

While I do not deny that memorization of APIs makes for more efficient programming, I would argue that, long term, readability, maintainability, and extensibility are far more useful time savers overall. Architecting a codebase which meets standards like these requires a different set of experience that comes with time and can't be trivially looked up online.

If I were to measure a programmer's ability, I.e., what makes a "good programmer", perhaps in the context of am interview, I would therefore not test rote knowledge.

Re: The Programming Talent Myth (2015)

#132

Post by LyndsySimon » Wed, Apr 11, 2018, 10:17 PM UTC

sophacles wrote: post #103

EpicEng wrote: post #11

> > The truth is that programming isn't a passion or a talent, it is just a bunch of skills that can be learned. This may be true if your definition of programming is the literal act of writing code / recalling syntax, and learning new tools. Of course, that's not really what programming is. That's the easy part. Programming is about problem solving, code is simply the tool. Critical thinking/problem solving ability,…

I put emphasis on tools because I've worked with a lot of recent graduates. There's the very real, practical problem of knowing what not to solve. I don't care if you're a genius or not, you're wasting time recreating (poorly) components that already exist in the standard library. Similarly if someone is doing blatantly bad-practice things because "its just implementation details" (stuff like hardcoded paths to /home…

> Similarly if someone is doing blatantly bad-practice things because "its just implementation details" (stuff like hardcoded paths to /home/username) it causes a bunch of extra effort to clean up the monstrosity.

Agreed. There's definitely a balance point there - I remember when I got to the point that I not only recognized that this a bad idea, but where they actively started bothering me even for one-off scripts. Something as simple as setting them as constants at the top of the script makes that feeling mostly go away and requires almost no extra effort when implementing.

There are many times when I think "This is really brittle. Surely there's a better way to do it...", which is usually quickly followed by "I'll figure out that better way later, for now, just isolate it and make a note to fix it when this is done."

Re: The Programming Talent Myth (2015)

#133

Post by dlwdlw » Wed, Apr 11, 2018, 10:21 PM UTC

pmcollins wrote: post #88

Lately, I've started thinking of programming as an art form. If you substitute programming with music, how would you make all of these evaluations about the craft and of its practicioners? You may be hiring for guitarist and require at least 3 years experience playing the guitar. J.S. Bach applies, but has never played the guitar. As an industry, we typically wouldn't hire him due to lack of experience. Instead we mi…

Reason may be similar to why artists and musicians typically don't make money. Money/power isn't that interesting. So the people who end up becoming the gatekeepers are those who can't see real talent and those with real talent think that those who are in it for the money aren't "real" enough.

The good but not greats are often really good at specific areas not necessarily tied to business concerns. The "greats" spend so much time on it that they end up really good at a bunch of things.

From a business perspective where output needs to be measurable/controllable you want someone either malleable enough to work on any kind of crap, or someone Soo good they can be good at anything.

The really good CSS person, the SVG animator, the functional JS guy will all be passed in favor of the malleable new grad or the industry expert. The only way is if these individuals market themselves and create a new domain of expertise by giving talks or writing books. The value is appreciated by the environment but not companies.

Re: The Programming Talent Myth (2015)

#134

Post by LyndsySimon » Wed, Apr 11, 2018, 10:35 PM UTC

lazyasciiart wrote: post #60

vinceguidry wrote: post #2

While on the surface of it, sure, programming is a skill and not an innate talent, it would be foolish to compare it to other career fields in that way. You can go to school to learn how to be an architect, then go and get a job as an architect and be immediately productive. You can go to school to learn how to lay bricks, then go to a job site and immediately start building something. You cannot go to school to lear…

> You can go to school to learn how to be an architect, then go and get a job as an architect and be immediately productive. You can go to school to learn how to lay bricks, then go to a job site and immediately start building something. Do you actually know anyone who's worked in these fields? Because that's not true. Wanna be an architect? Go to school + get 2 years of experience + take a professional certification…

I've never laid brick, but I've been an electrician. Tradesmen are almost never working independently, and certainly not when they are working in a junior position. There's a lot of mentorship that goes on, and a lot of tribal knowledge that's shared - things that are simply not written about.

When I started as an electrician, I knew a lot about electricity already. I've always been a bit of a nerd and knew more about how electricity actually works than many journeymen I met. I knew almost nothing about how to actually put that into practice, though.

For example - when wiring an electrical outlet, you have to wrap the end of the wire around a small screw. It's obvious enough that if you do it clockwise tightening the screw holds the wire in place; if you do it counterclockwise, tightening the screw moves the wire and makes life difficult. What wasn't obvious was that instead of taking a pair of needle-nosed pliers and bending the wire to the right shape, there was a small hole in each side of a pair of wire strippers that was exactly the right size to do it: http://www.kleintools.com/sites/all/product_assets/catalog_i...

Had the person I was working for not shown me that, I would have probably never figured it out.

I think the role of a junior developer is very similar to that of an apprentice electrician, in that the dev knows at least enough to implement something on their own so long as they are given concrete tasks. A mid-level dev is similar to the journeyman; they take a partially-defined task, break it into well-defined chunks, and either implement or delegate. A senior dev is the master electrician - they decide what tools to use, make the larger-scope decisions on a project, etc.

This analogy breaks down once we start talking about software "engineers" or "architects". I can't really think of anything I saw in the trades that maps to it; it's more about identifying and anticipating important changes over time and mitigating their costs.

Re: The Programming Talent Myth (2015)

#135

Post by Zimahl » Wed, Apr 11, 2018, 11:28 PM UTC

humanrebar wrote: post #111

vinceguidry wrote: post #75

Earlier quoted context omitted.

Nobody's going to accept indentures in this day and age.

Pro athletes, medical residents, and certain teachers seem OK with it. College professors can't exactly take their tenure with them.

Pro athletes ... seem OK with it.

Pro athletes are a terrible example. There has been decades of litigation, lockouts, negotiations, etc. across almost all leagues to get to where we are now and there are many that continue to think the system is too restrictive for the players and too much in a league's favor.

Re: The Programming Talent Myth (2015)

#136

Post by Zimahl » Wed, Apr 11, 2018, 11:40 PM UTC

draw_down wrote: post #62

I understand why it's important to emphasize that programming skills can be learned and that we aren't just a bunch of god-given talents. But how far are we going to take this? Surely we can admit that for any given set of skills some people are going to take to it more readily than others, and we can't account for the difference simply in terms of amount of practice or hard work. The top mathematicians or violin pla…

I think his point was that there's a bell curve and chasing this idea that there is a load of top talent is absurd. There obviously are really great, amazing developers out there, but there are magnitudes more 'mediocre' developers that can still accomplish some really great, amazing products.

Re: The Programming Talent Myth (2015)

#137

Post by HillaryBriss » Thu, Apr 12, 2018, 12:40 AM UTC

vinceguidry wrote: post #64

HillaryBriss wrote: post #46

Earlier quoted context omitted.

all investments carry risks. e.g. if a company invests in a building for their office, there's always a risk that building will incur excessive maintenance expenses, become unusable because of some calamity, or that the location around the building will become a bad neighborhood and make that building a lot less useful. i think a company can invest in, say, teaching their employees a valuable skill and then make mone…

You can insure against risks. You can't against bets. Good luck getting an insurance company to sell you a policy covering training cost recovery in the event of employee-initiated turnover.

i feel like we're playing word games. "risk" vs. "bet."

the distinction you raise is that there (apparently) is no such thing as an insurance policy that protects a company against a valuable employee's departure.

but that doesn't mean "invest" is the wrong word to use when a company spends money to educate an employee.

also, there are strategies aside from a literal insurance policy which companies can and do use to increase employee retention rates. (just like there are strategies other than insurance policies that companies can use to protect a building against damage or loss of value.)

Re: The Programming Talent Myth (2015)

#138

Post by YeGoblynQueenne » Thu, Apr 12, 2018, 1:01 AM UTC

btilly wrote: post #33

BurritoAlPastor wrote: post #17

Earlier quoted context omitted.

Do you mean to say that being able to think in abstractions or keep a lot of state knowledge in short-term memory are skills that cannot be learned? So where did we acquire these skills, if not by learning?

Your calling them "skills" prejudices the answer. My best understanding is that they aren't skills, they are hardwired abilities. My best guess based on research that I've seen on IQ is that about half of the hardwiring is genetic and half is a result of childhood upbringing, but by adulthood they are not readily changed. That said, we build concrete skills around how to make the best use of those abilities. We build…

>> My best understanding is that they aren't skills, they are hardwired abilities.

And isn't it the most amazing coincidence that those who are thus exceptionally gifted are uniquely placed to benefit from the demand for those very abilities in an extravagantly lucrative profession?

I mean, imagine what would happen if everyone could program! Where would those six-figure salaries go then?

Re: The Programming Talent Myth (2015)

#139

Post by YeGoblynQueenne » Thu, Apr 12, 2018, 1:10 AM UTC

btilly wrote: post #104

itamarst wrote: post #61

Earlier quoted context omitted.

> several who have taught CS for decades tell me that most students simply can't "get" pointer arithmetic or recursion Or maybe they're just bad teachers.

Or maybe they're just bad teachers. Maybe so, maybe not. However I never had trouble when they tried to teach me things. And have heard good things from others who they taught. One of the people who expressed this basic opinion to me is https://www.amazon.com/Randal-Schwartz/e/B000APA744 . He is also someone whose expository abilities are widely recognized as being excellent. And he is also an example of a self-taugh…

To be fair, "bad teachers" is the simplest explanation. The alternative is to go chasing intricate definitions of exceptional intelligence and long-tailed aptitude disributions that take hella lot of explaining.

Re: The Programming Talent Myth (2015)

#140

Post by YeGoblynQueenne » Thu, Apr 12, 2018, 1:20 AM UTC

EpicEng wrote: post #15

itamarst wrote: post #14

Earlier quoted context omitted.

Critical thinking, logic, empathy, etc. are all skills one can learn . And that's the point.

Eh, I'm not convinced of that. I don't think you can take any person and teach them to think through problems logically. It seems simple enough, and you can certainly make them _better_ at it, but I really do believe we all have upper limits on our potential.

>> I don't think you can take any person and teach them to think through problems logically.

That's actually the whole point of scientific training: teaching people to use the tools of science, including thinking logically and avoiding sources of bias and so on.

If you want to go back into antiquity, the ancient Greeks who started the whole Logic thing, Socrates, Plato, Aristotle et al, they never presented logic as some kind of innate ability of human beings, rather they set out to teach it as an instrument of thought that was far from innate. Because if it was innate, it wouldn't need all that work they put into it.