Brian Fitzpatrick and Ben Collins-Sussman argue that the 'genius programmer' ideal harms collaboration. They advocate trading ego for growth, sharing work early, and understanding how tools shape social behavior.
Why Hacker News points people here: HN regulars recommend it as a career-shaping talk on code review, humility and collaborative development.
“One of the best talks about code reviews and similiar things”HN comment, 2016
Talk that changed their view on publishing unpolished code.
Full comment
I recommend The Myth of The Genius Programmer: this video What you see on Github is people's polished code - you don't see what they are throwing away. They might be better, but you are probably looking at some of the code they are most proud of. (Actually, for my github/bitbucket page this is no longer the case. After I watched this video, I started publishing as much of my code as possible, if it actually did what it was supposed to)
Strongly recommendsoleksiypOct 2016
“One of the best talks about code reviews and similiar things”
Top talk on code reviews and collaboration.
Full comment
Google I/O 2009 - The Myth of the Genius Programmer One of the best talks about code reviews and similiar things this video
Strongly recommendssethops1Jan 2024
“Two talks given by Ben Collins-Sussman absolutely changed my career path”
Talk that shifted a programmer toward professional engineering thinking.
Full comment
Two talks given by Ben Collins-Sussman absolutely changed my career path from being a hot headed programmer to thinking like a professional engineer. The Myth of the Genius Programmer: this video The Art of Organizational Manipulation: link I rewatch these every few years, or before an interview. Puts me back in the right headspace. If you're reading this Ben, thank you.
RecommendscoppolaemilioSep 2014
“keep enjoying creating things. A google talk”
Reassurance that you needn't be a genius programmer.
Full comment
"I hated discussing what OO pattern should be used" "they submit patches to major frameworks, writes things in assembly for fun" You don't have to do this kind of things to be a programmer. Of course discussing OO patterns with your team is a need but submitting patches to major frameworks is on your free time! If every programmer would do so we wouldn't have so many incomplete open software. Try not to be chased by the "The Myth of the Genius Programmer" and keep enjoying creating things. A google talk: this video
Recommendsmaze-leFeb 2018
“Interesting video, that touches the issue”
Touches on being average and the genius programmer myth.
Full comment
Most people are average, thats kind of the meaning of average. I consider myself an average programmer advancing on an average career path and had plenty of recruiters contact me with interesting opportunities recently. Sure its not Google or Facebook, but so what, I wouln't like to work for a mega coorporation like that anyway. If you doubt yourself because you consider yourself average, consider that the constant talk of excellence, highest skilled people and so forth is mostly HR PR bullshit. Sure, there are extremeley talented people out there, but they are pretty rare. Interesting video, that touches the issue: "The myth of the genius programmer"[0]. [0]: this video
Cites itRyanMcGrealNov 2011Full comment
It's open source insofar as the code, when it is released, will be released under an open licence. However, it fails the 'unofficial' criterion of a project that is developed in the open . See also: this video
Cites itmqsiuserMay 2014Full comment
So, just as a reference: "Google I/O 2009 - The Myth of the Genius Programmer": this video There are quite a couple of possible views in IT, which makes it hard for us
Cites itoctosphereNov 2018
“Further research into the Bus Factor can be found here”
Cited for further research on the bus factor.
Full comment
Some basic heuristics I use for determining the capability of other programmers and myself: 1.) Does the code have a good bus factor i.e If the maintainer dies tomorrow by being knocked down by a bus, can other people pick up where he/she left off? Further research into the Bus Factor can be found here: this video 2.) Is the code well documented? This is so obvious that it is painful to write this comment, but it is a very simple heuristic for determining capability. Documentation can include code comments. 3.) Is the code resilient to weird input? The code should perform well under heavy fuzzing and where possible, sanitize different input. It should be tested against this: link
