Google I/O 2009 - The Myth of the Genius Programmer
Google for Developers5 HN recommenders · recommended in 5 months, 2011–2024
talk · general · evergreen · 2011–2024 on HN
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.
HN regulars recommend it as a career-shaping talk on code review, humility and collaborative development.
Up next
9 mo on HNJonathan Blow - How to program independent games - CSUA Speech
Alexandre Franco
9 HN recommender · 2015–2026
3 mo on HN35C3 - The Ghost in the Machine
media.ccc.de
3 HN recommender · 2020–2023
4 mo on HNBut what is a Fourier series? From heat flow to drawing with circles | DE4
3Blue1Brown
4 HN recommender · 2020–2025
2 mo on HNJoscha: Computational Meta-Psychology
media.ccc.de
2 HN recommender · 2018–2020
4 mo on HNDrone Delivery Was Supposed to be the Future. What Went Wrong?
Wendover Productions
4 HN recommender · 2022–2023
11 mo on HN🚀 TDD, Where Did It All Go Wrong (Ian Cooper)
DevTernity Conference
11 HN recommender · 2018–2024
11 mo on HNBret Victor The Future of Programming
Joey Reid
12 HN recommender · 2017–2026
10 mo on HN"Uncle" Bob Martin - "The Future of Programming"
Paul Stringer's Mobile Tech
10 HN recommender · 2016–2022
10 mo on HNTim Ewald - Clojure: Programming with Hand Tools
ClojureTV
9 HN recommender · 2014–2024
9 mo on HNUsing Python to Code by Voice
Next Day Video
12 HN recommender · 2013–2025
9 mo on HNTransforming Code into Beautiful, Idiomatic Python
Next Day Video
9 HN recommender · 2014–2022
9 mo on HNAgile is Dead • Pragmatic Dave Thomas • GOTO 2015
GOTO Conferences
11 HN recommender · 2016–2026
8 comments from Hacker News
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.
Google I/O 2009 - The Myth of the Genius Programmer One of the best talks about code reviews and similiar things ▶ this video
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)
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
"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
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
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
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