Slashdot Mirror
Larry Page and Sergey Brin Are Lousy Coders
theodp writes "Don't tell Business Insider's Nicholas Carlson about Santa and the Easter Bunny just yet. He's still reeling after learning that Larry Page and Sergy Brin are actually pretty lousy coders. That's according to I'm Feeling Lucky: The Confessions of Google Employee Number 59, a book about the company's startup days by Douglas Edwards. 'I didn't trust Larry and Sergey as coders,' Google engineering boss Craig Silverstein recalls in the book. 'I had to deal with their legacy code from the Stanford days and it had a lot of problems. They're research coders: more interested in writing code that works than code that's maintainable.' But don't cry for Larry and Sergey, Argentina — even if the pair won't be taking home any Top Coder prizes, they can at least take solace in their combined $50+ billion fortune. And, according to Woz, they certainly could have kicked Steve Jobs' butt in a coding contest!"
The computing world works specifically because some people have ideas and others have the ability to implement those ideas. And the few who can handle both of those are not generally going to be capable businessmen. It is a rare individual who can excel in all three roles.
In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
They're research coders: more interested in writing code that works than code that's maintainable.'
So you're basically criticizing them because they're good at prototypes instead of production parts? Seriously? The world needs both prototype engineers and production engineers. STFU.
Non-story/trollbait.
--
BMO
That's pretty normal for PhD students.
Most of us are aware of better coding practices, but getting things done on academic schedules tends to result in whatever can be done before reading week or before tuition is due or the like.
I've always seen software engineers point fingers at other engineers and say that their work sucks. It's the one thing that remains constant in this industry and it's no different from any other competitive field. Most of the time however the guys pointing the fingers have more skeletons in their closets in terms of bad code and use it as a deflection mechanism. Sure, there are incompetent coders but they usually wind up moving into management or the fast food industry.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
I don't think it's fair to criticize old code by today's standards.
For a lot of these mega-successful people, it's not the beauty of the code, or the maintainabilty of it. It's having the idea that software can do something, that this something is valuable and can be used as an engine drive profits, and then getting there first. Making it as good as it can be comes much later, if ever. Seemingly not at all if you're Microsoft. Not being able to code doesn't mean that much.
You see? You see? Your stupid minds! Stupid! Stupid!
And he didnt even have access to an 8080 CPU while writing it. He wrote a 8080 simulator on a Harvard computer. Punched out on tape and sent Paul Allen to New Mexico to test it. This impressed me.
I work for one. In the startup stage maybe 50% or more of the work is coding. But then you ad sales, managers, testers, corporate, documentation, yada, yada.
more interested in writing code that works than code that's maintainable
That's how business works in general. You want to write good code, but deadlines and shifting goalposts turn all your best plans into a swamp.
He responded by telling her that he went to school for sales and not writing. He then told her to look at his book and it how it says "Best selling writer and not best writing writer".
I don't know...kind of seems relevant here in that well written fill in the blank has little to do with monetary failure or success
Disclaimer: I have never read one of Kiyosake's books, so I don't know if he mentions this in one of them or not, but I thought it was a pretty insightful.
fwiw, I feel the same way as metrix007. The application is statistical computing, and the environment is typically R with some C for non-vectorizable loops and such. I write in emacs.
The thing is, not everyone who codes is a coder. If your job is to write maintainable software, generally to other folks' specs or ideas, over a period of months then, yeah, you'd better play nice. That job sounds like hell to me, and I'm glad I don't have it.
95% of the code I write never gets re-used, because the idea it was implementing turns out to suck, and it's hard to know in advance. It makes a lot more sense to just rewrite from scratch the 5% that ends up useful or interesting to other people.
"They were pure niggers." – Noam Chomsky
I am a biologist working with computers (statistics, bioinformatics etc). My main problem with CS students is that they are more concerned with frameworks, coding principles, version controls, choice of the right language than whether their code actually works.
Biologists rarely get the things right. I had a brilliant student who came up with a new algorithm and actually discovered something new (in biology), but the code was an awfully coded Perl program without a single function declaration. But it was correct and produced interesting results. Contrast that with a CS student who spent three months of his thesis on building a Java framework for an algorithm that he did not come up with and produced a shiny tool that in the end turned out to be useless.
You can find people who know how to read instructions (e.g. SVN manual) and produce clean, reusable, maintainable code by the dozen. Finding the people who have new ideas -- that is the hard part. Even if their code sucks, if their thinking is right, there will be money to pay a self-rigtheous CS student who will, in his words, "clean up the mess" (but will not otherwise come up with anything substantial).
So maybe LP and SB are lousy coders. But then, they are great hackers.
I remember reading an interview with one of them several years ago (I believe it was Brin), where they talked about the original homepage. At a time when other search engines were cramming as much crap onto their homepage as possible, Google stood out for being very minimal and serving up "just results" very quickly.
He said they were amused when people gave them compliments for taking such a bold move and assumed it was an intentional departure, but in reality they just didn't know HTML and cobbling together a single form and crappy logo was pretty much all they could manage (or were interested in).
I am typically the first guy to do an implementation. After that a bunch of guys come in and they refactor the code.
I pass all acceptance tests. (Typically a cucumber suite). The people I work with know this.
When I am contracting time is money. I don't refactor unless you pay me.
I can refactor that code as well as anybody, but by that time I'm typically called away on another project.
(My last assignment was writing a REST API while in Vietnam 5 subcontractors were writing a mobile app against my API on a nightly basis. That was a major pITA since they were 12 hours ahead of me. I prefer working against the West coast, three hours ahead is pretty much ideal.)
Now after I'm done In typically think of a much more elegant way of doing things, but by that time I'm usually on something else.
One thing: My hastily written code is nicer today than my refactored code was 5 years ago. So I guess I am improving.
People that hire me typically couldn't care less about what tools I use, or how elegant my code is.(Unless you work for a software company; I deal with a lot of businesses in totally different fields that need an issue solved, and need it done quickly.)
Hajo Monogamy: Belief so strong that millions of people end perfectly good relationships in order to start a new one.
I don't know of any coders who started off writing easy to maintain code. /* revising other people's first draft of code just makes you over-confident that you are better than they are when that probably isn't true. Compare first drafts to first drafts, not to final code after all the bugs have been worked out and the customer has finally started understanding his own requirements */
Most of the coders who do _write_ code that is easy to maintain only do so after having to come back a month or year later and revise code they themselves have written.
There are even good business reasons not to worry about maintenance, such as if the product doesn't fly, then maintenance of it is moot. And if writing easy-to-understand code slows down getting the product out the door, don't do it.
I wouldn't call the guys who wrote the best search algorithm known to man "lousy" at what they do. Perhaps unconventional, but certainly not lousy.
What is it with the Uber Coder mythology? The developer community has its own values. Each profession has certain ideas about what is valuable. Many people value money - that when someone asks how much you make this is a proxy for making a personal judgement. Coders generally don't judge based on money. They judge based on intellect. Not real intellect - that is far too difficult to determine, but rather perceived intellect.
As a result we see a number of interesting effects. The first is the prima donna whose code is impossible to read and proud of it. If anyone questions it they usually reply that if you can't read it it is because you are not as skilled or intelligent as they are. Another effect is that overt technical skills are valued above soft skills. This means that becoming a manager or team leader is seen as almost selling out and becoming the Pointy Hair Boss.
This fails to understand that success in software is not highly correlated with these 'geniuses' who refuse to play nice or refuse to manage teams. Success is correlated to effective teams who actually work at their communications and team development disciplines. The success stories we hear about may or may not be highly skilled; this is not a differntiator. What is key is the ability to develop and maintain effective development teams, and to manage them in a way that gives them the autonomy to be creative but the dicipline to ensure the deliver value.
The skills Larry Page and Sergey Brin brought to the table that allowed them to succeed were not coding skills, and I think that the implicit critique of their technical skill devalues the real reasons they made it.