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

The Programming Talent Myth (2015)

lwn.net

Post reply on HN
Print view View original

91–100 of 146 posts

Re: The Programming Talent Myth (2015)

#91

Post by dajohnson89 »

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…

will you pay me for those 3 days' work? and tbh it's not even the money, it's my non-existent time.

Re: The Programming Talent Myth (2015)

#92

Post by EthanHeilman »

buvanshak wrote: post #81
thoughtsimple wrote: post #71

I used to be a "rock star" programmer. I could run rings around my coworkers. I wrote an embedded OS for running machine tools (I had help.) Back then, you read books and memorized everything. I knew x86 assembly and could use a logic analyzer to debug my code. This was in the 80's. Now the amount of knowledge required to do even mundane tasks is an order of magnitude more. No one can memorize all the APIs and framew…

>you read books and memorized everything. Why did you have to memorize everything? I have also done x86 assembly. You remember what you can. You look up the rest. Same today.

If you memorize it you don't have to context switch when you look it up. The benefits of memorization are enormous if it reduces your the number of times you have look up details to zero. It's similar to touch typing vs hunt and peck typing with the following exceptions:

1. context switches are much more expensive than looking at a keyboard to find the key to press,

2. memorization enables you have a more complete mental model which greatly speeds up design, reduces bugs and enables you to find bugs faster.

3. you gain surprising insights if you can run the program in your head when you are falling asleep, in the shower or walking around.

When I am doing cryptanalysis the first thing I do is commit the protocol to memory. Sadly if I'm not working on it 24-7 I quickly forget and have to rememorize.

Re: The Programming Talent Myth (2015)

#93

Post by cchubitunes »

itamarst wrote: post #61
btilly wrote: post #33

Earlier quoted context omitted.

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…

> 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.

For those of us who didn't grow up coding at age 7, this is golden!!!! The amount of terrible CS teachers out there would amaze you!! I mean "blow your mind away" amaze you. I almost gave up CS because of my absolutely terrible professors. I couldn't even understand simple Classes and object!!! It was that bad!!!

Luckily, since I really wanted to learn, I had to seek alternate resources. I was fortunate to stumble on Stanford's Cs106a taught by Mehran Sahami and it changed my life forever. That man is the gold standard for what a teacher should be. He broke down complex ideas and made them look so simple.

Since then, I use a combination of different resources to learn said "difficult concepts". Recursion, got it...pointers, got it too. I have used Standford courses, Berkeley course, udemy, Udacity, Coursera and even youtube to learn. These sites have some really good teachers.

I have since come to understand that CS is really not that difficult. All is takes is a willingness to learn and a good resource to learn from.

Re: The Programming Talent Myth (2015)

#94

Post by seanmcdirmid »

vinceguidry wrote: post #78
seanmcdirmid wrote: post #74

Earlier quoted context omitted.

Investments are bets. You can totally insure your bets, the term “hedge your bets” exists for a reason. You seem to be equating bets with gambling for some reason.

Self-insurance against the risk of employee defections costing them time and money is exactly what employers are already doing, by not taking on the risk of educating and training employees .

You can hedge your bets in many different ways with different assumptions for likely outcomes. For example, if you think it likely that your employee won’t hang around for very long, then you can act by treating them as disposable. You could also choose to mitigate the risk of them leaving if you thought you could be successful at it. Both approaches are forms of self insurance, none of them are full proof, and they can also lead to self fulfilling prophecy problems.

Re: The Programming Talent Myth (2015)

#95

Post by pmcollins »

dajohnson89 wrote: post #91
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…

will you pay me for those 3 days' work? and tbh it's not even the money, it's my non-existent time.

No, but I will let you put what you created on GitHub. That becomes part of your portfolio. Put a link to your GitHub account on your resume.

If you already have enough sample code, there may not be a need to provide more.

Re: The Programming Talent Myth (2015)

#96

Post by aidenn0 »

Pigo wrote: post #24
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 do believe these skills can be learned, but it's the enjoyment I derive from these things that I believe is the difference between some people and I. When I was in junior high I would do various logic problems for fun. I asked for nothing but a TI-85 for my birthday one year. There probably are people who are better than me at coding who hate the work. But I've hated every job I had until someone started paying me…

After (as an adult) watching kids develop, there is a huge positive feedback loop for various abilities.

When you are slightly better or faster or just find doing it (whatever "it" is) more rewarding compared to your peers, then it takes lower effort to get the same reward. This means you are more likely to spend more time doing it. This means that after a while you have more practice than your peers, so the difference in ability is amplified. Now various grownups around you notice and complement you on it, get you lessons to do it better, provide you with supplies, &c. and the difference grows.

By the time you are looking at teenagers, it's hard to tell how much of the difference stems from natural ability, and how much of it is this snowball effect.

Re: The Programming Talent Myth (2015)

#97

Post by maerF0x0 »

> The US Bureau of Labor Statistics estimates that by 2020 there will be a 1.5 million programming job gap

This makes me wonder 2 things

1) Why are we debating if we should keep the ~500k H1B visa holders around (of course we should) and

2) Why don't we just train the top 10% (in ability + willingness) of the ~13M unemployed people in this country?

Re: The Programming Talent Myth (2015)

#98

Post by AnIdiotOnTheNet »

thoughtsimple wrote: post #90
buvanshak wrote: post #81

Earlier quoted context omitted.

>you read books and memorized everything. Why did you have to memorize everything? I have also done x86 assembly. You remember what you can. You look up the rest. Same today.

If you didn't develop in that timeframe you might not get the difference between then and today. It takes forever to look things up so you end up memorizing instead. And it isn't a big deal because the number of things needed to be a successful software developer wasn't that great. To be successful and finish projects more or less on time, memorization was needed. Edit: For example, for a different project I knew the…

It's a caching problem. If memory access is slow you want to cache more, if not then you don't bother. Things you use a lot will spend more time in the cache, things you don't you'll have to keep retrieving from memory.

We really aren't as different from computers as we sometimes like to believe.

Re: The Programming Talent Myth (2015)

#100

Post by dpweb »

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,…

Better also to not just grasp but live on concepts like opportunity cost and technical debt. You are Not adding value making the wrong choices in these areas, nevermind your ability to type code.
Post reply on HN