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"
What in the world is the moderator thinking?
Well, if nobody knew, I guess it's still news.
More prayer and praise at the alter of Google. Wow. Just wow.
Their code wasn't up to par with business standards while they where still in uni.
How odd... who would have thought that such famous people would have to learn things as well, I'am shocked!
Here I was thinking that unless you where born with l33t programming skills and your first words are in binary you can never make it in the world.
But seriously..
Most famous people in business are not where they are now because they started out especially good in their field, they became who they are now because they had original idea's and worked endless hours to make it possible.
And if you're working on your project in your parents basement you usually don't worry about how to maintain your code as long you understand how it works.
This is something all coders go through at some point.
Almost makes SLASH look robust. Almost.
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!
My code is generally pretty ugly...because I don't care about maintainability, or even at times efficient.
I care about solving a problem, as it is a challenge. That's it.
Improving efficiency, making the code look nice, documentation...all these things are boring and I'd rather not waste my time on them.
And that's what most of coding is.
If you ignore ACs because they are anonymous - you're an idiot.
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.
Is the most delicious of all code.
If billg were working for most USA companies, and used the machine at work to do this side project, they'd own a "shop right" to use it.
These days, at most USA universities, the university gets the rights... If the university spent any federal government funds on that computer, then "government funds were used by an academic institution in production of intellectual property" so Bayh-Dole comes into play, and the university has the rights to it; the government has a "royalty free nonexclusive license for government purposes" and the student may or may not share in that. No amount of university/student agreements or policy is going to change that.
So we have the interesting scenario that if pushed.. the US Govt might have rights to Google. Stanford accepts government funds and has used Bayh Dole in the past (this came up recently in Stanford v. Roche).
Skilled researchers produce good research, then start a company based on the results and hire skilled software engineers to produce good software engineering.
Somebody finds this shocking.
Someone else is shocked that someone finds this shocking.
Someone writes to slashdot explaining that someone is shocked about someone finding this shocking.
The NSA has right to Google. Even if Google doesn't know it.
Do you even lift?
These aren't the 'roids you're looking for.
Is garbage, why does anyone link to that?
I wouldn't expect Ford to know how to assemble an engine.
I wouldn't expect Oppenheimer to know how to operate a centrifuge.
I wouldn't expect Ray Kroc to know how to refill the Coca-Cola syrup.
The article is fine on its own; it serves as a great doctor's waiting room tabletop article. Slashdot, on the other hand, need not publish it as news.
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).
After quoting a time schedule and costs, my previous manager once told me that "[He] doesn't know how to do that task nor understand the technical issues but doesn't think it should take or cost that much!" I guess if you can buy MS Word for $700, that is the ball park for any software task. I wish I had told him that he needs to buy a copy of MS Word and his problem is solved.
Unfortunately, most workers in the US revere top level executives as some sort of business geniuses. Call me "anti-business", but I believe most were lucky that they got in when the going was good and managed to hold on. I remember reading about William Penn (who at one time owned the land which became Pennsylvania). He leveraged himself too much and went bankrupt and died penniless. Since that time, our bankruptcy laws haven been changed to protect the wealthy and given them a chance to "reorganize" and keep "creditors at bay" until they get their finances in order. A case in point is Donald Trump who should be working selling hot dogs on 57th since the mid-1980's. Listening to him for half an hour on his "reality show" makes me want to puke. It would be good if that was his occupation, but his show was just a way to stay in the limelight for a bit longer.
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.
In novel writing, like in programming of innovative things, you should write it once, then write it again, as well as make a series of incremental rewrites in the second version.
You have different priorities the first time round. Get the most difficult core algorithm or core concept things implemented fast, to learn fast what's wrong with them.
If you were a really really good programmer, you might try to build in generality, modularity even in that first go around, but you would have to make sure it wasn't locking in half-baked concepts. That's why old AI programmers loved LISP. It lets you build some of the generality and modularity, encapsulation, in all the way along the process from exploratory prototype, but in a way that's way easier than in say Java or C++ to tear apart and fundamentally re-factor. Lots and lots of tiny functions, each one in a way its own type checker and complexity hider.
Unfortunately, economics of the software industry often dictates that hurried prototypes get propped up and lipsticked into production code.
The tragedy of the spiral development model is you almost never get to go around the spiral more than once, or if you do, it's done too late and the second iteration is then way too expensive. At least Google, as an exception to the rule, had the resources to do it again, better, several times, valuing quality over schedule in each subsequent round.
Where are we going and why are we in a handbasket?
Maintaining and extending software is *always* hard. If abandoning concepts such as minimizing coupling, or hiding data make the design/implementation easier, then do it. Code that tries to adhere to these best practices when the problem space makes it difficult is consistently horrendous to extend and no easier to maintain. Not all problems can be partitioned out into neatly abstracted uncoupled cohesive realms of responsibility. Beauty is code that works well and is easy to extend, not code that is easy to understand. The latter is often impossible despite all our best efforts.
Full disclosure, I mostly write research code now, and my observations are based on over a decade of production coding experience that is probably not representative of normal business/web software.
refactor the law, its bloated, confusing and unmaintainable.
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.
GW basic was cool though it had some oddities you to manually unwind a loop to stop a memory leak something like this my gwbasic is a bit rusty bu i recall having to do something like this
10 FOR I = 1 to 100
20 X=X+1
30 IF X = 50 THEN I= 100 ; GOTO 50
50 NEXT
If a start up writes up their code with best engineering practices so that the code will be maintainable 10 years out, you can be sure no one will be looking at the code 10 years out because you will have never launched v1.0 and you'll be out of business. When you start out, the first release just needs to be good enough to satisfy your initial customers and get to get some funding. Then once you have some stability you hire people to solidify the code and expand the user base.
I find it amusing that Google has a good reputation for code quality and Microsoft is perhaps questionable, yet their founders have the opposite reputation.
> "[He] doesn't know how to do that task nor understand the technical issues but doesn't think it should take or cost that much!"
So you just pay whatever someone asks for? We should talk. I have some wonderful solutions to sell you. I don't know exactly how to make toilet paper, but I'm pretty sure it doesn't cost $84 million per roll and I'm not going to pay $84 million per roll.
Beyond that, he was probably right - accomplishing the business goal should not cost that much, as you somewhat admitted ...
> I wish I had told him that he needs to buy a copy of MS Word and his problem is solved.
If that would have solved the problem for 90% lower cost, you should have, and he was right to reject your proposal.
Then you say you think people who are successful are just lucky. Let's think this through. Did you successfully make breakfast this morning? Are you consistently successful when you attempt to pour cereal? Can a two-year-old say the same? Why are you successful at making breakfast and the two-year-old isn't? Because you're lucky, every single time? Or because YOU KNOW WHAT YOU'RE DOING?
Trump keeps being successful at putting together $xxx million real estate deals because he knows what the heck he's doing. He's annoying as a TV personality, yes. That has almost nothing to do with the fact that he keeps building successful hotel / casinos because he knows how to build a friggin casino. He knows how, and he works 60+ hours a week doing it. That's why successful people keep on being successful while lottery winners are normally broke within a few years.
Successful people know how to do something that works and they keep doing it. Unsuccessful people keep doing things that don't work and keep being unsuccessful, EVEN IF YOU HAND THEM $50 MILLION.
For you, you can choose to be jealous and angry, or you can pick up any of many books in which Trump and others lay out exactly the principles they follow for success, then apply those principles to whatever you want to do. I'm a programmer. I have no interest in big real estate deals, my interest is in computer systems and business. I built and sold a web hosting company, then built a software company which sold over a million dollars of the software I wrote and I sold off that company. I'm now running my THIRD successful company. Do I get lucky every single time? No, I apply the principles that work, including the ones Trump laid out in Art of the Deal. That and I sometimes work until 2AM.
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.
What Google needs is someone who can design a user interface. When I'm using their stuff, I don't have to look at the code, but I do have to deal with the UI. And theirs are surprisingly bad.
All of the developers I've worked for and with who brag about the maintainability of there code have one thing in common, they write REALLY bad code. Maintainability is one of those catch words that doesn't mean anything, just like software engineer. Software isn't engineered, it's written, tested and released. Claiming that software engineering is a legitimate field is the same as saying baking engineer or house wife engineer, basically you want to bloat your own ego for nothing and sound like an idiot well doing it.
What you want to look for in a good programmer is someone who can sit down and write code that is well formatted and functional, period! If you ever find a programmer who wants to have code reviews, meetings, large pseudo code sessions, UML graphs and etc... just fire them because they aren't going to do the one thing coding is about and that is witting code. If you can't maintain someone else's code as a programmer then 99/100 times you just suck at actually programming. I really think we need to get off this concept of software being engineered and we need to stop using catch words that make programming sound like it's a medical practice full of critical elements and tight restrictions ( I'm not including medical based software here ).
Anny citation? I thought that Allen has written the 8080 simulator!??
http://en.wikipedia.org/wiki/Altair_BASIC
I can only say that this is SO true! My VP of engineering 25 years ago could write GREAT prototype code, but it would have been NUTS to put it into production! We needed hard real-time code that could run factories, nuclear power plants, semiconductor fabs, US Navy ships / repair depots, stealth fighter avionics production systems, and NEVER fail. That was an entirely different kettle of fish! One thing that placed him above most managers was the fact that he realized that, and let the rest of us to make it bullet-proof! He is still a good friend to this day.
FWIW, I am currently a senior systems engineer for a Fortune 100 company.
Where "worked" means you get a monochrome screen of death every 49.7 days?
Maintainability is highly subjective. I have maintained code that got all of its definitions from the database, so that changing field definitions or adding fields requires no code change and very little UI change. Changing business logic was impossible because of where changes were detected and transferred to persistence.
That was a different definition of maintainable.
I have seen code where a clearly separated ui, business layer, persistence layer, and storage, including mapping objects both ways, require changes in 10 places or more to make a tiny change. And the guy before me missed several places so the changed field lengths didn't actually work.
Another different definition of maintainable.
I'm not going to go into the stupidity of excluding medical software because it doesn't fit the definition of coding jobs you want to disparage, your misplaced priorities, or your apparent general ignorance outside of a very small range of experiences you have had, because that's just obvious.
But I do want to impress upon you that maintainability does mean something, and anyone you ask will give you a definition - usually different. There is, however, a generally accepted definition that, while somewhat malleable, involves allowing someone other than who wrote it to find the logic needed to make changes or find bugs and fix them, or add enhancements without having to restructure more than a tiny bit.
Sometimes that involves code reviews to ferret out "clever" but non-obvious solutions, documentation such as UML or other graphs, pseudo code sessions to sanity test a design before it is etched in stone, or kick Murdoch5 (1563847) in the balls.
He had some trouble in the early 1990s, AFTER he'd already made three and a half billion dollars. I'd trade places with him. He was extremely successful in the 1960s, 1979s, 1980s, had a downturn in the early 1990s, then more success.
Successful projects? His very first building was a grand success. Trump purchased a run down,half-empty building for $3.7 million with his father, a moderately successful real estate guy. Trump renovated it very nicely do it had a 100% occupancy rate and then sold it for several times what he bought it for.
He's a blow hard. He's annoying. He's consistently successful. I look at that and ask "what can I learn about how to be successful, and how not to be annoying?"
Do we really look to these people for coding style?
i don't think so...
So wrapped up in your anger that you cant give credit where credit is due
The TopCoder reference is a really odd one. Code written in programming contests is generally not written to be maintainable. Rather, the focus is on submitting it fast and having it pass all tests. TopCoder contests, with their challenge phase (where participants review competitors' code and benefit from finding bugs in there), seems to particularly encourage writing obfuscated (and therefore unmaintainable) code.
UML is probably the worlds most ridiculous method for laying out code, not only is it completely inefficient, it's usually unclear, cluttered and in the end doesn't produce any code!
Code reviews involve a bunch of people sitting around arguing about why you did something one way vs another. One time working on large PHP system I used a regex to verify an email address, during the code review it got brought up that I should of used email_verify ( or something like that ). The person leading the review didn't understand that we can't control how email_verify was implemented and that I wouldn't accept my system being broke because some developer between releases decided to change the implementation of it, ultimately we changed it after arguing for about 10 minutes, if it ever breaks I'll just smile.
On that exact same project I was working on a chat / feeder system, my co-worker spent days and days drawing up pseudo code and charts and no writing a single line of code. At the end of the week I had a working chat and feeder system which was running and very usable, he had a bunch of non functional code and a lot of UML that didn't show how it was going to work.
On another system, I was once told to take all my comments out of the code because they cluttered it up and made it harder to read. This was an embedded system that was fairly complex so I commented almost every line, sure enough at code review a few developers had serious issues with my comments so I got told to take them out. I explained that in 10 years you'll have no bloody idea how that code works and you'll have no way to upgrade it should you need to. Once again after arguing for a good twenty minutes I just removed them to make the leader shut up.
I can keep going for a long long while, the one thing all of these people had in common was that they were software engineering and rarely if ever wrote code, the code they did write was completely un-maintainable for any aspect you want to pick. I have probably another 50 examples where I was asked to make large code changes because I didn't have pseudo code or I didn't draw up UML or they thought I could of picked C# of C and etc...
The best project I ever worked on was for a medical device. I sat down with the team I was working with and the first thing out of the leads mouth was "We don't use UML, we don't Pseudo code, we don't waste time if we can be coding", The project was spec'd for 6 months and we had a working beta system ready in 2, all because we didn't waste the time to follow "software engineering practices", the code is serviceable, although has never been edited, the code is upgradable, although we've never been asked to that and over all it's the best embedded system I've ever worked on because we wrote code and didn't sit down and argue about shit which doesn't matter.
The best way to find bugs or fixes or potential issues is to run your code and simply see where it fails. I've heard and read tons about how to write bug free code and solid testable code and maintain code and it's all total BS, if you can't run your code and if you can't test your code then you shouldn't be working on it. Even if that included writing a simulator to run it on, which I've also done.
Gates sucked ass as a programmer also.
What Gates, Page and Brin have in common is a sociopathic nature that allows them to stomp anyone who gets in their way, or even looks at them.