Loading summary
A
Up Next, on episode 25 of Stack Overflow, it's a Yegi thon. Joel and Jeff sit down with Steve Yegi to discuss Google programming languages, writing code, and just plain writing. This episode runs long as a special tribute to Steve. On IT Conversations. Hi, this is Phil Windley. Today I'm excited to bring you another great program from Stack Overflow with Joel Spolsky and Jeff ATWOOD Here on it conversations. The conversations network is a 501c3 nonprofit and we need your help. For a tax deductible donation of as little as $5 per month, you can support this channel and the rest of the Conversations Network. So please visit conversationsnetwork.org to become a member and help us continue to bring our programs to the world for free. Our audio files are delivered by Limelight Networks, the high performance content delivery network for digital media. And now, here's StackOverflow.
B
Hey, we have Steve Yegi on the line.
C
Hey, gents.
B
Hey, Steve. So Joel is on. Let me make sure everybody's here. Joel, are you here?
A
I think so.
B
Okay. And we're recording. Everything's good.
C
Cool.
B
Okay. We had a little technological breakdown earlier in the call. We were experimenting with some new equipment.
C
Well, I'm glad because I had to take that time to run to another room since Googlers kind of throw a lot of parties and so like, you'll book what you think is the quietest part of the room and then all of a sudden people will be like throwing some sort of party next to you. And that actually happened. So. So we're all good now. It's quiet.
A
What was the party about? Successful search results.
C
I didn't bother to ask. I just fled.
A
Uh huh.
C
They throw parties, like for. I mean, they even throw meta parties. It's a little over the top here sometimes you'd think they'd be working, but.
A
No, like the 1024th party on a weekday or something.
C
That's right. So yeah, how do you guys do this? I was asking Jeff if there's like a theme song, you know, like the Muppet show or, you know, something like that.
A
Well, I have new gear, so I could make a theme song. Would you. Do you have any requests? I'm booting up itunes.
C
Nothing really comes to him, actually. How about the Muppet Show? Can we swing that?
A
I'll work on it.
B
Well, I have a suggestion. So one meme that came up recently was they want to put, I don't know if you guys know the Transformers, the movie for a lot of people of a certain Age. That was a very significant movie. And there's this incredibly cheesy theme song music. It's like 80s guitar schlock, but it's very beloved. And they actually contacted the guy who wrote it and he wrote back to them and they want to include it in rhythm games like Guitar Hero and Rock Band. The reason I know this song, it was actually a song in the movie. I don't know if you guys have seen the movie Boogie Nights. It's one of the incredibly cheesy songs that he sings in the studio as part of his recording career, quote, unquote, Dirk Diggler's recording career.
A
Awesome.
B
I had no idea. I had no idea this song was in the Transformers. So it's like taking on a whole different meaning to me now.
C
But that would be, say, people of a certain age. You mean old people, right?
B
Yeah, that's what I'm fast becoming. It's a little scary when you're like 10 years older than a co worker. It's like the first time that happens. It's a little weird. You're like, wow, we have almost no like, growing up TV shows in common anymore.
C
Yeah. Although. Yeah, I mean there's a lot of. There are a lot of people around here put me to shame and I'm getting up there, but I'm kind of curious, like, what's the plan for the people who. Programmers like us who work and work and then never quite make it big enough to retire and sail our yacht around? I mean, do we just work until we collapse on our keyboards? I mean, I think the dynamics kind of changing a little bit, isn't it?
A
I think that what will happen is that eventually, of course, you'll get kicked out of Google because you won't be producing. You'll be just too old to really crank out the code. So you'll end up at one of those companies that doesn't yet have TPS reports. And you'll institute the TPS reports.
C
Yeah, because by then that movie will be so old that nobody will have heard of it.
A
Exactly. They won't know the old ways. And you will have had a reputation as being an organizational person, a good.
C
Person to organize things. Although I have it on good authority from an intern there, although, you know, this is admittedly secondhand and everything, but that intel is actually the source of the TPS reports.
A
No kidding.
C
Have you guys heard this?
A
This stands for something.
C
Yeah, it does. And they actually send out a memo when the COVID page changes.
A
Great.
C
Well, yeah, nice place, but. All right. So you know we don't have to talk about getting old and dying on here.
A
But actually, you know, I mean, my. Steve, my experience has been that as I. You probably. I don't know if you agree with this or what you think about this, but my experience has been that I get slower and slower, but I still produce the same number of debugged lines of code because I get smarter and smarter about how I do things.
C
Yeah, yeah.
A
And it sort of makes up for it.
C
That is true.
A
Like, there's none of that reckless.
C
You guys know Foo Camp, right?
A
Yeah.
C
You guys both been there?
A
Yeah, no, I've heard of it. Go to things like that.
C
So, like, and they do this introduction ceremony, right, where, you know, all 300 people are in this tent and they got to stand up one at a time and they got to say their name where they're from, and three words.
A
Oh, it's a Google Weekly staff meeting.
C
Oh, man, I'm getting all confused. No.
A
Did they stop doing that at Google? Yeah. You know, I was consulting at Google when There were about 50 people and everybody would get together in the cafeteria every Friday and stand up and explain who they were and where they're from because there were so many new people every week and what they were working on and what they accomplished this week and what they hope to accomplish the next week.
C
Yeah.
A
And with just like, I don't know, you know, in the two weeks I was working there, they went from like 50 to 75 people. And it was just ridiculous. It was just too many people.
C
Yeah, I mean, like the day. The week that I got here, there were probably like 50 or 70 new people. And it was like three and a half years ago, and they made us wear these colored beanie caps, you know, and sit in this special section, you know, at tgif. And I mean, like, it was crazy. It was like this army of new people, you know, And I mean, like, some of them were. I mean, you know, you're sitting next to like Ken Thompson or something. I mean, there's famous people starting every week, too.
A
So when you're hiring this many new people, doesn't it happen that they get in and they never really learn the Google way of doing things? They just sort of continue doing things their old way. Nobody notices because there's nobody experience to look over their shoulder. And they just sort of bring all their bad old habits from whatever TPS report company they came from.
C
You'd think that, but it's kind of weird. I noticed this dynamic where people change to fit the company that they're at.
A
Right.
C
I mean, they really, by and large, they adapt. And so like, you might have worked at some company three companies ago where, you know, the management style was, you know, you're encouraged to be a jerk. Right.
A
I did. In fact. Exactly three companies ago. How'd you know?
C
Yeah, I mean, I recognize that it's relatively rare and everything, but in some places, you know, they kind of like a hole managers. Right. And so, like, you know, people show up there and they'll turn into a holes, but, you know, they never really lost that nugget of goodness that they had before they started. And so, you know, they'll show up at Google and like, literally, like 15 minutes of looking around and they'll be like, oh, this place is. I get it. Right. And then they'll kind of like they'll revert back to being the good person they were before, you know, and it's the same thing for, you know, whatever your work habits also, I mean, there's a lot of peer pressure here to, I mean, to unit test and to document things, and they've got a lot of even automated processes in place to kind of like almost force you to do it.
A
So how come that's happening?
C
They have slowed their growth.
A
Like that never happened at Netscape. Had this problem that they hired people at about the rate that Google is hiring them now.
C
Have you at Netscape?
A
No, no, no. I just know about this, I was.
C
Going to say, because I was wondering, I mean, if you were at Netscape around the time I think you're talking about, then you probably should have blown all your money on crack by now. But maybe that was only a few.
A
Of them, not me, and I have better taste than that.
C
Yeah, I'd hope so. So at Netscape, they just, like, I.
A
Believe they went from 50 to 1,000 engineers in one year. And the net result is that everybody brought whatever bad habits they had from their previous company in Silicon Valley. They were just sort of kind of hiring anybody who walked in the door, which I don't think Google has gotten that desperate yet. Although.
C
No, Yeah, I mean, not yet, but I mean, since you mention it, you got a resume for me.
A
But when you have a whole team of.
C
Sure.
A
You know, let me just hand off all the rejects from Fog Creek. When you have a whole team of people that arrived and there's sort of nobody there from the company, you know, they're just all kind of new. They're all sort of thrown together. They're gonna do whatever they do. You know, the chances that they'll actually have the same culture or way of doing things as the company itself, you know, would just be a coincidence. So you're saying this has not happened at Google?
C
No, I mean like and I've been at other companies that have gotten really big really fast. I mean, you know, when I was at Amazon in 98 they had an actual initiative called Get Big Fast followed by Get Small Even faster. They kind of went through an expansion and contraction cycle. But, but that did happen there, right? I mean there was nobody, it was kind of a cultural thing to where you weren't allowed to tell other engineers what to do or how to do their jobs. Right. I mean down to the level of fine grained stuff like how to format your code or what language constructs that everybody regrets being in the language that you're not allowed to use. Right. Threads all the way up to high level stuff like what RPC protocol are you going to use? And so there were like four of them for several years that were non interoperable at Amazon and it was pretty horrible, right? Whereas at Google like somebody like very early on, I'm thinking like the first handful of engineers here kind of set up this set of processes designed for growth, designed to acquire people and sort of get them, get them looped in right away. So it's non negotiable. You show up on your first day and there's like they tell you about style guides, right? Every programming language has a style guide, a pretty detailed one that shows you, you know, tells you how you write in that language and you have to follow it. It's mandatory, right? And they run linters over your code and they won't let you check in unless you've, you know, actually follow. And every code review you have to pass this readability review which is this like big deal in each language where they basically grill you. It's like Free C Boot Camp, you know, or Python Boot camp where you've got some drill sergeant, you know, yelling over your shoulder how come you didn't use prototype link there, you know, and it's like, and then once you're done, like you understand how they think about the language and you know, and you know how the style guide works. And so it makes moving groups really easy because all our code looks the same.
A
How do you know who wrote something?
C
You know what I'm saying? How do you know who wrote something? Well, most shops these days use perforce, right?
A
Use blame. Yeah. P4 blame.
C
Yeah. So exactly. And I take it back to handy.
A
I always Found in the past, it was real handy to know who wrote something by the coding style. But that sort of starts to fall apart when you get to five or six people.
C
Yeah, that's true, that's true. I could always tell it was my friend Todd when like the comments were all misspelled.
A
Yeah. And then you know what bugs to look for. You're like, he never gets his whatever thing right. And you immediately know to look for that bug and go correct it even, even before you even check the code. You just sort of assume that it's going to have that bug. It's probably a one off bug. I got to add an extra one in his malicure.
C
So, you know, we do have, after that readability review, we have code reviews. And then, I mean, they take them pretty seriously. So that effect happens that you're talking about. You get to know your team. I mean, there's arguments inside of Google all the time about whether to change certain things. Right. And one of the things that certain groups have kind of objected to is, you know that article, of course you do. The essay from who was the one in the first Spolsky software writing that wrote Starbucks isn't two phase commit. Oh yeah, who was that?
A
Now I'm going to have to find out.
C
I forget his name, but it was my favorite one in the whole thing. Right. And it really comes up during code reviews, right? Because when you're working and you got this unit of work, some set of files that you've changed or whatever added that you want to get somebody to approve so you can check in, then you got to put it into their queue and then it's sort of like email, Right. I mean, the SLA on it, you expect to be somewhere between a couple hours and a day or two. Right.
A
It's Gregor Hope.
C
What?
A
Gregor Hope.
C
He wrote that?
A
Yeah.
C
Wow, man. I work with that dude and I didn't even know you wrote it.
B
All right, well, come on, Steve, you planned that. You're just trying to show off now.
C
No, no, like, oh, I work.
B
Oh my goodness, I work with that guy.
C
Well, well, no, I'll just, I'll say, Gregory, I didn't even know you were that smart. But so like that happens during code reviews where you want to actually trust your team. You want it to be sort of like a. What you really want to be able to do is check the thing in and then they review it at their leisure. And if they have issues that they want you to fix, you maybe fix them in a follow up change list, right?
A
Right.
C
We call it tbr. Right. There's an option you can pass to the tool to say to be reviewed by so and so.
A
Yeah, okay.
C
And that's really frowned on inside of Google. They don't like it. Right. But there are some really smart teams, guys that I really think are doing a great job that have privately decided that they're not going to follow the process because they all know each other and they actually know that Bob always forgets a 1 and his Malloc and that kind of thing. Right. And so after the team has gelled, they argue that once you guys know each other so well that you know even what mistakes they're going to make, then it's okay to trust them to check stuff in and then, you know, and then they'll follow up on it when you give them homework. Right. I don't know. I actually like that model.
A
But you know, I, I mean, doesn't the problem then because if everybody's using the same standards and you suddenly decide that there's a better way to do something, the only way to get it changed is to convince the entire company and that's never going to happen.
C
Yeah.
A
So don't you get locked into bad ways of doing things and wrong programming languages and.
C
Well, it's not the whole company. Right. You have to change the sort of the subset of the company who care care about it. You have to convince them.
A
Right, right.
C
This is actually a really interesting point because I mean, well for starters, like there's you know, like we got Guido here for Python, right. You know, and so like if you can convince him he's a benevolent dictator, right. Then you can effect a change. And so, you know, we'll have long running talks with him, you know, over a period of years about whether, you know, you want to add, you know, anything, pick your favorite, you know, optional static types, say, or lambdas or multi line lambdas or whatever. And he's got his own sort of bar for whether it meets his aesthetics.
B
Right.
C
Which by the way, I think is one of the coolest things about languages that were designed by one person is that they have an aesthetic. Now it might be butt ugly, but at least it's consistent. I mean I'm not going to name any names, but languages that rhyme with Furl, right. You look at them and I mean, but I mean it's a very consistent sort of aesthetic where you got these committee languages and they just like Java 7 or common languages, Lisp or Ada and they're all over the method.
A
Wouldn't you Say that Java has more of a common aesthetic than Perl. And Java was designed by committee and Perl was designed by Larry Wall.
C
So Java 1, remember, 1 0, beta 4, whatever, the first one we all saw was, actually did have an aesthetic. It was a simple 10 aesthetic. But I mean it was like, but it made sense, right? And then all of a sudden all these so called smart people got to weigh in. And the thing is, when you get a bunch of smart people in a room talking about programming languages, you know, they're not going to agree on a bunch of stuff. I mean, they're going to be at polar opposites, right? And so as soon as they all get a chance to get their little feature in, you start to get this, you know, this monster. And that's what Java's kind of turned into in my opinion. Whereas languages like Python, where they've kept a benevolent dictator the whole time, they've actually managed to evolve in a way that kind of is consistent with the original vision, you know? So like when you're trying to convince people in the company like about a style guide change or about a workflow process change or a technology change, it's a marketing job, right? You just gotta like.
A
But the people that are good at coming up with those ideas are often pretty bad at the marketing or not interested in it.
C
This is so true, man. I swear to God, if there was one thing it wouldn't be, you know, if I could teach every engineer, right, it wouldn't be typing, although I'd be tempted. And it wouldn't be a handwriting class, although I'd be tempted to do that too. After this weekend. I'd totally teach them how to market.
A
Wait, I want to hear about this weekend. You were in charge of interpreting the scribbled notes.
C
Yeah, man, I was like a walking handwriting recognition failure. Like, you know, food camp. You know, you sign up to talk and you put, you know, you write in the square on a big board and a time and a location, what you're going to talk about, which itself is a marketing thing, right? Yeah, I mean, you know, people are looking at all these talks going on at the same time and of course they're going to pick the one that sounds the coolest and they're also going to pick the one they can freaking read. And people are writing just chicken scratch. And you're like, wow, that's a great idea. What's, you know, I don't know, I can't understand every third word, but it's a Roman numeral.
A
3.
C
Yeah, so that was a little iffy, but you know, but one of the sessions that came up at this sort of food camp knockoff this weekend was people were talking about like leaving to do startups.
A
Yeah.
C
And they were like, well, why can't we just do a startup inside the company? Right. Because Google's supposed to have the sort of infrastructure in place to do that. Right between the 20% time and they got kind of a sliding scale of awards that they give to teams that were really successful. I mean like all the way up to the founders awards. And so they were kind of, it was a little whiny, right? They're like, well, we don't have access to VPs. This is right after some of the VP. This is right after Larry said that he goes to one of the cafes there and sits down and he's lonely because he doesn't know anybody. And I'm like, just go talk to him. You know. But they, you know, they complain about all these things that ultimately I realized boiled down to marketing your idea. And these people are talking about going out into the wild and being entrepreneurs.
A
Well, wait, okay, here's the thing. A startup, for a startup to work, it has to be an idea that is not very convincing. It does. It has to be a completely terrible idea.
C
Come on.
A
No, I guarantee. Because if it's a. If it's because let's say you have an idea. Gosh, search really sucks and I know how to make it better. I'm going to. And let's not take that idea because it's just too unique or whatever kind, whatever your idea is, if it's obvious it's being done and when you explain it, everybody says oh yeah, that would work. I'm surprised that's not being done then it is being done. However, if you explain it and they say that wouldn't work because of blah. Could never possibly work. You couldn't have auctions on the Internet because people are untrustworthy and they'll use it to steal your money by pretending to sell you a laptop and not sending you the laptop. So you can't have auctions on the web. Yeah, no. But as it turns out, you can have auctions on the web or you know, whatever the idea is, it has to have like a. I believe that an idea to be successful has to have a fatal flaw at first glance and it has to sound like a terrible idea and you have to believe in it for some reason which you just have trouble explaining to anybody except your brother in law who joins you in the Startup or your college roommate who doesn't really get it because you do need somebody to join you. But the idea has to be not obvious.
C
Yeah.
A
And when explained, it has to sound bad, otherwise it's getting done.
C
Well, you know, that sounds right. Because if I look back at all the startups that I missed out on. Right. I think I recognize that had I been pitched with that idea at the time, I would have said that won't work. Right. Like YouTube. I mean, just never. I mean I would have just laughed at those guys.
A
Yeah. How are you not going to just get filled up with all kinds of copyright violations? You're going to be a permanent lawsuit target.
C
Exactly.
A
And it's just going to be a big hosting site for pornographers.
C
Yeah. And you know, I mean, there was another one. Oh yeah. That actually. And then every once in a while there is actually a good idea and you're like, oh my God, how come nobody else thought of that? It really does happen sometimes. Right. Like that company that like just revolutionized the. They just stole 13% of the market share from digital video recorders. Right.
A
Flip.
C
Like what the flip. Thank you. I mean, that was a good idea, right? I mean, come on, you can't say it wasn't. I mean the thing like, you know, it's, it's, it's, it's the perfect description of something that fits in your pocket. It has one button, you know, record, you know, it has this other teeny button play. There's no wires, just plugs into your computer from the USB port, doesn't have any battery, you can change. I mean, it's like, I mean, but.
A
Let'S say you were the guy inside of Sony or Panasonic or somebody making video recorders and that was your idea. Are you going to try to sell to them?
C
You're absolutely right. Playing Devil's Advent they would have said.
A
Poke out my eyes.
C
It's all high end audio files that want this stuff. You're describing a market that doesn't exist.
A
Yeah, yeah. That's really what it is. There's sort of a. Besides the fact that you have to make something that's totally unconvincing and therefore the more people that you have to convince, the more unlikely it will be to get made. You know, you're also in a conservative institution because institutions are conservative. They try to preserve the institution. Even, you know, an institution like Google, which tries not to be conservative and deliberately encourages people to do startup like ideas with 20% time and whatnot. And yet realistically, I Think that you have a much better chance of just going out and doing it outside. And that's why these companies buy so many startups. They're basically outsourcing of the innovation. There's too many reasons why, there's too many organizational reasons that startups kind of can't happen internally. And you know, Google might prove, you know, they're certainly doing more than anybody else is to encourage skunk work projects and to try to reward people disproportionately for coming up with great ideas. Although that to me sounds like a horrible idea. And they're doing more than anybody else.
C
Well, I don't. I mean, they reward people. I mean, years after the thing has like become, you know, clearly really successful to the level that they would have paid a bunch of money for for them if they had been a startup.
A
Yeah.
C
Make any sense?
A
Yeah, it does. But what about all the people? But there are people that are working on things that are just not as easily recognizable, that may be worth a lot more to the company. And there are people that are just good soldiers that are doing what they were told and they're doing it well. And it's not their fault that they didn't invent Gmail. They would have loved to have invented Gmail. They were probably telling somebody that they should do Gmail for months and months and months. Nobody was listening to them because they weren't very persuasive. So what it winds up, it seems to me like it winds up partially being unfair, but also partially giving people an incentive to try kind of stupid, flashy things in hopes of getting this somewhere down the line.
C
So, you know, you're right, I mean, you're right about all of the sort of institutionalized resistance to new ideas. I mean, and you know, there are a bunch, right? I mean, people, they almost have a built in, sort of, nah, that could never work, you know, type of a reaction. I mean, we're kind of jaded, right?
A
Yeah.
C
But that said, you know, that causes people to go off and do startups and you lose talent and you lose it's kind of opportunity cost because you might wind up, it might get sold to somebody else. Right? Not you. And so it's in Google's best interest and I think it's really in every company's best interest to try to find a way around these problems.
A
Why shouldn't Google just. I'm just playing devil's advocate here. I mean, I can see why Google thinks this, but if I were in Google's position, why wouldn't you just say, you know what, there's going to be some great ideas and they're not going to be invented here. We're open to buying companies and let's let the market test these ideas first. And the ones that make it to success will overpay for. And instead of paying for developing 20 ideas in house and one of them pays off, you just buy one of those companies instead of 20 for 20 times as much money, because that's what it's going to cost you to buy the startup. Once it's successful, you're going to have to pay a multiple of 20 because it's been successful. And you might as well do that. And then you get to choose the 1. Pick and choose among the ones that kind of work instead of having to only, well, only choose among the ones that were done in house.
C
Sure. Well, you know, I can't obviously speak for Google about sort of policies, right? I mean, all I can talk about is sort of what engineers in our position think. And having been at a bunch of other companies, I can say that the sort of decision about whether to go do a startup or try to advance your idea inside a company, that's a common pattern. It's a common theme. And I can also tell you I could look at a bunch of companies that we've acquired and I can look at an equal number greater number of internal startups that actually happened here, like where somebody just said, screw you guys, I've been here for long enough. I've given enough blood to the company or invested or whatever. Or maybe I worked at Microsoft for 15 years before I came here and so I'm working for free anyway. There's all kinds of ways that you can get into this sort of situation where you're willing to kind of walk if they don't let you do what you want to do. But every once in a while, one of those people actually has an idea that they want to pursue and they say, I'm doing it here because you guys have good infrastructure and I don't want to have to reinvent bigtable and your localization system and all that other stuff.
A
Right, right, right.
C
So, and you know, examples, I mean, you know, that we talk about all the time, like, you know, Orkut, which hasn't been a huge success in the US but in some countries it's completely taken over. Right?
A
Yeah.
C
And I mean, Gmail was to an extent like that, certainly Google Talk. I mean, there's a whole long list. So, you know, I mean, it can be successful and I think what happens is people are basically willing to kind of take the risk reward ratio and compress it. Right? Because I mean, like some of us like are married and we have kind of lives outside of work and the concept of doing a startup where, yeah, sure, the potential reward is a lot higher, you know, but I mean, the risk is huge, right? You know, that's just not that appealing. We want to be innovators, but not entrepreneurs, right?
A
Absolutely. And you know, when you're an entrepreneur, you're going to waste an awful lot of time. You know, like Fog Creek is what, 8 years old now? And today Michael and I, the co founders, were actually installing blinds.
B
Good, you got blinds. That's very exciting. Actually.
C
That's a great engineering activity. Joel, are you going to be writing about technical challenges there?
A
Nah.
C
I mean, that's the thing, right? It's like, I think programmers who say, well, I'm going to quit and do a startup kind of grossly underestimate just how much non programming stuff they're going to wind up doing. I mean, if you're going to do it, you want to be at heart an entrepreneur and actually maybe even not a programmer. You want to be more of an organizer.
A
I mean, it may be that you're just bored with programming, that that's, you know, a solved problem for you and you want to move on to the next thing.
C
Whatever your reasons, but your reasons shouldn't be, I have this great idea that I want to build with my own hands and so I'm going to go out and be an entrepreneur. Because it ain't going to work for you, right?
A
Right. It might. It can.
B
So one thing that I hear missing a little bit there is, I think for some people, they want to be, you know, like Larry Page, they want to be one of the key people in the company. And I know I've worked at places where, not that I want to be king of the world or anything, but it's a little frustrating because you're not part of the cabal that runs the company. You're just never going to be the guy that's really a part of the key decisions that take place at the company. And I know that can be kind of frustrating. I mean, I guess if you have this sort of magical infrastructure where you never hit roadblocks and you're always able to do exactly what you think needs to happen for some idea to move forward, then I guess that wouldn't be necessary. But I think I've seen that drive it where you just can't become part of the power structure of the company. I mean, you're doing great work, you're helping them build whatever it is they're building. But sometimes you just want to own the thing that you're building, like really own it, like every aspect of it. Right. And I guess there's maybe infrastructure issues there where if you're building something that requires like bigtable or you know, thousands and thousands of servers, then you're sort of in a catch 22 situation, right. How can you actually build out that kind of infrastructure without having a company support you on some level? Yeah, but that's something I'm not really hearing there. Do you not hit roadblocks at Google in terms of getting your ideas done, getting, you know, making progress on things? I mean.
C
Yeah, so you certainly, I mean, when people were having this discussion this weekend, that exact one came up, right? I mean, you've got this weird problem where you have a lot of trouble getting the people that agree that the idea is a good one, which maybe is a good thing, right? Because it means nobody else is doing it. But then if they suddenly get it and they really like it, they may steal it from you. Right? Because you're not part of the core decision makers. And I mean, I've seen that happen. I saw a couple dudes put together this amazing thing that they were going to make a general purpose tool, but the specific use case they came up with was so valuable that the VP said, you're going to work on that and only that and don't generalize it. Right. And they were happy because they had become important, but they were kind of a little sad because they had also lost a little bit of a vote in what their original sort of vision was.
A
Yeah, right.
C
And if you, I mean, ultimately you either got to stick to your guns and say, look, this was my vision and I understand it better than you guys because I've been thinking about it longer, you know, and if you're right, you know, then maybe, you know, again, it's a marketing thing, right? You're marketing yourself and your ability to like, you know, sort of be the, the torch bearer for this vision, right? And then they say, all right, you do what you think is right. But in the end, I mean, like the company's probably going to ask you to, I mean any company is going to ask you to probably make some changes, right? Like, if nothing else, you know, maybe like having the infrastructure here is kind of a two edged sword, right? I mean, it's really cool to be able to have thousands of servers and infrastructure like BigTable and protocol buffers and GFS and all that stuff. But there's a lot of pressure to actually use it to scale. When you're at the phase of your project where you're still prototyping and you're like not even sure if you're going to keep the thing that you're building right now. So why bother trying to make it scale and localize it and integrate it with everybody else's properties? You want to defer that until you know what you're building. Right. And so at some point, I mean, you know, if these things really aren't working out for you, I can see why people, you know, go off and they try to find, you know, find funding.
B
Right.
C
Or they self fund I guess is probably more common these days. But I still would like to, you know, I don't know, I think I still would like to teach a marketing class because I think people just totally underestimate all these obstacles. Kind of fall by the wayside if you're, if you've got a really good spin, you know.
B
Right.
C
I mean you guys have pitched to venture capitalists, of course. Right. I mean, you know how these people are, right? They're people.
A
What? Neither of us have pitched a venture capitalist. Of course not.
C
It's kind of shocking to a lot of people that when you pitch to a vc, right. They're not judging you on the technical merits of your idea or anything other than whether you're waving your hands like a football commentator and sort of like weaving this vision of how things are going to be and getting them all excited. It's a, it's like a football coach getting the team all revved up. I mean that's the way that's the successful ones that I've seen have been exactly like that.
A
That's probably true.
B
I think there's a little bit of a tension there. I mean, I think you can have sort of a college campus. I think some of the best sort of technical companies sort of come across like college campuses where you can graduate and do anything potentially. Right. I mean there's sort of this open endedness to, to the experience that I think is kind of a little bit of an illusion because you're never going to be Bill Gates, you're never going to be Larry Page. It's just not going to happen.
A
I have this theory that the whole Xbox product at Microsoft was pretty much. They went into that whole business just because they had these great talented people that really wanted to do it. They were really sick of working on Excel and they sort of deserved a chance to try to make a new thing. And I don't think Microsoft was doing.
C
That's more than a theory. Somebody told you that, didn't they?
A
No, no, that's just a theory. But I know who the given who the people are.
C
Yeah, that can be a good policy.
B
So, Steve, I'm definitely hearing that you're still very much sort of in love with the Google experience, because I remember that long. Well, every post you write is long, so that's sort of a catch 22 things. Long post. It's just a post by Steve Yegg, so. But you had sort of waxed poetic about the Google experience and it sounds like, I mean, there have been. I know there's some posts you made that were sort of oblique about some.
A
Weirdnesses, some kind of land of marshmallows or something.
B
Yeah, the marshmallow thing, which we all interpret.
A
What was that about? Yeah, tell us what that was about.
C
It'll be an exclusive system really, is that we had an evil manager who went undetected for a long time and believe me, they've got some pretty serious detection mechanisms and place because you know how much damage an evil manager can do and we don't want them. But one actually managed to. Was just sort of a master politician and went undetected for two, two and a half years until I finally worked for the dude. And it took me even a year until we all finally. And then now he's gone. Right. I mean, of course as soon as Google realized that he was an evil manager, it was over. But that's relatively rare and it's sort of a testimony to the company that they can recover quickly once they figured it out. Right, But I mean, like, by and large, I mean, yeah, sure, but the thing is, you got to recognize I'm also good at marketing. Right. And so I can make the Google experience good for me internally. And I'm working right now on a project that was my idea and I had gotten to the point where I was like, okay, I've done three projects and I think statistically I'm starting to become an anomaly because I've actually worked for three years at Google. I've been on three projects and all of them were canceled for business reasons. Yeah, I mean, and the stories themselves are hilarious, but unfortunately I can't tell them on the radio, so you'll just have to take my word for it.
A
Well, luckily, this is not the radio. Yeah, this isn't going out in the public or anything. This is actually completely Google internal, so go ahead.
C
No, I fear that the literally dozens of listeners to your. Your core dump, sorry, Segfault company Will potentially catch on to the bad. So I can't talk about it. But the stories are really funny. Right. And basically for different reasons.
A
Yeah, yeah.
C
Say again.
A
We have 24 listeners.
C
Even after like being on three canceled projects, which really isn't a whole lot of fun, I have to recognize that that's kind of part of, you know, how like a major league pitcher can, you know, every once in a while one who's got a 300 plus can pitch an 11 no hitter. Street, sorry, get hit on 11 times. I mean, there's all these weird statistical anomalies that can happen if you actually look at the numbers. And I'm just an anomaly.
A
Right.
C
I mean, like if the company's trying to generate luck, which is what Eric Schmidt is always saying, right. By doing a whole bunch of stuff and some of it will stick.
A
Yeah.
C
Then, you know, schmuck of Steve Yeggi is gonna get unlucky three times in a row. Right.
A
It's not just that. It's that probably most things that they're doing are not gonna work. Yeah, I would expect.
C
I mean, so I mean, they try to do. They try to do a better job of like course correcting and like trying things really quickly and then like if it doesn't appear to be panning out, trying something else, you know, quick hit kind of mode until something looks promising. But yeah, a lot of the initial stuff doesn't work out. A lot of 20% percent projects that Googlers fire up, they don't pan out. And the company does a pretty good job of, I mean, actually very good job of kind of rewarding you anyway for trying. And there's not a lot of companies that will do that. On my last canceled project, there was a bonus for the team members. And I mean, it was a public thing. Everybody got to sort of see what the bonus was right in the company. And it was sort of a recognition for a year of hard work on something that for perfectly legitimate business reasons that had nothing to do with the technology, you know, they had to cancel it. And some people, man, they can't handle that. I mean, they're on the ledge and you got to talk them down real slow. I mean, they should usually more junior people, but.
A
Yeah, I don't know about junior. They identified with the project that they're working on.
C
Yeah.
A
And that's kind of important because otherwise they're not going to work the 24 hour days if they're not properly identified.
C
Yeah, Google, actually I got in trouble once for working 24 hour days, so I had to back off.
A
But you know what I mean? I mean, people are going to be devoted. People are going to be much more devoted to a project that.
C
You know, it's funny, if you were going to point to one thing in my blogs that's never really been spoken, but it's underlied everything that I've written. It's that identifying with anything so strongly that it like starts to give you emotional reactions is really bad.
A
It's bad for you, but it's good.
C
For you because you never know when your language is going to be obsolete or your project is going to get canceled or your favorite framework is going to like be replaced. Right.
A
Hey, speaking of languages and frameworks and all that and emotional and all that kind of stuff, is there. You know, there was sort of a couple of years ago, I'm trying to describe this. What do you think of the characteristics of the people who worry endlessly about which programming language to use? Is that everybody or is that all the good programmers or.
C
I don't know what's going on with that. Although I finally gave up three years ago after, you know.
A
But you know what? There was a whole fan club. Well, I mean, you have a fan club because you write beautifully. But it's not just that, it's also that. Thank you. There's a whole. Like you could go to, for example, the very early days of Reddit or now it's those people who moved on to news. I'm not going to say where it is hacker news. I'm not telling anybody the URL because I don't want people going there. But. And invading and having.
C
I know which one you're talking about.
A
Anyway, they just love a good argument about what the perfect programming language is going to be. And even just the idea, to me it's very strange. And it kind of seems to me, it feels to me like the kid who says I'm gonna learn guitar. So he goes down to the guitar store and he's like, what's the best guitar to get? And he's posting all the discussions, what kind of guitar should I get? And he's like, should I just use the regular strings that come with that or should I get my own strings? Like, what kind of pick should I have? And like, what kind of chair is the best chair to sit in when you're learning how to play the guitar and who's the best teacher and where's the best. Just go on and on and on about this stuff. Yep. And, like, getting all the gear.
C
Like, what's the. What's. I mean, seriously, what's the best car?
A
Yeah.
C
If you're gonna buy one car. I mean, seriously, what's the best one to buy?
A
Well, that. That doesn't even have an answer. But. But I'm thinking almost about, like, the.
C
Well, neither does the guitar one. Right. I mean, you just pick one and you run with it.
A
Well, you wouldn't. And. And what's funny is, like, a real guitar player would pick up any old crappy piece of guitar and have fun with it.
C
That's true, too. That's true, too. Yep. Well, it's. Yeah. So, I mean, like, part of it is that, like, all the languages out there today kind of leave something to be desired. They all have a fatal flaw. They're all great startup ideas, Joel.
A
I think they all have a not fatal flaw, is what I would say. They all have something. I mean, you could call it a fatal flaw, but it's just not fatal. I mean, we went for years on VBScript, and that's the worst possible language of all languages out there. The only language that is worse than.
C
VBScript is five years using 8086 assembly. That was the worst.
A
That's fine. Come on. There is one language that's worse than VBScript, and that would be Tickle.
C
Oh, Tickle. Tickle's pretty bad. I'll give you the bet. Yeah, but you realize we've just made, like, permanent mortal enemies. Of all the people who identify with tcl.
A
Oh, I don't.
C
See, they get all emotional when you say Tickle sucks, which it does.
A
You know, I can tell you about an online brokerage that went out of business because of Tickle.
C
Oh, ouch.
A
But with really good programs. But, you know, what I found is that it's the quality of the programmer, not the quality of the language and the good programmers. What's amazing is when you look at, you know, actually there was a language that was worse than tcl, and it was the original Excel macro language, not the Visual Basic, which I put in with a team at Microsoft in the, I guess, early 90s. But the one that just came up in the 80s was sort of an accidental programming language. It didn't have scope, it didn't have variables. But every time you executed a statement that had some kind of value, which was then in a cell that you could then reference and just an unbelievably messy programming language. I mean, just really just bad in every possible way. And there were a few people who were professional Excel macro developers and they showed you, and they had these style guidelines, like, always use column B for these things and column C for these things, and use the following naming convention to create your own artificial scope. And when they stuck to that, they were able to write good code in this absolutely disgusting programming environment that had just about everything wrong with it. But there were kind of ways to work around a lot of these things. And you know what I found is that the variation between a good programmer and a bad programmer is much, much more dramatic than the variation between a good language and a bad language.
C
Yeah, okay, fair enough. So, but I mean, just what do you think it is that differentiates them? I mean, maybe it's an unanswerable question, but I mean, do you think there are any sort of common characteristics of the programmers that stand out?
B
Yeah, well, can I interrupt for one second? So I think one thing we're missing in the whole.
A
Oh, Jeff, Jeff.
B
Yeah. Was, you know, some of these languages that we were stuck with early on, we were stuck with because we just didn't have enough power. Right. Like, I mean, this is my classic thing I don't like about C is I feel like we had C because we didn't want to use assembly language anymore. Right. It wasn't like people said, oh, you know, this is a really productive environment for programmers. They just said, I don't want to work in assembly anymore, but it needs to be fast, right? It needs to run on these older PC. So I think as we have more power, I think we can use more expressive programming languages. And then it becomes more, I think, about the framework than the language even. Like, look at jQuery, for example. JQuery is hugely popular and I think for good reason. It's a really fun API to use. It makes using JavaScript and manipulating the DOM really fun and simple. Right. Way more than it would be if you were writing JavaScript alone. So I think we're just continually moving up this abstraction layer because we have all this ridiculous amounts of computing power. So to me, that's what the choice is about. It's about trading off computer time for human brain time.
A
I'm not saying that you don't make improvements in programming languages. I definitely feel like you do. I feel like there are definitely better and worse languages. I don't want to deny that. And there's definitely major steps forward and there are some Kind of minor steps forward. I think the major steps forward are things like garbage collection, managed code, like not having to manage your own memory actually does get you more productive because you stopped dealing with accidental complexity and you can deal with only the complexity that you care about.
C
And that was such a concurrency. Concurrency is another big one, right? I mean like I wasn't able to actually use threads, you know, sort of safely, sanely until the Java util concurrent libraries came out. And they actually made it reasonable at the expense to Jeff's point, of a little extra computational overhead because the libraries may not generate as efficient locking as what you could do by hand. But it did let you throw together this multi threaded thing that would get 1,000 times the throughput. So who cares if you lost 30% efficiency over a hand tuned version, right? You never would have got the hand tuned threaded version working. I think that's as big as average, close to it.
A
Okay, so then there's stuff like even I don't know, native strings, which C, that's huge. Or native Unicode. So you don't have to, if you want to do Unicode anyway. There's a bunch of things like this that were kind of these big steps forward and then there's a lot of really little things like whether you have, frankly I'm going to put closures in that thing where the great features that everybody's super excited about and even the ability to call functions recursively is something that the average programmer uses about once a year. So, you know, it's good to have but it's not going to make a, you know, necessarily make a huge difference in your, you know, that one time a year it does, but it's not as big a deal as garbage collection. So you know, but that said, you know, there are definitely languages that are better and worse. That said, I think there are also programmers that are better and worse. And there's something a little bit weird about, you know, frankly script kiddies obsessing over what language they will choose to be betrothed to as if they were, they were kind of picking. And it just sounds like 16 year olds trying to decide what you use jalopy to get, you know, should I get it?
C
So, you know, I think there is, there's a 10. I mean, so obviously I would love to see everybody learn a whole bunch of languages because it does make you a better programmer. I mean it makes you, it gives you the ability to take a look at some language like Excel macros and see and sort of squint at it. And say, ah, if I did this and this and this, it would almost look like a real language. Right? And so you can't do that unless you've seen a bunch. And so like, you know, unless you programmed in, I don't know, pick your favorite five high level languages, you can't squint at Java and say, oh, I know how to turn this into almost a real language. It's hard, right? Because you're down in it. So I'd love to see people do that. But there is sort of a tension to try to kind of, kind of find one language that you can kind of stick with. Because languages today are silos and they don't interoperate very well.
A
Right.
C
I mean they kind of interoperate at the IPC level, you know, these really coarse grained but they don't. You can't like share stack with a lot of them, right?
A
It sort of depends. I mean if you stick to the Microsoft world, they all interoperate nicely.
C
Yeah, well, Microsoft got it. Yeah, they did, right? I mean with Net, I mean they brought a bunch of. Once we. Microsoft realized that languages matter, which the big sun lawsuit was a big slap in the face, but they got it to their credit and they went out and got a bunch of great language people and built net, which does a whole bunch of things right. And now Sun's been playing catch up and I'm going to hear a bunch of crap from sun people going, oh, we support languages just as well now.
A
Let me just tell them in advance. Nobody email us, nobody. Just don't. We're already sorry. We're going to apologize in advance for everything that we say.
C
Yeah, I mean I love them all, they're all great, really. Please don't email me about it.
A
No, you're right. I definitely feel like the. Well, you know what, that was sort of. Net is sort of the interoperability in. NET and the way the languages work together and share a stack and a lot of those things and the way you can even communicate between processes and between assemblies and all that kind of stuff is really just kind of a version of. Com that assumes garbage collection.
C
Yes.
A
Once you assume garbage collection or memory management as they call it, then you can do things that in. Com you used to have to do manually and they were a nightmare. So like. Com had the right idea. It was just impossible to ever get. Keep your reference counts correct and.
C
Yeah, yeah. So you know, I mean, but you know, even so, right. Even when they. Even in the rare cases like Net where you can get Them to interoperate. And I think that they actually had to make concessions, right. Like they actually had to change vb, you know, to the, to the chagrin of, you know, hardcore BVB users actually make semantic changes, right?
A
Oh yeah.
C
To make them all interoperate.
A
Yeah.
C
And that has to happen to some extent.
A
Yeah, it was. I mean, that was a problem. That was sort of, you know, abandoning of the world's most popular programming language. I hate to say this, but VB was the best selling programming language of all time. And at the time, yeah. And to abandon all that code basically say, you know, we'll give you some tools that don't work for importing it and we're going to make these fundamental changes in the way the language works and then we're going to just sort of blithely change the whole forms system so that you can't really port your code. Reasonably was just made. That entire population basically made the largest single cohesive community of developers in the world all suddenly decide, okay, what's next? What programming language we can't keep using? Vb, what are we going to use next? And I think they scattered to the winds really. A lot of them just started doing web and they went to php, they went to.
C
And if they were trying to kill eb, then that was a great move. Right. But it's every language community's fear that they're going to make a decision that actually causes people to scatter to the wind. I mean, it happens, right?
A
Yeah.
C
I mean, that's how people, or sometimes just a language will come along and it'll recruit from some existing language. That's how they get sort of successful. Right. They target some other audience and say, you're unhappy, come to us.
A
Yeah.
C
So but even when you get to the point where things are interoperable like in. Net, like just having things in two different languages still poses these sort of, these impedance mismatches, these sort of friction points, right. Where maybe your tool is better with one of them than the other one. Or, you know, maybe, you know what I mean? You can't mix at the source code level very well. Right. It confuses your editor or whatever. I mean, they've got a lot of work to do before languages kind of become this sort of commoditized interoperability.
A
They are in. Net, but only because each language has kind of taken a slightly different form than its native self would be, if that makes sense. Right.
C
Because you can't get people to switch. Most people will never switch languages. They're One horse programmers, right. And so, I mean Microsoft's made a really good, really good decision to try to like get as many of them as possible possible together. They have to make minimal changes to their working model. They have to learn this new version of VB or C or Ruby or Python. They're doing all these things right. And then they get interoperability, which is really good. So I don't know. Yeah, maybe the answer to which language is going to be solved by Microsoft.
B
So Steve, let me interject here. I want to make sure we have time to talk about what you're working on. Like I want you to be able to see sell us, market us. I want you to market to us. I want you to tell us what you're working on, if you can tell us about it.
C
Yeah, right. So Google's got this weird sort of like desire to develop things sort of in relative secrecy and then as soon as they reach a certain point, we kind of want to open source them or open them up. Open standards, those kinds of things. Right. It's this weird trade off, right. Because like, why would you develop an open source project in secrecy? And I think the answer is because you want to get it to a certain point where you can suddenly shock people into realizing that it was a really good idea as opposed to doing what we were talking about before and pitching it and having people go, nah. Right.
A
That's really true. Also Google, I mean, yeah, everything that Google does is going to be watched much more closely. And if they release a new, I don't know, the Google brown paper bag, G paper bag, it's gonna get, you know, it's gonna be number 1,000 sandwiches.
C
And it better have tech meme display, 40 languages. Yeah.
A
And you're gonna get Arrington saying snotty things about it. And you know, and the trouble is if it's not great on day one because you're showing it a little bit too early, then that's all anybody's gonna remember is like how not great it was. And they're not even gonna look at version 2.0 or 3.0 or 4.0 because they're gonna be like, wasn't that that funny thing that they released? Oh, I know. Like to take a Google product, knol, which I know there's some better way to pronounce it. K N O L. Nol I never.
C
Even heard of it.
A
Google.com knoll, you've never heard of it.
B
That's great.
C
It's probably a good thing that I've never heard of it, I take it.
A
Well, yeah, that is a good thing, actually, because a lot of people looked at it and. Yeah, you are. It's supposed to be a Wikipedia clone.
C
That's sad. Well, okay, so. But yeah, your point is. Well, I mean, that's. That's exactly right. You want it Got a lot of publicity.
A
But you know what?
C
Cool.
A
Got a lot. Cui l got a lot more publicity. And you probably looked at that, right?
C
Cui C U I L Dude, I'm a philistine, man. I don't know what's going on anywhere Steve's doing.
B
Steve's doing actual work over there. He doesn't have time for this.
A
He was in the New York Times. Don't you get newspapers over there in Alaska?
C
Yeah, so actually, most of my news these days has been coming from Reddit, although I finally weaned myself off the habit because it was. I was becoming progressively more depressed about the sort of average intelligence of U.S. citizens.
A
Well, it was getting progressively lower on Reddit. It had nothing to do with U.S. citizens.
C
Yeah, maybe I was also depressed by the intelligence, the commenters kind of. I was depressed that that was going down too. But. But I don't get. I mean, it's weird. I mean, all these newfangled things like compact discs and, I don't know, whatever the hell I really am pretty much holed up doing like, whatever thing it is that I think needs to change the world. Unfortunately, I can't talk about the project that I'm working on right now because I'm in the same boat. I want it to be cool before I show it to people because I kind of got one chance to make a first impression.
A
Right, that's fair.
B
So you can't talk about anything at all that you're doing? Is that what you're telling us?
C
Well, so, I mean, like, on the side, I've been trying to find time to spin up a 20%. I mean, a couple 20%, right. I want to open source that JavaScript on the rails clone thing that I did.
A
Is that the JavaScript on Emacs or something? Or is this something else? No, not JavaScript.
C
No, no, no. It's a clone of Ruby on Rails, more or less. That's written in JavaScript on the JVM because there was some sort of legal loophole that let me use that language inside of Google, but not Ruby, and it worked out pretty well. And there's a lot of interest in me open sourcing it. And so we talk about it on and off, but unfortunately it's kind of dependent on certain other Google technologies getting open sourced first and they're in the pipeline right now. So I also want to take that game that I wrote, that I won that award for back in Comdex in 2002, which had a really nice. For a handheld client, I want to port it to the Android.
A
Yeah.
C
But I don't know much about the Android yet, so I got to take a look. But I think that it's in Java. I mean, like, I don't follow what's going on inside of Google very well, which is nice because I'm always pleasantly surprised when people tell me what they're doing. Right. They're like, I'm working on blah. I'm like, wow. But, you know, so I don't know, there's a bunch of stuff I'd like to do on the side. And then there's my main project, which was my idea and I pitched it inside of Google. And now I'm fiercely defending anybody, like trying to take it from me or change the vision. But it'll probably be like six months before I have anything that I can offer externally.
B
So, Steve, let me ask you this. So your project, when do you think it'll be cancelled?
C
Ain't gonna happen. It's mine.
B
I'm just kidding, of course.
C
Yeah. Well, so the nice thing is I actually own the business in addition to the technology this time, so I'm in complete control of it.
A
What does that mean, you own the business?
C
Well, I actually make the decision about who the customers are. You know what I mean? It's like personalization inside of Amazon was this really interesting group because they didn't have product managers going off and researching how it was supposed to work, because product managers, I mean, it was all these algorithms, right?
A
Yeah.
C
So the personalization team got to decide how it worked as a feature in addition to how it worked as a technology. And they were always really happy because of that. Right. And so my thing has this sort of nice property that they can't ever bring in salespeople to say, oh, you got to do it differently.
B
So you're like the PM or whatever. I forget the terminology for that. But the project manager or the person setting the vision as well as the engineering staff.
C
That's right. I just basically wear this stack of hats that's about 6ft high. It's like a mini startup inside of Google.
B
How many people are working on this with you? Just you.
C
Or I got a long line of people who've asked me to, but I am still subject to sort of, you know, headcount budget. So I have like one full time team member and one part time contributor and then we had some interns and actually they're giving us more. So it should be probably 5 by Q1. It's a small project and I want to keep it small.
B
Cool. So what's the rough timeline? When do you think we would maybe hear something about this publicly?
A
Steve, at this point, I want you to say six to eight weeks.
B
Oh, that's a joke. Because of our stack overflow development schedule. Sorry. Basically at this point you just make up a number is what he's basically.
C
All right, well, let's just put it this way. I'm not having a lot of Scrum meetings.
B
That's why it's going so slowly.
C
You need more Scrum? No, actually it's funny how we get an extra hour a day for coding when we don't have Scrum meetings. Now I've really made a lot of people mad, but.
B
Yes. The other thing I want to ask you about is just your writing schedule. I know a lot of people are curious and I know I'm curious because I know how long it takes me to write sort of a very small piece. The type of thing when I used to post on coding horror, I would post. I know how long those took me. So I would look at the posts you wrote and I would just sort of. My mind would sort of go into overdrive. Like the work schedule it would take to produce a post of this size that's actually written reasonably well kind of boggled the mind. So I was kind of curious if you want to talk at all about your writing process and how long that takes and how it works.
C
Yeah. I used to try to always do something that I could write in one sitting. So if I would try to write it and if I get three quarters of the way through and poop out, then I'd be like, oh, it's too long, I need to break it up or I need to take a different tack on it, or whatever. So pretty much everything I've ever posted, I wrote in one. Wrote and edited in one sitting. And it's usually 40% writing and 60% editing, which always shocks people to hear I throw a lot of stuff out.
A
What?
B
We don't believe you. We don't believe you.
C
I do. And just if you don't believe me, I'll give you one.
A
I would hate to see what's on your cutting room floor.
C
I'm truly shocked, but I have a Couple big ones in the pipeline that I've been really struggling to get out. And I've been trying to do a better job of actually building them. And almost like I'm writing a chapter of a book so I can spend like instead of 11 hours straight, which is usually what it is, like on some weekend, then I can do it like two hours every couple days.
B
Right.
C
It's weird. I mean, you can't write about anything that's interesting without making a bunch of people mad.
A
That is sort of a problem.
C
Right? It's better to be unemployed. There's. I mean, anything that's interesting always has at least two positions that you can take. And a villain, if there's one position, people are like, what are you talking about it for? Right.
A
I think you need a villain. You have to make somebody out to be the villain too.
C
I bet I wind up being the villain.
B
Well, I totally know what you're saying there, because I wrote this blog post about commenting and people complained a lot because it's a little bit controversial. And I said to those people, I was like, well, what do you want me to write? That you should write comments in your code? I mean, this is not an interesting thing to write about. More interesting, consider when you actually wouldn't put comments in your code is a much more interesting thing to think about. Because it's harder. Right? It's much harder to think about. Wow. I really shouldn't comment my code in certain cases. That's a more.
C
Are you saying I shouldn't comment my code? I'm really mad at you.
B
Exactly. Then people get pissed off. But you're right for it to be interesting, even for me to write about it, I'm not going to write. You know, you got to write something that's interesting. So I totally respect that. It's got to be a little controversial. And then people accuse you of trying to be controversial when all you're really trying to do is trying to be interesting.
C
Yeah.
A
Well, that's the same as trying to be controversial. Yeah, forget it. The blogosphere is over.
C
Hey, Joel, do you like, do you get like random non technical people telling you how much they love your writing? Yeah, I mean like we're talking like real estate agents, security guards. I mean like people who are like so far removed from anything technical.
A
That's a software program that they bought, Steve. It's a program that they buy and they run it and they type in their URL and it sends email to a whole bunch of high page rank people saying, I really like your Writing. Could you please link back to my website about.
C
No, I mean, in person. It's weird. I'll be in the pharmacy, and somebody will turn around, they hear my name, and I'm like. And they're like, I read your blog. Little privacy. I'm in a pharmacy. Yeah, but seriously, what are you buying.
A
In a pharmacy there?
C
Because, like, when you're writing now, all of a sudden you're thinking, oh, man, I gotta be, like, funny, too. Because they're like, steve, you're a clownfish. Say something funny. So, like, the bar keeps going up if I actually try to make people happy, you know, so it's kind of crazy, but you have to just sort of, like, decide that you're not gonna make anyone happy but yourself. And if the thing's a total flop, then you don't care because you just have a thick skin about it. Right?
A
Yeah.
B
Talk a little bit about. So you started doing all these really long entries at Amazon, but they weren't public, right? Because I remember when your blogs first sort of hit the scene, it was a bunch of stuff you had already posted internally on Amazon.
C
Some of them. There were some really good ones that they actually. This CTO mailed me and asked me to take down, actually. And this was just back before the search engines would pick up blog posts, right? Fast enough, so I actually had time to, like, respond and remove some of the posts that I had written that they felt gave away too much internal information about Amazon's, like, technology, which it didn't really, but, you know, whatever. And so I was. So, unfortunately, some of the particularly good ones, I think, actually got yanked. But, yeah, that was. It started off me just writing. Just rant, literally ranting, because I'd been there for five years.
A
And how did these get distributed internally at Amazon? Was there some kind of. Does Amazon have internalized?
C
It was just like anywhere else, everybody has a phone tool entry that maybe has a link to an internal blog, if they have one. And I didn't ever tell anybody to go read it. But it's weird. There's a set of people who are these early adopter types who just go and check every new blog to see if something good comes out, Right? And so gradually, by word of mouth, over a period of two or three years, I went from, like, no readers to, like, 1,000 readers every time I posted. And I didn't really know how that happened, but. And I'd tell them to go away every once in a while. I'd be like, this is my blog. It's like my diary, I want to be able to say whatever I want without you getting all upset. So go away. And that just seemed like bring more people in.
A
Yeah, that doesn't work.
C
No, it doesn't. It doesn't work. It does the opposite of what you want.
B
So, Steve, let me ask you a question about the Amazon post. So when did you realize that those were better sort of in public, like the internal stuff was actually? Because I remember you talked about how hard it was for people to find it internally. This is sort of the paradox of information. When working within an organization, it's almost like it's more efficient to put the information out into the world and have people find it that way than it is for people to find things internally.
A
It's even thanks to Google, it's more efficient to write notes to yourself in a place where Google can find it so that you can find it again. If you're trying to figure out how.
C
You did something, you guys know, you realize that like in like 99 or so, sometime around the time that Google became just big enough to be like kind of viable for the next few lifetimes, it's unlike. And then a few, you know, a few other search engines sprung up, you know, MSN and Yahoo. So now there's all these copies of the web and historical copies. Everything you write will basically last forever now.
B
Right?
C
Right. It's even backdated. I find Usenet posts that I did when I was 19 that live forever.
A
Oh, I'm going to search for some of those.
C
It's totally changed. I mean, if you think about motivation for why people even do things like open source software or write essays or whatever, it's like it's the new bid for immortality. People used to have little kids. You have to have to have to have kids that look like themselves and you teach them to talk like you. That's your bid for immortality. But these days, I mean, like, everything you say can be quoted out of context 500 years from now.
A
The other thing is, if you're not like on the web, if you're not writing stuff on the web, then when people search for you, they're going to find stuff that you don't control. You know, it may be good, it may be bad, it may just be, you know, a little piece here, a piece there. Just to give a random example. There's like a childhood friend of mine who I haven't seen since I was. And every once in a while I'll search for his name on Google and I'll find a Story about his brother getting killed in a car crash. That's the only thing you can find about this person, Is that the only thing you can find about his existence. And he. For all. For all intents and purposes, it's not that he doesn't exist. He does exist. He has a life and stuff. It's just that his life online is not controlled by him because he hasn't really produced anything there. You pretty much have to kind of flood if you want to control. Think of all these people that had one negative story about them because they did something stupid once and it was on YouTube and now that name is known. Now they're known as that Star wars kid, or whatever it may be. This is their reputation that they have to carry around forever. And the only way you could ever overcome that is just by flooding the inputs, flooding Google with all kinds of other stuff about you.
C
Yeah, and, Joel, you were taking it offline. You put yourself in print just in case there's some big EMP that wipes every.
A
Every disk in the world in case of emergency.
C
Yeah.
B
I think for the average person, that's what Facebook and MySpace and things like that do for you. They give you an ability to put a footprint on the web that you can kind of control to some degree. Because they're not going to certainly write blog posts. I mean, the average person is just not going to blog. And I know, Steve, one of your absolute favorite things you ever wrote, and I always cite it all the time, is the one about why you should write blogs.
C
Yeah, love that one.
B
And the thing that's challenging there is that for a lot of people, it's just not in their DNA to do that. It just isn't. It's not going to be. I don't care. Cajole them. It's an excellent idea, but it's just not going to happen. And I feel like for those kind of people, stuff like Facebook and MySpace and to a lesser extent, the stuff we're doing is stack overflow is a way for them to have a footprint without trying to convince them to do something that would be awesome, but they're just not going to do it. It's not in their DNA. So it was a little frustrating to me because I would work with these brilliant, brilliant programmers that nobody knows about. And I still feel like there's this huge untapped market of really excellent programmers that nobody knows about because they're not marketing themselves. I guess this all goes back to.
C
Marketing and you have hallway conversations with people who are brilliant. Right. And their ideas are brilliant, but that's it. Their ideas are limited to hallway conversations. It's kind of sad that people don't take a little bit of time to write down what they're thinking because they may think it's not interesting, but somebody out there is going to find it interesting when you show it to 4 billion people, you know, and then I.
B
Feel guilty too because people will criticize you about your public presence. And I kind of agree with them that it's not that for me in particular, it's not that I'm really that good at what I'm doing, it's that I'm noisy. Right?
C
And to a certain degree, I hear you.
B
If you're good at, if you're good at making noise and you can make the right noises that sound kind of right, you can achieve a level of success that you really probably don't deserve. And I'm speaking about myself here. I'm not talking about you guys.
C
No, no, it's true for me too. I mean, I know so many programmers who are better than me. I mean like, and everybody always assumes that because I'm talking about things and offering opinions that I'm implicitly saying that I am an expert or that I'm a better programmer than them or that I'm arrogant when in fact, I mean, I've said it, you know, again and again and again. I mean, I'm a dumbass, right? I have an internal blog inside of Google called Dumbest Person at Google where I offer the sort of tongue in cheek inductive proof as to why I'm the stupidest person in the company. And people loved it, right? I mean, you know, because, like, because it was kind of true and it was nice to hear me saying it, but I still don't understand. I think it's just people's natural reaction when you say something that accidentally puts them on the fence of, you know, they take the other side. You know, you've said something that they identify with and you've said it's stupid or it sucks or it needs to change, then their first reaction is going to be ad hominem.
B
Right? Right. And that's another reason a lot of people don't do it. They just don't want to be attacked, like ever. It's kind of like when you play a video game and really the goal is just to win.
A
And they're right.
B
People don't really want to be challenged, they just want to win.
A
Forget challenged. Exactly. No, they don't mind being challenged. They Want to be challenged and overcome.
B
Well, be challenged and win. They want to have the illusion of potentially losing, but they don't want to actually lose. It's really true. If you look at game design, that's how it works. You have the perception of danger. You always feel like you're in danger, but you're not really.
C
You're ruining my video game experience. I don't want to hear any more of this.
A
I don't blame people at all.
C
I was in real danger, buddy.
B
If it wasn't for your skill on the controller, the earth would have been lost. I mean, without you, Steve. I mean, clearly.
A
Hey, we are way, way, way out of time.
B
Well, I figured it was okay to go over because this is Steve Yegi. I mean.
C
Your podcast is too long.
A
Now. I feel bad.
B
No, no, no. Come on, Steve. He probably gets this all the time. His stuff is awesome. And it was a great honor, Steve, by the way. Great honor to have you on. And it's interesting. Certain people, and this happened with Joel. I feel like I know you, even though I don't know you at all through your writing. So, like, when I talk to you on the phone, it's like, oh, we're just continuing conversation that we had already had. And I love that about what you write. And thank you for taking the time to do that, to do this with us.
C
Thanks for having me on this, man. I mean. And I'll send you some mail about where to send my honorarium. Oh, you didn't tell your viewers about that. Okay.
B
Oh, that's right.
C
It's been great, man. Thanks for having me, guys. Thanks. Do it again sometime.
A
Thanks for coming on. We sure appreciate it. It gets lonely with just me and. What's that kid's name again? Jeff. Me and just me and Jeff, we like, you know, I just call him old thing.
C
All right, well, it was definitely. It was actually online. So, like, if you guys want to have me back on sometime, I'd love to do it.
A
Cool.
C
All right.
A
All right, thanks. All right, see you later.
B
Bye.
A
Steve, before we hang up, I got some announcements here. One of the announcements. Hey, we do. We haven't taken calls for a couple of weeks, but they are sort of piling up. And we do encourage you to call in if you have questions for Jeff and I. If you got anything you want to talk about with Stack Overflow or if any of the issues that Steve Yegi brought up today are interesting and you have any comments on that, call into our podcast hotline. You can either call by phone and the number for that is 646-826-3879. Or you can email an MP3 or Ogg Vorbis file and just email that to podcastackoverflow.com either way, try to keep it under 90 seconds and we might play it in a future week. Anything else?
B
Jeff? No, I think that's it. And I think maybe we should have a question show. I think we're far enough behind that we should think about having almost all questions show.
A
Yeah, send in your questions. We're running out of interesting things to talk about. Hey, quickly, anything new in Stack Overflow this week you want to announce? I noticed all kinds of new tabs here.
B
It's so long. I would say follow the blog. I'm trying to get better about putting more stuff on the blog about the changes that we're doing.
A
Cool. I'll just send people to blog.StackOverflow.com blog.StackOverflow.com as usual. If you'd like to contribute a little bit to the community, we have a transcript wiki online and there will be a link to that also at the blog post. Or you can go to stackoverflow.fogbugs.com and look for the transcript wiki and what you'll find. There is a community from around the world of people who are volunteering their time to just type out a few minutes or a few seconds or a few lines of this podcast to contribute. And very rapidly that becomes a complete transcript, which is very helpful to people and allows it to show up in searches. And it helps people who are hearing impaired or don't feel like listening to a 4 hour 65 minute podcast with Steve Yegi just going on and on and our boring selves. So that would be appreciated. Until then, see you next week.
B
Yep, bye.
A
You've been listening to Stack Overflow with Jeff Atwood and Joel Spolsky. The Conversations Network is a 501c3 nonprofit and we need your help. For a tax deductible donation of as little as $5 per month, you can support this channel and the rest of the Conversations Network. So please visit conversationsnetwork.org to become a member and help us continue to bring our programs to the world for free. Our audio files are delivered by Limelight Networks, the high performance content delivery network for digital media. The post production audio engineer for this program was Joel Spolsky. Our website editor was Jeff Atwood. The series producer is Jeff Atwood. This is Phil Windley. I hope you'll join me next time for another great presentation from Stack Overflow here. On it. Conversations.
Podcast: The Stack Overflow Podcast
Episode: #25
Date: April 19, 2011
Hosts: Joel Spolsky, Jeff Atwood
Guest: Steve Yegge (Google engineer, prolific blogger)
Episode Title: (Unofficially: "The Steve Yegge-thon")
Main Theme:
A wide-ranging, candid discussion with Steve Yegge about software development culture at Google and beyond, code quality, the evolution of programming languages, internal innovation vs. startups, and the challenges and rewards of technical writing.
This episode is a deep dive into developer culture, both inside Google and across the industry, featuring Steve Yegge. The conversation offers insider perspectives on:
On workplace adaptation:
“People change to fit the company that they're at…they adapt. Peer pressure to unit test and document things…and they've got a lot of even automated processes…to almost force you to do it.” – Steve (07:01 / 08:02)
On innovation inside vs. outside:
“The more people you have to convince, the more unlikely it will be to get made.” – Joel (22:37)
On language choice and gear obsession:
“Like the kid who says I'm gonna learn guitar…what's the best guitar to get? …A real guitar player would pick up any old crappy piece of guitar and have fun with it.” – Joel (40:26 / 40:47)
On fame and anxiety:
“I could make the Google experience good for me internally…I'm also good at marketing. And I'm working right now on a project that was my idea.” – Steve (34:40)
On code and identity:
“Identifying with anything so strongly that it starts to give you emotional reactions is really bad…because you never know when your language is going to be obsolete or your project is going to get canceled.” – Steve (38:38)
On the permanence of online identity:
“Everything you write will basically last forever now.” – Steve (65:21)
The episode delivers a broad, nuanced view of developer life at “web scale”, software culture traps, the fallibility and heroism of programming languages, and the weird, inexorable importance of self-published writing. Through humor, candor, and a bit of snark, Joel, Jeff, and Steve demystify several cherished developer myths and surface timeless realities about craft, innovation, and human aspiration in tech.
Recommended for:
Developers at all levels, engineering managers, tech bloggers, and anyone fascinated by the history and sociology of programming.