Live data from Hacker News

The Programming Talent Myth (2015)

lwn.net

81–90 of 146 posts

Re: The Programming Talent Myth (2015)

#81

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.

Re: The Programming Talent Myth (2015)

#82
post #38

Earlier quoted context omitted.

Are you really equating company loyalty with high-mindedness here?

Well, yeah, that's what it means, right? If you pay me $50k per year and invest $20k of company resources to train me, and the second my training's up, I jump ship to a company promising to pay me $60k, wouldn't you feel ripped off? Nobody these days would turn down a $10k raise out of company loyalty. They might for other reasons, but loyalty is absolutely not one of them anymore.

The right thing to do is to start transitioning the $20k you were spending training the new guy into salary as he acquires the skills.

Its stupid to spend the $20k, figure its "done" and then think you can just go on paying the $50k after the fact even though the employee is clearly now worth $70k.

You want a $70k talent, you can either find one straight up or make one with some mix of lower salary + training until you have one.

Re: The Programming Talent Myth (2015)

#83

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.

You move a lot faster by memory. I regularly switch between Ruby, JavaScript, Python, and Scala at work and it's quite insane, I spend way too much time realizing language Y doesn't have feature X I use in language Z and looking it up vs rare moments of flow when I've been using the same language for more than a week or two.

Re: The Programming Talent Myth (2015)

#84

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…

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.

Re: The Programming Talent Myth (2015)

#86

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…

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

if you have to spend 15-20 minutes pulling out books and looking up commands/registers every hour, you lose a lot of productivity.

that was the reality of programming before the internet

Re: The Programming Talent Myth (2015)

#87

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.

When you memorize all the details of an instruction set, there is a qualitative difference when you code in it.

It's like the difference between being a stammering tourist in a foreign country who is constantly flipping through a dictionary to make elementary utterances, and a native speaker.

I first realized this many years ago after writing an emulator for the Motorola MC68010. Unrelated to that project, I had the occasion to write some assembly code in the same instruction set. Just, wow ...! It was like, I .. know ... everything ! (cue sound of thunder, lightning effect.)

Re: The Programming Talent Myth (2015)

#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 might hire some mediocre kid with the 3+ years experience and a history of guitar lessons, even though after a 100 days on the job, J.S. Bach would have been a mind blowing, mesmerizing guitar player, even if he was still a little clumsy. And after a few years, he'd be more amazing still. Yet as an industry, we focus the ability to be productive on day 10 instead of day 100 or 1000. For long term positions. Why?

How would the software industry conduct an interview for a musician? We'd ask you about all of the songs and instruments you've ever played and have you talk about those experiences. We might ask a hypothetical question about what if you had to play a certain piece, how would you handle it. Maybe we'd have you answer some trick questions: "What are the frequencies of the first five harmonic multiples of B right below middle C?"

I find this to be utter madness.

I think the best way to find a good (or potentially good) developer is to have them do what we do in our jobs, which is, given some vague requirements and some undefined period of time -- a few days or so -- write code to solve a simple problem.

And I loved the part in the article about mediocrity. I've found the best developers to be humble enough to constantly work on improving their craft. So, don't reject a candidate because they appear to "lack confidence".

Re: The Programming Talent Myth (2015)

#89

Earlier quoted context omitted.

An investment and risk go hand in hand.

Yes, but the difference between an investment and a bet involves the amount and type of risk. Investments generally don't disappear. Bets do. Also the expected rewards are higher too. If a company bets $20k in an employee, the best they can hope for is that the employee does a good job. Not that that bet doubles in value.

> If a company bets $20k in an employee, the best they can hope for is that the employee does a good job. Not that that bet doubles in value.

What do you think it means from the company's perspective to "do a good job"? A developer who does a good job will most likely double that $20k in a few months.

Re: The Programming Talent Myth (2015)

#90

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 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 hex codes for every 8051 instruction. This was necessary to be successful debugging using a logic analyzer. Looking up each op-code would be prohibitively slow.

Post reply on HN