9 ms·

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 a

• bkeroack 12y ago
  Is speed really the most important metric?
  • nilkn 12y ago
    It's not just speed. It's everything. They're not just faster -- their code is cleaner, faster, more elegant, and better according to most metrics you could think up.
    • zaphar 12y ago
      A measure of the elegance and cleanliness of code is so arbitrary in our industry that it's useless as a metric. Faster is concrete enough to be useful though.
      • samspot 12y ago
        How do you measure speed though? Speed to hit the done button or speed to get to production bug-free? You aren't really measuring speed accurately until you account for all the downstream time, and even include time for problems found in production. After all that, you need to account for any technical debt that was accrued as a result of going too fast to get this specific task done. Almost every day I run into a 1 hour fix that is now going to cost us 10 hours to recover from. Are some developers faster than others when you include all these concerns? Certainly. But measuring it is so incredibly difficult and error-prone that we mostly just stick to some emotional impression of how fast someone is.
        • zaphar 12y ago
          I was actually referring to the runtime performance of the code not time to completion.
  • kwhitefoot 12y ago
    Perhaps not the most important but it is important. Whatever the job, if you can do it faster you have more time available to do it better.
  • carlmcqueen 12y ago
    Speed in every industry, including programming, is part of the sauce not the special ingrediant as far as I've seen. All the way to working a line in a factory, the speed of the line is constant but the accuracy on top of speed is what sets the best apart. Anyone can go fast and make mistakes, those who have figured out a method that works for themselves and keeps up with the pace (or keeps ahead) and puts out a high quality product at minimal mistakes is what stands out.
• jeremiep 12y ago
  From personal experience, speed has very little to do with productivity. Productivity is a function of knowledge and experience. The most productive programmers I've met almost always had enough experience in what not to use. They have a clear focus on the simplicity of their code and their ability to reason about it. They understand the problem and the hardware as well as the language in a very detailed manner. They are by nature extraordinarily curious people. In comparison, the worst programmers I've met were the exact opposite, learning barely enough to get the job done and never digging into the details. Sometimes they don't even understand the hardware they're using. They pick the wrong data structures, think about code first and data is an afterthought. Productive programmers don't really type faster or think faster. They just make far less mistakes to begin with and such mistakes always inflate the development time exponentially.
  • altcognito 12y ago
    > They pick the wrong data structures, think about code first and data is an afterthought. It makes me so happy to read this. Data in the grand scheme of things is vastly more important than code. "picking" data structures is a luxury in many cases and thus data structure often dictates the structure and expectations of your code. Data usually outlives the code. Data is effectively the earth in your code farm. Take care of it, and form it as best you can given a set of restrictions so that your program runs smoothly.
    • base698 12y ago
      According to SICP data and code are the same! Interesting concept anyway. http://stackoverflow.com/questions/355406/concepts-that-surprised-you-when-you-read-sicp#answer-483339 http://stackoverflow.com/questions/355406/concepts-that-surp... http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html#%_sec_2.1.3 http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html...
      • webnrrd2k 12y ago
        That's like saying all Turing-equivalent languages are the same. It may be true in theory, but is hardly a useful point in most programming language discussions. As an example of code vs. data, and this is a general statement (so YMMV) I try to structure my code such that, if there is a choice between making the code more complex, vs making the data more complex, I generally choose to make the data more complex. The code is usually harder to reason about, so it's a win if I can use a simpler algorithm.
• 67726e 12y ago
  Been screwing with computers since 9 or so, and programming since 11 or so. I'm now about 4 years into my professional career and usually get the typical "amazing programmer" remarks, that I'm fast, smart, good code, beyond my years, etc. I think that a lot of things go into it. First, practice, practice, practice. I spent waaaaay too much time in high school writing/designing/building projects. By the time I hit university, I could write a compiler or build a web application. Old hat. That's always going to be a hurdle folks who are serious about programming are going to have to get over, I just did it early on so when I started working with others I was ahead of the curve. The big problem I've noticed among my friends at school that floundered vs the ones that succeeded, and that of the (great) professionals I've worked with is the ability to solve problems. Some folks look at a task like "build a web application" and seize up at enormity of the task. Others, start breaking down the problem into it's component parts. Pick the front-end, back-end tools, database, and drill each piece further down. I think this is just as important, if not more, than raw coding talent, especially since strong problem decomposition skills apply across the board. I'm regularly amazed/annoyed when folks can't solve trivial computer problems not because they are hard, but because they are afraid to jump into the deep end and start making educated guesses, googling, just plain trying. I'm not a teacher, manager, or any kind of people herder so I'm not really sure how or why folks are like this, but if you just try to tackle the problem, you'll eventually get somewhere. Overtime you build up knowledge, experience, and mistakes and you become that 10x programmer, or that 10x chef, or that 10x <thing>.
  • taurath 12y ago
    > Some folks look at a task like "build a web application" and seize up at enormity of the task. Others, start breaking down the problem into it's component parts. This can be learned by anyone!! This is not a binary idea. The more "complete unknown" concepts in said task the more likely anyone is to seize up - good programmers (or basically any engineer) are just more practiced than most at overcoming a lack of knowledge.
    • 67726e 12y ago
      I guess the ability to overcome the urge to seize up is, itself, something one needs to acquire. There is little in my life that I'm afraid to attempt. Investigate a problem and break it down into its component parts, repeat ad nauseam. I know too many folks who just throw their hands up and don't even tackle it. Now you also need to recognize when you're in over your head (in terms of knowledge, in terms of capital, etc). I could attempt many car repairs myself, but the time and capital required is typically prohibitive. Of course one would have to first make an attempt on the problem to make the analysis.
• mathattack 12y ago
  I agree with most of what you said, except that perhaps the distribution is a little more complex than bimodal. Perhaps it's multi-modal, with various discernible leaps in performance. (There's a big gap between "Green", "Good" and "Rock Star", so I think that there's at least 3)
  • nsnick 12y ago
    Any distribution can look multimodal if you under sample.
    • mathattack 12y ago
      True. My contention is that learning happens in steps, it's not linear. This is especially true in programming. So rather than a smooth curve of talent, there are plateaus that people reach. I would love to see data on this. Who knows, I might be wrong. (Wouldn't be the first time - even today)
  • tracker1 12y ago
    I think there's also an in-between for Green and Good, which is Effective... There are a lot of tasks that don't need an elegant solution, only a working one. If your solutions are broken up pretty well, where a given piece can be updated or rewritten without having to refactor everything, it makes that easier, and makes a project work better with multiple developers of varying skill.
• VLM 12y ago
  One strong indication that programming talent is not bimodal is only bad engineers (programmers in the solder language) see the world as strictly binary. As I get older and gain more experience its astounding how much of the world does not operate in a simplistic pass/fail manner instead has an optimum operating point at "muddle thru mode". Or another way of putting it is only a really bad architect/designer relies on eternal perfection, or attempting to see the world thru those very limiting glasses leads to lots of fail. An interesting literary or fine arts comparison is the assumption that the quicker something is made, the better or more valuable it is. Obviously a xeroxed page from a Hello Kitty coloring book is inherently better than an original dutch masters painting.
  • bad_user 12y ago
    Obviously xeroxing a Hello Kitty coloring book is not better if you want a painting that's worth something and in fact the process a xerox machine goes through is inherently more complex than placing pain on a canvas by means of brushes. I also don't see what perfectionism has to do with the parent or the TFA - perfectionism vs pragmatism is not the issue being discussed. Statements like "only bad engineers ..." needs proof or if kept as an anecdote I surely hope the sample size is bigger than a couple, plus I need some criteria by which those people were classified as bad engineers. In my experience in our industry we tend to make outrageous claims without anything to back it up, which is preposterous given how much of our jobs relies on gathering and interpreting numbers. The TFA along with the myth being discussed are no exceptions.
• a8da6b0c91d 12y ago
  > 99% of people can learn to program A good sixth of people are nearly functionally illiterate. I'd say well less than a third of people could ever write a real program.
  • Bjartr 12y ago
    Is that because they're unable to learn, or because they haven't been taught?
  • vacri 12y ago
    Not only that, but most people are utterly uninterested in programming. Talk to almost any teacher and they'll say that uninterested students don't learn well.
  • logfromblammo 12y ago
    "Real program" treads close to No True Scotsman. 99% of people can learn to write hypersimplistic programs, with an absolutely maddening amount of hand-holding. Those people will never be employable as software writers, because they cannot be independently productive. My own father can program well enough to impress all of his friends with his old-man's technical savvy. But whenever he tries something even slightly difficult, he needs my help. He can do well enough to make websites that include a few simple interactive features, but he will literally beat his head against the wall for days trying to solve something that I can fix in 30 seconds. I can't explain that disparity without employing the premise that some people are naturally better at coding than others. The ultimate irony is that my mother is a retired lawyer who specialized in draft legislation. If she cared to, she could probably learn to program ten times as well as my father in one tenth the time. She does not care to; she prefers to play video games. (So do I, for that matter, but I need the money.) Lawyers that work in contract law or draft legislation are essentially writing programs in (nearly) natural language that execute on a human-based operating system, with non-deterministic processors.
• ChrisArgyle 12y ago
  Kaplan-Moss has been working on high profile projects with highly talented developers for something like a decade. Due to this environment his analysis (unwittingly?) only includes data at the "good programmer" end of the bi-modal distribution. Unfortunately for The Rest Of Us we're stuck with the occasional coworker who writes code like a misprinted example from Teach Yourself C# in 21 Days.
• Throwaway98123 12y ago
  Agreed, and I think this applies to nearly everything in life. Everyone can learn, but it takes a certain something, which you can't learn, to become great. I spent years in life drawing classes, about 6 hours a week. There was always a clear divide between those that were great, and everyone else. Those that were great, reached that level quickly, and everyone else improved, but remained slightly above average at best. Or, take public speaking. We can agree Elon Musk is a talented man, and he has more practice when it comes to public speaking in real world scenarios than most people in this world. However, he's just an average public speaker. A decade from now, he'll likely improve a bit, but still remain average. Why is that? Why are there high school students that can take a public speaking course one semester, and give a better speech or presentation? I think they just possess a quality he's missing when it comes to speaking. Fortunately, everything in life requires a different set of attributes. There are many people out there that can never be brilliant programmers, and likewise, many of us could never be notable in improv, or stand up comedy.
  • ddingus 12y ago
    This quality can be teased out of more people than we think. A whole lot of "that quality" comes down to a couple things. One is basic inhibition. Learning to shed this dramatically improves one's potential for performance activities of any kind, and speaking in public is a performance activity for sure. The other is coming to understand people better. Empathy is a part of this, but so is just understanding how different people are and how they respond to things varies just as much. There are commonalities, of course, but there comes a basic security from being able to read the crowd and that feedback feeds into the lack of inhibition, allowing a person to shine much brighter than they would otherwise. This from a geek who had a fair amount of music, theatre early on. I still remember the "unlock" where I came to understand the importance of conveying intent, being humble, and not having that basic fear that locks one up so much. Failure is OK. So are basic gaffes and mistakes. People are way more forgiving than we are to ourselves. I think Elon could improve considerably. He doesn't need to, and he's got his time priorities right where he wants them. Maybe sometime in the future those could change. Should that happen, some time spent with the right kind of people could very well open him up to a degree we may find surprising. Elon has deep passion and resolve and drive. Those things, brought out in a bit less stiff fashion may have an impact he would value someday. In a very real sense, those that pick it up quickly, care more too. I sometimes mentor engineering types who need these skills for things like pre-sales, or to begin consulting and selling in various ways. Reducing inhibition is important. For many, it's simply not knowing what will happen, so the default is to do the minimum to limit risks and unknowns. Caring is also important. For many, the speech or show more generally, isn't core. Does not matter as much as the tech, or whatever it is being spoken. Cracking that tends to be linked to understanding the selling of ideas, movements of money, and a lot of other things get driven by those who can handle people, and there is a science, and I would argue, technical aspect to that just as there is any thing with sufficient dynamics as to not be obvious at first glance.
• zaphar 12y ago
  The problem with relying on personal anecdotal evidence is that it is inherently biased. The only way to truly answer the question is find a way to reliable measure coding skill. Otherwise you find yourself making the same mistake you think Jacob is making. Using faulty data to back up an assumption. Part of the thrust of Jacob's talk was that there is probably a whole class of developers out there who would be just as good as the rest of us but they can't get entry due to an assumption that Coding is an innate skill and not a learned one. He even gives examples like the lady who had written a working distributed GIS processing pipeline but didn't think she was a Coder. I'm a little like Jacob in that people automatically assume I'm a 10x coder. I have a pedigree from Google. My github and bitbucket accounts are full of small libs and projects I've played around with. My code has been used by CouchDB and the list of languages I have at least surface knowledge about is huge. There is exactly one reason for all these qualifications though. I've been in the industry for more than 10 years and I was a hobbiest programmer for several decades before I was in industry. When I started learning I was doing gw Basic. My first "real" programming languages was VB6. I was a stereotypical below average programmer. I didn't know a linked list from a hashtable. All I needed to turn into the "ninja" people see when they look at me now was time. I've met a lot of people who could absolutely reach this same level. And 90% of those people with potential resist trying because they think "I'm not really a coder". The myth really does need to die.
  • agentultra 12y ago
    Hear, hear! I started on AmigaBASIC and later ARexx. QBasic on later 386/486 machines. Pascal, OOTuring (a Pascal-like educational language), and C in high school. Perl near the end of high school. Python in my early twenties. Common Lisp in my late twenties. Have tried a bit of Haskell and OCaml here and there. Though I'd say I've settled on Python, C, and Common Lisp... trying to make brain space for OCaml only because I find Mirage to be such a great idea. I've given talks on BloomL implementations, constraint propagation solvers in game level design, and have written various bits of libraries and such over the years. Nothing terribly "ninja" like here. Depending on the audience I may sound like a wizard or a clueless hack. The reality is I'm probably somewhere in the middle in skill if programming were a quantifiable skill. The only reason I can cite these things is because I tried and learned some things not because I was born with some legendary ability to whisper to a computer what I want it to do. At the end of the day they are just machines and there's nothing super-human or special about learning how they work. It just takes time and effort like anything worth doing. The theory, as I understand it, is that without sufficient evidence we must assume that programming ability follows the same bell-curve distribution as every other quantifiable skill we can measure.
• lolatu54 12y ago
  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 then this is the wrong profession for you. You have to stay current, or else you will slide from good to mediocre to fired within the span of several years.
  • zimpenfish 12y ago
    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.
  • garthk 12y ago
    I'm not as sold on passion as a requirement as I was. Too often, it's just monomania or obsession in a fancy outfit. See also: Programmer Passion Considered Harmful: https://news.ycombinator.com/item?id=9211214 https://news.ycombinator.com/item?id=9211214
• ebbv 12y ago
  I think the source of your confusion is based on a false assumption that speed has anything to do with programming skill or quality of output. I've never met a really good programmer who cared much about how quickly she finished a project. Only about doing it right. On the other hand, I've met a lot of bad programmers who were really concerned with writing code quickly, or bragged about how fast they could code, who's output was terrible. Now it may be that a skilled programmer comes to an answer more quickly than an unskilled one. But it's also true that a sloppy programmer comes to an answer more quickly than a careful one.
• justinpaulson 12y ago
  I think there is a lot more granularity in abilities than you are accepting. Like the article discusses, there are many different skills that make up "programming." These include writing code, architecture, data structures, communication, debugging, interface design, documentation, etc. To say that there is a bimodal distribution is to say that all developers are either extremely good at all of those things or extremely bad at all of those things. From my experience, even the best coders are still lacking in one of those areas, and even the worst coders are usually pretty good in one of those areas. I also think you arbitrarily use the 10x thing a lot based on how you feel things are happening and not actual measurements. It is simply illogical to assume that all developer either fit into a category where they will complete a task in 1 day or 10 days...I'm using speed here because that is the metric you used in your post. I think what you will see more is a wide range of timeframes that developers will finish a task in. And with that some of them will have great interfaces, some will have terrible interfaces, some will have average interfaces. Furthermore, some will have excellent documentation, most will probably have no documentation. Some of the developers will be able to clearly articulate everything that is happening in the interface and in the code, some will not. Some will have created reusable frameworks, some will have hardcoded values. The quality of how they perform the task will be very granular based on a number of aspects, speed being only a small part. The bimodal distribution your anecdotal evidence points to is very lacking in the full scope of what makes up "being good at programming."
• mannykannot 12y ago
  The evidence you offer does not go so far as to support an inference of bimodality, only that there is some sort of broad distribution. That is as far as my personal experience of the matter goes, as well. Some teachers in the field think they see bimodality in their classes, though there is some evidence [1] that this is a result of teaching to those with prior experience. One might guess (but cannot assume) that this carries over to the workplace, but also that it could be mitigated by better teaching. [1]Anthony Robins. Learning edge momentum: A new account of outcomes. Computer Science Education, 20(1):37–71, 2010.