Google I/O 2009 - The Myth of the Genius Programmer
ฝัง
- เผยแพร่เมื่อ 16 พ.ค. 2024
- Google I/O 2009 - The Myth of the Genius Programmer
Brian Fitzpatrick, Ben Collins-Sussman
A pervasive elitism hovers in the background of collaborative software development: everyone secretly wants to be seen as a genius. In this talk, we discuss how to avoid this trap and gracefully exchange personal ego for personal growth and super-charged collaboration. We'll also examine how software tools affect social behaviors, and how to successfully manage the growth of new ideas.
For presentation slides and all I/O sessions, please go to: code.google.com/events/io/sessions.html - วิทยาศาสตร์และเทคโนโลยี
I'm here because of jwasham repo.
me too
thronecode what is jawsham repo?
thronecode thank you !
same here
Me too,
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
the bus factor was also important
+Albert Vila thanks 1 hour saved
+Albert Vila They had a summary in the video.
+Albert Vila And this one: "You are not a beautiful or unique snowflake. You're the same decaying organic matter as everything else." ;) Deeeeep bro deep. :P
+Fashy Gainz - "beta cucks"? You are not a genius. Attempting to pull others down to your mediocrity isn't going to make you any better off. Obviously learned nothing from the talk.
FYI: Video glitches out at 27:50 then recovers at 28:16.
thanks
Thanks
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.
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'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.
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.
Like you?
Yer fancy talk don't 'mpress me none
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.
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.
Don't bash yourself buddy, use C++...
lol. why? So that he becomes even more doubtful of his ability?
I wouldn't have really thought that someone with a 100-box perfectionist nature would have such grammar issues.
Perfectionists want all the criticism they can get, above and beyond all their own self-criticism. It helps them increase their degrees of perfection. Sometimes it helps them live even less delusionally. They prefer to live without delusions.
"I have to check a 100 boxes for me to be actually confident about my work. Its *just my perfectionist nature*"
lol, way to try to turn your defect into a good thing. Very unlikely that you're a perfectionist, especially with that grammar, as Ellie noted; probably just bad at coding.
_"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"_
Goddamn, stop trying to make yourself look special. Everyone wants their code to be perfect.
11 years old and still for the most part relevant. Loved it!
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.
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 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.
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.
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.
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!!!
I NEEDED to hear that. This is good advice that extends beyond the programming field. Thank you Google.
A must see video for every programmer!
You guys are wonderful speakers! Hats off! I will have to keep visit this video over and over !
So much wisdom. Totally gonna summarise this for my next developers meeting.
Thx guys
Also, I thinking defining what is a failure is another important thing to be aware of.
"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* ".
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
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.
These are some great real life lessons for software developers. Thanks.
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.
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
this talk has definitely changed the way I look at making software
This makes you feel better about your skills. Great 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
In the time to do it 'right' , the company will go bankrupt. I know few companies that spent 2-3 years and went bankrupt.
Too many cooks(programmers) can and will spoil the dish. I remembered management though one year man hours to complete a program project can be done in one month if you throw in twelve programmers. Same as if you can get nine woman together you make a baby in one month.
5mins in and I have to say that these two are just so cool. Really enjoying this.
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.
I love these guys!!!
"If you have different opinions, please get your own talk at your own conference" :D
Looks like a glorified form of my year end review :)
good stuff -- they are making their point convincingly w/ an element of humor !!
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.
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.
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
"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 TH-cam (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".
+calind79 Yes. It originally was. Today, though - github.com/FFmpeg/FFmpeg/blob/master/MAINTAINERS
@@laurent-simpliciteetminima5793 I know, but I pointed out ffdmpeg as it's used by TH-cam for recompression, hence the irony.
@@calind79 right!!!
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.
Mariano undergraduate these day only know windows and their crack version of everything plus they (generally) develop some kind of hatred against documentation.
Genius comes from your hard work, i surely cannot hide my work if it was not the perfect version of my work.
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.
It's no myth - *I* am that programmer!
Sarah Cartwright are you sure you're not a unicorn?
+Bogdan Barbu I am both!
+IARRCSim Small pot bellied pig...
+Sarah Cartwright No doubt about it Sarah so now back to your cave. Don't frightening anymore all the normal ones! :)
+Yvon Colin And here we see the socially inept nerd trying to mingle with the female species.
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.
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
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.
There is also a fear of losing credibility that comes from having nasty office politics that depend more on ego and prestige than actually caring about your codebase. A good mantra is to strive for egoless programming: c2.com/cgi/wiki?EgolessProgramming
Mind you, this largely has to be part of the culture.
Simple yet powerful information.
Great talk on the psychology behind effective collaboration
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.
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.
I actually listened to this all and enjoyed it :)
This really helped me, thanks.
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 can't agree with you more man, well said.
I recommend that you not exit before Q&A. It's actually the most useful and interesting part of the talk
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.
Not sure I would be a senior Android engineer today if I hadn't watched this talk in 2009.
how was this so impactful?
Thanks for subtitles! My verbal english skills is not too good, but i can read.
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.
What a great talk :)
it's more or less how it works. the major difference between wikipedia and version control is that version control is either an addition to the shell or to the editor/ide, whereas in a wiki, the editor is a component of the wiki. a good, purpose-built svn client feels a lot like a wiki.
code review works more or less the same way as well; the only difference is that programmers generally can't take criticisms as well as most other people.
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.
Prob is: Someone might get your code and idea and steal it.
This mainly focuses on open source. If you're open sourcing you're code, that risk will always be present no matter how late you release it. If you want to protect from this, use a license so you have some legal ground. And if you're not open sourcing and just working on it with friends, then get some trustworthy friends.
I meant with Google, because they encourage the sharing of code. In general it's way too obvious I guess.
I've had people steal my code.. at first i was pretty upset but then i just wrote more/better code. And because the thieves had tried to sell my first round of crap, people were interested in the next versions. So the thieves did some of my marketing for me. They tried to steal and sell the next versions too, but I just stayed a step or two ahead of them.
There is a certain kind of customer that is more trouble than they are worth. They want a bargain, and then they ask for a lot of support. These kinds of customers and thieves gravitate towards each other. One wants a cheap deal, and the other has one. This keeps both kinds busy and out of my way.
Dan Kloke yobpcviugn njvgty
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 ;)
Good talk! Learned a lot from it.
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.
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
Opinion!!
This is overstated rationalization, for not working adding the feature.
:(
Cool description. So about those Stack Overflow Moderators
great talk, thank you
Shows up in my recommendations in Apr 2020
2022. this still makes sense alot
Thank you
The guy at 45:17 took the words out of my mouth.
I am a developer and i always thought i was some kind of a genius.. I often felt like superman when i pulled off something.. Everyone treated me that way too.. But then it hit me.. I and we are pawns in someones game of chess.. Designated to move forward and eventually die.. The real genius were the guys who made me feel like a genius.... And made me bust my head for them
sounds like a great novel
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.
Same thing I was thinking..
Little Fishy I thought; I choose my path at the end of the day.
Just watching this to see where programming is at now a days.
I wanted to hear more from the "psychologist" guy because I expect that while what they describe is ideal, a lot of reality isn't, precisely because it's hard to deal with those non-ideal situation that people brought up ("how do we deal with people with huge egos?"). I consider myself somebody with little to no ego. I've been told to "be more aggressive."
How do we "fix" an environment in a place where many times, leadership doesn't want that precisely because it makes them feel good even if it's not good for the company? I remember reading a while back about this research that a big part of why companies fail isn't because of the people under leadership but poor leadership itself. (Think about all those "too big to fail" companies.)
The summary of it was that if you have poor leadership but great employees, your company can still fail (think Apple in the early days). If you have great leadership but poor people (think Microsoft now), your company just might have a chance. We still blame employees today because they're easier to target. (Poor as in poor performance. Hard to write in this little comment box.)
Yet you'll often see in articles floating around saying, "how to be the perfect employee, how to do your job right, always be this, always be that" but even less article for leaders and managers (the counter argument is that there are more Indians than Chiefs). Any other articles I've read on becoming leader is just another form of "how to be a good employee" or some form of feel-good writing.
Speaking of feel-good, I also feel like that any ego I might have has protected me more than it has hurt. Imagine if employers were to see my many false-starts. Would I still get the job? Compare that to another candidate who had the "perfect history." For those of us relatively new to the professional / real world, I can speak for many of us when I say we've been trashed before by these anonymous people and don't think there is much change in this area unless something in the environment has actually changed (for example, increased moderation).
So it isn't necessarily insecurity. I wouldn't mind showing false-starts if it meant employers understanding that I could do that job. Otherwise, this talk is basically "here are some ideal situations. Do that and be this. But if you run into a problem or your environment doesn't allow for it... well, sorry, we don't have an answer for that."
Basically, I'm not scared -- I'm frightened. I'm constantly overwhelmed and constantly dealing with hard problems (many of which actually don't have a solution) and there seems to be nobody around even though there are billions of people on this planet and we're all connected.
I just wish there were more concrete solutions. Otherwise, this talk is basically a "here is what a paradise would look like but we have no way of making it happen for more people."
Nice video I agree with most points
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.
Great video
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.
Robert Engels Truth at its finest.
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.
I should not always hide code, because I was always helped by people they willing their source(Open source). I always google coding stuff want to get help.
this is the time i also should share.
The suggestion to connect with nature makes sense to me, as it gets us away from the everyday world that fosters the elitist mindset. And it's very good to bring down to earth friends, but all should be welcomed who are open to it, even if they may not be quite freed of their neuroses. :)
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!
God! These guys are Genius! Oh, wait...
Nice talk
Since genius in every field exist so there must be programming geniuses as well...although there may be a handful of those
This great for all areas of academia
Perfect
You are unique... just like everybody else...
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.
About 28:00 i have some serius issues watching this, It stutters, no sounds etc.
"She asked to see my python,
I only know JavaScript"
Yeah, intelligence is a tough concept to grasp...for one thing, it's necessary to distinguish fluid and crystallized intelligence. We seem to be making a lot of progress with it though, partly due to advances in AI. I should also clarify something else I said earlier, that I am no longer elitist. The truth is that I'm no longer AS elitist as I used to be, but I still hold elitist views in some ways, sadly. These are very hard to extricate oneself of; I believe it requires re-socialization.
BUT IM A GENIUS! I swear. Back to the cave now...
Ok, I have mostly worked with CVS which is ok, but it's really old technology.
If the software could be 'atomized' like separate articles, then that would significantly improve the development speed for large projects. But that's easier said than done probably. :-) It would require a new abstraction level in software development.
what happens at 27:55?
And 32:00 is great - totally agree! Hate those, who create 99% and then share shier code for checkout. :D
Great video. Love these! :)