HackerTubewatch
Surprise me
Frame from Google I/O 2009 - The Myth of the Genius Programmer Plays via YouTube's privacy-enhanced embed

Google I/O 2009 - The Myth of the Genius Programmer

20 videos recommended on HN
YouTube
5 HN users recommended this talk5 months2011–2024 score 6.5
Years with an HN recommendation, 2007–2026

HN regulars recommend it as a career-shaping talk on code review, humility and collaborative development.

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.

“One of the best talks about code reviews and similiar things” (HN, 2016)

3 strong recommendations · 2 recommendations · 3 citations · Talks

8 Hacker News comments

From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.

@bajsejohannes Apr 2011 Strongly recommends
on HN thread Your taste is why your work disappoints you.
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)
Talk that changed their view on publishing unpolished code.
@sethops1 Jan 2024 Strongly recommends
on HN thread FAQ on Leaving Google
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.
Talk that shifted a programmer toward professional engineering thinking.
@coppolaemilio Sep 2014 Recommends
on HN thread Ask HN: What do you do when you realize you are not a programmer?
"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]
Reassurance that you needn't be a genius programmer.
@maze-le Feb 2018 Recommends
on HN thread Ask HN: Is there no place for people, who are average at something?
Read more
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]
Touches on being average and the genius programmer myth.

Citations, criticism and jokes

@mqsiuser May 2014 Cites it
on HN thread What Programming is Like
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
@octosphere Nov 2018 Cites it
on HN thread Ask HN: As a programmer, how do you know if you're a good one or not?
Read more
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]
Cited for further research on the bus factor.

Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.

Keyboard shortcuts

/
Search
j k
Next / previous video
r
Surprise me
l
Like (video page)
w
Watch later (video page)
?
This help
Esc
Close