The Changelog: Software Development, Open Source - Why smart engineers write bad code (Interview)

Episode Date: March 29, 2019

We're talking with Adam Barr, a 23 year Microsoft veteran, about his book “The problem with software,” sub-titled "Why smart engineers write bad code." We examine that very idea, the gap between industry and academia, and more importantly what we can do to get a better feedback loop going between them.

Bandwidth for ChangeLog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at ChangeLog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash ChangeLog. This episode is brought to you by Linode, our cloud server of choice. And we're excited to share the recent launch dedicated CPU instances.

If you have build boxes, CI, CD, video encoding, machine learning, game servers, databases, data mining, or application servers that need to be full duty, 100% CPU all day, every day, then check out Linode's dedicated CPU instances. These instances are fully dedicated and shared with no one else. So there's no CPU steal or competing for these resources with other Linodes. Pricing is very competitive and starts out at 30 bucks a month. Learn more and get started at lino.com slash changelog. Again, lino.com slash changelog. All right, welcome back, everyone.

You are listening to The Changelog, a podcast featuring the hackers, the leaders, and the innovators of software development. I'm Adam Stachowiak, Editor-in-Chief here at Changelog. On today's show, we're talking with Adam Barr, a 23-year Microsoft veteran, about his book, The Problem with Software, subtitled with Why Smart Engineers Write Bad Code. We examine that very idea, the gap between industry and academia, and more importantly, what can we do to get a feedback loop going between them? So we're here to ask the question

and hopefully get some answers. Why do smart engineers write bad code? I'm joined by Adam Barr. You've worked at microsoft for 23 years you're a veteran in the industry and you have a book that dives all into this question so obviously you have a lot of thoughts about it but before we dive into the meat of the topic let's learn a little bit about you and what brings you here so So I started working at Microsoft in 1990, a long, long time ago. Actually, one of my first projects was the very first version of Windows NT, which is now what people call Windows

after a couple name changes. And before that, I was a self-taught basic programmer in high school. Like a lot of people from my generation, I graduated from college in 1988 worked at microsoft as you said for 23 plus years now i work as a consultant and i wrote this book came out last fall the problem with software why smart engineers write bad code which as you said answers tries to answer that question yeah so why that question what brought you to write the

book and what was your motivation yeah one of the more interesting jobs i was i was primarily tries to answer that question. So why that question? What brought you to write the book? And what was your motivation? One of the more interesting jobs, I was primarily developer, dev lead, engineering manager. But for about five years in the middle, I worked in this group called Engineering Excellence inside Microsoft, which did training and consulting for teams internally.

And it was quite interesting because normally at Microsoft, you only get a view of the team you work on and this enabled me to get this view across Microsoft and realize that even inside Microsoft which people may think of from the outside as having this single way of writing software there was actually a bunch of different ways and some were better and some were worse but people didn't really know they just tended to use the same technique and language and process that they'd used before, which might have been something that the person who created the group happened to like or have some experience with. And from our central perspective in engineering excellence, we could tell that some of these processes were better than others. And it made me realize that

across the industry, you have the same issue that people just don't really know if the way they're writing software is actually correct, if they're using the right language, as I said, or the right tools and technologies. And a lot of it starts with what I consider the basic problem with software, which is that when you're in school, academia doesn't really study industry. And you don't get a lot of advice on this. You tend to write small pieces of software, two or three people working for a semester and then you're done and in that environment really any language is fine and everybody can meet in a room to discuss things so

stitching together large pieces of software from individual components doesn't really happen and the original authors of the software are there for the entire duration so they just know how it works the documentation is not really an issue and yet you get into industry and you're working on these large pieces of software obviously microsoft i worked on windows and office two very large pieces of software at this point they have thousands of developers on them and this stitching together and maintaining it over different cycles of engineers as people leave and new people join really becomes critically important and it's just not something people are prepared for when they go to school and study computer science or

software engineering so there are a couple of problems that i've seen with regards to academia and its ability or inability to prepare programmers for industry. The one that you're hitting on here is really the scope of the work or maybe the breadth or the depth of the projects and the needs of the projects are not real enough, big enough, you know, scope enough for that to really make an impact or prepare you. And then the other problem that I see often is that the industry moves so fast and the state of the art moves so fast that many times people are learning technologies that are outdated by the time they graduate. Does that resonate with your experience and who you've spoken with about this or is it mostly the scope of things in academia that's the problem?

Well, the state-of-the-art issue is also there. So certainly people come out of school, even if they did study web design, which they may not have done, and used a JavaScript framework, which they may not have done, there's probably something new that's come along in the last six months that makes their knowledge obsolete.

And that's just a general problem in the industry. You get that switching jobs also. I use this framework, but now my other company is using a different framework. I'm actually sympathetic to academia in that situation. They really don't need to attempt to keep up with the absolute latest and greatest because if you've had experience

working on large pieces of code, then you can work on other large pieces of code that knowledge transfers. Trying to nail down the specific knowledge of a particular package or a particular backend stack, I think is difficult and still may not apply because there's a bunch of them out there now. And also would require academia, I think, to move a little faster than they typically do or should because of course they might decide that some new package is the latest thing but they might be wrong so i don't think academia should be out there trying to predict okay my students are graduating in two years what specific languages are going to be important then but certainly just

giving students exposure to large-scale programming is very important. You have these coding camps springing up, which are much shorter in duration and much more hands-on. And they could possibly focus on, okay, we're actually going to teach you something that you could then turn around and use the month after you graduate. I think that could be a very interesting way to become a programmer as well. I think I compare the amount of time I spent actually programming when I was in college, actually sitting in front of a computer when I was there for four years. But I only took eight upper class computer science classes. And a lot of that was in the classroom versus a coding camp where it's hands-on all the time for months. It's really pretty comparable. And you have an instructor there and fellow students to help. And so I think a coding camp is a very valid way if you really want to get the latest and greatest stuff but i think it's fine for academia to say

no we're going to teach at a slightly more general level when you say academia do you you mentioned coding camps would you consider like lamb school or bradford school of computer science if you're familiar with those would you consider those you know in the gray area between boot camps or coding camps and academia? Because they kind of play in this intensive role in this sort of partnered relationship with the would-be or could-be developer. I mean, what I've read about academia and what I looked at was really four-year universities granting engineering degrees, essentially. Gotcha. So, yes, there are some gray areas.

There's companies. Amazon is or was running an internal coding camp, essentially, for their employees who wanted to transition to become programmers. So there is a lot of ways you can learn that are a little more close to the industry, but also running as a for-profit business. So to me, I'm thinking of academia as the ivory tower with the professors and the tweed jackets with the elbow patches, that whole thing. Going back to the coding schools a little bit,

it seems like the fundamental premise of the coding boot camps is counter to academia in the sense of, and somewhat speaks to the problem that you're seeing with academia not addressing real- world or industry needs. That being said, a short boot camp isn't going to give you a large scale project either in that time. But just the idea that you can't possibly be prepared for industry completely. Most of us learn on the job anyways. So let's get you up to speed and dangerous, so to speak, on a modern stack that is immediately employable or useful

to industry. And then backfill from there. Maybe go back and obviously you're going to have to learn computer science concepts to become, you know, to make this your career. You can't do a 10 week or a 12 week session and expect to be proficient and done learning, right? You're just starting to learn. But that style of instead of saying, well, let's go study computer science for four years

and then get industry experience, saying let's bootstrap industry experience and then backfill maybe with a degree, maybe with online education, you know, the computer science aspects. Do you think that's a viable way forward? Yeah, I think that coding camp graduates show up in industry with some gaps as well that are different from the gaps. Huge gaps. Huge gaps that are different from the gaps that someone with a four-year degree typically shows up with. They have the very specific knowledge, but they don't have the breadth and the view across different technologies. So I certainly would not recommend somebody skipping college and going to bootcamp and then trying to go into industry when they're

19 years old. I think you get a lot of life skills in college, completely independent of what you learned about programming. You get a lot of life skills in college that are very valuable. So I would not present it as an alternative college. You can also come out with $150,000 in debt. Yes, well, that is true. I think that CodingCamp, after you've gotten a degree, and maybe you've had a degree that was in math or in a natural science or something that was a little, had this sort of computational thinking angle to it a bit. You had some experience in modeling things in your mind, which would let you model how a computer was working and help you when you were debugging problems. I think with that, plus the coding camp degree, you would be a viable candidate, certainly for an initial job working in the same technology stack that you learned in your coding camp. And yes, I would certainly then recommend that you started working on your own, working on larger projects, maybe find an open source project to contribute to, to try to backfill

the other gap in knowledge, the sort of broader view you might get in an actual four-year degree. What about goals, though? Don't you think that the goals for a boot camp or the gray area of, as I mentioned, Lambda or Bradfield, for example, the goals are fundamentally different? So the goals for academia, a four-year program, for example, aren't to teach today's best practices, though they should be aware of them. And it's more like skills and skill sets that are on the long term and deep knowledge in computer science or various areas of software engineering. The goals are fundamentally different, right? Oh, yeah. No, I agree.

The boot camp is trying to get somebody employed quickly with a specific skillset and that should not be what academia is teaching. But academia should be more focused on the other areas. What's the right language to use? Can you tell if software is high quality? Can you tell if software is obsolete? What is good code?

What is bad code? What's the right trade-off in performance and maintainability of the software. They should be studying that sort of thing in industry rather than on these- Fake projects. Either studying on these small projects or really not concerning about it. I've never heard of anybody coming out of college where they studied things like code readability and maintainability.

It's just not considered. It's just, okay, you're writing code to implement an algorithm. Once it works, we're done. People rarely read each other's code. They don't do code reviews. They don't talk about large bodies of code. They don't read code

as a way to understand how to write code. There's a whole area that they could dig into, completely independent of the specific technology, which the bootc camps focus on. Yeah. So if we compare the, is there a software engineering degree? I know computer science was the degree that I went after,

but if we think about software engineering and we just compare it to the other STEM fields, specifically engineering, because that's the easiest comparison, it's pretty safe to say that if you, and maybe this isn't something that's wrong, so I'll just say it it you all can push back but it seems like if i go and get a decent degree in civil engineering and i got a stamp on the wall

you know on a piece of paper that i hang on my wall that says i'm a civil engineer i have a you know bachelor's degree in this particular area of study you can trust me to pretty much know how to build a bridge after that right or to sign it i don't is that civil or that architectural you know like the the things that a civil engineer should do like there's a corpus You can trust me to pretty much know how to build a bridge after that, right? Or to sign it. I don't know. Is that civil or architectural? You know, like the things that a civil engineer should do. Like there's a corpus of knowledge that's old and refined and relatively static. I'm just making some assumptions because I'm not a civil engineer. But you know, the laws of physics aren't changing, for example.

Whereas if somebody comes out and says, I have a computer science degree or I have a stamp on a piece of paper on the wall that says I'm a software engineer, that doesn't necessarily tell us anything. Is that a true statement? Is that a problem? That's correct. Yeah, my brother actually has a civil engineering degree. So yes, I mean, that's exactly the case. Civil engineering in college involves learning a lot more that somebody else has already figured out. So when you design a bridge, this is how you calculate the load and these are the different materials. And this is in this situation,

you use this kind of bridge in this situation, use this kind of bridge and getting a software engineering or computer science degree, because right now the terms are essentially used interchangeably. There's not really a specific specialization

of one or the other, although you could foresee that. Getting a computer science or software engineering degree just means that, OK, I took some classes, I learned some algorithms, and I probably taught myself to code in a lab late at night trying to implement a compiler or something without a lot of guidance and certainly without a lot of picking up historical empirical knowledge from previous studies. I just got it working. And maybe I did that in high school

in basic or something like I did, which is an even worse language to teach yourself the program in than a lot of languages used in the industry. And I mean, I know my personal experience and I've talked to other people and this is not just because I went to school a long time ago. This is talking to recent graduates when I was at Microsoft. Yeah, a lot of them just figured out on their own and that worked and it got them through college, and it really got them through internships at Microsoft, because Microsoft internships are also very small and short. And got them going, working there full-time. And then at that point, sometime after being hired, they had to realize, oh, wait, I'm working on a large piece of software with a lot of people, and things like code reviews really matter. Whereas when I first came to Microsoft, to me, a code review was sort of a veiled insult. What? You have to review my code?

Don't you know my code is perfect? And it just felt like people criticizing me for no reason. And then eventually, after working with other people's code for a while, it sort of dawned on me. Oh, yeah, okay, I understand now. There's certain standards you want to enforce, and there's actually benefits of a code review. It makes you better as a programmer. I've got a question here on this front. Do you think that this gap that we're identifying also leads into interesting and or bad hiring

practices? So if we don't understand what a software engineer truly can do, as you said, Jared, if I have got this sign on the wall or this stamp on the wall that says, hey, I'm a software engineer, it's difficult to quantify or understand the necessary skill sets. It almost leads to bad hiring practices, too, by asking, hey, can you do these really stupid things that don't even really feed into your job? They want to know if you can sort a list or write an algorithm. Meanwhile, you're going to be writing a Rails app or something like that. A whiteboard.

Yeah. Right. There's this joke about what do you call the person who graduated last in their medical school class? And the answer is doctor. Because when you graduate from medical school and you pass whatever test you have to take,

you're a doctor. You've learned all this stuff. And I've asked doctors, how do you interview people? And they say, oh, well, we just talk about how they deal with patients and their views on certain different styles of care or whatever, but nothing about, hey, here's a wound. Can you sew it up? Like, you know, they assume they know that. I mean, they went to medical school and you get nothing of the sort in software engineering.

And so you do wind up doing a lot of these coding interviews and there are different theories on whether they're good or bad. I personally think they're bad, but it's not clear that there's anything better at this point because you don't really know what it means to have a software engineering degree. And Microsoft would occasionally hire people who were music majors, but they'd code it on the side, which is sort of cool for the music major. And it's good that Microsoft is thinking beyond just a certain degree. But if you hired a doctor who had been a music major, that would be really weird. And the fact that it

works in software engineering is more, I think, an indication of the current immaturity of the industry. So the coding interviews, I realized even looking through feedback, when you interview Microsoft, you see all the feedback. It's not even clear what people are looking for in interviews. Some people are really looking for a specific algorithm. Can the person guess an algorithm that I have in mind? I was more looking for, can they write some code, reason about it, explain what it does, say things like after one iteration of the loop, such and such will be true. And therefore they can try to prove it works and talk about optimization and working with certain constraints, essentially what you actually do when you're debugging something. And the code they write is just a starting point. I once did an interview where somebody said, solve this problem. And I came with an algorithm and I wrote it. I think I wrote it correctly.

Then about 10 minutes left in the interview, I realized my algorithm was broken when I was talking about testing it. It just didn't handle some case. So I said that, rewrote a correct algorithm. Again, I think I wrote the code correctly in the last 10 minutes. So is that a good interview or a bad interview? Right. And I think some people would say that's a terrible interview. They wrote a bad algorithm and they only got lucky to catch it at the very end.

What if it had shipped, et cetera? But my view would be, well, that's a pretty good interview because first of all, I solved two problems for the price of one. And I realized while discussing testing that I had a bug and then I fixed it, which is really what you actually do as a software engineer. But I think a lot of people would disagree on that and say, no, no, no. I mean, you got to come up with a clever algorithm or we're not going to hire you. This episode is brought to you by Clubhouse. One of the biggest problems software teams face is having clear expectations set

in an environment where everyone can come together to focus on what matters most, and that's creating software and products their customers love. The problem is that software out there trying to solve this problem is either too simple and doesn't provide enough structure, or it's too complex and becomes very overwhelming. Clubhouse solves all these problems. It's the first project management platform for software teams that brings everyone together. It's designed from the ground up to be a developer-first product in its DNA, but also simple and intuitive enough that all teams can enjoy using it. With a fast, intuitive interface, a simple API, and a robust set of integrations,

Clubhouse seamlessly integrates with the tools you use every day and gets out of your way. Learn more and get started at clubhouse.io slash changelog. Our listeners get a bonus two free months after your trial ends. Once again, clubhouse.io slash changelog. so we've been talking about this gap between industry and academia and why smart engineers can write bad code adam i'm assuming the response to that is because they aren't taught well enough to write good code coming out of college what are some things we can change if we're just going to maybe mold a four-year curriculum or take an existing university and change the way they do what they do to produce better output? What would you change?

Well, one big thing which really has only become possible in the last 10 or 15 years is reading and modifying large bodies of code. That's one of the big gaps you get. You don't get that experience in college. And now we have all these large open source projects. So it's something I encourage people if they ask me, how can I make myself a better candidate for a company like Microsoft? I say, contribute to an open source project, or at least make changes,

learn the code, make changes, even if you can't get them accepted to commit them. And I think universities could certainly do that. They could have a class that was some open source project, whatever, Linux, Apache, something, and have a professor get some familiarity with it and then guide the class through first understanding the code and then making changes. And then you can start discussing the style of coding used and how you'd match that and whether you liked it or not. And the students could start looking at each other's changes before they actually tried to commit them publicly.

And really, I mean, there's really nothing stopping you from doing that. I think it'd be quite an interesting class. I think the students would be interested. And it would just give you in an interview something to talk about that was not, okay, the two of us wrote a little app for two months and then we threw it away. Especially if your changes got committed, but even if it wasn't, essentially nothing blocking that. And I would encourage universities to offer that sort of class. The other thing I think is that just have more hands-on classes. So I know computer labs can cost money and it's tricky to keep them working and whatnot, but have some classes where you're actually in a lab with the instructor and

you're working through problems and you can help each other, the instructor, the TAs can help, rather than all the instruction being just in a class. And then the students go off without the professor and go try to actually write the code. Because a lot of the problems you hit happen when you're actually writing code. And it would be good to have the professor with the experience to say, oh yes, I can help you with that

or just give advice if people want it. I mean, we spent a lot of time, I spent a lot of time in college. We had one big lab in school because this was pre-internet, pre-campus network. So we were all together, but still we'd mostly just be grinding away in grim silence next to each other. Nowadays, students, I'm sure, mostly code in their own room, so they're not near even other students they could ask for help. So having more labs, even if you said the students have to bring their own computers, but just having it all be programming together, I think would be very

helpful. The other thing I think, I talk in the book about empirical studies, which is basically studying programmers, how they work. And I think students should both read empirical studies. So Microsoft Research is actually driving a good uptick in empirical studies of software engineering, which was a big thing in the 70s, but kind of died out. So students should study some of that. There's actual studies about what's the right amount of code, what's the right length for a method, things like that. Studies of variable naming, this sort of thing. And so I think students could study that, but I could also try to do a little bit themselves. They could actually try to do a little research project where we write code in two different ways or in two different languages or with two different constraints and actually try to figure out something about which is better. Partly to learn about it and partly just to get students to realize that there are different ways to write code and the way they've learned or taught themselves may not be the only way. I think people come out of college

because they've been successful being self-taught. They come out with a little hubris. They're not humble enough. And it takes them a while to get knocked down a few pegs and realize that they do have something to learn. They're not the genius programmer that they probably think they are. Certainly, I essentially felt that way when I came came out of college and it took a while to get disabused of that notion yeah all it takes is a little bit of your code running in the real world for you know a few days or a few hours even to realize that uh yeah we're not quite as clever as we think we are right with paying customers and yeah back when i started we were still in the throw it over the wall day where we essentially blamed the test team if there was any bugs, which is a terrible, terrible attitude because it let us get away with sort of believing in our own omniscience a little longer. Yeah.

But eventually things get to customers and they get to customers a lot quicker nowadays if you're working on a web service. And then you realize, oh, well, hey, you hey, there's a bug and you wrote the code. So it's really your fault. As part of writing this book, so having that answer, what would you change? Are there any academia programs out there that are doing it somewhat right or mostly right or really right that sort of lead you to this change? I can imagine that you've done a lot of research and part of writing this book, right? I did do.

Yes, I did a lot of research. I read a lot of research and part of writing this book, right? I did do. Yes, I did a lot of research. I read a lot of books. Sort of a trick question there. I talked to academics. I talked to a professor who was very into language study, the theory of languages, comparing languages, choosing the right language. I was got Carnegie apply to Microsoft. I had some very impressive candidates. There was a school called Olin in Massachusetts, which is specifically an engineering college and seemed to have a bit more of a let's focus on actual real-world problems approach.

There's little bits here and there, but I think the general engineering degree from a big school still pretty much follows the same general pattern it did when I was in school. And that's based on talking to people and also just seeing candidates come in and what courses they've taken and what skill set they've had when they showed up at Microsoft to interview. At least up to a couple of years ago when I left Microsoft. I'm thinking of two angles for this, you know, one to give some praise to those out there that are, you know, seeking to, you know, create that feedback loop between industry and academia, but then also potentially some pointers to those listening that are, you know, not quite in their software engineering career that are pursuing a four-year degree or know someone to say, hey, you know, Carnegie Mellon or these other schools might be great examples from your point of view, given this problem that we're talking about. Yeah, the other thing I do want to call out is a couple of schools, Carnegie Mellon and Harvey Mudd, which are addressing another problem in software engineering, which is

the lack of women. And they are really trying to make sure their programs are as open as possible to women and encouraging them and supporting them and trying not to get people scared off by the high school nerd type, which of course I was, who is most likely male and make sure that a CS program is welcoming to people who just show up and say, hey, I want to major in computer science because I like computers, I like games or whatever, I like virtual reality. I have an interest in it, but I was not in the programming club in high school. I think that's very important just to expand the pool of people who could become professional programmers because we need a lot of programmers. And knocking 50% of the world's

population out of the running from the start, of course, is a bad idea. Thinking about this concept, bad code, good code, and even the problem with that and the troubles in that, just going back to the analogy, because we can only compare ourselves to these other established academic traditions. You know when you made a bad bridge because the bridge falls down, right? The laws of the physics aren't changing. It seems like we're such a young industry and software engineering is such a, you know, is it an art? Is it a science? Is it a craft? I don't know. It seems like it's an amalgamation. It's such a new thing. Like what art is it a science is it a craft i don't know it seems like it's a amalgam it's such a new thing like what are best practices what is good code even these things are

moving targets you know we have we can teach design patterns we can have principles like you know don't repeat yourself single responsibility etc etc but even those can be abused and misused and produce bad code at the end of the day because the person who was following the rule didn't understand the times at which it makes sense to break the rule to actually write good code. So is this, I don't know, I kind of throw my hands up and say some of this seems like an untenable problem. And Adam, I'm curious what you think with regards to how do we even go about designing or describing or defining what code is good, what code is bad? Has a lot of work been done in this in an objectified, quantifiable way that we can teach it with authority? I mean, there has been some research. There's been an uptick in it recently.

I just saw research on variable names recently, which is great. And that sounds like a simple thing, but at least at the start to say, okay, we're not going to argue over that. I mean, you could, of course, talk about tabs versus spaces, which is getting a little to the silly side, but things like method naming and what's the right amount of commenting

and that sort of thing are very important. And there are better or worse ways to do it. And they have been studied. So I think there is things you can learn. I think if industry had more of a demand for that sort of knowledge, if they actually paid attention to these sorts of studies,

because Microsoft Research did a lot of studies of software engineering, but not a lot of that knowledge filtered back into actual product groups. So if people cared about that, it would drive more demand for it. And you could start studying all these problems. I think that there is better code and worse code. A lot of it is only determined

after the fact, long term. So whether code is maintainable, you would see that in the bug rate and things like that, but that would take a while. And it sort of gets to this problem that people tend to study small pieces of code. And in particular, what you can study in small pieces of code is performance, whether it runs fast. You can tweak the code, make it 5% faster by some clever little trick in how you write the code. And that's easy to evaluate by yourself, even on a small project in school. And so people tend to focus on that. And a lot of people think that code that runs fast and is really quote unquote cleverquote clever is good code whereas figuring out if code is maintainable involves talking to other people and and then also just

just long-term usage over a large group of people so it's very hard to study in academic setting you could do it but it would require more work and so people tend to bias towards the things that they like when they're writing on their own versus things that matter when working in on large pieces of software so i think that's the important thing to realize that although a lot of people seem to instinctively think that well code that's faster is also cleaner because i've cut out some code or something in fact the typical pattern is that code starts out fairly cleanly designed and then in order to make some performance optimization right, people will add some side channel or some extra API parameter or whatever, just because, oh, in this situation, we need to optimize it. And really, performance is generally fighting against clean design and therefore against readability and maintainability. I think a lot of people don't realize that.

And when they complain about new kids coming out of school, that's what they complain about. They'll talk about people programming in C sharp and they don't realize what exactly goes on when they're manipulating a string. And isn't that a terrible thing? And to me, I mean, I'll take people not knowing what code is generated on string manipulation. I'll take that gladly over buffer exploits in network-facing C code, where, yeah, everyone knows what's going on with that string manipulation because you wrote the code yourself and you got it wrong

and you have a buffer overrun. That's much worse than, oh, yeah, these kids today don't know what's going on. To me, having string manipulation taken out of the hands of programmers, the nitty-gritty details, is a fantastic thing, which is why most modern languages have chosen to do that.

So you're basically saying it depends. Yeah, I guess you could summarize most of my answers that way. I think that, as I said, just think about readability over performance and cleverness. If we just got that notion lodged in everybody's head that that's what matters i think that would be a huge sure huge step forward i agree with that that being said readability is inherently subjective right because it's the subject it's up to the scrutiny of the reader you know just like beauty is in the eye of the beholder readability is in the eye of the reader and so maybe maybe we need to start so simple as

prioritizing priorities and saying readability is a priority and that's good enough starting place but then from there you have to then define well what is readable code versus unreadable or what is maintainable or changeable and like you said over time you can track that retro actively but to teach it in a rigorous, again, authoritarian, not to use that style, but authoritative way where we say that we know, like, to have some truths about readability seems like a large endeavor and one that would require. It seems like this is what academia should be doing. Isn't that what they're doing? Oh, I absolutely agree. I mean, yes, of course, there's some subjective aspects to it.

Yeah. But you could, first of of all want to find out right you could say we want to know what readable code is and we want to study it and if industry could say if academia tells us something we'll actually pay attention to it which is another problem we won't just keep doing whatever we did last week uh something like method length has been studied somewhat and steve mcconnell and code complete looked at various studies. Of course, that was 20 plus years ago. But I think the answer was over 200 lines is too long. That was what the research actually showed back then. And yet you have people running around saying that over 10 lines is too long.

I once saw a talk at Microsoft where somebody said that if you have to add a comment to your code at all, it means your method is too long, which I think is silly. But of course, that's just my opinion. But clearly, you have wide disagreement if some people are claiming 200 is the cutoff and some people are claiming 10 lines is the cutoff. And this could be studied. Yes, it's so much objective. We'll at least get some clarity on these orders of magnitude differences that people are just arguing about without neither side having particular proof of what they're saying. Yeah, so interesting. To get more extreme, even than that, I'm thinking about Sandy Metz's five rules. She's a longtime OOP programmer and teacher, and she has rules for programming.

She says, you know, do these rules, and then eventually you'll learn when and why you can break them, and you'll get good at object-oriented programming. Her rules, very quickly, 100 lines per class, 5 lines per method, which I find incredibly constraining. When I tried this, I just immediately broke that one. 4 parameters per method, 1 object per view. That's what's specific to MVC pattern, I believe. 2 class names per

controller action this is a specific to ruby and rails in that case but at least the first three hundred lines per class five lines per method four parameters per method or four arguments sent in so there are some very constricting rules that uh she believes produces good code or i guess i should her word or clean code so that produces clean code so Or I guess I should, her word, or clean code. So that produces clean code. So definitely some work being done in this space, but no consensus, because that's, you know,

a lot of people would disagree with that, those rules. Right. And what did she study? Is that just her personal experience and based on what? And I'm sure that's correct in some situations and incorrect in other situations. And so. Right.

I think you have a lot of this where it's just. Yeah. And she'll even say that it's lot of this where it's just yeah and she'll even say that it's not always correct it's just a she teaches it as a starting place for people to go from there start there and then move move away and hers is all industry experience she's not an academic yeah a lot of programming wisdom is hey this thing works for me so let's tell other people about it even the so the law of demeter which is this pretty standard taught object-oriented concept you know class a knows about class b then a can know about b and

b can know about c but a should know the details of c which was actually presented at oops law a while ago in the original paper even which was actually from academics just that look this is something we came up with it might be be a good idea. It might be a bad idea. It probably doesn't apply to all situations. I love it. We need to study this more, which is sort of the academic approach. Like we're just, you know, this is just one study kind of thing. Yeah.

And clearly there's some counterexamples where forcing an extra method on B just to avoid A calling to C is sort of silly. But yo, now the law of Demeter is often proposed as like, this is a thing you got to do. This is object-oriented canon. And I mean, don't violate it. So things tend to grow like that, even agile. If you read the first Scrum paper,

which was also at Uppsala, Scrum was about only object-oriented code and it was only about incremental improvements, not about version one. It was only about a certain not about version one it was only about a certain team size and then it got popular now scrum has turned into this be all end all solves all problems for all teams it's even leaking outside of computer science my my brother the civil engineer has heard about how scrum can help you an engineering project so i understand

why it happens people are are successful. They can write books. They can go to conferences. People want to hear more. So of course, they're happy to tell them. And it's not a knock on the people who came up with Scrum. I mean, in the situation they were working on, small projects, making incremental improvements, it was a great idea. It was much better than trying to do some crazy waterfall. Project management was completely unnecessary and not responsive to customers and all that stuff so so scrum in its correct environment is a good idea but it got overhyped like a lot of these things do you can look at devops or functional programming that's sort of

what's getting overhyped right now again when there are good situations where devops is an improvement or a functional language is the right choice, but they're not the magic solution to all software engineering problems. So you're saying it depends. Yes. In this case, I'm definitely saying it depends. And, you know, that's one piece of advice to software engineers is just be a little skeptical if someone comes to town and says, hey, I got the problem here. Try to figure out if it actually applies, really applies to your situation or not. Don't just go for the latest cool thing here's a pro tip for people who are writing best practices

or patterns down if you aren't sure if it's a good idea or a bad idea don't call it a law right the law of demeter i think that's the uh maybe the hubris there even though they admit like you said in their paper that it it's like, this is a concept, we see some value to it. You call something a law, you know, like gravity, right? We're all pretty much stuck to that one. But with the law of Demeter, I mean, as a young programmer, you hear law and you think, alright, this is

I can never call through to C, it's just a rule. That's problematic. This episode is brought to you by Raygun. Raygun recently launched their application performance monitoring service, APM as it's called. It was built with a developer and DevOps in mind, and they are leading with first-class support for.NET apps and also available as an Azure app service. They have plans to support.NET Core,

followed by Java and Ruby in the very near future. And they've done a ton of competitive research between the current APM providers out there. And where they excel is the level of detail they're surfacing. New Relic and AppDynamics, for example, are more business oriented where Raygun has been built with developers and DevOps in mind. The level of detail they're providing in traces allows you to actively solve problems and dramatically boost your team's efficiency when diagnosing problems. Deep dive into root cause with automatic link backs

a source for an unbeatable issue resolution workflow this is awesome check it out learn more and get started at raygun.com slash apm So the goal of this book is to raise awareness, get the industry people interested in what's going on, but also academia, having that feedback loop between the two counterparts. The industry is moving forward or maybe faster, as we've said, than academia and for good reasons. And academia has a whole different goal set in terms of educating the future engineers of the world,

software engineers. So how do we get these two parties to talk more? Is it conferences? Is it podcasts? Is it forums? What are some good, you know, based on your research, what are some good ways that we can get this feedback loop going?

Well, I think conferences is a great starting point. I think that people in industry tend to go to very technology-focused conferences or open-source conferences. And there's a lot of great conferences put on by IEEE and EACM, which people might think of as, oh, that's academic stuff. But really, there's actually a lot of valuable knowledge you can bring back. And then they do focus even somewhat on software engineering, not just on algorithms, on vision or AI. There are conferences about software engineering, but put on by the ACM and I are in the positions to create curriculum or lead curriculum, they feel invited or welcomed?

Or there's actually content there that it makes them feel like their time is valuable? Because obviously they're probably older than their life. They probably have other things that may be attracting their time, like maybe vacations or something like that. When they've got some downtime or whatever, do you think they feel like they're welcomed into this community i think i think the professors the researchers are welcomed it's interesting the term software engineering really first came into common usage in 1968 when nato put on a software engineering conference and they invited academics and and industry people together and they all agreed that yes we have a problem with software engineering even 50 years ago.

The same problems, bugs and predictability and all that. And they had a conference. So they agreed, yes, we should have a conference the next year to try to solve this problem. And in 1969, they had a conference, the second NATO software engineering conference, also the last NATO software engineering conference, because academics and industry got into a big argument about whose fault it was. And, oh, the academics are off in the cloud and the industry guys just want to shovel software at the door.

And so that was the end of that. But there are some good conferences now. I think one issue is that, because I've talked to academics about this, and they say, oh, there's people from Microsoft who come to our conference and they present and we talk to them. But that tends to be Microsoft research, which is not the product group. And so, as I said earlier, that knowledge doesn't tend to transfer back to the product groups that actually work on the shipping software. And I wish you had a lot more people from those product groups actually shipping stuff go to those conferences. So the big one probably is the ICSC,

the International Conference on Software Engineering, which is happening actually in May. That's a joint ACM IEEE conference. It's in Montreal this year, which is my hometown. Unfortunately, I can't go because of conflicts, but that's a very good one. There's papers on a variety of topics, but some of them are about software engineering and some empirical studies of software engineering

where you could actually learn about this. And I think somebody from a product group coming there and saying, hey, I actually work on a large piece of software. What can you teach me would be very welcomed. I think that people do want this knowledge to spread the industry. It's just that there's a slight lack of this knowledge. And also industry is viewed as not really welcoming it because they're just interested in shipping stuff and counting their money and whatnot. And so I think it'll be great.

I mean, the more people, the more actual people working on shipping software who showed up at these ACM IEEE kinds of conferences, the better. So there's that. There's actually ESEM, which is ESEM, the Empirical Software Engineering and Measurement Conference, which is in Brazil next year. There's one on computer science education, which just happened next year. This is in Portland, Oregon, actually, which has a lot of interesting papers about people learning the program, which is actually still an important topic for, I think, for industry people.

There's CHI, the Computer Human Interaction Conference, which I think is in Scotland this year coming up. Again, a very interesting topic for a lot of software developers. Actually, CHI started out, CHI started out studying programmers. That was the computer human interaction they were interested in, is programmers working with their computers. And it really was empirical software studies, but then kind of veered into looking at users how people interact with user interfaces and stuff but again still very interesting for any programmer to learn about this sort of thing jared have you heard any of these conferences are they new on your list no they're all not on my list i feel like this is good information to have i'm also just revisiting the acm which i haven't really like just acm.org

haven't considered this organization i think since i was at university i think they gave free membership or at least discounted membership back then so i remember reading a few papers on acm but adam would you even suggest just like membership with acm and participation in that organization or similar ones as a step? I would recommend that ACM and IEEE Computer Society, which are sort of similar and they both run conferences and they're both useful.

ACM has this awesome digital library. They've got all their publications going back 50 plus years online. All the OOPSLA stuff. O oops stuff oops is the acm object oriented conference you want to read the original scrum paper or the original love demeter paper or whatever you can read dykstra edgar dykstra complaining about this that and the other so

there's a lot of good stuff you just want some historical background you want to you know probably half the references in my book or to some obscure ACM paper that you have to, I think you need a membership to read. Although your company may have a membership. If you're at university, as you said, you can probably get a free membership. So yeah, I think ACM and IEEE Computer are very valuable things to join. So my brother's a civil engineer, so he belongs to ACSC, the equivalent, the American Society of Civil Engineers. And it's sort of kind of unquestioned that, of course, a civil engineer would at least belong to that and get their publications, have access to their library.

And the fact that most programmers don't know about them and certainly don't belong to them is just kind of a strange thing in software. Where professional engineers work in industry, why would we not be involved with the two big professional associations in our industry it's a good question adam have you ever thought about joining acm or or anything like this no i mean either i mean they're not even on my radar there's the disconnect right there yeah on display and actually have magazines i mean they're interesting they send you yeah i mean i definitely i remember them but it's almost like they you know once i graduated college and went into the field and started writing software professionally i completely disconnected from these things and haven't ever considered them until today which was uh you know talking 14 16 years later yeah they just had an article right there's an article just by a physicist about why quantum computing might be entirely bogus which was interesting to read uh that sort of thing i mean they talk about

self-driving cars a bit now so just interesting stuff to read about and like i said it just seems like you should belong to it as a working programmer yeah not trying to personally shame you and i'm not here right well i mean memberships but yeah well i think we ask the question, how do we get both sides to speak? I think we have to, the first step would be to be aware of the presence of each other. And if, as an organization like ChangeLog Media, producing podcasts around software developers and the whole entire culture of creating software, whether it's leading it, creating it, designing it, you name it, you know, I would imagine it would make sense for the two kind of parties to be aware of one another so that we can shed some light. And that's why this conversation with you is so important. Right. Well, this is great. I'm feeling all warm and fuzzy because this really is what my book is trying to drive. I'm not proposing a solution to the problem with

software. I have some suggestions, a lot of stuff we talked about, but a lot of it is just bringing people together, recognizing the problem, and then we can start trying to tackle it. First step to any problem solving is admitting there's a problem and understanding it. I think back in the old days, working in Windows, Windows NT, we thought we were doing good engineering, and I think we're doing better engineering than most. We really tried to design in quality to the extent we understood that. But still, we had no unit tests. As I said, we had that throw-it-over-the-wall culture to test where we sort of blame tests if bugs happened.

I mean, it took a long time to ship. So even people who wanted to do it well back then just didn't have the knowledge to do it well. But now I think there's a lot more out there. That's sort of why I subtitled the book, Smart Engineers Write Bad Code. I'm not trying to throw the engineers under the bus. For one thing, I am an engineer. People mean well. They're not malicious. They want to write good software, but there's this knowledge gap that they have. So while you're talking about Microsoft in the good old days or the bad old days, or at least just the old days of Windows NT. What did you work on there? Any horror

stories or maybe the opposite of a horror story? Any good stories? Anything that was amazing that happened or terrible while you were there that you'd like to share before we call it a show? I worked on the first version of Windows NT. I worked on low-level networking, network transports, and network card drivers.

This is under Dave Cutler back in the day. And there's probably only 40 or 50 developers on the whole thing. Now there's thousands, literally. We just had a reunion, actually, a 25th annual, 25-year reunion of shipping the first version in 1993. And Cutler was there and a bunch of people I hadn't seen in a long time, which was really nice. It was really why I worked on large software. And you get these problems where it happens once and it triggers in a debugger, something crashes and you have to go forensically investigate it by digging through memory. And if you lose your repro step, if somebody kicks a power plug out of the wall or your

debugger disconnects or something, you've lost your state and you have to hope it happens again so thinking back i mean there was a lot of very difficult bugs in that environment because you're so far down in the guts of the system and you know that's what i remember so specific bugs we had weird bugs that happened due to you know something in a network lab configuration or we had a bug because of a bad hardware chip, that actual network chip had a bug, which you never think of as a software developer, but things like that. But then we also had bugs

that were very tricky software problems that you just had to figure out. We had one bug where we were trying to figure out what was happening with a token ring driver, which is some network technology so obscure that I'm sure most of your listeners never heard of it. So we had this token ring bug, and we said, well, let's try to write to a log, some log in memory to see what's happening.

Just track where at this point we got a packet, we sent a packet, the packet completed transmitting. And we started out writing words to the log, transmit, receive. And we realized that even that was messing up the timing so much that we could write a single letter to the log. And we're talking about basically writing something to memory, writing one byte instead of six bytes or whatever. We had to change it. So we were writing only a single byte to memory at each point in this log.

Otherwise, it messed up the timing and the bug never happened again. So, I mean, things like that are like, yeah, I remember you started to work on applications and higher level stuff. It's like, oh, wow, this bug just repos every time. Run this test script and the thing crashes. Like, it seems so easy. But yeah, just a lot of time spent. Now it's back when you couldn't work remotely. You had to go in.

You had to go into the lab to look at problems. You had to go to your desk to work on anything. So you spent a lot of time at work. If something broke, you were getting in your car and going to work to look at it. You couldn't just remote in. And yet, when I look back, I don't know if you ever read The Soul of a New Machine, that book about a data general project back in the 70s, which was this crazy death march project, actually shipping hardware. And when I read that book, I thought, wow, I want to work on a project like that. And a bunch of other software engineers I talked to at Microsoft also also read Soul of a New Machine, and also had the same response. Well,

I want to work on a project like that when you're sort of young and it seems exciting. And I really did work on that kind of project. And in retrospect, looking back, yes, it was a great experience and all that. So I don't regret doing it, but I'm glad I got that checked off and now I can go work on more rational things but it was a great thing and i mean obviously it was hugely successful for microsoft and it's the foundation of windows and yeah and made a lot of money and is used by a billion people or whatever it is so it's kind of cool that somewhere down there in the guts of windows there's probably still a couple lines of code that i wrote especially if they're still using that token

ring technology yeah Hopefully not. I was at an airport in Barbados a couple months ago and they were remote booting, doing a network boot of the check-in terminal because they had to reboot it. I'm like, oh, well, that's my code that's about to get probably some of my code there because I worked on remote boot at one point too. That's probably my code that's going to get run soon.

Nice. The best code is a code that can continue to bring value years down well the best code is the code that continue to bring value years down the road you know if you think about what code is for code that you write and then gets used by a few people for a small amount of time and just doesn't have much value to it even if it's readable and maintainable and all the virtues but code even if it's ugly and it was nasty and it was bug ridden you had to bleed it out back in the day. And here it is 30 years later, you know, still bringing some value to some people around the world. That's a pretty cool thing.

Yeah, hopefully my code is somewhat readable. I'm not meaning to imply that it was terrible. I'm just saying you've learned a lot. You've learned a lot. When you're working at Microsoft, I would sometimes get mail 15 years after I'd work on something because my name was there in the code my alias was there in the code as the person who worked on it uh these questions why did you do this i'm modifying something and you know try to remember that is a little difficult but hopefully i i didn't get a lot of questions because it was mostly understandable maybe from that comparison jared there might be

actually two types of code good code well three good code bad code and viable code because you can write good code that's not viable and you can have viable code that's not good code what you want is good valuable code that's right but we'll take bad viable code too because that's right why not right that's right i just think you know coming at it from that lens like thinking of a value standpoint because you can always go back and refactor right i mean just because it's written doesn't mean you can't go back and change obviously that's time and time is money but you know if value is is something we seek then simply just good or bad that might be you know more long-term value yeah but i know that

there were cases at microsoft where people would say we can't understand this thing we're just going to throw it away some particular module or part of the nt kernel or some application or whatever where because of how it's written and the fact that everybody worked on it was no longer around it was just completely replaced and obviously that's a big negative if your code is just completely incomprehensible and people think it's better to spend the time to completely rewrite it yeah that's in that many code i don't think that's happened to anything i wrote although who knows maybe they would just they were kind enough not to tell me i don't know auto mailer when they delete your last line of code from the system just send an email off your code has been deleted you've been wiped from the system that would be rude so over here at the tail end remind

us where the best place is to buy this book. So if someone wants to kind of go deeper than simply this conversation, this is an industry insider that's explaining why there's so much bad software out there and why academia doesn't teach programmers what industry wants them to know. So if they want to dive deeper into this, where's the best place to buy this book? Well, it's on Amazon, you know, barnesandNoble.com. It's published by MIT Press. I know some of the Barnes and Nobles in Seattle had it. Last time I checked, if you actually want to go to a physical bookstore and buy it. And also it's available on Kindle and whatever other e-book formats you choose to use.

You know, speaking of going to a real bookstore, went to a Barnes & Noble recently, and those places are actually pretty cool. You can grab the book you want to buy. You can look through it. I mean, how novel of an idea is that, right? You can even sit down in a comfortable chair and read a little bit of it. So cool. So I would actually recommend that. Turns out physical retail stores have value.

They do. Who would have thought? Who would have thought? And they got cool music in there, decent environment. You know, it depends on the one you go to, of course, but I'm an advocate of it. No, I do like bookstores, although there's been some shrinking of bookstores. I hope that Barnes & Noble survives and you still have that opportunity to go in, as you said, and actually get a book.

There's a little local, there's a local bookstore. I live in Redmond, Washington. There's a local bookstore called Bricks and Mortar Books, which started, I think, a couple of years ago. And they're just being a nice little community bookstore. And I certainly hope they survive. I try to go there and buy books there if I think they'll have it. There you have it. The problem with software, why smart engineers write bad code.

We dug in deep with you, Adam. Thank you so much for your time. We'll link it up in the show notes. Thank you, probably. And I really appreciate all you're doing for the industry and your veteranship and you know i've used windows before so i've used your code at least once one thank you for your time my pleasure thank you glad you enjoyed it all right thank you for tuning into this episode of the changelog hey guess what we have discussions on every single episode now so head to changelog.com and discuss this episode and if you want to help us grow this

show reach more listeners and influence more developers do us a favor and give us a rating or review in itunes or apple podcasts if you use overcast give us a star if you tweet tweet a link if you make lists of your favorite podcasts, include us in it. And of course, thank you to our sponsors, Linode, Clubhouse, and Raygun. Also, thanks to Fastly, our bandwidth partner, Rollbar, our monitoring service,

and Linode, our cloud server of choice. This episode is hosted by myself, Adam Stachowiak, and Jared Santo. And our music is done by Breakmaster Cylinder. If you want to hear more episodes like this, subscribe to our master feed at changelog.com slash master. Or go into your podcast app and search for Changelog Master. You'll find it. Thank you for tuning in this week.

We'll see you again soon. Because you've stuck in here to the end of this show, we got a special surprise for you. This is a preview of our new upcoming show called Brain Science. This podcast is for the curious. We explore the inner workings of the human brain to understand behavior change, habit formation, mental health, and the complexities of the human condition. It's hosted by myself, Adam Stachowiak,

and my good friend, Muriel Reese, a doctor in clinical psychology. It's about brain science applied, not just how the brain works, but how we apply what we know about the brain to better our lives. There we go. So where do we begin to understand the mind? Humans have brains with all this neural activity. And I'm just thinking about what I know about my brain. I understand that it's up there, what it is. I understand it's very important to me and without

it, I couldn't function. But, you know, my mind isn't my brain's activity. How can we begin to break down the brain and the mind to really understand the operations behind our mind? Well, one of the things that is really important when we're looking at the brain and the mind is actually the words that we use to describe different things. And so I think it's really important to be as clear as possible. And so I think we use to describe different things. And so I think it's really important to be as clear as possible. And so I think we want to differentiate the brain from the mind. And so the brain is made up of different structures.

And then the mind is sort of the inner workings of the physical structures, which is not observable. But when we're looking at the brain, there's some primary structures that are fundamental to being human. And that involves sort of three different brains. Well, we have the brainstem, the limbic brain, and the prefrontal cortex. I know it might get a little heady in talking about some of these things, but I think it's helpful when we can have a visual.

So if you put your right hand up in the air like you're being sworn in with all five fingers next to each other. Go ahead and. Okay. Fold your thumb across the palm of your hand and then close your four fingers over the top of your thumb. Okay. I got that. And so in order to correlate these with different structures, your wrist would be synonymous with your brainstem, which is the reptile brain. Then your thumb is the limbic brain or mammalian brain, which means all mammals have that part of the brain.

And then your four fingers are what we refer to as the frontal lobe or part of the prefrontal cortex. OK, so we sort of have three brains in one and all do different things in our brain to help us be able to live and move and be safe. So if we have three brains in one, they all have their different roles. It sounds like, you know, the reptilian seems, I don't know, like it can't think very well. When it comes to the reptilian brain, I'm assuming it's just sort of like, you know, gut reactions, you know, very, very quick thinking, you know, almost subconscious kind of stuff potentially. Is that right? Yeah, you're spot on.

Sometimes I think, again, it's helpful to parallel things with what we do know and do understand. So thinking of different animals, reptiles, right? Lizards, turtles. So the brainstem is really only responsible for these key functions within the body so breathing heart rate the essentials and and fight or flight if a lizard is afraid right it needs to figure out what it needs to do to survive so the brainstem is just preoccupied with the function of survival how do i not die and then if we move up to that mammal brain, right, we can think about, you know, cats or dogs, bats, and that mammal brain or limbic brain is really the feeling

center of our brain. There's two key brain structures as part of that, and that is, involves the amygdala and the hippocampus, which is responsible for memory. The one thing I think is super fascinating about the mammal brain is really the way in which we bank memories. Whenever things have the most emotion associated with it, we're more likely to remember that. Okay. So it doesn't matter whether it's positive or negative. So be it a wedding, a birth of a child, you know, or something super traumatic,

our brain goes, oh, that's so important to remember. It vacuum seals it so that we hold on to that. And so this is why, too, our lives have different meaning and being able to feel is a fundamental part of being human. The mammal brain is really the feeling center. So as opposed to more of the fight or flight from the reptile brain, our mammal brains, they're still more of an unconscious, subconscious things. But imagine that the Dewey decimal system of your brain sorts things according to feelings when we're mammals. That's a preview of Brain Science.

If you love where we're going with this, send us an email to get on the list to be notified the very moment this show gets released. Email us at editors at changelog.com. In the subject line, put in all caps, BRAIN SCIENCE with a couple bangs if you're really excited. You can also subscribe to our master feed to get all of our shows in one single feed. Head to changelog.com slash master or search in your podcast app for ChangeLog Master. You'll find it. Subscribe, get all of our shows and even those that only hit the master feed. Again, changelog.com slash master. Thank you. you