5 ms·

The Myth of the Genius Programmer

61 points by mlinsey 17y ago

Hexstream 17y ago
No way I'm watching a 50-minute video I'm not even sure will be worthwhile. I didn't find a transcript. I had a look at the PDF and there's nothing groundbreaking in there IMHO...
silentbicycle 17y ago
While I don't have the time to watch a 50 minute video at the moment, a common theme I see in the PDF is that people are reluctant to share source code until it's reasonably "done". A lot of things that seem impressive as completed works have spent most of their development messy and (by definition!) incomplete. When coupled with potentially endless anonymous criticism via the internet* , this can be pretty intimidating. I get where they're coming from. I have several projects that I really need to polish up and upload, and I want them to feel presentable; I don't really understand how people get used to working in public (on github, for example). I also do a fair amount of maintenance programming, and ... I want to make sure my code is better than that. Just because I change my mind, make mistakes, etc., it doesn't mean I need to publish sloppy code. * Look at the comments in any discussion on Reddit. About anything. People get nasty, often just because they can.
- swombat 17y ago
  I don't really understand how people get used to working in public It's easy. Until your code is good, no one gives a damn about it. Even if it's good, you'll still have to shove it down people's throats before they care. So don't worry that "someone might see your bad code". They won't. Nobody cares.
  - akkartik 17y ago
    Alternative phrasing: to make something good I find I have to be thinking about it all the time. If I think about it all the time I talk about it every chance I get, ask for help, comments, feedback. It's easier to ask for help if the thing you want them to help you with is a click away. So make it public.
  - staunch 17y ago
    Successful projects are not determined by the quality of the code, but the utility of it. It's quite possible to have a very successful project, that a lot of people use, made up of embarrassingly bad code.
- mlinsey 17y ago
  I see where they are coming from too, and I often feel the same way; sometimes I have found myself starting on side-projects and not even telling close friends what they are about because I am scared or embarrassed to have anyone see my work in an embarrassingly incomplete state. I think one of the key lessons for me, which is very easy to grasp intellectually but much harder to internalize, is that any nastiness you receive in the short term doesn't really matter (and often comes from people who don't really matter). If you succeed in the long-term, that's what you will be known for, and all of the scorn directed at your early works will seem irrelevant. You should therefore do whatever maximizes your chances at long-term success, which includes taking the risk of exposing yourself to humiliation so that you can get better faster. It's one of the things I really admire about, say, Jeff Atwood. He's consistently bashed here and elsewhere for being incompetent, and it's not undeserved: even though I consider myself a pretty poor programmer at the moment, I can often tell when he says things that are fallacious or ignorant. And yet, with Stack Overflow he has been involved in a project more successful than most people's projects here. I would never mistake him for the mythical genius programmer, and I may be puzzled at the attention he receives or his persistence about writing topics he doesn't know much about, but when I see how he keeps writing and keeps building useful things even when everyone is publicly explaining to him all the ways he sucks, I wish I had his cojones.
- 10ren 17y ago
  Re: a bit tangential on nasty criticism. An approach I try to have (it's not for everyone) is to see the code as trying to do something worthwhile, rather than for the greater glory of 10ren. Without my ego on the line, I have more attention for the code itself. :-) With this attitude* , only criticism about how the code is serving its purpose is relevant. If someone criticizes it (or I imagine they will) because it's Lisp (or because isn't), or because it uses design patterns (or because it doesn't) and the criticism doesn't seem to make a difference to its purpose - it's just kind of bemusing. * Hard to do. EDIT ah... having now read the slides, this is one of the things they're saying.
- rimantas 17y ago
  You don't have to work in public using github. That's the nice feature of DVCS — you can have it all your code for yourself and at the same time enjoy all the benefits of VCS. Using centralized system you don't have much choice - either you don't commit, or you commit and everybody sees your ugly code. With DVCS you can have your private branches and work on your code as long as you want. When you a happy with your work, just push it to the public repo (hosted on github for example). Even more, you can have a lots of tiny working commits and then "squash" them into one big and nice final commit.
gchpaco 17y ago
There's a flaw in the video around 27:55 that is obnoxious, but it seems to just be local corruption.
yan 17y ago
Love this: "The failures tend to get smaller over time, and successes get larger. That's a trend you'll see, especially if you're learning, over time"
- cubicle67 17y ago
  Wouldn't this be true only if you're doing the same thing over and over?
gchpaco 17y ago
This is a bit of a diversion from Fitzpatrick and Collins-Sussman's talk, but I run into this belief a lot, and want to make a point. I see little evidence here that Collins-Sussman has finally understood DVCS as a social entity, although he certainly seems to have the technical details down. The strongest argument for DVCS--any DVCS--that I have found is the periodic fights over "committer access" or project direction generally for projects like NetBSD, XEmacs, gcc/EGCS, or glibc/eglibc disappear. I've seen more times than I can conveniently remember a perception of a cabal of committers who communicate exclusively with each other. This looks a lot like the structure of some sort of conspiracy, even though that is rarely the purpose. Even when it is, it's usually trying to work around some productive but extremely difficult person like Ulrich Drepper or Theo de Raadt. DVCSes have the critically important property that there is no longer any inherent technical center of development but that the social center of development is retained (usually). So while there is a technical hierarchy of git repositories that goes to Linus, if you think he's an idiot and want to take it a different direction, it's easy to do that--and if he decides you have a good idea in the end, he can merge with you without huge amounts of effort. Collins-Sussman has been concerned, publically, that there's some splintering process that DVCSes enable and that SVN prevents. But this perception is one you can only arrive at if you are in control of the SVN repository--if you are trying to submit patches to somebody doing this, and you don't have write access on the SVN server for branches or whatever (which imposes a nontrivial amount of effort), you more or less have to do this splintering on your own, without any tool support. In my experience DVCSes don't make this any more common than it was once; it's just that now these private splinters are visible, and can be integrated. Another secondary thing that's very convenient for me is that I can make many small changes and push them all at once when I'm happy with them--because they're small they're easier to review. But this is a workflow issue, it's not that one couldn't do this with SVN.
- delano 17y ago
  DVCSes have the critically important property that there is no longer any inherent technical center of development but that the social center of development is retained (usually). This is a really good point. It allows the social structure of the project to grow and change in a very natural way which makes it not only easier to adapt as committers come and go, but effortless.
spaghetti 17y ago
When you finally reach enlightenment or a state of "genius" you won't be thinking about what other people think of you.
alavrik 17y ago
These guys look like being advocates of mediocrity. I haven't seen such radical egalitarianism promotion even from junior managers. I especially disliked the moment when they interrupted the criticizer who was talking that there are a lot of evidences of geniuses existence and highly productive programmers in particular. And rather than advising to learn from the best programmers, they are advising to learn from ephemeral "community" and trimming ones ego and ambitions.
- jrockway 17y ago
  These guys look like being advocates of mediocrity. Yup. They wrote Subversion and continue to encourage people to use it. Perhaps they should tone down their egos and realize that Subversion was not really that great of an idea, and there are now several competing tools that do everything Subversion does, but better.
  - gchpaco 17y ago
    A lot of the problems SVN ran into was trying to use cutting edge technology and standards before they were really ripe. WebDAV, for example, or the endless, endless iterations of Berkeley DB corruption. It is, in a lot of ways, an excellent illustration of the dangers of trying to solve the wrong problem.
    - rimantas 17y ago
      Linus was making fun of SVN in his talk ( http://www.youtube.com/watch?v=4XpnKHJAok8 http://www.youtube.com/watch?v=4XpnKHJAok8 ). One of his point was, that SVN chose the wrong way right from the start and there is no way to have "CVS done right" because CVS is hopeless by design.
      - absconditus 17y ago
        CVS may have had serious flaws, but I find Linus' original revision control practices to be less than optimal: "The Linux kernel source code used to be maintained without the help of an automated source code management system, mostly because of Linus Torvalds' dislike of centralized SCM systems. In 2002, Linux kernel development switched to BitKeeper, a SCM system which satisfied Linus Torvalds' technical requirements." Nearly a decade without a revision control system? http://en.wikipedia.org/wiki/Linux_kernel#Revision_control http://en.wikipedia.org/wiki/Linux_kernel#Revision_control
deleted 17y ago
[deleted]
joe_the_user 17y ago
Looking at the handout too..., I am a bit disappoint this talk was not an effort to address the old cliche that some programmers are ten times as productive as other programmers and similar things. I already hate kind of thinking but I would like to have hard figures to use in arguments against the kind of people who believe this bolox. I agree with statements like "lose the ego" but I don't think that would fly in arguments with my manager.
- jimboyoungblood 17y ago
  It may be an "old cliche", but also happens to be true. Maybe you can quibble over whether it's a 10X, 100X, or merely a 5X difference, but some programmers are clearly much more productive than others.
  - stcredzero 17y ago
    It's also true that some programmers are more productive collaborators than others. (In fact, some are effectively anti-collaborators -- less work gets done when they pitch into a project.) If you are in a collaborative enterprise, this might be something to consider.
- joe_the_user 17y ago
  Wow, love the opinion based moderation here. Minus four used to be for trolls but now it seems it for disagreement? Even if you think I'm wrong here, does this post merit this treatment? (I moderate base on opinion for posts in the positive range but negative has, uh, negative connotations). I would say that I've have been in a number of situations where one team member was indeed more far more productive than another. But as far as I can tell, this was a product, itself, of the breakdown of team-process. Either the productive programmer wouldn't tell the unproductive programmer how they did their magic or alternatively, the unproductive programmer wasn't interested in finding out. One way to see team organization is as a way to prevent one person from always being "on the critical path". The most effective way is give skills to those who don't have them. There might indeed be no simple metrics that will support my view but I suspect this is because it is complex than such metrics can describe. There have been some studies lately showing that, in general, few people gain their abilities through "raw talent" rather than hard work see http://www.scientificamerican.com/article.cfm?id=the-expert-mind http://www.scientificamerican.com/article.cfm?id=the-expert-... . I guess these are what I'd fall back on for any proof. Whether person is willing to learn a given skills is whole other problem but I think these studies show that if a person is willing to learn, they are able.
Iiis 17y ago
Don't have time to watch the video, but I read through the PDF (which, btw, consists of very brief notes, so it's not really worth reading. However I think I got their basic thesis.) I find it an interesting point of view, since I'm a total noob when it comes to programming - first year CS student, only done a few tiny VB projects before that. However, I really enjoy programming, work on a few projects in my spare time, and plan to get some decent languages (a scripting language (Perl/Python/Ruby), and maybe a functional language (Clojure?) under my belt soon. I've used OO in class projects, but I want to figure out how to use it in my own projects. I want to learn software engineering practices. I want to learn graphics programming. That's just over the next couple of years! In 10, 20 years time, who knows? The appeal to me is that I can never peak in programming, their will always be new stuff to learn. Anyway, where was I? Oh yeah, my point was that I'm a noob now, I'm very willing to be modest and learn from others, but the hope of becoming a genius programmer I find very motivating.
stcredzero 17y ago
Ward Cunningham is a great role model. He's super-smart, darn clever, and just a really soothing sort of laid-back guy. He doesn't have to struggle with the alienate/suffer fools conundrum because he's aware enough to be learning something from the majority of his interactions with other people. If you can achieve that, you can conserve all the energy you'd waste swatting at fools.
kunqiana 17y ago
From my point of view the video is basically saying collaboration is most important as a programmer. Unlike athletes, programmers have to work together to achieve something great. Anything that is really impressive/great will come from the contribution of many programmers (eg linux). The question is: what is the most effective way to collaborate? Is there something about the ego that makes us ineffective? It would be really interesting if they had elaborated more on what makes a "healthy ego". Personally, as one of the critics has said, "people have egos no matter how humble they appear to be." It is simply human nature. Perhaps sometime it is more important to not to dumb down our own egos (or other people's) but to be more empathetic and reasonable working together.
- pj 17y ago
  In all fields, there are soloists and there are teams. There are team sports and individual sports. Michael Phelps is a soloist. S. Wolfram is a soloist... he has a backup band though...

61 points by mlinsey 17y ago

No way I'm watching a 50-minute video I'm not even sure will be worthwhile. I didn't find a transcript. I had a look at the PDF and there's nothing groundbreaking in there IMHO...

silentbicycle 17y ago

While I don't have the time to watch a 50 minute video at the moment, a common theme I see in the PDF is that people are reluctant to share source code until it's reasonably "done". A lot of things that seem impressive as completed works have spent most of their development messy and (by definition!) incomplete. When coupled with potentially endless anonymous criticism via the internet* , this can be pretty intimidating. I get where they're coming from. I have several projects that I really need to polish up and upload, and I want them to feel presentable; I don't really understand how people get used to working in public (on github, for example). I also do a fair amount of maintenance programming, and ... I want to make sure my code is better than that. Just because I change my mind, make mistakes, etc., it doesn't mean I need to publish sloppy code. * Look at the comments in any discussion on Reddit. About anything. People get nasty, often just because they can.

swombat 17y ago
I don't really understand how people get used to working in public It's easy. Until your code is good, no one gives a damn about it. Even if it's good, you'll still have to shove it down people's throats before they care. So don't worry that "someone might see your bad code". They won't. Nobody cares.
- akkartik 17y ago
  Alternative phrasing: to make something good I find I have to be thinking about it all the time. If I think about it all the time I talk about it every chance I get, ask for help, comments, feedback. It's easier to ask for help if the thing you want them to help you with is a click away. So make it public.
- staunch 17y ago
  Successful projects are not determined by the quality of the code, but the utility of it. It's quite possible to have a very successful project, that a lot of people use, made up of embarrassingly bad code.
mlinsey 17y ago
I see where they are coming from too, and I often feel the same way; sometimes I have found myself starting on side-projects and not even telling close friends what they are about because I am scared or embarrassed to have anyone see my work in an embarrassingly incomplete state. I think one of the key lessons for me, which is very easy to grasp intellectually but much harder to internalize, is that any nastiness you receive in the short term doesn't really matter (and often comes from people who don't really matter). If you succeed in the long-term, that's what you will be known for, and all of the scorn directed at your early works will seem irrelevant. You should therefore do whatever maximizes your chances at long-term success, which includes taking the risk of exposing yourself to humiliation so that you can get better faster. It's one of the things I really admire about, say, Jeff Atwood. He's consistently bashed here and elsewhere for being incompetent, and it's not undeserved: even though I consider myself a pretty poor programmer at the moment, I can often tell when he says things that are fallacious or ignorant. And yet, with Stack Overflow he has been involved in a project more successful than most people's projects here. I would never mistake him for the mythical genius programmer, and I may be puzzled at the attention he receives or his persistence about writing topics he doesn't know much about, but when I see how he keeps writing and keeps building useful things even when everyone is publicly explaining to him all the ways he sucks, I wish I had his cojones.
10ren 17y ago
Re: a bit tangential on nasty criticism. An approach I try to have (it's not for everyone) is to see the code as trying to do something worthwhile, rather than for the greater glory of 10ren. Without my ego on the line, I have more attention for the code itself. :-) With this attitude* , only criticism about how the code is serving its purpose is relevant. If someone criticizes it (or I imagine they will) because it's Lisp (or because isn't), or because it uses design patterns (or because it doesn't) and the criticism doesn't seem to make a difference to its purpose - it's just kind of bemusing. * Hard to do. EDIT ah... having now read the slides, this is one of the things they're saying.
rimantas 17y ago
You don't have to work in public using github. That's the nice feature of DVCS — you can have it all your code for yourself and at the same time enjoy all the benefits of VCS. Using centralized system you don't have much choice - either you don't commit, or you commit and everybody sees your ugly code. With DVCS you can have your private branches and work on your code as long as you want. When you a happy with your work, just push it to the public repo (hosted on github for example). Even more, you can have a lots of tiny working commits and then "squash" them into one big and nice final commit.

gchpaco 17y ago

There's a flaw in the video around 27:55 that is obnoxious, but it seems to just be local corruption.

yan 17y ago

Love this: "The failures tend to get smaller over time, and successes get larger. That's a trend you'll see, especially if you're learning, over time"

cubicle67 17y ago
Wouldn't this be true only if you're doing the same thing over and over?

gchpaco 17y ago

This is a bit of a diversion from Fitzpatrick and Collins-Sussman's talk, but I run into this belief a lot, and want to make a point. I see little evidence here that Collins-Sussman has finally understood DVCS as a social entity, although he certainly seems to have the technical details down. The strongest argument for DVCS--any DVCS--that I have found is the periodic fights over "committer access" or project direction generally for projects like NetBSD, XEmacs, gcc/EGCS, or glibc/eglibc disappear. I've seen more times than I can conveniently remember a perception of a cabal of committers who communicate exclusively with each other. This looks a lot like the structure of some sort of conspiracy, even though that is rarely the purpose. Even when it is, it's usually trying to work around some productive but extremely difficult person like Ulrich Drepper or Theo de Raadt. DVCSes have the critically important property that there is no longer any inherent technical center of development but that the social center of development is retained (usually). So while there is a technical hierarchy of git repositories that goes to Linus, if you think he's an idiot and want to take it a different direction, it's easy to do that--and if he decides you have a good idea in the end, he can merge with you without huge amounts of effort. Collins-Sussman has been concerned, publically, that there's some splintering process that DVCSes enable and that SVN prevents. But this perception is one you can only arrive at if you are in control of the SVN repository--if you are trying to submit patches to somebody doing this, and you don't have write access on the SVN server for branches or whatever (which imposes a nontrivial amount of effort), you more or less have to do this splintering on your own, without any tool support. In my experience DVCSes don't make this any more common than it was once; it's just that now these private splinters are visible, and can be integrated. Another secondary thing that's very convenient for me is that I can make many small changes and push them all at once when I'm happy with them--because they're small they're easier to review. But this is a workflow issue, it's not that one couldn't do this with SVN.

delano 17y ago
DVCSes have the critically important property that there is no longer any inherent technical center of development but that the social center of development is retained (usually). This is a really good point. It allows the social structure of the project to grow and change in a very natural way which makes it not only easier to adapt as committers come and go, but effortless.

spaghetti 17y ago

When you finally reach enlightenment or a state of "genius" you won't be thinking about what other people think of you.

alavrik 17y ago

These guys look like being advocates of mediocrity. I haven't seen such radical egalitarianism promotion even from junior managers. I especially disliked the moment when they interrupted the criticizer who was talking that there are a lot of evidences of geniuses existence and highly productive programmers in particular. And rather than advising to learn from the best programmers, they are advising to learn from ephemeral "community" and trimming ones ego and ambitions.

jrockway 17y ago
These guys look like being advocates of mediocrity. Yup. They wrote Subversion and continue to encourage people to use it. Perhaps they should tone down their egos and realize that Subversion was not really that great of an idea, and there are now several competing tools that do everything Subversion does, but better.
- gchpaco 17y ago
  A lot of the problems SVN ran into was trying to use cutting edge technology and standards before they were really ripe. WebDAV, for example, or the endless, endless iterations of Berkeley DB corruption. It is, in a lot of ways, an excellent illustration of the dangers of trying to solve the wrong problem.
  - rimantas 17y ago
    Linus was making fun of SVN in his talk ( http://www.youtube.com/watch?v=4XpnKHJAok8 http://www.youtube.com/watch?v=4XpnKHJAok8 ). One of his point was, that SVN chose the wrong way right from the start and there is no way to have "CVS done right" because CVS is hopeless by design.
    - absconditus 17y ago
      CVS may have had serious flaws, but I find Linus' original revision control practices to be less than optimal: "The Linux kernel source code used to be maintained without the help of an automated source code management system, mostly because of Linus Torvalds' dislike of centralized SCM systems. In 2002, Linux kernel development switched to BitKeeper, a SCM system which satisfied Linus Torvalds' technical requirements." Nearly a decade without a revision control system? http://en.wikipedia.org/wiki/Linux_kernel#Revision_control http://en.wikipedia.org/wiki/Linux_kernel#Revision_control

deleted 17y ago

[deleted]

joe_the_user 17y ago

Looking at the handout too..., I am a bit disappoint this talk was not an effort to address the old cliche that some programmers are ten times as productive as other programmers and similar things. I already hate kind of thinking but I would like to have hard figures to use in arguments against the kind of people who believe this bolox. I agree with statements like "lose the ego" but I don't think that would fly in arguments with my manager.

jimboyoungblood 17y ago
It may be an "old cliche", but also happens to be true. Maybe you can quibble over whether it's a 10X, 100X, or merely a 5X difference, but some programmers are clearly much more productive than others.
- stcredzero 17y ago
  It's also true that some programmers are more productive collaborators than others. (In fact, some are effectively anti-collaborators -- less work gets done when they pitch into a project.) If you are in a collaborative enterprise, this might be something to consider.
joe_the_user 17y ago
Wow, love the opinion based moderation here. Minus four used to be for trolls but now it seems it for disagreement? Even if you think I'm wrong here, does this post merit this treatment? (I moderate base on opinion for posts in the positive range but negative has, uh, negative connotations). I would say that I've have been in a number of situations where one team member was indeed more far more productive than another. But as far as I can tell, this was a product, itself, of the breakdown of team-process. Either the productive programmer wouldn't tell the unproductive programmer how they did their magic or alternatively, the unproductive programmer wasn't interested in finding out. One way to see team organization is as a way to prevent one person from always being "on the critical path". The most effective way is give skills to those who don't have them. There might indeed be no simple metrics that will support my view but I suspect this is because it is complex than such metrics can describe. There have been some studies lately showing that, in general, few people gain their abilities through "raw talent" rather than hard work see http://www.scientificamerican.com/article.cfm?id=the-expert-mind http://www.scientificamerican.com/article.cfm?id=the-expert-... . I guess these are what I'd fall back on for any proof. Whether person is willing to learn a given skills is whole other problem but I think these studies show that if a person is willing to learn, they are able.

Iiis 17y ago

Don't have time to watch the video, but I read through the PDF (which, btw, consists of very brief notes, so it's not really worth reading. However I think I got their basic thesis.) I find it an interesting point of view, since I'm a total noob when it comes to programming - first year CS student, only done a few tiny VB projects before that. However, I really enjoy programming, work on a few projects in my spare time, and plan to get some decent languages (a scripting language (Perl/Python/Ruby), and maybe a functional language (Clojure?) under my belt soon. I've used OO in class projects, but I want to figure out how to use it in my own projects. I want to learn software engineering practices. I want to learn graphics programming. That's just over the next couple of years! In 10, 20 years time, who knows? The appeal to me is that I can never peak in programming, their will always be new stuff to learn. Anyway, where was I? Oh yeah, my point was that I'm a noob now, I'm very willing to be modest and learn from others, but the hope of becoming a genius programmer I find very motivating.

stcredzero 17y ago

Ward Cunningham is a great role model. He's super-smart, darn clever, and just a really soothing sort of laid-back guy. He doesn't have to struggle with the alienate/suffer fools conundrum because he's aware enough to be learning something from the majority of his interactions with other people. If you can achieve that, you can conserve all the energy you'd waste swatting at fools.

kunqiana 17y ago

From my point of view the video is basically saying collaboration is most important as a programmer. Unlike athletes, programmers have to work together to achieve something great. Anything that is really impressive/great will come from the contribution of many programmers (eg linux). The question is: what is the most effective way to collaborate? Is there something about the ego that makes us ineffective? It would be really interesting if they had elaborated more on what makes a "healthy ego". Personally, as one of the critics has said, "people have egos no matter how humble they appear to be." It is simply human nature. Perhaps sometime it is more important to not to dumb down our own egos (or other people's) but to be more empathetic and reasonable working together.

pj 17y ago
In all fields, there are soloists and there are teams. There are team sports and individual sports. Michael Phelps is a soloist. S. Wolfram is a soloist... he has a backup band though...