The Changelog: Software Development, Open Source - The Kollected Kode Vicious (Interview)

Episode Date: November 13, 2020

We're joined by George Neville-Neil, aka Kode Vicious. Writing as Kode Vicious for ACMs Queue magazine, George Neville-Neil has spent the last 15+ years sharing incisive advice and fierce insights for everyone who codes, works with code, or works with coders. These columns have been among the most popular items published in ACMs Queue magazine and it was only a matter of time for a book to emerge from his work. His book, The Kollected Kode Vicious, is a compilation of the most popular items he's published over the years, plus a few extras you can only find in the book. We cover all the details in this episode.

When people write in, I actually respond personally from my email. And, you know, because they'll usually ask a specific question and I'll say, oh, this is a very interesting thing. And if I write a piece and it's published, then I'll send that to them later. Yes, I get emails as code vicious, but it's not like, you know, I'm not Dear Abby or Dear Ann. I'm not getting hundreds of letters and I don't have a staff that has to address them. So, you know, I respond to all emails personally and thank you for your question or we published this under blah, blah, blah at this or that's really interesting. But maybe if it's something that is actually really interesting to me, I'll respond not as code vicious in the email to them, just saying what I think generally without going to 1,500 words. And then I'll write the piece.

Bandwidth for ChangeLog is provided by Fastly. Learn more at fastly.com. Our feature flags are powered by LaunchDarkly. Check them out at launchdarkly.com. And we're hosted on Linode cloud servers. Get $100 in hosting credit at linode.com slash changelog. What up friends? You might not be aware, but we've been partnering with Linode since 2016. That's a long time ago. Way back when we first launched our open source platform that you now see at changelog.com, Linode was there to help us, and we are so grateful. Fast forward several years now, and Linode is still in our corner, behind the scenes,

helping us to ensure we're running on the very best cloud infrastructure out there we trust linode they keep it fast and they keep it simple get a hundred dollars in free credit at linode.com slash changelog again a hundred dollars in free credit at linode.com slash changelog Welcome back, everyone. Yes, this is the ChangeLog, a podcast featuring the hackers, the leaders, and the innovators in the software world. I'm Adam Stachowiak, Editor-in-Chief here at Changelog. Today, we're joined by George Neville-Neal, aka CodeVicious. Writing as CodeVicious for ACM's Q Magazine, George Neville-Neal has spent the last 15 plus years sharing insights of advice

and fierce insights for everyone who codes, works with code, or works with coders. These columns have been among the most popular items published in ACM's Q Magazine, and it was only a matter of time for a book to emerge from his work. His book, The Collected Code Vicious, is a compilation of the most popular items he's published over the years, plus a few extras you can only find in the book. We cover all the details in this episode. So we're here with George, aka Code Vicious. For for the last 15 plus years you've been writing this column for acmq which is kind of an ask annie style column where people write in and you respond under this code vicious persona which is kind of a angsty i don't know kind of a neck beardy you can describe it, programmer.

Cranky. Cranky, there you go. That's the word I'm looking for. And you've been doing it for so long that you've turned this into a book now called The Collected Codevisions, which we're here to talk about. But tell us, first of all, how'd you become this character? Tell us that story. So I was involved with ACM's Q Magazine from nearly the beginning. They had invited me in to actually do an issue on embedded systems because Q is actually curated content. We go out to people in industry and we try to find people who will write about particular topics. They were doing a topic about embedded

systems, which is something I've done a lot of even back when they started. And they liked the issue so much they put me on the board, which was an amusing surprise. And about a year into the magazine, we realized we had no columnists. We didn't have any regular feature writers who came back with a consistent voice. And it was something we felt the magazine needed, or at least some people felt the magazine needed. So Q editorial board meetings actually are held over dinner at a nice restaurant, which is the closest thing to a payment we get for working on this stuff. Yeah, it's not a for-pay gig, but very nice dinners, very nice people, far too much wine, it turns out. So at one of these meetings, we were discussing, well, what are we going to do

about columnists? And someone else, Wendy, turned to the table and said, well, we should have someone who has a real attitude problem, someone who's bald. And for your listeners, I have been shaving my head for most of my career. So I was tagged with trying to come up with a column. And the original idea was something along the lines of actually Miss Manners, which I used to read with my mom when I was a kid. And people would write in and you give a kind of a snarky response. And, you know, initially I tried to write very much in her style, which is nearly impossible for what I wanted to do. So the style went through a couple of revisions. You know, it's, we had a whole bunch of ridiculous names that you can see in the preface to the book where I talk about what Code Vicious could have been named. But along the way, I realized that what I really wanted was something

where I could vent my spleen over incredibly stupid things that happen at work, which I think is something that all of us really want to do, but not many people take the time to sit down and try to reason out a rant over 1,500 to 3,000 words. So I did that, and I came up with a bunch of test pieces, brought them to the board, and we hammered out the name Code Vicious, which I stole from Sid Vicious, because I'm an old-school punk rocker. And then that was how the actual pieces

started getting written. We would put something in each issue, and then eventually they got reflected also into CACM, which is ACM's big print magazine so it's funny that you stole it from sid vicious because when i first heard it for some reason i thought about the macho man randy savage to me it sounds like a professional wrestler's land like oh yeah like you're gonna get like you're gonna take a chair and hit someone with it yeah which has a similar a similar style so is this code vicious vicious? How much of it is it you, your voice,

and how much of it is just purely fabricated because the column has to be cranky and snarky, like you said? Well, so I don't know how many of your listeners will be people who've worked with me on various open source projects or other projects, but I have been a cranky old man since I was a young man, and now I'm just aging into it. So I've got the great beard, which helps.

And I've shaved my head for a long time. That helps. Tattoos kind of give a sort of an aura of harm. So it's actually not very far from my voice. It's kind of that voice that you'd like to use in meetings or I'd like to use in meetings, which I don't get to use in meetings because HR would fire me. It's very close to the voice that I use for that particular piece. Now I've written, you know, I've written textbooks, I've written this book and I've written the columns and I've written, you know, scientific papers. So those are all written in a different voice. And this

is the one that is, I wouldn't say it's the closest to my personality, but it's the most freeing. You know, I don't have to sit and very carefully consider which terms I'm going to use. I can, for the most part, stream of consciousness, how I feel about a particular topic, and then go back and do some editing. One of the things I mentioned in the book, and I've mentioned before, when we got to our 100th column, we had a special column for the 100th column. And one of the people I credit with a lot of the readability of the work is actually Jim Moore, who's been the publisher of Q and has been the editor of Code Vicious the entire time that I've been writing it. So every once in a while, I'll read one of my own columns and think, did I write that or did Jim edit that in? And then I had to go

back and look at the original. Sometimes the clever line is mine and sometimes the clever line is Jim. And sometimes the fact that I'm not saying things that would get me censured at ACM is Jim's help as well. But yeah, it's very close to kind of, I like to think of it as if someone were to come into my office and ask me a really stupid question and we were to have to go over it, that would be the kind of thing that I would, you know, 80% energy level of what I would kind of say, no, look, this is what's going on. You're absolutely wrong. Or this is why this is terrible. Or, you know, why didn't you look at these things? And it's very much that kind of feeling. Whereas, you know, when you're writing a textbook, you don't get to write like that. You know, it's very, I wouldn't say dry. We try to make it so that it's

not too dry, but it's definitely not. There's a lot less emotion, a lot less heat in, you know, my other writing. And in this, I get to, you know, go full bore. On that note, there's a well-known term that emotion is energy. It has to go somewhere. At least we say that on our show, Brain Science. And I'm curious that this is an outlet for you in terms of therapeutic even. Oh, yeah. I mean, well, I wouldn't want to shrink to be reading these columns and telling me what they really thought of me, sending me pages from the medical text. What I mean is in terms of being an outlet for you. It is definitely an outlet for me.

I mean, initially when I started writing them, you know, they would come up each month because we were doing 10 issues a year of Q at the time. And, you know, it'd be like, oh, well, you know, what are the things, who's written in or what do I have that I want to write about? And then over time, I realized every time

I was going to be really angry at something at work or really angry at something in a piece of software, I could just write down what I was angry about in this file. And then when I ran out of material, I could just go open the file and I'd be angry all over again. And so in that way, yeah, it's definitely a way of keeping myself from, I haven't put any holes in my office wall in a while, but it keeps me from smashing things on my desk or screaming too loud and scaring the neighbors. It is definitely a good outlet. And the thing that's always an interesting balance is, well, how much of it is outlet and then how much of it will be useful to a reader, right? Because just having me scream into a text buffer, while that might make me feel better, is it really going to help my readers? Well, is there a framework to what you write then? So, you know, balancing the outlet in terms of, say, emotion and letting loose and being free, which you write, but then also being,

I suppose, having a decent answer. And you sort of have to weave the two in there, right? How much is there a framework for it or a science to it? I wouldn't say there's a framework or a science or an outline, a formula. I mean, it's always call and response, right? There's a letter that comes in and here's what the problem is. Here's what my problem is. What do you think of this problem or what do you think of these things? And then my response is an opinion. And so when I write the response, the one thing I do, and sometimes I have to catch myself in the middle of the writing, because when I do the writing, it is completely stream of consciousness.

I just sit down and I start typing. And I've been writing long enough that that, I mean, not just as code vicious, but generally, that that's a process that works for me. A lot of other people have to sit down and very carefully consider, whereas I can just sit, open a buffer in Emacs and just start typing. And I will exactly do that when I have to get a piece done. What I've noticed is about halfway through the piece, if I have not gotten to the point of writing the point of the response, like the bit, you know, what's the hook? What is the, even if it's not the answer, what is the thing I wish to communicate in response to the question? Then that's the point at which I sit down and I think,

okay, well, what do I really want to tell the reader? Because that's the thing that makes, I think, these things worth reading. If you want to just go read Rantz, you can just go read Reddit or some other bitch. But the point of the writing has to be to either get the person to think about something differently or do something differently or look at the problem from another point of view. And so that's, for want of a better term, that's the closest thing to our framework I have is that I'll usually get halfway through the response. And sometimes I will have gotten, you know, the point will be very forefront in my head, especially if, I mean, depending on what the question is, certain questions, you know, I kind of have the answer.

It's like, oh, no, I totally want to answer this in this way. And, you know, we're going to, I'm going to take them on an arc from the beginning to the end of this 1500 words. But in the last 500 words, we're going to get to the point of like, here, these are the things that really matter. So sometimes that's very apparent to the beginning. Sometimes it's not. If it's not apparent at the beginning, then I'll just start writing. And sort of as I get to the middle i'll usually have written down you'll see this and i think a significant number of the pieces that eventually you wind up with like there's a list or a

description list or something like that that gets called out which is okay you know we've talked about this problem here are the five things that i think are really important and those are my answer right there's this old snl sketch with jimmy fallon i don't know if you guys remember where he played nick burns your company's computer guy and people would call him for help over to their desk hey hey i can't hey nick i can't get the email figured out whatever and he was this obnoxious cranky his tagline was move like he's just like get out out of the way. I'm going to do it. Nobody liked the guy. He played into this trope and this stereotype of the angry,

cranky, obnoxious, in that case, IT tech support person, but translated over to programmer. I think Code Vicious could potentially go there if you weren't actually being helpful. He's like, I'll do it for you. You can't reach across your column and say, let me write that code for you or let me just do it

because that's not the point. And so I feel like there could have been an opportunity to lose the thread and just become a cranky guy, like you said, berating people through your text buffer. But if you keep the column actually useful, people know what they're going to expect. They know it's code vicious, so they're not surprised when you

interweave the crankiness into the pros, but you actually have something to say that's useful at the end of the day. I think it's a nice combination of entertainment and education in a way that's like you know what you're getting. I think

that for me, even when I'm dealing with people one-on-one, I mean, I, you know, the nice thing about being able to write code vicious is I can say things in code vicious that I cannot say at work, even though I've thought them so loudly, the paint would come off of a, you know, the conference room wall, right? People have pointed out to me, so I wear glasses and people pointed out to me that they love being in meetings with me when I take my glasses off because they know I'm about to say something really horrific. Usually someone in the meeting has said something really, really dumb

and just really totally useless to whatever problem we're trying to solve. And I guess my tell is to take off my glasses. So I definitely don't make for a hostile working environment, but writing the column is the place where I get to do that. But yeah, as you say, if it were just that, it would not be entertaining. I can't imagine that people would have read it. I mean, I was quite surprised when, I don't know, five or six years into it, I found out that Code Vicious is the single most popular thing that's ever been written for ACM. Now, there are not many columnists at ACM. I mean, we've got Tom Limoncelli and a bunch of other people have come in from Q and some people in Kackham. But it turns out that Code Vicious has been downloaded by more people than anything else on ACM's digital library, which is one of the reasons I thought a book might be appropriate. So clearly, I have not – either people are all masochists and like to be verbally abused every month, which I don't think is true.

Or I have found a way to actually temper that with useful advice. Well, I think you struck a nerve, like you said, with your readership. And obviously to do this for that long, every month for 15 plus years, with payment being an annual very nice dinner and the like, you must be enjoying it.

The readership enjoys it. And notably, quite notably, one specific reader who wrote the foreword for your book likes it, which, you know, put that on your wall. Tell us about Donald Knuth and his thoughts on Code Vicious. So amusingly, you say put that on the wall. Well, I'll tell you about something that's on my shelf, which inspires me to write every month or two.

So for the Turing 100, ACM did this. I think it's actually the best event ACM has ever put on because instead of it being targeted at a particular area of computer science, ACM's things are very much, you know, SIGGRAPH, SIGCOM, the various SIGs. And so you go to a conference, you're only talking about graphics. You go to a conference, you're only talking about operating systems or computer languages, things like that. For the Turing 100, they brought in as many Turing award winners as they could, and they had them on panels talking about their areas. So we had a day and a half of a session on programming languages, a session on operating systems, a session on graphics, a session on AI.

It was great. And, of course, Donald Knuth, a very famous Turing Award winner, was there. And it just so happened that I'd actually met Don at a hackers conference years before. And we weren't friends or anything. We just chit-chatted. But I found out from another colleague that Don, he came up to me and he said, Don's looking for you. I'm like, OK, Don Knuth is looking for me.

That's a little strange. And I'm like, did I say something that offended him? I'm not sure. So I happened to, you know, when you're code vicious, that's kind of what you should assume is like, oh, I've said something terrible. Anyway, so I'm at the conference hotel in San Francisco. I happened to find Don in the hallway.

I was like, oh, hey, you know, Jeff told me, our mutual friend Jeff told me you were looking for me. What's going on? He's like. I was like, oh, hey, you know, Jeff told me, our mutual friend Jeff told me you were looking for me. What's going on? He's like, and he says, oh, I didn't realize that you were actually Code Vicious. I'm like, uh, okay. And he says, I love your writing. At which point I did my very best not to soil myself. Um, and you know, some, it's like one of those Warner Brothers cartoons where your soul jumps over the moon kind of thing. And I'm standing there and I'm talking to Don and I'm thinking, now what do I say besides

thank you? Which I said like three times. And we, we got to talking about the column and he actually asked if he could write a letter to Code Vicious. And I'm thinking, how do I sarcastically respond to one of the nicest and most brilliant people in computer science as CodeVicious? I am screwed. But of course, you know, to Don, I said, sure, I would love you to write a letter that would be incredibly kind. I will do my best to answer. And we talked for about 20 minutes. So, you know, Don doesn't do email,

right? So he has a secretary who's handled his email for a long time so he sends me a postcard which i have on my shelf because when i'm feeling like i don't want to write this month's code vicious i just look at the postcard from don canoes i'm like i guess i have to write this and so he wrote a he wrote a postcard asking about his current book and i sent him a personal response instead of putting this into a Code Vicious. Because like I said, there was, how am I going to respond to Don Knuth exactly as Code Vicious just seems terrible. And so that was the story of Don writing a letter and getting a response. It was actually cited in, I've got the books on my desk, I think it's in 4A, the responses in there.

So my name is in one of the volumes of The Art of Computer Programming. So 2012 was basically the year that I didn't need to do anything else as far as I was concerned because I'd gotten all the kudos I was going to possibly get. But you mentioned that he wrote the introduction, which is another story. So every year there's the Turing Award dinner ceremony, which is a bunch of geeks in fancy dress. It is really quite terrifying to see all of us in tuxedos and the women are in top of the line dresses and we're all a bunch of nerds dressed like that waiting for things to be announced. And I will tell you that Vint Cerf thus far has the best tuxedo of anyone who goes to the Turing Award. So my publisher, Jim, was trying to get me to do the book. And I was like, well, you know,

I don't know. It doesn't make any sense. We've already done all of these things. How would it be interesting to collect them together? But I was thinking about it. And it was Jim's suggestion. He said, well, why don't you ask Don to write the intro? And I'm like, it seems like an imposition on someone who's been very nice to me. But I saw Don at dinner, and I asked him about it. I was like, you know, I'm thinking about doing a book. I know you've enjoyed the columns. Would you be so kind as to – would you be willing to write an introduction? And he says, oh, I don't usually do that, but I'll think about it. And this very sort of, you know, I was like, okay, well, he probably won't do it.

And that was about a year, year and a half before last November, when I again saw Don at this conference that we both go to in California. And Don comes up to me and he's very excited. And he says, oh, I need to show you, I've written you the most wonderful introduction. And I realized, I'm going to have to write the book. I'll have to write the book. That's how we came to get the introduction. And yeah, then November.

So that conference is in November. So it was November of last year. And I immediately emailed Jim, my publisher. And I'm like, OK, so we've got an introduction. Now I need to put the book together. And then I, from there on, created the, and I'm like, okay, so we've got an introduction. Now I need to put the book together. And then I, from there on, created the book and found a publisher. And now it's a book. In fact, I believe I get paper at the end of this week. So it's available electronically, but I'm really looking forward to it. I'm old school. I like the physical book as well.

Yeah. This is a slight aside, but I'm curious of the feedback loop, because in this case, Donald Knuth came to you personally and said, can I write a letter to Code Vicious? But I'm curious, is the feedback loop to others who write in just simply the printed version of it or the published version of it? Do they get some sort of feedback loop saying, hey, you've written in and here's the response from Code Vicious? So when people write in, I actually respond personally from my email. And, you know, because they'll usually ask a specific question and I'll say, oh, this is a very interesting thing. It's if I write a piece and it's published, then I'll send that to them later.

Yes, I get emails as Code Vicious, but it's not like, you know, I'm not Dear Abby or Dear Ann. I'm not getting hundreds of letters and I don't have a staff that has to address them. So, you know, I respond to all emails personally and thank you for your question or we've published this under blah, blah, blah at this or, oh, that's really interesting. But maybe, you know, if it's something that is actually really interesting to me, I'll respond not as code vicious in the email to them, you know, just saying what I think generally without going to, you know,500 words.

And then I'll write the piece. And then once it gets published, that's when they hear back. Do you say that you actually respond with the piece at a certain point in your email? Or you just email them back and say, hey, it's published. Hit this up. I usually respond twice. So I'll respond immediately, within a few days. I mean, who responds immediately to email anymore?

I'll respond within a few days and say, oh, well, that's a really interesting topic. Immediately. Completionist over here. Gotta respond. Maybe I should give you my inbox. You have to pay me more than one nice meal a year. A year?

Okay. Anyway, so when people write into Code Vicious, then I will respond within a day or so, as long as it's... I mean, the funny thing is I've not gotten, and I probably shouldn't say this on the air, I've gotten very few random spam emails to Code Vicious. I mean, all of the email that's actually come through the KV link has all been from people with serious, you know, comments or concerns or questions. So I always respond, you know, from my personal email first, like, oh, thank you for writing in. And that was very interesting. And here's a bit of what I think of that or about that, or, you know, this is interesting or this is not, but, you know,

conversational kind of email. And then if, and when I publish a piece based on the question, then I'll send them the, you know, follow up, like, cause it'll be if, and when I publish a piece based on the question, then I'll send them, you know, follow up, like, cause it'll be months, right? I mean, if they send me something, I might not write about it for a few months and then eventually I will. And I'll be like, oh, that came from this person. I'll send them an email and say, by the way, I really enjoyed your question. And here's, you know, the, the code vicious response. What's up friends? When was the last time you considered how much time your team is spending building and maintaining internal tooling? And I bet if you looked at the way your team spends its time, you're probably building and maintaining those tools way more

often than you thought. And you probably shouldn't have to do that. I mean, there is such a thing as retool. Have you heard about retool yet? Well, companies like DoorDash, Braggs, Plaid, and even Amazon, they use retool to build internal tools super fast, and the idea is that almost all internal tools look the same. They're made up of tables, drop-downs, buttons, text inputs, search, and all this is very similar. And Retool gives you a point, click, drag, and drop interface that makes it super simple to build internal UIs like that in hours, not days. So stop wasting your time and use Retool.

Check them out at retool.com slash changelog them out at retool.com slash changelog. Again, retool.com slash changelog. so you've been writing these columns for a long time you've stacked up a huge pile of them now it's time to put together a collection surely they all didn't make the cut i see 87 essays across five chapters you've got them broken out nicely into some logical sections, the code at hand, coding conundrums, systems design, machine to machine, human to human. And then the essays are kind of fit in there as they make sense. But how do you go about even selecting?

You know, I'm sure you have your favorites. You probably have ones that you despise. Then there's ones that readers like. What was your process for actually putting this thing? Because probably there's some that aren't relevant anymore. So when I went to put them together, the first thing I did was I asked Matt Slabaugh at ACM, who does all of our stats, tell me which were the most popular. Because obviously, I wanted to know which ones people had read and, you know, read to the end, because we have the whole dwell time and all that stuff.

And so I started out with with most popular, but, you. But it's interesting that you mentioned the chapter names. That was the hardest part, fitting the pieces into a narrative that makes sense. One of the things I've actually written about is Code Vicious, especially since I've written a lot about documentation, good and bad documentation. I'm very big on narrative. I don't want to just splat words at people randomly and have them try to pick up information from that. So, you know, we started out with a list from most to least popular. And then I went through and I tried to find things that I thought kind of suited my frame of mind. So if you look at the chapter names themselves, Coded Hand, Coded Conundrum, System Design, Computer to Computer,

Human to Human, those came about because when I looked at the pieces all across the entire set of what I'd written, those were the five major themes. There are other pieces that lie outside those themes that talk about topics maybe that aren't easy to slot in there. But overall, I was like, oh, so there are places where I talk about very specifically, what should you do with a piece of code? Or more broadly, okay, we're going to design a system, which is a much bigger problem than just writing a function. Computer to computer is in there because I'm a networking geek and I've always been a networking geek, and it's the area that I enjoy working on most. So obviously, I was going to write a lot about that as Code Vicious. And then the most surprising one, of course, is to a nerd anyway, someone who works on deeply nerdy things is human to human. I had

actually written a significant chunk of material about how to deal with people at work, how to deal with, you know, explaining your work, all of these kinds of things, which are, you know, one of my publishers likes to say, well, those are the soft skills. And I'm like, I didn't think I had those. I don't think I'm supposed to have those. So, you know so once I had this list of what was most popular as well as the list of everything I'd written and then I saw these five areas then I just thought okay well I'm going to pick those as the five areas and I'm going to slot

pieces into each one and see which ones make sense and see which ones don't there were pieces that were definitely outside of those five areas, there were pieces that weren't as relevant anymore or would have required a lot more new words to be written around them. So one of the things that was nice about writing the book, when I first had the idea for the book, when we were talking about the book, the thing that I worried about most was I wouldn't have something new to say. But the nice thing about having the pieces is I could then go back and each piece begins with another new, let's call it an essay, about the topic that I wrote about.

So even if something was not relevant anymore, although I didn't include those, but even if something was changed in the last 10 years, I could talk about the changes and still leave the original conversation at, right? I could say how my thinking had evolved or how technology had evolved or maybe, oh, it's still the same problem, only faster, which is a common thing in computers. We're like, oh, we had these problems before. Now we just have them more quickly because we have faster computers.

So that was a lot about how to get that in there and how to pick the pieces and make sure they were relevant. Kind of like a director's commentary on his movie. You get a chance to actually just take your pieces and like, hey, here's a commentary, setting it up or tearing it down, and then here's the actual piece of content

that originally was written. I guess that's a good description. What about the quotes that go along with that? How was that selection process for you? I know some of them are, they're all pretty good. I like them all. So explain the quotes. So each essay has your intro,

but also has some sort of quote alongside. Right. Oh, epigraphs. And some of these are anonymous. Some of these are some from famous people, et cetera. So I've always liked epigraphs. In fact, I'm kind of stealing something that Don Knuth does in his books.

He's got them all over the place and his are far more intellectual than mine are. But I wanted to have something, I mean, part of doing Code Vicious is effectively I'm doing standup technology, right? I'm a standup comedian talking about technology, a very unfamous standup comedian talking about technology. So one of the things I always like to bring to the pieces and I realized I could do with the book and with the epigraphs in particular was to be funny. It was like, Oh, okay, well, you know what, how can we talk about this in an amusing way? Or how can we find some of those epigraphs are, you know,

quotes from famous computer scientists talking about how terrible software is. Right. So I guess in a way I'm dragging them along with me and making it seem as if I'm not the only cranky person in the room. Actually, my favorite epigraph story. So there's a musical comedian from the 1950s and 60s, Tom Lehrer, which he was quite famous for a long time. Some people in tech still know who he is. But he wrote this spoof song called Lobachevsky which talks about plagiarizing other people's work in mathematics and when i was putting in the piece about copying other people's work in computer science i'm like i i have to quote lobachevsky i know all about copyright but then of course my you know piercing came back and they're like yeah this is still

under copyright so you can't use this and i said well what if i can get permission and they said sure i'm like okay fine so um lara taught until some number of years ago he's now 92 but he taught a large part of his career at uc santa cruz i have friends at uc santa cruz i emailed them i'm like hey can you find tom lara and uh you're figuring okay it's you know it's a last-ditch effort i really want to use this piece. And three days later, as a text message, I just get two phone numbers and an email address from a friend of mine in Santa Cruz. I'm like, this is Lara's email address, right?

And they're like, yes. So I'm not calling this nice 92-year-old man to ask him for his permission. So I email him. I get an immediate response. He's very kind, very snarky, which was amusing. His comment was something like, oh, publishers are terrible and Pearson is the worst, which is my publisher.

And then he sent along the permission form sign. Amusing follow-up, though. Two months later, just this month in October, he's actually released all of his works as public domain. So all of Tom Lehrer's works, many of which are funny and many of which are classics, now anyone can have them as an epigraph in their book. That's pretty cool. So I don't know if I caused that by prompting that or he's just realizing he's 92. Yeah. Got easier to give permission. Or you just have really bad timing because you could

have just waited a little while. Saved yourself the trouble. Yeah. Well, you know, printing deadlines are worse than software deadlines. You can't push printing deadlines because they have these machines that print the books. So I was on a real deadline, not a software deadline. This chapter you're referencing, too, with this epigraph, it's copying. And I'm noticing that there's no in-write. So even part of your response to your pre-essay to what you had written prior to or what you published wasn't someone saying, hey, can you write about this? Or, hey, KV, here's my question. Is this an anomaly where it's you writing without, you know, sort of the, what do you call it? The call and response.

Call and response. Yeah. Without the incoming letter. Yeah. So there are a few pieces. I would say one per year where, you know, I have a topic I want to write about, but no one's written in about it. And so I'm just going to write about it. In the 15 years, there's probably been 10 or 15 of those. And yeah, this is one of those. There had been this, I mean, I can't mention the company or the person, obviously, but there had been an issue. Which had caused me to take my glasses off in a meeting. And I thought, OK, I need to write about this.

And it's funny or ironic, I guess. You know, sometimes I write about these things and I think, you know, this is kind of obvious. How do people not know this? A colleague of mine who's a relatively well-known computer science professor, having read that bit, was like, I am going to make all of my students read this because at least 10% try to cheat every year and they all get caught. I'm like, oh, I guess that was useful. But it was a very funny, for me it was something I just felt I needed to write because I was dealing with people who didn't get the issue. And then again, it turned out to be useful to someone else so that was that's always a good feeling what interesting about artists and you mentioned your association as opposed to stand-up comedy this is stand-up comedy with coding

involved i suppose if you're if that's how you how you say it is you have to have something to say right like artists the reason why they get up there in the first place or show up is they have something to say not too often you see an artist show up and have nothing to say so you have something to say is the point i think it would be difficult to sustain the act of creation which is a very highfalutin way to talk about this but it would be very hard to sustain the act of creation if you didn't have anything to say and actually i I like to point out the stand-up comedy thing or stand-up technology, as I like to call it. There's another aspect to stand-up comedians

that I think is relatively important and which I probably shouldn't admit, but it'll be very obvious. We like to be the center of attention. So not only do I have something to say, but I like getting the feedback, right? You know, many of us who went into technology just wish to be left alone

and have someone put pizza under the door and we'll slide algorithms out under the door. But that is definitely not my personality. I mean, I give a lot of talks, you know, on usually operating systems and sharing topics. And I am one of those people who is energized by doing that. Right. You know, most people, when you're like, oh, you have to give a talk, they're like, oh, my God, it's the worst thing I would ever want to do or they don't want to do it. And I'm like, sure, what's the topic? You know, how long do I have? You know, where are we going to be?

And I, you know, I'll just do that. And, you know, to the point of doing Code Vicious, it's definitely a longer round trip to feedback, right? Because, you know, I don't get comments immediately. I don't always have people coming up to me at conferences telling me they love my work or trying to hit me with something if I'm waiting to happen. But I think definitely I have something to say. It seems like I have many things to say. Many people have pointed out that I just don't stop saying things. But, you know, there's also a certain level of validation, right? You know, there's, oh, a lot of people read this and found it interesting. People want copies or people want to use it in their class,

like this friend told me. And, you know, that kind of thing, it's like open source software. One of the things that's great about working on open source is when someone uses it for something else, right? You know, the fact that FreeBSD, which I've worked on for many years, is used in storage devices and networking devices and gaming consoles and stuff that I would never build. But, you know, when I find out, oh, you know, this piece of hardware, this piece of software uses something I worked on. And that's a really good feeling. And I think the same thing is true of writing.

Absolutely. Well, to dive into a couple of your pieces, we've selected a few essays that have piqued our interest. Interestingly enough, the one that I liked was another one of these oddities where there's no call and response. You just wanted to write about this. This is chapter 1, essay 9, a nice piece of code. And this is all about writing good code. So you have thoughts, you have opinions, as you said. What makes good code, readable code, et cetera. And you put them in this piece. I'm just curious if you could summarize briefly what you think is worth writing about in that area.

Sure. I mean, for me, one of the things I learned very early in my career is I was going to read a lot more code than I was going to write. I mean, I think a lot of people, you know, have this belief that they're going to come out and, you know, write reams and reams and reams of code. And even if you write reams and reams of code, even if you started writing reams of code when, you know, I was doing that in the 90s and 80s, you're still not going to write more than you're ever going to read. So for me, good code is readable, right? Readability really counts. So, you know, a lot

of this is very mom and apple pie, put in comments, have a reasonable coding standard. You know, there's a bunch of stuff like that. One of the things though, is, you know, people can argue about what makes a good style. The thing that I come out in favor of, and this comes out in several pieces in Code Vicious, is it's not just readable style, but consistent. You can't have five people on a team with five different styles. You're all going to have to pick one and stick with it. And I don't care if it's K&R's old C style or if it's the camel caps from Microsoft or various things, having a consistent style just makes things a lot easier. I mean, one of the places where I saw this applied really well

was a closed source shop that I worked. And we built, this is a company called Wind River. They built a system called VxWorks. It's an embedded RTOS. But they had a very strong coding standard for two reasons. One, they did code reviews of everything they did because our software did really cool stuff like go to Mars and also really dangerous stuff like run medical equipment. So it's good that you do a code review so that people don't die. Not dying, very important.

Good point. You know, the coding standard was specific even to things like noun verb, you know, is one of the things that I think was really good in that style. So, you know, if you're going to have something like file open, then it has to also be file close, file read, file write, not switching the words around. Consistency.

You know, a specific down to that. The consistency is really important. You know, over the years, I've tried to stay away from away from although i just published and this is outside of the book this is the the latest code vicious you know the tabs versus spaces thing oh you weighed in oh yeah i did let's go to vicious think about it my real belief here is that our tools now should be smart enough that it doesn't matter there There should be an hidden indent carrier character. I suggested a particular character in the latest piece. And then your editor should render it the way you think it should be rendered, right? I mean, Vim and Emacs and Eclipse and all

the modern IDs, Visual C and all this stuff, they can all do this for us instead of it being like, oh, no, no, only two spaces. No, no, only four spaces. No, eight space. No, it's a dab. I mean, for my eyes, which are now in their 50s, and I've always worn glasses as well, the two space indents, they don't fly for me. And that was always, I think, the GNU standard, which is what was used to write Emacs and GCC. Two character indents just don't give me enough of a clue of where things start and stop.

So I was always a fan of more indent than that. But it doesn't have to be done with spaces or tabs. It can be done with anything at this point. People should stop arguing about that. It's interface. It doesn't have to actually be a character to represent. It's really presentation, right? It's a presentation layer.

I mean, think of it like a PDF. Isn't that the argument for tabs, though? Like with a tab stop, you can just use it, you can represent it however you want, but the tab itself could be that character that represents how many indents you desire as the author. I mean, I'm not a tabs guy, but I think that's the tabbers argument.

That is one of the tabbers arguments. The problem is that people have gotten so tied to the tab character that I picked a character that is not, well, it's certainly printable, but you

wouldn't want it to show up in your code. I'm curious. So that's, well, it's the Unicode character for the poo, of course,

because that way when you turn on what the Unicode characters look like, all your indents are poos. But you can represent that any way you want. That's a good reason not to use tabs. There you go.

Well, it should be poos versus tabs, or poos versus spaces. Yeah, let's add a third entry into the argument. There you go. You just created a new standard. It's like SKCD, right? There's too many standards, so here's a new one to rule them all, and it's the poo standard. It's the poo standard.

So yeah, the indent thing, I did finally weigh in on that. I mean, I think there are a bunch of perennial sort of programmer technologist arguments, right? Tabs versus spaces. I love, and actually I wrote about this as Code Vicious,

people who want to pick host names. Like, what are the host names going to be for our company? That kind of thing. There are these constant arguments about that. But back to the thing of what makes good code. Good documentation, keeping the documentation, matching the functions. Again, I always go back to this stuff we wrote at Wind River.

We had a system like Doxygen before Doxygen existed. In fact, our tech writers would modify the manual pages came right out of the code, that kind of thing. It was really quite cool. And you had to make the match or someone was going to come and find you. That to me is really important, describing what a function does because people are like, well, just read the code. And you're like, no, I don't think so.

I despise single character variables outside of simple loops. Oh, good qualifier. I was about to throw in the simple loop moment, but you qualify. Yeah, yeah, yeah. There are times, right? Yep, 4i equals 1 to 10 is right. But please do not name the two most important sockets

in your 50,000 line routing daemon R and S. What if those are your initials and you want to put your stamp on it? Come on. That was not. Yeah, I really, you know, you're trying to find all instances of the, of the variable R and you're like, oh my, and it's a global variable because that's the way the person wrote the code. You're like, ah, awful. I heard lore of a guy who used Lord of the Rings characters

for all variables in his entire software, and he had been there for years, and this was like some sort of form of job security. So you could go that route. I guess what I'm going to set Gandalf to one, but do we have Gandalf the gray and Gandalf the white? Yeah, it gets tricky, but you can't fire that guy. Don't do that at home, kids. This is bad practice.

Yeah, CodeVicious says do not pick names from Lord of the Rings. Pick something descriptive. Yeah, so descriptive variables are really important to me. Functions with too many arguments are a classic one. I mean, you see this often in the actual Windows API where it's coming from a Unix world.

You're like, oh my god, there are too many of these. There's two lines. I can't handle this many lines. So trying to keep arguments constrained, I think, is really important. You can always cheat and pass a structure. But making it so that when I look at a line of code, I kind of know implicitly from the function signature what's happening. Because I've seen code where it's 10 12 15 arguments you know per function and actually one of the particularly

bad places about this which i don't have to work in anymore uh was back in the early days of x windows programming so if you're writing graphical applications that use like the x toolkit or motif for these, these early toolkits. And I haven't done any of that programming in a while, but at the time you were just passing so many arguments that you could not keep them straight in your head. And that was really, that made for a lot of bugs.

I mean, the whole point of, you know, being picky about how code is written is so that you make fewer errors. Right. And when you do make errors, you can find them later. Yep. Because you're going to make them.

Yes, you're going to make them. Which might segue nicely into our next essay, which we thought we'd talk about, which is code spelunking, a term I love. And I never knew the person who coined it. So it turns out you coined code spelunking, which I thought was just like a term of art. It's existed for all time,

but I guess things have to start somewhere. Tell us about that chapter, that essay. So that's actually a piece that I wrote independently of Code Vicious. And it's something that's been really important to me throughout my entire career. Now, I don't know that no one else used code spelunking before I wrote the piece,

but certainly the term got a lot more use after the piece was written. So I don't know that I can claim to be the absolute first person to use it, but I certainly popularized it in that piece. This comes back to the realization again that I'm going to read a lot more code than I'm going to write. And with code splunking, it's very interesting to me. In particular, the tools have not improved. You know, a lot of IDEs will do a really good job on sort of a small code base, tens of thousands of lines. But, you know, for the most part, the state of the art in those tools moves about once a decade.

So, you know, back in the 80s, we had, or the 70s, we had tags, the 80s, we had global, which is a tool. And these are all in that piece. And the thing that I've really noticed that actually is desperately needed, one of the reasons I wanted to put the piece, even though it's older in the book, is to try and inspire people to build some tooling that I think we desperately need. So almost all tools that do things like code splunk, you know, show me all the functions calling this or show me all the functions called by this or whatever, are language specific. And there are very few large systems out there now that are only in one language, right? You almost always have, you know, some sort of

domain specific language, or, you know, you've got Python inside of some stuff that's calling C and C++. And, you know, these various frameworks, and they're all talking to each other. And so one of the biggest challenges now in the area of understanding large codebases, you know, as someone who works on operating systems, I work on code bases that are over a million lines pretty much every day. I don't, I very rarely look at a small piece of code is that, you know, you can try, you're trying to, and in particular, this is a big issue when you're debugging, you're like, oh, okay, well,

we crashed way down here in the C code somewhere or a C plus plus, or, you know, someday it'll be rust and go, whatever, some deeply compiled language. You're like, well, what caused that to happen? And you do a backtrace and you're like, oh, well, this thing came in from something. But you can't go any further back. You can't figure out what was the request and how did it get here? And what you really want to be able to do is be able to walk an entire system.

I mean, that's the sort of pie-in-the-sky goal, which we will not get to before the end of CodeVicious or the end of my career, I suspect. But with code splunking, the biggest problem now is we can usually, because our machines have big memories, pull in very large databases of single language source. So I can wander an entire OS because it's all written in C. I can wander Nginx or something like that because it's all written in C. I can wander, you know,

NGINX or something like that because it's all written in the same language. But I can't cross boundaries. Yeah, absolutely. And one thing that you said, which rang true with me, is that these tools

seem to be focused around allowing you to drill up or down a call stack. And they don't get much more breadth than that. I mean, especially across languages, but even inside a single language, there's, it seemed like a very much

a left or right kind of opinion, or up or down. You think about spelunking, you're trying to plumb the depths, you're trying to go here and there, and sometimes you need to get into a crevice or whatever, and it seems like there's just kind of like, go up the call stack, go down the call stack,

or like grep, right? What is our fancier versions of grep? And that's the tools that we have. So they are very simple still, yeah. And one of the things I've always looked for, and in a way, Doxygen does this if you generate the dot output, but what you'd really like when you start with a large piece of code is an interactive map, right?

Like, show me everything, which, you know, even in a huge screen with a lot of graphics power would be a graph with so many nodes, it would be really hard to look at. But, you know, that's the view that I would love to have. Now, I'm not a UI person, so I should not design this because if it doesn't fit in an 80 by 24 glass terminal, why would you bother? But, you know, it's definitely one of the things that I've always been interested in. And actually, a colleague, Tamara Munzner at UBC, years ago, had a graduate student work on sort of work on this as a problem. But, you know, graduate work, not much came out of it. But the interface generated was actually pretty good, because

what you want to be able to do is kind of, you know, with your mouse, grab a thing, and then it shows you all the things, you know, visibly. Like, one of the interesting things in code splunking is, I fixed a bug. I fixed a bug in this function. And now show me all of the things that call it because that's all of the things it could possibly... Be affected by this.

Effect, right? Now, you can do that in a, you know, a non-graphical way, which is what we have now with, like, Global and all these other tools. It's like, OK, give me a list of all the functions. But it would be nice if you could actually see the program as a visible call graph, click on the function you'd modified and then have it light up all of the things that, you know, it changed. Because you've probably fixed the bug relating to, you know, the three or four things, you know, that calls it. But that thing may have been used or repurposed or, you know, appropriately used or inappropriately used given software

somewhere else in the code. And it'd be really nice if you were alerted to the fact that, oh, by the way, you know, Bob actually used that function too. And Alice used the function as well. And they used it in different ways. And your change, you know, is going to affect their code. Yeah, absolutely. Another aspect of it is that, like you mentioned, there is reading and writing. And when it comes time to spelunk, you're of course reading, right? Lots of times, all of the context that you had

when you wrote or maybe you did not write this code, all that context is completely gone. So it's like, I think, like a murder mystery or like, you know, it's a mystery. How am I going to find this thing? And I think more experienced or what I consider more expert developers

are ones who are really good at that forensic analysis. And there's people that can find a bug, you know, faster and you can snap your fingers. And you're like, how did you do that?

And they've kind of intuited, they just have this sense of like, you know, they can see, it's like the matrix, right? They don't see the codes anymore, they just do. But I wonder if you have any of, I mean, you've been doing this a long time, do you have like methodologies when you're like, hey, I have

a bug, it's in this large code base or it's like a thing that happens that is non-deterministic? Where do you start when it comes time to spelunking? What do you do? Do you have any best practices or things that you do, maybe even just intuitively that you could elucidate? One of the things that I'm a big fan of is notes. I take copious notes. Actually, in one of the Codeviciouses,

I talk about the scientific method to debugging. I use OrgaMode and Emacs, which allows me to create special tags and all that kind of stuff. And so what I'll do is I'll just write down a bunch of theories, right? Theory one, theory two, theory three, theory four, theory five, and not look at the code at all. Because the code will, it's not confirmation bias, but the code will kind of bias you to want, you'll look at the code, especially if it's not your code. When code is not your code, I find, I don't know if I'm the only person who's this way, but I suspect it's more general. I think we're more judgmental of someone else's code than our own. And that causes you to jump

to conclusions. You look at the code, you're like, oh, this is a mess. I can't believe I have to clean this up. I mean, you know, why are people leaving dirty underwear in the code? You know, that kind of thing. By not looking at the code first and by writing down a bunch of theories about how I think the code is operating based on the bug that I'm seeing means that I can be a little more, I think, it makes me a little more objective. And then I've got a list of things to go through instead of just opening the file, cursing my existence, and wondering why I ever went into computer science in the first place. Because I know that's going to happen when I open even my own code. Sometimes you look at something and you're like, ah, I was supposed to clean this up. I forgot how bad this was. I forgot how bad this was because it was hidden in a file. So I'm very big on notes, having theories, and then because I've got the fancy tags, I can

basically say when it's been proven or disproven. And I just go through and very methodically try to find the solution. And I always keep notes because, I mean, I've always had a fairly good memory. But, you know, the thing that's really important, I find, is not only finding and fixing the bug the first time, but often a related issue will come up, right? You know, three months later, someone will be like, Hey, you know, do you remember when you fixed that thing? Well, that thing's broken again, or this looks like that thing that's broken. And if you have to do that all again from the beginning without notes, that is really tedious because that at that point, you're sort of beating yourself up going, wait, I looked at this. I knew how this

worked. Whereas if you had the notes of what you did last time, you'd be like, oh, okay. You know, it takes a lot less time. I guess this might make it or not, but is this a prime space for some tooling to be made? I know that you mentioned some in your book that's available and they're sort of, as you mentioned, rudimentary. Is there anything where like, this is proving ground for someone to say, I can make that kind of tooling. I actually am a UI designer, or I would like to have you as a feedback machine to say, here's how I can do a spelunking tool set. Is this prime place for someone to innovate? So I think so. And I think the place where I would expect to see it, but I haven't seen it yet,

are the Eclipse-based tools. So the Android dev tools are all Eclipse. Or Microsoft's tool suite because, you know, they've got the hands to do it, right? I mean, there are things that people have done. It's very programary to use the output, especially of newer compilers like LLVM to generate more annotations. That means you can use your editor to go find stuff. The visual display thing, I've never seen anything that did that credibly on a large code base. So one of the ways I used to test, so when I was at companies

where we would buy these tools to use on our code base, when you have a significant code base, millions of lines of code, you throw them at the tool. And almost always the tools were not meant to work with millions of lines they could work with tens of thousands of lines but eventually they run out of memory or sql space whatever they are so i think the place where i expect to see the innovation of at least i mean it'd be great

if i could take notes in you know on my code in eclipse or in you know in a microsoft visual product as well. And I'm sure there's an Emacs mode for this because there's an Emacs mode for everything. Just, you know, you have to find out what it is. But that kind of note-taking ability, I think that would be an interesting feature of an IDE. But from a visualization, a code visualization standpoint,

there have been tools people have pointed at me, but every time, you know, either they're very expensive, one thing, or even if they're, you know, you can try the demo version. I always point it at the FreeBSD tree. I'm like, so tell me about the operating system. And they're always like, uh, give us three hours and then we're going to crash. You know, most of the tools that have been written to do this were written Unix-like, right? So they're pipeline tools, they write temporary files, and so they don't run out of memory. But the ones that often when people build graphically first, they then also build the tool to pull everything into memory. And, okay, well, now we all have 16 or 32 gigs in our laptop.

But it's still like once you start generating cross references, you have this massive explosion. And I've yet to see a visual tool that could really do the job with a significant chunk of code. So that's where I think the innovation should be. What's up, friends? Have you ever seen a problem and thought to yourself, I bet I could do that better? Our friends at Equinix agree. Equinix is the world's digital infrastructure company, and they've been connecting and powering the digital world

for over 20 years now. They just launched a new product called Equinix Metal. It's built from the ground up to empower developers with low latency, high performance infrastructure anywhere. We'd love for you to try it out and give them your feedback. Visit info.equinixmetal.com slash changelog to get $500 in free credit to play with plus a rad t-shirt. Again, info.equinixmetal.com slash changelog, get $500 in free credit. Equinix Metal, Bill Frehley. So I will now read a quote from your book back to yourself.

How do you like that? I'm going to read this. Yeah, it's always entertaining. So in the obsolete coder, chapter five, essay nine, you say remaining relevant in one's field is an important question and one that is rarely discussed in undergraduate or graduate education. Once a programmer starts working, they might pick up new skills more by accident than by design. How do we remain relevant in our work? Remaining relevant is the work of a lifetime,

and if you do it well, you'll never be done. George, you've been around. Like you said, you're in your 50s now. You've been doing this for a very long time, and surely that is something that's in your psyche. You're thinking about staying relevant, remaining relevant. I'd love to hear you talk about it. So I think the response to that is fairly broad, but you know what I, I think what I said in the piece was I talked about, you know, reading broadly and looking at new technologies, you know, trying not to be pigeonholed as one thing, you know, throughout my career, the things I've tried to do are read broadly. So, you know, I'm involved in ACM. ACM publishes tons

of scientific papers. I don't read every paper, but I found areas in which I'm interested in, and I will read the abstracts to a bunch of papers. And, you know, now there's some good online stuff for this. There's the daily paper that comes out if you want to follow particular topics. I've always followed journals that are not specific to a particular technology. I think technologists can become very excited by a single piece of technology and become very specialized in that. But that's actually the opposite of what you want to do. I mean, yes, you should become an expert in something, but you should never believe that that's the last thing you'll be an expert in.

Although, I guess, at the moment, COBOL seems to have been the thing that you should have been an expert in. COBOL people are getting called out of retirement right now to make some good cash, aren't they? Exactly. You know, you're like, oh. And the other thing is to, I think, you know, it's important to see what the industry is doing, but industry trends are not the best thing to follow.

My current favorite one that I really enjoy, you know, I've been doing embedded systems and low-level systems and firmware for a long time. And, you know, when I was at university, we actually took two quarters, I was at a quarter school, two quarters of assembly language. And I love assembly language because I'm deeply broken in some way. But, you know, even the professor's teaching would say like, well, you're probably not going to use this. This is more to understand how the machine works. I use those skills and I look at assembly language for almost all of my clients and all of the people I've worked for, because when it comes down to what's broken, you have to know how the machine works. And I think that comes to the real point of the thing that I think people should be thinking about more than a particular technology. Obviously, okay, you want to go work for a company that's using Java, then you're going to have to

be an expert in Java. You're going to do Go, you should be an expert in Go. Or you're working in IT and you're doing DBA, you should be expert in whatever databases you're working. But the important way of remaining relevant and not becoming obsolete is to realize that those are technologies, but that understanding how things work, how, for instance, distributed systems work, how a large system interacts, how people deploy software, how a computer works at a low level. This is one of the things that's been particularly problematic over my career is when my generation of programmers, many of us started in the microcomputer world, Commodore 64 for me, Ataris for other people. Those were very limited machines,

but you had a lot of access to how they worked and you could figure out how the computer worked. 30 years, 40 years later, a lot of people now work with systems and they can't get very far down the stack. And that's a real problem when you come to dealing with scaling and performance, which are now the two main problems for most people building real systems. So sure, it works on your desktop. You made that thing work on your browser. Great. Now when a million people hit it because it's a game on Facebook or whatever it is, you know, does it still work? That requires a much broader understanding than just how your

JavaScript code works or how your Java code works. And so the only way I think to really remain relevant is to study the topic of computer science. And not every day. I don't expect everyone to be sitting around reading about algorithms. But to realize that that's the thing you should be studying, not Bob's latest language. It's like, oh, there's a book on Elixir. Let's become an expert on Elixir. And then three years from now, you're not using it.

I think that's the way to remain relevant over a lifetime in the industry. How many technology or language transitions have you survived through? Well, technically, I still program in assembly language, so I guess none? Take that one off. There you go. So I have mostly stuck with compiled languages, which change a lot slower. So for my scripting languages, it was always been Python, contributed a little bit of code to Python early on. I knew the folks doing it in Holland when I lived there in the early 90s. It's a perfectly reasonable scripting

language for most of the scripting things I would do. My compiled language still is C. I've been programming in C since I was 20-ish. And so, you know, C++, okay, fancy C. I have mostly avoided Java. I think if I'm going to wind up transitioning, it's going to be Rust will be the next thing because Rust is pushing really hard into the system space. But, you know, the other thing, I talk about this in at least one or two pieces in the book. You know, there's only three types of languages, right? There are functional languages, Lisp and its associated things. There are the algol languages like C and Python and pretty much every language that most people use. And then there's Prolog.

And nobody reprograms in Prolog, so it's okay. If you know C, you can learn C++ and JavaScript and Java and PHP. Because they all do the same thing, right? They all have local variables. They all have side effects. They all have functions. They all have function returns. Some of them are more typed than others.

Some are not typed. Some are strongly typed. But, you know, how you express yourself in those that's like so i actually speak several human languages as well as computer languages and the difference between say that that family of computer languages is a difference of dialects it's not even as far as french and italian it's you know french of many different regions because okay we use different words we put semicolons or we don't put semicolons. We put arguments before types. We put types after arguments.

But in the end, it's the same structure, right? Where are the functions? What are the arguments? What's the return value? How do return values come back? How do I structure my code? How do I have modules? How do I add or remove things?

That stuff is, if not universal, so closely related across the currently popular set of computer languages that i don't it's just not that big yes going yeah yeah i mean going between lisp and c that takes some mental energy right but c to to C++ to go to Rust, Java, JavaScript, Python. I mean, once upon a time, we all programmed in BASIC. Even that's not that different. Thoughts on Rust as you approach it, potentially? I find Rust really interesting. But the only way I'm going to really have a strong opinion about it is I've got to write 50, know, 50,000 lines of it. So I've had a couple of projects on the side where I thought, OK, well, and there were open source things where I was like, oh, I'd really like to write this thing that I worked on in C and Rust and compare it.

I'm just very excited by the work the Rust community is doing. Like, they're very serious. They're very big on documentation. They write good books. They write well about their code. You know, they make some very interesting claims about safety and the safety of the executable, which would be very interesting to verify for myself. I mean, certainly people have been writing papers about it. I'm very excited about their push into the embedded space because I've been an embedded guy

for a long time. It is definitely the most exciting new language I've seen in a while. I'm much more excited about it than I was about C++. When it comes to, I suppose, someone out there listening thinking, am I obsolete though in regards to this essay, the way you indicate that is with being over-specialized or under-specialized. What's the sweet spot in terms of obsolescence? Should I be just specialized? Not too much.

Not too much, not too little. Right in the middle. It's like Michael Scott. He's not superstitious. He's only a little stitious. That's right. I could give the lawyer's answer, right? Which is, it depends.

I hate when lawyers say that. But I've had to interact with them at work. I mean, I would be very nervous if I only knew one technology well, right? So that's where I think the over-specialization, and people do that. People are like, oh, no, I just do whatever. I just do Java, or I just do, and Java is fairly broad, right? There's a lot of work you could do there.

But I only work on this style of system. Now, of course, again, this is Code Vicious, and so it's very personal. The answer you're getting is how I've perceived my career and how I've wanted to do things because I really enjoy new and interesting ideas. I'm always looking for the better answer. Is there a way I can do this faster, clearer? You know, the code is more understandable or things like that. I think on the other direction, the overly broad question, I think there's less risk in that.

Now, you could get to the point where you, and it was something about experts, you know, eventually, you know, absolutely everything about nothing. You know, you could get to the point where you really don't have a grasp of any particular technology, and I think that would be a problem. But I don't think that's the bigger risk for people in this industry. I think the biggest risk for people in our industry is they worked on a technology, they really liked it, they know it really well, they're super comfortable with it, and they don't want to leave that because they're super comfortable with it.

It didn't occur to me until just now, though, how would you answer or respond if you were responding in the Code Vicious voice specifically? Not so much George's voice because this has been George. Does Code Vicious have an audible change in inflection? Yeah, I was like, how would you respond? Oh yeah! See, I just go to Macho Man, which is inappropriate, but that's where I go in my head. That's okay. So it's funny you ask it this particular way because I had a company have me in

to give a couple of talks on performance, software systems performance. And the person who invited me had actually been a reader of Code Vicious and was like, we'd love you to come give a Code Vicious talk. And all I could think was, do I have to get drunk beforehand to, to really like just show up, you know, in a Hunter S Thompson, you know,

screaming at people. Um, I mean, if I were going to give the one, the one word answer to the obsolescence question, it's read, right. Just start reading things about stuff you don't know that are related to, you know, technologies you think you might be working on. Just go read stuff. Now, I understand amusingly enough that I should probably modify that to go watch a bunch of videos. Because having talked to the folks at Pearson who really want me to do Code Vicious as a video, and we'll see how that works out. The current crop of people in the industry,

that's sort of the younger generation, get a lot of their information now by watching short YouTubes while they're at work, although now that everybody's trapped at home, I guess they're all just watching YouTube all day. Long YouTubes, yeah. Long YouTubes. Long YouTubes. You don't have to sneak it in anymore. That's right. Not worried about your manager walking in behind you um but yeah that um the way people now pick up new skills

are through these video courses so that's not me um i'm very much a reader i want to be left alone with a book or you know a paper or something like that and a little peace and quiet in a reading chair. But, yeah, there are people who watch these things. And there's a ton of content, right? So the most important thing is get outside your box, find something that's interesting, still related to technology that you think personally you could like. When I first went into computer science back in the 90s, it was one of the big uptakes of CS students in colleges because they all realized they could make a lot of money. And so when I got to school, we had 300 undergraduates in my class studying computer science. And when I graduated, there were 89 of us because it turns out that most people don't really enjoy what we do. And you have to be motivated.

I mean, back to an earlier question about, you know, art and artists. The same thing is true of programmers, right? I mean, yes, there are people who can come in every day and crank out some amount of code on something that they don't really care about. But I find those coders are not people I want to work with, right? The people I want to work with are the people who are excited about the technology they're working on. They're excited about the thing they're building or whatever it is. And so the only way to broaden your interests is to broaden them in a way that works well with something you're interested in. So, you know, I'm not going to go from being a systems person to working on AI. I mean, I might work on the

performance implications of the low-level code of that, but I'm not going to sit around trying to think up solutions to problems in AI. That's too far of a jump. But certainly, within the systems area, you can look at various operating systems. You can look at various chips. You can look at various applications. IoT is a classic one of these now where we're probably all doomed. But, you know, in the IoT world, you've got computer technology applied to all kinds of different problems. You've got medical, you've got power, you know, people doing power distribution.

So, you know, if you know one component of the technology, you can be like, well, I can pick up some other component of it by looking at the way someone else applies it. So over the years, George, surely you've changed your mind on a few things. You have these essays spanning all the way back to the early 2000s. I'm sure there's things that just didn't make the cut because maybe you didn't like them. But then what about the ones that's like, actually, I've changed my mind on this.

Somebody who's interested and passionate about technology like yourself reads all the time. We change, right? Your tastes change. Maybe you move from two spaces to four spaces as you get older. Maybe you decide tabs aren't so bad, but those are insignificant changes. But we do. We change both our tastes and our thoughts on certain things. Is there anything you've changed your mind about over the years that you could share with us? I mean, sure. One of the things, and I've talked about this in some of my networking talks in the last few years, but there's something called Postel's Law. John Postel was one of the key figures in the development of the Internet. He's passed away, I don't know how many years ago now. But one of the things that he said was this.

He said, be conservative in what you do. Be liberal in what you accept from others. And the way we applied this to the early internet was you should be transmitting very small, very specific pieces of information. But on the receiving side, you should liberally interpret what someone sends you so that you can get the job done. Now, that advice makes perfect sense in a research network connected by a 56 kilobit modems, you know, a bunch of universities. You know, it's fine because, well, what's going to happen? OK, well, you know, there was the Morris worm, which brought down the early Internet back when I was in college. But for the most part, there wasn't going to be a lot of collateral damage to using that as a design point, as a way of designing distributed systems,

you had to design principle. Unfortunately, that's totally wrong now. The internet basically is full of bad actors. There's a billion people connected to the network. That means even if 1% of those people are bad actors, that's a huge number. to the network. That means even if 1% of those people are bad actors, that's a huge number. And so we can't write software in the way that Postel asked us to. And it was definitely something that I was... I mean, to say that you're on Postel's side is silly. I mean, Postel was someone who really knew what he was talking about. So we all followed this advice for some period of time. But eventually you realize that you just cannot design software in a connected world in that way. It just absolutely has to be turned on its head.

You need to be incredibly conservative in what you receive because if you're not, someone is going to use that to get around your software, whether it's secrets or passwords or changing the value of your bank account or whatever it is, you know, being liberal in what you accept is never going to work in a modern system. And even now you can't use that in a research network anymore because, you know, we all know what happens to prototypes. That becomes version one. Exactly. Right. So, you know, you can't give the excuse of, well, you know, this one's a prototype. We're going to rewrite it when we do it, you know, and then marketing or management, yoik it right out of your hands and put it on the network. And suddenly you've got, you know, CVEs out the wazoo.

So does half of his law hold though? The first half, do you still think the conservation on the front end there or on what you put out or do? Yeah. And, you know, the being conservative in what you transmit, which is how that's usually put into practice, that's fine. That's not controversial. It's this being liberal on what you accept. Well, that's a good one. I think that one has more to do with the change

of your surroundings than necessarily a change of mind. We've talked about some languages and the differences between languages and used to have a stance that there weren't any bad languages or something along those lines. But you seem to have changed on that one. Can you talk about that one? Sure. I mean, you know, along with, we talked about tabs, v spaces and things like that. So, you know, programmers will have their preferred language. You know, I only want to write in C, I only want to write in C++. And often they will twist themselves into knots to make the language they prefer be the language they use to solve a problem when another language might be more appropriate to that problem set. And so, you know, when people would write in and say, well, you know, how would you compare X to Y language? My general answer was usually, you know, like when we say there are no bad questions, that's actually not true.

But they're also, you know, the response, there are no bad languages. I used to believe that more strongly. And now I now I don't believe that anymore. Now I believe there really are languages that should not be used to implement any significant piece of software. For instance, I love shell. Shell is a fine thing. And if you wish to write a shell script of 20 or 30 lines, that's fine. But shell should not be used to write a significant piece of software. And people have done this. And they continue to do this, which I find amazing, given that there are better things to use if you want a scripting language.

And I understand why people like scripting languages. There's many reasons to like them. But writing a significant software installer in shell is a terrible idea. I used to be very polite about what I thought about Java, and now I am no longer polite about that. I think Java is possibly one of the worst things that has ever been done to the software industry.

And I think no one should be writing in it. And the thing that I think is worst about it is it requires so many dependencies that it is nearly intractable to understand any large system. And where this really comes out is teaching languages. So there are schools now, because the industry demands Java programmers, that teach undergraduate first-year programmers Java. That is not a teaching language. I mean, okay, back in the day, we used BASIC as a teaching language. That was also not a good teaching language for other reasons. It lacked sufficient structures and things that we also wanted. But trying to get someone to understand how to program a computer with something as complex and dependency,

rife with dependencies as Java is just terrible. And every significant piece of Java code that I've had to go read has just made me think this was not a good idea. And what I find funniest about Java is that it was originally intended as an embedded systems language. That Sun's original idea was that it was going to be, you know, write once, run your code anywhere on any Java-enabled set-top box, which is what it was actually written for. And you look at Java now and you're like, nope. No. No, this is just terrible. And, you know, then there are other sort of smaller languages

like Perl. I mean, Perl is an amazing artifact. And Larry is a very, Larry Wall, very clever guy. You should not write anything in Perl. Like Perl has been, you know, at the time, Perl was a useful thing because there weren't as many available sort of scripting languages. So your choices were C or something, or C or shell. was a useful thing because there weren't as many available sort of scripting languages so your

choices were c or something or c or shell but at this point no one should be writing in pearl like it's all of that should just go away i feel like you're getting more controversial as you go so i can't wait to hear the next one is there another one how about what what else do i dislike because there's probably a lot of people that disagree with you on the pro point, probably less so on the shell point. Yep. C++. Okay. A language that gets worse and worse with each passing standard. I mean, the only thing to like about C++ is at least I didn't have to rewrite the queue.

The standard library was better in C++, but debugging C++ code, especially with like templates and, you know, just the complexity that C++ allows people to add. People complain about C because C is insecure and we have these issues with strings and all this stuff. But you're like, yeah, but I can't arbitrarily change how I'm shooting my foot in C as easily as I can in C++. C++ has the thing where it's like, oh, I thought I was using this class, but I'm actually inheriting from this class. The fact where that kind of stuff is hidden from you makes debugging C++ code far harder. And templating is just one of the worst things that's ever been foisted on programmers. So we had Josh Ose from Let's Encrypt on the show a while back, and he has a similar distaste for C that maybe you do of some of these other languages. He thinks that all networked software needs to be rewritten and rushed eventually

away from C. So he would say like no one should use C for anything that's serious and networked in 2020. It sounds like maybe your response to that, maybe I'll just let you give your response, but expert C programmers don't shoot themselves in the foot. But is it too dangerous for mass usage today? Like, is Rust just better? And because of the security properties, etc? So I would like to see Rust proven to be better that way. I mean, I'm, I would be very happy to trade in C for a safer C. The reason C never gets supplanted isn't the safety issue, because it turns out that most people who are producing products for you don't care about your safety, but don't tell them that. What matters is performance. So no one has come up with something other than hand-coated assembly,

which is portable and as performant as C. Now, Rust is getting very close. So if Rust can keep the safety qualities and be as fast as C, then yes, we should chuck as much C out as possible. And all the people who work with me on the FreeBSD project right now are sharpening knives. And once the pandemic is over, they're going to come to my apartment and cut me into little ribbons. But yeah, I definitely think C is... There are projects in the world right now is the cherry work that's been done at the University of Cambridge, Robert Watson, who I've worked with on various things, trying to change hardware so that hardware is safer and that we can actually use pointers without foot shooting. But changing hardware is going to take a while, so we'll see how that works. I think it's very promising. And expensive. Yeah. Well, you know, it changing hardware is going to take a while. So we'll see, we'll see how that works. I think it's very promising. And expensive.

Yeah. Well, you know, it's how we make money. I mean, just ask Intel. Intel would definitely want to sell you a whole new set of secure computers. Sure. And from the language standpoint, I definitely think he's right. I think, you know, see, even with expert programmers, I mean, I work with people who've worked in operating systems even longer than I have, and they make mistakes, and we all make the same mistakes.

We have a ton of tooling to try and prevent us from making those mistakes, you know, from neurocompilers to static analysis. But the reason that nothing is supplanted C isn't that there aren't safer alternatives. There are, but they're slow. Like, often orders of magnitude are slower. So, you mentioned a bunch of

bad languages, or at least from your opinion. What are some good ones? What are your favorites? So my favorite scripting language is still Python. I like scripting languages generally for teaching because they allow the iterative learning loop. I wrote some code. I can try a little bit of code.

Oh, it works, doesn't work. I mean, I do have issues with the whole bracelet thing in Python. That's the thing that's always bothered me. Literally, your indentation is how you're handling where your code is. So generally, for scripting, I use Python. For coding, I use C because that's the world I live in. I would say that I like C for its brevity and its simplicity. And that's generally what I like.

I like systems to be able to be expressed simply. Other languages that I've liked, I've liked because they were appropriate for what they were. Many, many years ago, I programmed in Rex because there was a good A-Rex thing, an interpreter for the Amiga. I like Forth, but I'm totally broken. So I think Forth is nice and compact. If you want to build something small and compact, like controlling your washing machine, Forth is great. I like Go. I think Go has some very interesting ideas.

We've talked about Rust. I like Rust. Most of the other languages that I've seen that have come and gone haven't had really an effect on my day-to-day coding. Let's see. What I can tell you is that there are assembly languages I like more than others.

That's relevant to us. A lot less relevant to your listeners. Good stuff, George. Well, the book, Collected Code Vicious. Don't spell it with a C. KV likes to spell everything with Ks, so it's Collected with a K, Code with a K. Vicious,

however, does start with a V, so you figured that one out. And you can get it on Amazon. It's put out by Pearson. Anything else with where folks should find it, information about the book you want to get out there? So there is a webpage for the book as well. It's codevicious.io, which points to all the places you can get it and various updates on when various parts are coming out.

I have a Twitter, which is code underscore vicious. And yeah, that's all the places to find information about me, the column or the book. And you mentioned that you don't have pages yet. So it's available as digital now. Is that right? Correct. And pages soon. Paper is supposed to be out on the 29th of October.

By the time this goes out, it'll be out there. So I don't know if that means it comes off a machine somewhere. We'll see. Love the cover. It's a great cover. Ones and zeros. I mean, it's on point. be out there so i don't know if that means it comes off a machine somewhere we'll see love the cover so it's a great cover ones and zeros i mean it's on point i did not design the cover i do not do graphics that was someone at pearson did a very nice job and sent me seven covers george you like this yes i do okay cool yes yes ship it go yes Please don't ask me about color. And what about the column?

Is some of it, I know that some of it is available online. Is most of the archive of Code Vicious available to read, or is some of it still downloadable, subscribable? What about if someone wants to dig into your, you know, 15 years ago? Back issues. Yeah. So all of Code Vicious is available in ACM's digital library, which I think is dl.acm.org.

You can also find all of the pieces off the ACMQ site, which I think is acmq.com. Everything is published electronically in ACMQ and then electronically and on paper in Communications of the ACM, which is the ACM's flagship magazine. So I think if people are looking for back issues or back bits,

the ACMQ site is probably the easiest one to download from. And then we didn't ask you that you want to share it before we let you go. Have you laid it all out there? I think I've spoken quite enough at this point. George, thank you so much for your time today. It's been awesome talking to you. Yeah, I appreciate it. Thank you.

Awesome work on the book. Thanks very much. That's it for this episode of The Change Law. Thank you for tuning in. If you haven't heard yet, we have launched Change Law Plus Plus. It is our membership program that lets you get closer to the metal,

remove the ads, make them disappear, as we say, and enjoy supporting us. It's the best way to directly support this show and our other podcasts here on changelog.com. And if you've never been to changelog.com, you should go there now. Again, join changelog++ to directly support our work and make the ads disappear. Check it out at changelog.com slash plus plus. Of course, huge thanks to our partners who get it

fastly linode and rollbar also thanks to break massive cylinder for making all of our beats and thank you to you for listening we appreciate you that's it for this week we'll see you next week Thank you. Bye.