21 ms·

The Programming Talent Myth (2015)

98 points by vanni 8y ago

adam-a 8y ago
I think this is absolutely spot on. So many people put their programming expertise or productivity down to some innate quality (that is apparently overabundant in white men). To me it seems nearly every one of those rockstar ninjas has also spent an enormous amount of time learning their trade - usually a lot of time outside of formal school or a 9-5 job. I think if there's one skill that might be innate and that helps people be better at programming, it's patience. Learning to program and learning programming tools is for most people a boring and extremely frustrating task. You need patience to stick with it after spending two days solid trying to debug some linker error or CSS bug or whatever esoteric programming issue you inevitably have to deal with.
- toasterlovin 8y ago
  Yeah, but people also tend to spend time on things they're good at. Is programming solely about innate skill? No, of course not. There's a reason why the distinction between senior and junior developers exists. But are you going to put the time in necessary to develop into a senior developer if programming feels like mental torture?
- neogodless 8y ago
  I agree with you, but even patience can be learned! (You can train it, practice it yourself, and improve your ability to persevere.)
- Will_Parker 8y ago
  > So many people put their programming expertise or productivity down to some innate quality Yes. Some people (both as kids and adults) seem to be innately interested in different kinds of activities. And it is perhaps impossible to separate talent with passionate interest since B leads to A. Take the kids from my tribe, extremely passionate about patterns and things and systems and numbers and coding from early childhood, _despite_ concern from parents and teachers, social ostracization, and efforts to limit computer time. We also tend to acquire talent.
vinceguidry 8y ago
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 learn how to be a programmer, and then expect immediately to be productive at any arbitrary programming job, unless you're a talented coder. The education gap is too great. It's like medicine in which you need a few years of residency before the medical field considers you fully competent. If you go to code school and learn Rails and React, then you can expect to be somewhat immediately productive on a Rails / React project. You can't expect anything out of them if it's not a Rails / React project. They may be able to ramp up quickly, if they're talented. If they're not talented, then they won't be able to, and the employer has to take the hit. We will need a revolution in software development pedagogy before individual aptitude stops mattering to employers. The state of education at the moment is so bad that unschooled yet talented individuals can be much much better at fulfilling business requirements than trained and educated professionals. Try that with medicine!
- itamarst 8y ago
  Or, employers will start taking the long view and actually start investing in their employees.
  - vinceguidry 8y ago
    That's not an investment, that's giving your money away. Would you spend $X0,000 on something that can walk out the door at any moment?
    - sidlls 8y ago
      Did you ever consider that the employee might be a smidge less likely to walk out the door if the employer invested in him or her, recognized his or her achievements in a timely manner with responsibility and authority (promotion) and compensated him or her fairly? Seems to me employees "are likely to walk out the door" mainly because employers view them as expendible expenses and not humans trading labor for something of value
itamarst 8y ago
If our starting point is that programming is mostly about skills, productivity starts getting interesting - what does productivity mean? My personal take is that it means solving problems with less wasted effort. Less code (a 0.1× programmer can solve problem with 10% of the code - https://codewithoutrules.com/2016/08/25/the-01x-programmer/ https://codewithoutrules.com/2016/08/25/the-01x-programmer/), but also by solving the right problem, and coming up with better solutions (https://codewithoutrules.com/2017/10/04/technical-skills-productive/ https://codewithoutrules.com/2017/10/04/technical-skills-pro...). These are all skills you can learn. And I think focusing on learning technologies obscures a lot of these skills, since they're about communication and listening and project management. For productivity in terms of technological knowledge I'm starting to think that, since choosing which tool is more important than how to use it, a better way to get better is to study case studies. Instead of trying to learn "how can I use Mongo, how can I use PostgreSQL" you try to learn "when should I use Mongo, when should I use PostgreSQL". I'd love to hear about good sources of case studies. http://www.aosabook.org/en/index.html http://www.aosabook.org/en/index.html is good, but doesn't cover kind of programming one would do at a company, much.
- iamcasen 8y ago
  This is exactly correct. In the past, I didn't consider myself an excellent programmer, because I struggled to solve esoteric number permutation problems and recursive graph search problems during whiteboard interviews. It seemed to me that all my peers could do it, and they were getting good jobs for it. Over time I learned that the real value comes from solving the right problems, and recognizing wasted effort. It comes from architecting systems that are easily maintainable. That's what makes money in the business. Solving narrow, intensely interesting algorithms, is a rare case that is not widely needed in the industry at large.
humanrebar 8y ago
> The truth is that programming isn't a passion or a talent, it is just a bunch of skills that can be learned. Aren't these all talents? * learning many things * learning difficult things * recalling things you've learned when you need them If something is a skill, one would expect all engineers to get better at it with practice. But there are many abilities in engineers that don't seem to work that way.
- muzani 8y ago
  They're definitely learnable skills. The thing I find with engineering is that most skills remain untrained with experience. If years of experience meant you'd be better at a skill, then older would be able to reverse park very quickly. But without deliberate training, most skills don't improve.
- itamarst 8y ago
  Learning is a skill you can get better at, so it's just a dependency. Learning is not an unchangeable talent. Some books that will help you learn better: * Power of Intuition, about naturalistic decision making - https://www.amazon.com/Power-Intuition-Feelings-Better-Decisions/dp/0385502893/ https://www.amazon.com/Power-Intuition-Feelings-Better-Decis... * How Learning Works - https://www.amazon.com/How-Learning-Works-Research-Based-Principles/dp/0470484101 https://www.amazon.com/How-Learning-Works-Research-Based-Pri... (my review: https://codewithoutrules.com/2016/03/19/how-learning-works/ https://codewithoutrules.com/2016/03/19/how-learning-works/) No doubt others can recommend more books.
  - toasterlovin 8y ago
    Wether or not a trait is mutable is different from the degree to which that trait is mutable. The distinction is important. Most breeds of dog can be trained to learn some simple commands, but good luck getting some mutt from the pound to herd sheep like a border collie. Here's a video of border collies in action: https://www.youtube.com/watch?v=bpjP3mxv21s https://www.youtube.com/watch?v=bpjP3mxv21s
  - walshemj 8y ago
EpicEng 8y ago
> > 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, the ability to think in abstractions, the ability to hold a large amount of information in your head all at once, etc. are all skills, and not skills that the majority of people are particularly good at. We wouldn't judge a carpenter on e.g. his/her ability to use a saw, or a EE on their ability to use a scope. I never understood why so many put so much emphasis on the tools a software dev knows.
- sophacles 8y ago
  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/username) it causes a bunch of extra effort to clean up the monstrosity. That's not to say problem solving is not extremely important, but the time suck created by bad tool use (or not using tools out of ignorance of their existence) ultimately reduces the productivity of a programmer, or in some cases, whole teams.
  - LyndsySimon 8y ago
    > 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."
mnglkhn2 8y ago
If you believe programming is not a talent then you won't complain when your pay is not structured the same way that talent pay is.
mistrial9 8y ago
"programming" is not one thing.. most comments here fail to make even a basic distinction between [ php forms developers; dev-ops Go pipeline builders; game developers; domain-specific problem solvers] or other. Include in any of those categories varying, more or less GUI design, more or less quality, more or less efficient execution, more or less language mastery, more or less elegant design. Fish apparently are not good at describing water (!)
ionised 8y ago
The only thing stopping someone becoming a programmer is a genuine interest in the craft. People generally don't get good at things they find boring. We software developers are not special. We don't have something that non-programmers lack, apart from maybe an inflated sense of self-worth.
weirdmantis 8y ago
It's like drawing. Sure maybe with a lot of effort anybody could draw a close approximation of a good drawing but unless you are innately talented and driven you will never be at a good enough level to make a great career at it.
jasode 8y ago
The 2 sides debating "talent" are always talking about 2 different things. (#1) "talent" doesn't exist: knowledge and skills can be learned. No infant comes out of the womb knowing 5 languages or physics equations or the syntax of "printf("hello world")". Every single human who knows how to do something well at one point in their life did not know how to do it well. If one can improve by learning, it means talent doesn't exist. This aligns with Carol Dweck's "growth mindset", the 10000 hours meme, self-improvement, etc. This internal perspective compares oneself at time_before vs time_after. (#2) "talent" is a subjective ranking of people's abilities: there are people who are noticeably better at expressing their skills. E.g. NBA basketball player Shaq O'Neal has spent more than 10,000 hours practicing free throws with a dozen different coaches to achieve 52% success, but there's a high school kid that can sink them at 80%. We can say the kid is "more talented" at free throws. To say that "free throws" is a "learnable skill" doesn't change anything about noticing the obvious difference in abilities. If Person A learns faster than Person B, that in itself is a talent. This external perspective compares people against other people. People who hold meaning #1 vs people thinking of meaning #2 are having 2 different conversations. E.g. when companies say "they are looking to hire the most talented" (meaning #2), they are not talking about people who can self-improve (meaning #1). In this essay, Jacob Kaplan-Moss is talking about meaning #1. Yes, you can read it and take all his advice to heart. However, you still have to understand meaning #2 to properly decode what others are talking about when sports teams, music record labels, Hollywood, venture capitalists, and startups all say they are "looking for the best talent".
jbellis 8y ago
I guess "programming talent is a normal distribution, not a U distribution" doesn't make for as catchy a headline.
d0lph 8y ago
I don't want to be mean but it looks like programming is both: Talent: 1. natural aptitude or skill. Passion: 2. strong and barely controllable emotion. ... * an intense desire or enthusiasm for something. ...
- humanrebar 8y ago
  Couldn't passion be innate as well? If you hate cilantro, you certainly won't have a talent for eating cilantro. (Also, passion in this context doesn't imply any sort of lack of control. You don't program in the "throes of passion".)
  - d0lph 8y ago
    I've skipped meals programming, when things are interesting at least.
draw_down 8y ago
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 players or whatever in the world probably do work harder than others in their field, but that's not the same as saying that the difference between them and others is simply the amount of work/practice.
- Zimahl 8y ago
  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.
pixelperfect 8y ago
Does anyone else disagree with this article? There is talent for programming, and that talent is correlated with IQ. A person with average or below average IQ is very unlikely to excel as a programmer. There is a lot of academic literature to back this up.
- humanrebar 8y ago
  I think innate intelligence (whether measured by IQ or more qualitatively) is a real thing. I think people implicitly live that way and organize society that way. I also think it's also considered a faux pas to actually say as much. People tie respect, identity, and self worth into intelligence a lot. It's hard to say Kimberly is smarter than David without offending people. Let alone to say engineers are generally smarter than elevator operators (to pick a mostly extinct job). To some degree, all the interview hazing and discussion about "programming talent" is all dancing around the West's inability to discuss intelligence quantitatively and dispassionately. To be fair, historically there has been a lot of sexism, racism, bigotry, and pseudoscience tied up in the science of intelligence. I'm not sure how to get society to re-approach the subject in a scientific, productive, and beneficial way.
thoughtsimple 8y ago
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 frameworks needed to do their jobs programming. I couldn't work without search. I don't memorize anything anymore. I work on dozens of different technologies. Basically, I've become a mediocre programmer at a large number of different programming tasks where once I was expert at a very few. I'm the same person but the meaning of what is a programmer has changed over time. I'm OK with that.
- allthenews 8y ago
  I don't think programming ability is measured by the number of APIs/libraries one has committed to memory.
  - kazinator 8y ago
    Having an accurate and large knowledge of relevant API's will help you program faster and more accurately, and make better design decisions earlier. (You avoid the "if I had known about these API's, I'd have done it differently" situation.) It's hard not to conclude that this is one axis in the multi-dimensional "ability" space.
  - geezerjay 8y ago
    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.
    - allthenews 8y ago
      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.
Adamantcheese 8y ago
All I'm seeing here is that regardless of actual dictionary definition I still won't be hired because of some vague opinionated definition in someone's head.
pmcollins 8y ago
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".
- dajohnson89 8y ago
  will you pay me for those 3 days' work? and tbh it's not even the money, it's my non-existent time.
  - pmcollins 8y ago
    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.
    - 8y ago
maerF0x0 8y ago
> 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?
- humanrebar 8y ago
  a. There isn't really a gap. Employers are just slow to adjust to market rates for quality engineers. b. If engineer salaries went up to the market clearing rate, certain business models that assume certain labor costs will become flawed c. Who is going to pay for the training, especially in the case that all the training doesn't actually end up making the candidate any good at the job?
israelsonbj 8y ago
Why do computer science curriculums yield such a common thought toxicity? How can they engage greater diversity and cultivate empathy, compassion, and give students perspective to self-evaluate themselves?
foreigner 8y ago
The sentiments in this article are all very nice and progressive, but... have you ever actually tried to interview people for a programming job? The simple fact is that lots of people, perhaps most people who apply for jobs as programmers, are completely helpless. They couldn't code their way out of a paper bag. It's actually really depressing interviewing them, because you want them to be successful and yet most of them fail miserably at the most basic things.

98 points by vanni 8y ago

I think this is absolutely spot on. So many people put their programming expertise or productivity down to some innate quality (that is apparently overabundant in white men). To me it seems nearly every one of those rockstar ninjas has also spent an enormous amount of time learning their trade - usually a lot of time outside of formal school or a 9-5 job. I think if there's one skill that might be innate and that helps people be better at programming, it's patience. Learning to program and learning programming tools is for most people a boring and extremely frustrating task. You need patience to stick with it after spending two days solid trying to debug some linker error or CSS bug or whatever esoteric programming issue you inevitably have to deal with.

toasterlovin 8y ago
Yeah, but people also tend to spend time on things they're good at. Is programming solely about innate skill? No, of course not. There's a reason why the distinction between senior and junior developers exists. But are you going to put the time in necessary to develop into a senior developer if programming feels like mental torture?
neogodless 8y ago
I agree with you, but even patience can be learned! (You can train it, practice it yourself, and improve your ability to persevere.)
Will_Parker 8y ago
> So many people put their programming expertise or productivity down to some innate quality Yes. Some people (both as kids and adults) seem to be innately interested in different kinds of activities. And it is perhaps impossible to separate talent with passionate interest since B leads to A. Take the kids from my tribe, extremely passionate about patterns and things and systems and numbers and coding from early childhood, _despite_ concern from parents and teachers, social ostracization, and efforts to limit computer time. We also tend to acquire talent.

vinceguidry 8y ago

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 learn how to be a programmer, and then expect immediately to be productive at any arbitrary programming job, unless you're a talented coder. The education gap is too great. It's like medicine in which you need a few years of residency before the medical field considers you fully competent. If you go to code school and learn Rails and React, then you can expect to be somewhat immediately productive on a Rails / React project. You can't expect anything out of them if it's not a Rails / React project. They may be able to ramp up quickly, if they're talented. If they're not talented, then they won't be able to, and the employer has to take the hit. We will need a revolution in software development pedagogy before individual aptitude stops mattering to employers. The state of education at the moment is so bad that unschooled yet talented individuals can be much much better at fulfilling business requirements than trained and educated professionals. Try that with medicine!

itamarst 8y ago
Or, employers will start taking the long view and actually start investing in their employees.
- vinceguidry 8y ago
  That's not an investment, that's giving your money away. Would you spend $X0,000 on something that can walk out the door at any moment?
  - sidlls 8y ago
    Did you ever consider that the employee might be a smidge less likely to walk out the door if the employer invested in him or her, recognized his or her achievements in a timely manner with responsibility and authority (promotion) and compensated him or her fairly? Seems to me employees "are likely to walk out the door" mainly because employers view them as expendible expenses and not humans trading labor for something of value

itamarst 8y ago

If our starting point is that programming is mostly about skills, productivity starts getting interesting - what does productivity mean? My personal take is that it means solving problems with less wasted effort. Less code (a 0.1× programmer can solve problem with 10% of the code - https://codewithoutrules.com/2016/08/25/the-01x-programmer/ https://codewithoutrules.com/2016/08/25/the-01x-programmer/), but also by solving the right problem, and coming up with better solutions (https://codewithoutrules.com/2017/10/04/technical-skills-productive/ https://codewithoutrules.com/2017/10/04/technical-skills-pro...). These are all skills you can learn. And I think focusing on learning technologies obscures a lot of these skills, since they're about communication and listening and project management. For productivity in terms of technological knowledge I'm starting to think that, since choosing which tool is more important than how to use it, a better way to get better is to study case studies. Instead of trying to learn "how can I use Mongo, how can I use PostgreSQL" you try to learn "when should I use Mongo, when should I use PostgreSQL". I'd love to hear about good sources of case studies. http://www.aosabook.org/en/index.html http://www.aosabook.org/en/index.html is good, but doesn't cover kind of programming one would do at a company, much.

iamcasen 8y ago
This is exactly correct. In the past, I didn't consider myself an excellent programmer, because I struggled to solve esoteric number permutation problems and recursive graph search problems during whiteboard interviews. It seemed to me that all my peers could do it, and they were getting good jobs for it. Over time I learned that the real value comes from solving the right problems, and recognizing wasted effort. It comes from architecting systems that are easily maintainable. That's what makes money in the business. Solving narrow, intensely interesting algorithms, is a rare case that is not widely needed in the industry at large.

humanrebar 8y ago

> The truth is that programming isn't a passion or a talent, it is just a bunch of skills that can be learned. Aren't these all talents? * learning many things * learning difficult things * recalling things you've learned when you need them If something is a skill, one would expect all engineers to get better at it with practice. But there are many abilities in engineers that don't seem to work that way.

muzani 8y ago
They're definitely learnable skills. The thing I find with engineering is that most skills remain untrained with experience. If years of experience meant you'd be better at a skill, then older would be able to reverse park very quickly. But without deliberate training, most skills don't improve.
itamarst 8y ago
Learning is a skill you can get better at, so it's just a dependency. Learning is not an unchangeable talent. Some books that will help you learn better: * Power of Intuition, about naturalistic decision making - https://www.amazon.com/Power-Intuition-Feelings-Better-Decisions/dp/0385502893/ https://www.amazon.com/Power-Intuition-Feelings-Better-Decis... * How Learning Works - https://www.amazon.com/How-Learning-Works-Research-Based-Principles/dp/0470484101 https://www.amazon.com/How-Learning-Works-Research-Based-Pri... (my review: https://codewithoutrules.com/2016/03/19/how-learning-works/ https://codewithoutrules.com/2016/03/19/how-learning-works/) No doubt others can recommend more books.
- toasterlovin 8y ago
  Wether or not a trait is mutable is different from the degree to which that trait is mutable. The distinction is important. Most breeds of dog can be trained to learn some simple commands, but good luck getting some mutt from the pound to herd sheep like a border collie. Here's a video of border collies in action: https://www.youtube.com/watch?v=bpjP3mxv21s https://www.youtube.com/watch?v=bpjP3mxv21s
- walshemj 8y ago

EpicEng 8y ago

> > 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, the ability to think in abstractions, the ability to hold a large amount of information in your head all at once, etc. are all skills, and not skills that the majority of people are particularly good at. We wouldn't judge a carpenter on e.g. his/her ability to use a saw, or a EE on their ability to use a scope. I never understood why so many put so much emphasis on the tools a software dev knows.

sophacles 8y ago
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/username) it causes a bunch of extra effort to clean up the monstrosity. That's not to say problem solving is not extremely important, but the time suck created by bad tool use (or not using tools out of ignorance of their existence) ultimately reduces the productivity of a programmer, or in some cases, whole teams.
- LyndsySimon 8y ago
  > 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."

mnglkhn2 8y ago

If you believe programming is not a talent then you won't complain when your pay is not structured the same way that talent pay is.

mistrial9 8y ago

"programming" is not one thing.. most comments here fail to make even a basic distinction between [ php forms developers; dev-ops Go pipeline builders; game developers; domain-specific problem solvers] or other. Include in any of those categories varying, more or less GUI design, more or less quality, more or less efficient execution, more or less language mastery, more or less elegant design. Fish apparently are not good at describing water (!)

ionised 8y ago

The only thing stopping someone becoming a programmer is a genuine interest in the craft. People generally don't get good at things they find boring. We software developers are not special. We don't have something that non-programmers lack, apart from maybe an inflated sense of self-worth.

weirdmantis 8y ago

It's like drawing. Sure maybe with a lot of effort anybody could draw a close approximation of a good drawing but unless you are innately talented and driven you will never be at a good enough level to make a great career at it.

jasode 8y ago

The 2 sides debating "talent" are always talking about 2 different things. (#1) "talent" doesn't exist: knowledge and skills can be learned. No infant comes out of the womb knowing 5 languages or physics equations or the syntax of "printf("hello world")". Every single human who knows how to do something well at one point in their life did not know how to do it well. If one can improve by learning, it means talent doesn't exist. This aligns with Carol Dweck's "growth mindset", the 10000 hours meme, self-improvement, etc. This internal perspective compares oneself at time_before vs time_after. (#2) "talent" is a subjective ranking of people's abilities: there are people who are noticeably better at expressing their skills. E.g. NBA basketball player Shaq O'Neal has spent more than 10,000 hours practicing free throws with a dozen different coaches to achieve 52% success, but there's a high school kid that can sink them at 80%. We can say the kid is "more talented" at free throws. To say that "free throws" is a "learnable skill" doesn't change anything about noticing the obvious difference in abilities. If Person A learns faster than Person B, that in itself is a talent. This external perspective compares people against other people. People who hold meaning #1 vs people thinking of meaning #2 are having 2 different conversations. E.g. when companies say "they are looking to hire the most talented" (meaning #2), they are not talking about people who can self-improve (meaning #1). In this essay, Jacob Kaplan-Moss is talking about meaning #1. Yes, you can read it and take all his advice to heart. However, you still have to understand meaning #2 to properly decode what others are talking about when sports teams, music record labels, Hollywood, venture capitalists, and startups all say they are "looking for the best talent".

jbellis 8y ago

I guess "programming talent is a normal distribution, not a U distribution" doesn't make for as catchy a headline.

d0lph 8y ago

I don't want to be mean but it looks like programming is both: Talent: 1. natural aptitude or skill. Passion: 2. strong and barely controllable emotion. ... * an intense desire or enthusiasm for something. ...

humanrebar 8y ago
Couldn't passion be innate as well? If you hate cilantro, you certainly won't have a talent for eating cilantro. (Also, passion in this context doesn't imply any sort of lack of control. You don't program in the "throes of passion".)
- d0lph 8y ago
  I've skipped meals programming, when things are interesting at least.

draw_down 8y ago

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 players or whatever in the world probably do work harder than others in their field, but that's not the same as saying that the difference between them and others is simply the amount of work/practice.

Zimahl 8y ago
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.

pixelperfect 8y ago

Does anyone else disagree with this article? There is talent for programming, and that talent is correlated with IQ. A person with average or below average IQ is very unlikely to excel as a programmer. There is a lot of academic literature to back this up.

humanrebar 8y ago
I think innate intelligence (whether measured by IQ or more qualitatively) is a real thing. I think people implicitly live that way and organize society that way. I also think it's also considered a faux pas to actually say as much. People tie respect, identity, and self worth into intelligence a lot. It's hard to say Kimberly is smarter than David without offending people. Let alone to say engineers are generally smarter than elevator operators (to pick a mostly extinct job). To some degree, all the interview hazing and discussion about "programming talent" is all dancing around the West's inability to discuss intelligence quantitatively and dispassionately. To be fair, historically there has been a lot of sexism, racism, bigotry, and pseudoscience tied up in the science of intelligence. I'm not sure how to get society to re-approach the subject in a scientific, productive, and beneficial way.

thoughtsimple 8y ago

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 frameworks needed to do their jobs programming. I couldn't work without search. I don't memorize anything anymore. I work on dozens of different technologies. Basically, I've become a mediocre programmer at a large number of different programming tasks where once I was expert at a very few. I'm the same person but the meaning of what is a programmer has changed over time. I'm OK with that.

allthenews 8y ago
I don't think programming ability is measured by the number of APIs/libraries one has committed to memory.
- kazinator 8y ago
  Having an accurate and large knowledge of relevant API's will help you program faster and more accurately, and make better design decisions earlier. (You avoid the "if I had known about these API's, I'd have done it differently" situation.) It's hard not to conclude that this is one axis in the multi-dimensional "ability" space.
- geezerjay 8y ago
  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.
  - allthenews 8y ago
    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.

Adamantcheese 8y ago

All I'm seeing here is that regardless of actual dictionary definition I still won't be hired because of some vague opinionated definition in someone's head.

pmcollins 8y ago

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

dajohnson89 8y ago
will you pay me for those 3 days' work? and tbh it's not even the money, it's my non-existent time.
- pmcollins 8y ago
  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.
  - 8y ago

maerF0x0 8y ago

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

humanrebar 8y ago
a. There isn't really a gap. Employers are just slow to adjust to market rates for quality engineers. b. If engineer salaries went up to the market clearing rate, certain business models that assume certain labor costs will become flawed c. Who is going to pay for the training, especially in the case that all the training doesn't actually end up making the candidate any good at the job?

israelsonbj 8y ago

Why do computer science curriculums yield such a common thought toxicity? How can they engage greater diversity and cultivate empathy, compassion, and give students perspective to self-evaluate themselves?

foreigner 8y ago

The sentiments in this article are all very nice and progressive, but... have you ever actually tried to interview people for a programming job? The simple fact is that lots of people, perhaps most people who apply for jobs as programmers, are completely helpless. They couldn't code their way out of a paper bag. It's actually really depressing interviewing them, because you want them to be successful and yet most of them fail miserably at the most basic things.