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

I'm here because of jwasham repo.

Summarizing: There is no genius Lose the ego Criticism is not evil Embrace failure Iterate Quickly Be a small fish Be influenced Be vulnerable Tools Involve collaborators early, but not too (at the 'sweet spot') In other words: Don't try to be a genius Collaborate early and often Pay attention to your tools Pay attention to timing

FYI: Video glitches out at 27:50 then recovers at 28:16.

The synergy between the speakers is amazing. They tag team each other brilliantly. And I am so conscious of the bus factor that I think my employers and clients think me daft.

"How long will you drive around lost before you stop and ask for directions?", Depends on the neighborhood you are in.

11 years old and still for the most part relevant. Loved it!

Listening to this talk, specially coming from people who work at Google, made me feel much better about my work. We programmers are also human and we will make mistakes, the best thing we can do is try not to repeat them. And there may some genius programmers, but for 99.9% of the programming community, this level of humility will do just fine.

I always love the types that try to use obscure vocabulary to make it appear that they are extraordinarily intelligent. this isn't just in the world of computers but everywhere.

I feel so good watching this, because I'm someone who's very skeptical of my own abilities, I have to check a 100 boxes for me to be actually confident about my work. Its just my perfectionist nature, I also suffer from paralysis through analysis, where I will look into something to the finest detail and get discouraged if i can't solve one aspect of it. This talk kinda tells me not to fear failure but simply jump into whatever you're doing and learn to swim.

This talk is so true. I'm a freshman computer engineering student, and the first thing I was taught in my CS class was pair programming. Knowing how to work in teams and receive criticism with humility is invaluable to all areas of engineering.

Such a great talk, looking at geeks' life from psychology POV. The delivery is perfect by who seems like genuinely nice and smart guys who actually speak from experience.

I'm not a programmer but I know a corporate talk when I hear it. Internal, employee relations cutting their creative assets down to size so they don't get cocky. It is a effort to trivialize self-identity and discourage independence. "Remember, you're part of the team! Don't go off on your own because you'll fail because you're nothing." This is pure corporatism.

You guys are wonderful speakers! Hats off! I will have to keep visit this video over and over !

thanks for changing my life... now I can follow my passion that my heart always asked to go for ...

This talk has really so many invaluable lessons!!!

A must see video for every programmer!

I NEEDED to hear that. This is good advice that extends beyond the programming field. Thank you Google.

5mins in and I have to say that these two are just so cool. Really enjoying this.

So much wisdom. Totally gonna summarise this for my next developers meeting. Thx guys

Great talk, I really loved it. Many mentions of code review: Worth mentioning that pairing seems to be substantially better at reviewing code than code reviews are. Pairing also has substantial other benefits.

This talk is in resonance with the art world. There's this book on how to succeed as an artist called "Show Your Work" by Austin Kleon. He talks about this cocept of scenius insted of genius, means that scene is a bunch of people working in one field together. It's a collective intelligence that helps us to stand on the shoulders of giants. You are never alone. Let's colaborate more openly.

I am glad I found this video. Being a programmer you often if not always have to deal with rivalry, people who undermine you to better valorize themselves. They even come to spend more time undermining and making smear campaign than they actually working. Especially in France... I am the mythical programmer by the way.

I think this video is good enough for all the youngsters out there thinking of changing the world. They would get to know which direction they need to move so they dont waste their time....Thanks for the video google

It's so weird listening to this 12 years after it was filmed and listening to them refer to a bunch of tools I've never heard of and no longer exist.

Whaa! Way to make me feel old. I vividly remember the discussions about CVS vs Subversion and than the wonderment that a third competitor actually won the race that seemed to be the most impractical (At least now I talk about git)

I still resonate with these guys after about 10 years. These opinions are time-proven. I hope I have learned before starting on my project. But what do they say, it's never too late to learn.

This makes you feel better about your skills. Great Talk

These are some great real life lessons for software developers. Thanks.

Being insecure in our field isn't always a bad thing. For example, the strong desire for approval often is the main motivator for people sitting on forums like IRC and StackOverflow all day just trying to answer peoples' questions. People like that provide a tremendous service and are often the ones who really solved the toughest problems you couldn't break. They're unsung heroes. The free outsourced extensions of every team in existence and I hope they always exist.

I love these guys!!! "If you have different opinions, please get your own talk at your own conference" :D

Also, I thinking defining what is a failure is another important thing to be aware of.

this talk has definitely changed the way I look at making software

Simple yet powerful information.

Great talk on the psychology behind effective collaboration

I actually listened to this all and enjoyed it :)

"some people learn by trying and failing" YES. I've also heard it said as, "if someone is learning something, for god's sake *let them do it badly* ".

Sharing my notes on from this great talk: * There are no geniuses * Drop the Ego * Criticism is not evil * Embrace Failure * Failure is nice if you are not doing the same mistake repeatedly * Document the failure. That’s why Google does Blameless Post Mortem * Iterate Quickly * Don’t just fail, fail quickly * Faster you will execute, faster you will iterate, faster you will learn * Practice is key * Be a Small Fish * When you are big fish in pot, you are comfortable but you are not learning a lot * Being a small fish in big pot is scary but also is educative * Be influenced * Respect is the two-way street * If you can admit your mistake in front of your peers, you will be vulnerable * Be vulnerable * Don’t afraid to tell your mistakes. Others will appreciate that. * Pay attention to your tooling. * Tooling will affect the way of your collaboration. If you do all these things, people will think you are a genius 42:19

I have always followed their view on coding even before this video even though I am an amateur my peers really do look up to me for that because even thought the biggest software I wrote so far is 2000+ lines of code I made sure to give it to my peers to review it or give me suggestions some times they didn't even want to give suggestion cuz the project didn't interest them but I made them do it for my sake so I can kinda approve these guys stuff

What a great talk :)

This really helped me, thanks.

I came across this video after just googling random things and I'm not a programmer, although a little familiar with it but this video wasn't relevant to me in that sense but that doesn't matter. I think this applies very well to anything really like he was talking about playing the banjo, but also in sports, or for practicing medicine, or law, writing music, etc etc. Don't be afraid to fail, fail fast learn quick, collaborate with peers to be better as a whole. Just found it very insightful.

great talk, thank you

Not sure I would be a senior Android engineer today if I hadn't watched this talk in 2009.

It is interesting that Brian and Ben spent several years rewriting CVS as subversion. Linus took a few weeks break from kernel development to hack together the core of what became git. (Yes, it took a while to mature, but the core was in place very quickly.) Maybe genius is rare, but there is plenty of evidence that it is real. The problem comes from everyone believing that they are the genius. (Yes. Do lose the ego.) Consider also who employs Ben and Brian. Perhaps they have an institutional bias toward collaborative tools. ;-) Revolutions are never started by a committee.

9:15 study with a buddy 12:50 truth in much of life 15:25 good insights 45:ish what is a genius? 47:40 funny End: That was a good talk, had a lot of truth to it. Remember that nothing exists in a vacuum and while every area of practice has its customs and inherited problems much can be learned from interdisciplinary studies. Working in groups either witting code, writing a book or making a stage play has its similarities. Good talk.

Good talk! Learned a lot from it.

Looks like a glorified form of my year end review :) good stuff -- they are making their point convincingly w/ an element of humor !!

Thanks for subtitles! My verbal english skills is not too good, but i can read.

"Can you name a piece of software that's really successful, really widely-used by a lot of people and was written by on person?" Oh, the irony. ffmpeg was written by one person (Fabrice Bellard) and is used by RU-vid (part of Google). Also, I love it when people end their presentations with "well, we're talking about an ideal but it's pretty difficult to do in the real world".

Cool description. So about those Stack Overflow Moderators

2022. this still makes sense alot

Thank you

I, for one, use git rebase to clean up a bunch of illogical commits that I make as a means of saving my work. I'm not afraid of people seeing me make dumb mistakes, as evidence I point to my github repos, I just don't want my repo to be a bunch of commits that make no sense as discreet units.

Genius comes from your hard work, i surely cannot hide my work if it was not the perfect version of my work.

It's no myth - *I* am that programmer!

I'm only 8 minutes into this video, but they've already nailed a crucial point: the fear of looking stupid leads some programmers to do their work privately and behave territorially, which in turn inhibits collaborative software projects. I think this observation gives credence to the validity of XP-style paired-programming.

I can't agree with you more man, well said.

Great video

Shows up in my recommendations in Apr 2020

I recommend that you not exit before Q&A. It's actually the most useful and interesting part of the talk

I've worked the many coders over the years. Some were geniuses in some areas, and others in others. But, for the most part, virtually all programmers where just throwing code together to get projects done. They wrote code with no regards to future maintenance. The also didn't consider how changes in one section of code affected the whole system in the long run. There was never time to do it right, but there was always time to do it over (and over, and over) : P

I always want people to see my mistakes so that I can use them to advance... This is why I attempt to network to as many individuals as possible. Every mistake is a valuable tool for advancement as it shows how not to do something.

53:40 is the perfect example of bias in the workplace. The speaker was clearly speaking about situations he finds himself for factors that are not easily observable and the speakers being completely oblivious to what he is talking about because they are not affected by such biases. A bias is like what was once called an "unwritten rule" and when the "unwritten rule" is broken, it manifests itself as a bias. Such "unwritten rules" are cultural, ethnic, social in nature.

Nice video I agree with most points

Prob is: Someone might get your code and idea and steal it.

Oh! Pairing discussed in the questions! :-) I find pairing to be more harmonious and collaborative, while code reviews are confrontational. I guess each one works differently in different teams.

I have been working on programming for over 13 years and liked the talk. The problem is not about individuality, socialism, or even being a genius, but thinking you are a genius when you are not. There's A LOT of developers who think they are super smart when they are just ordinary guys. And no reality check can convince then otherwise. Unfortunately, when it comes to computing this kind of attitude can mean the failure of projects.

Having collaboration and creative tension between programmers is not necessarily the opposite of having key x10 contributors. It is instructive to see what these presenters have done (or haven't done, as the case may be) in the previous eight years.

Nice talk guys. Despite talking about the ideal thing, it can be applied in the real world. I've just seen two examples of starting something and calling people in: one in software and one doing crosswords ;)

I can agree with this talk. Sure, some people are just smarter than others, but most experts are only experts at 1 or 2 things. In programming, collaboration will always produce better results...unless you're collaborating with unskilled workers. In the end, it all comes down to putting people on a pedestal. I, and many others, have come to realize these people that we put on a pedestal, are just that, people, like you and me. Once you realize this, it's mostly about motivation

Good talk!

This great for all areas of academia

God! These guys are Genius! Oh, wait... Nice talk

You are unique... just like everybody else...

man i wish i could be that calm in front of people

The mythology about our idols is all that keeps me motivated, remember how dry the stuff we do is, if we don't keep this interesting, we might as well go back to having the people in the caves being the only ones who care to know how things work.

This is a perfect example of why the 'every kid gets a trophy' mentality is so dangerous. You didn't need code reviews and constant critique to move you along a different path in life - the clock or scoreboard did it for you. The fallacy that if you were "picked last for kickball" was due to some personality contest - just the opposite - it is a prime example of highly effective teams at work. If the "captain" didn't chose winning teams, the players would no longer make him the captain, so he was forced to pick those that gave his team the best chance to succeed. Being picked last should of been, and probably was, a decent motivator to move on to something you were better at. Now make it a development team - I would rather have two "geniuses" that didn't like but respected each other, than ten poor to mediocre developers that got along famously. The best make up would be to add two very smart egoless (impossible) know-nothings to the geniuses, because at the end they would probably be the most effective. Far too often, in my experience at least, the worst thing a team can do is keep bad programmers programming - usually for the sake of moral/loyalty. The destruction they cause takes years to repair if its even possible - usually those projects just die because they are unmaintainable. Keeping people in positions they are not qualified for does no one any good - especially the misplaced "developer". Either that or go to work for a company that makes so much money off one aspect of the business, that 95% of all of the work of all of the employees never amounts to anything and is abandoned (so why worry about the quality? team harmony is far more important) and hide out until the someone realizes the emporer has no clothes.

Opinion!! This is overstated rationalization, for not working adding the feature. :(

I find that the way people convey their criticism, is really the biggest factor for me not wanting to work with others. Not a lot of developers know how to critic someone's work without being snarky and unproductive. It probably stems from the same insecurity in all of us, to be better than the person you're criticizing.

I see it all the time on IRC. You have folks on there who CAN help others, but they will lead others on and on and on. They will make you think they want to help you, and then they will hand out the most vague, time-wasting advice (ie, terminal commands, code examples)...not really enough to help you, but enough to bring glory to themselves in the channels. It's better to just say "thanks for trying to help" and then re-ask the question 30 minutes later.

The video glitches out at around 28:00. I'm not sure if it's because the video is so old that the compression has killed that part. Maybe google could look into this

My company only hires two types of programmers: Geniuses, who do all the heavy lifting, and Drones - who do the monkey code. It's true everywhere - don't let anyone tell you otherwise. Every successful commercial product / project has at least one SuperStar. Period. You can't succeed without them. Google knows this, and that's why they want you to believe that no one needs SuperStars. So you feel better about being a Drone for them. LOL They need lots and lots of Drones.

Exactly. To be selfless without concern for oneself is actually to neglect oneself, which is evil. To be totally selfish without concern for others is also evil. That's what I meant by that we need to be concerned BOTH about ourselves (ego) AND others at the same time.

nice speech

I keep wanting to turn my headphone amp down because of the feedback loop.

Since genius in every field exist so there must be programming geniuses as well...although there may be a handful of those

cool ideas

really nice talk that my favorite career.... hey guys i'm a foreign student here in the U.S planning to become a computer programmer but i don't know where to start i also don't know anything about computers. Can u guys give me some tips i'll appreciate for that. It was really nice presentation u guys are great and u inspired me.

Judging by how buggy Android is, I can tell there's certainly no Genius Programmers at google lol

"She asked to see my python, I only know JavaScript"

at 8:45; Well, not just 50 years ago, but there is something to be said for writing code to completion without worring about syntax issues.

You've got good attitude! Good luck! But i also agreed with the person you replied, there are genius programmer call assembly programmer. Really they are genius! To my opinion, they are best at working alone!

2009 : Google has a code hosting platform and is supporting mercurial. 2022 : What's mercurial? What's google code?

simply love this comedy

33:40 "to early" part is cool

I love the free lunches company cfos and cios buy you to hear you talk about how much of a genius you are........

Asking Google to hide your data...only a genius programmer could come up with that idea.

2021: Still makes sense

Instant like for the fight club quote.

Very true that there's still much more to discover about intelligence; but to the extent that AI has attempted to truly understand the nature of intelligence rather than focusing on building expert systems (which has been its main focus), it's played a major role in contributing to our very limited understanding of human intelligence. For example, cognitive models and architectures seem to fit this bill.