Transcript

Adam Barr Which—I guess I’ll tell the time I checked in code that didn’t compile. That—that’s probably a good one [Rich laughs wheezily].

Paul Ford Yeah, that’s—that is al—that’s a classic. Everybody loves a good like—

Rich Ziade People can relate to that.

PF—“When I Failed” story—yeah [Rich laughs, music fades in, plays alone for 18 seconds, ramps down].

RZ Do you know what we love, Paul? [Crinkling sound]

PF What do we love? Potato chips.

RZ Veterans.

PF Oh, we do love vets. Actually, there’s a great organization [music fades out] called Vets Who Code. We had the founder on the—

RZ Wonderful organization.

PF—on the show once. But—

RZ Trains up veterans.

PF There’s other kinds of vets too.

RZ There are. And they know—they see it all. They’ve seen it all.

PF Mm hmm!

RZ The good and the bad.

PF I always think of them as the kind of people who are sorta sitting on the dock of the house—their lakehouse, and then a helicopter comes down behind them.

RZ Oof!

PF And, “We need you for one last job.”

RZ [Laughs] They get recruited one last time!

PF That’s right, or [ok] they write a book.

RZ [Laughing] Or they write a book! We’ve got a veteran on the podcast today. A true software veteran.

[1:02]

PF A veteran of Microsoft.

RZ His name is Adam Barr.

PF Adam, welcome to Track Changes.

AB Thank you. That was a uh—a wonderful introduction. I was [Rich laughs] on the edge of my seat, trying to figure out where you were going with it, but [Paul laughs] it all makes sense now.

PF We like to take the listener on a little journey.

RZ Tell us about your background and, I mean, obviously if you pull your name up on LinkedIn there’s this huge entry in your experience but tell us about yourself and sort of your back story.

AB So, I—I did work at Microsoft for—for 23-plus years. I—I’m not an actual military veteran, to be—to be clear. Not—not to compare Microsoft to that. I worked at Microsoft for 23 years and, like a lot of the people I worked with, I started in 1990; I actually worked in two different segments. I taught myself to program in Basic . . . on an original IBM PC. I still have a DOS one-point-zero [DOS 1.0] floppy disk that I’ve saved for historical purposes.

PF Everybody loves those, those are very exciting.

AB Well, at one point even the Microsoft museum only had a one-point-one DOS diskette to display. So I felt kinda—kinda cool. Anyway, I taught myself to program, I went to college, I maj—majored in computer science, but basically it was using those skills that I had taught myself primarily when I was writing code in college because programs in college aren’t that big. Then I went to Microsoft—I actually worked somewhere else for a while—but eventually wound up at Microsoft, and kinda was using those same skills, the self-taught skills, eventually figured out a bit about writing larger pieces of software. I worked on various projects; I worked on both Windows and Office at different times so you can probably blame me for . . . almost anything. I was a program manager for a while; I worked on Powershell. The very early days of Powershell, the—command line language that Microsoft has. Which is very cool. And I was an instructor for a while, inside Microsoft, in a group called Engineering Excellence. Which sadly was cut by Satya Nadella, actually, who I know is a hero to many but he didn’t cut me personally, I had left the group by then but he did kill the Engineering Excellence group, unfortunately, which I thought was very valuable for doing internal training and consulting inside Microsoft. Then [sucks teeth while saying “then”] I left a couple of years ago to write my book, The Problem With Software.

[3:11]

RZ The Problem With Software. I mean you just went right for it with the title.

PF I mean, Adam . . . what is the problem with software? [Giggles under his breath]

RZ Wait—wait, before we get to that, gimme something—I mean, right now there’s like a glow around Satya Nadella, like he sort of can’t do wrong. Gimme—gimme the dark side here. Gimme something. I mean, everybody’s got their flaws.

AB I don’t think they’re the dark side, particularly. I think that [Rich laughs wheezily] he’s, honestly, Satya’s not single handedly writing all the code. If you’re familiar with Bill James, the baseball writer who [yeah] was behind a lot of the ideas that led to Moneyball and all that [mm hmm]. He had a theory that it’s good to alternate between a baseball manager who yells at everybody the second they make a mistake, and then the more relaxed kind of manager, because the first kind gets everyone really disciplined but they get tired of being yelled at. The second person comes in, he’s everybody’s friend, they feel much better but they still have the discipline from the other guy but eventually they start to slack off and they kinda need a disciplinarian to come [oh boy] back in [ok]. But then they still have the memory of the—of the nice manager for a while and so they’re ok with the disciplinarian until that gets old. Anyway, the point of all of this is I think Steve Ballmer was kind of a yell-at-everybody person but he did instill some discipline at Microsoft about, “Hey, we . . . have to . . . do things well or Steve’s going to yell at us,” and Satya’s more the mellow, friendly type and so he’s benefitting a bit from the remaining discipline that was instilled by Steve. So—

RZ Got it.

AB If you take this analogy further, Microsoft will get a little sloppy at some point in the future, although [Rich laughs wheezily] I’m not promising that and—and we’ll need to bring in—

RZ Discipline.

AB—somebody a little harsher—

PF Can you imagine?

AB He wasn’t saying one type was better than the other, he said it’s good to alternate between the two.

RZ That makes a lot of sense to me, you know—

PF See, we jumped the gun and just got both at once when we started Postlight.

RZ I know! [Laughs boisterously] We did it dual track.

PF Yeah [Rich laughs]. I’m just thinking about the level of monstrosity that will need to be exerted when Nadella’s done. Like—like—like—

[5:09]

RZ To reestablish.

PF Ballmer was one of the great yellers of the like—the twenty-first century.

RZ Almost to a comedic level, right?

PF He’s famous for it.

RZ Yeah, yeah.

PF Right? And Nadella, like, does poetry.

RZ Right, a lot of zen.

PF And just thinks deep thoughts and the absolute monstrosity that will have to come in, the Jack Welch level turnaround nightmare in about 11 years [Rich laughs wheezily].

AB Yeah, I mean, I think it’s very hard. Everybody eventually wears out their welcome and you need something different to—to get people going again. So, I mean, obviously Satya’s done a lot of good things. He’s clearly very cloud focused; that was his background.

RZ So tell us about this book. It’s a dark title.

PF 20—23 years. In.

RZ 23 years in. And you came out and—did you have this—I’m gonna guess this was swirlin’ in your head while you’re at Microsoft, “I’m gonna write this book.”

PF Well, and also let’s be clear: the title of the book is not My Great Life in Software.

RZ No.

PF It’s not Software: the Thing That Will Deliver Us All to a Better World.

RZ No.

PF It’s The Problem With Software.

[6:06]

AB So the—the idea was swirling around in my head especially when I was in the Engineering Excellence group inside Microsoft. So, Microsoft has not had a single way to engineer software and you typically only see the methodology of the group you’re actually in but in Engineering Excellence, you went around to all these groups and I realize that—Although people at Microsoft have generally figured it out, there’s a lot of variability in how people do things, some is better; some is worse. And then you get out in the broader world, beyond Microsoft, and there’s even much broader variation. People not really realizing how to produce reliable software . . . in large size teams. So the problem with software, what the book is about, I guess the title’s a little dark. I just like the title. And I always was planning to use it for the book. I—I never really thought about it much. The problem is that what you learn in school: you go to college; you major in computer science or software engineering—what you learned about is working on small pieces of software, with one or two or three or four people. And in those environments, almost any language works; almost any methodology works. You probably throw away the code once you get your grade, but when you get to a large company, you’re trying to write something that will last for a long time; people are paying money for; the team working on it now is not the original authors. A lot of this stuff matters much more: what language you use; how you maintain it; how you document it; all those things. And so that’s really the problem, everybody comes out of college thinking they’re a great programmer, maybe eventually they realize they’re not and they could actually learn something but in that interim time there’s a lot of bad software written.

RZ In our experience many don’t stop thinking they’re great programmers, many years after college, but we won’t get into that. Tell me, I mean, you’re hopping around seeing different software groups, obviously dealing with different problems, approaching things differently. What’s the thing you saw again and again? Like, like, “This is clearly a pattern.”

AB One thing I—I saw a lot, actually, was that people were chasing the—the cool, shiny way to develop software and that was agile Scrum, in particular. This is in the late 2000s, about ten years ago. And even if somebody inside Microsoft would come and say, “You know, Scrum is really for small teams, and you have a large team—” Like us in Engineering Excellence, for example, might come by and say that. They would say, “Oh no, I went to this conference and—and somebody on my team is a certified Scrum master and [Rich giggles] it’s gonna solve all these problems even for this team with hundreds of people,” and so I think what I saw a lot of was just people wanted some easy answer to producing software on a large team, and there was no easy answer but they were interested in chasing the easy answer. Because that would make their lives easier. So, we almost spent as much time explaining to people why what they were doing wouldn’t work despite that conference they attended last month as telling them what they should do. So this is not a knock on Scrum. Not specifically. Scrum is very useful in certain situations but . . . it was presented a little more broadly than that and Microsoft people were as eager as anybody else to—to be convinced.

[9:11]

RZ Well the latest thing is something we deal with, right? I think everybody does. I mean a smart, curious—I think people wanna know they’re growing professionally. And we deal with that in terms of technology choices. A lot of times it’s like, “Why did you do all that heavy lifting? Why would you want to do all that heavy lifting for something as basic as a—that, you know, WordPress’ll solve.” Or, “You did WordPress but why’s it so complicated? And why’s it is so convoluted?”

PF Well, WordPress isn’t cool.

RZ Is that what it is? It is cool? Or is it just feeling like you’re growing professionally and that you’re learning the latest thing?

PF It’s a lot of those things; and I think it’s also developer mindset but also just product mindset and just tech mindset is, “Let’s solve that problem that’s gonna come down the road.” You know it’s—this—today is a little bit boring, like the next five years are really interesting. Solving the problem for today is like [right], “Ehhh. I can set up WordPress and make it work and integrate it with Salesforce but do I feel really like I’ve thought about the year 2025?”

RZ Right, right.

PF Also, the other point I make is it’s—it’s hilarious to hear about—I feel like for 20 years now, I’ve been saying the words, “Yeah, ya know, Scrum’s ok.” I mean I don’t wanna say anything bad about it [chuckles] [yeah] cuz someone will rip my face off [right]. But it’s—it’s—it’s—yeah these orthodoxes really get into our world.

RZ Especially the less technical people.

PF Because everyone’s just—

RZ “Are you gonna do it? Are you gonna do the—” Like we’re an agency and a lot of times we’re talking to the business stakeholder and they’re like, “Do you use Scrum?” They just wanna hear—they wanna check that box so bad.

PF It’s—it’s the same as them saying like, “Do you host things on web servers?”

RZ It’s like, you know, “Lemme just make sure you’re not crazy and that you’re gonna do this the right way and I can go back and tell people, ‘Oh they’re a Scrum shop’.” What else? Tell us, what else—you know, I guess, what’s—what other ideas sort of poured into this book?

AB Well, the idea that people were self-taught and therefore they needed to be humbled a bit. That’s important because as I said, you can—a lot of people have—especially a lot of people managing teams right now who are around my age, have this success with their self-taught skills and so they think they’re good but the other thing: the book is arranged somewhat historically and it’s showing how there were various methodologies or solutions offered that were going to make software easy, starting back with structured programming, way back in the late sixties and seventies. Just the idea of having if blocks and structured loops and all that . . . through object-oriented programming, unit testing, TDD, all that stuff. And then agile, and now you’ve got DevOps, and Kanban, and functional programming, et cetera, et cetera. There was really a history of something that is useful being invented; people hoping this is the magic solution, jumping on it, the thing getting hyped way beyond what it deserves, without any real academic backing because academia is not thinking about that kind of stuff, and then inevitably crashing, so maybe Scrum is out of favor now because it didn’t solve all the problems. But it, it was overhyped then and maybe it’s being underhyped now, and DevOps and whatever will probably go through a similar—a similar cycle. I think it’s because until you really start to get good experimental evidence, some empirical studies showing that these things actually work, and not just in small, academic settings but on large software projects, you can always claim fantastic results and people will—will be very interested because software is complicated and they’re trying to simplify it.

[12:35]

RZ So—so I—there is none. I mean, there is—I mean over the years, I mean, the new thing has come—has shown up every five years.

PF Well lemme—lemme ask Adam a question. What’s the—what are the things that have blown your mind? Like what are the actual surprises over those 23 years where you went, “Never expected this to change the industry the way it has.”

RZ . . . of these trends.

PF Of these trends, yeah.

RZ Yeah like which one really did pull it off? Or none?

AB Yeah I don’t think anything has—has really pulled it off. Software is still very complicated. I think what blew my mind, actually, is to go back and I started reading historical software development guidance and to realize that in the 1960s people were writing about the same problems: how do I manage a large team . . . that’s stitching a piece of software together from different components that has to last for years when the original authors have gone? Et cetera, et cetera. And they actually started down the path of studying it in the seventies, where academics would do studies on . . . how programmers actually worked and there were studies on—on whether GoTo was good or bad and variable names and commenting and all this stuff, and then it essentially got swept aside by the personal computer because back in the seventies, you needed to be at a large company or at a university to get access to a computer, and so you were at least around other people who had some experience. But then . . . everyone could get a PC, they could teach themselves outta the IBM PC Basic manual like I did. And they were off to the races . . . and then they never really had this exposure to large software until they had maybe been at a company for a while, and so they never realized that they had some gaps in their knowledge, so it’s really the researchers in the seventies, you know, sort of forgot more about developing software than—than a lot of people ever learned. I mean Microsoft was trying—Microsoft—well, first, they had the idea of having testers. That was sort of a—a breakthrough idea at Microsoft in 1984 or something. Of course IBM had gone through all of this 20 years before and then they—then they said, “Oh you can just test the software and all the bugs are . . . the testers’ fault,” and IBM had also gone through that same incorrect path, and eventually IBM got to realizing you had to design quality in, and Microsoft eventually got there but this was after many, many bugs, and many unhappy testers getting yelled at by obnoxious developers, so it was a fairly expensive learning for the industry that was really repeated in a lot of other companies too when if you had just gone and studied history you would’ve realized all of this because people were writing books about it. Fred Brooks and Harlan Mills and people were writing books about this in the sixties, and the problems they were tackling are the same ones people face today.

[15:13]

RZ I mean, there is a lot of—first off, it’s—I think, the fact that you can pull something off on your computer, on your laptop today, without talking to anybody, and make it run, and it could be kinda slick, and you could put it out in the world. I mean, look: it—it breeds a certain level of arrogance. I think that’s real thing that’s out there. That you kinda have to swim against. Trying to convince a software engineer today that the new thing isn’t necessary or is actually gratuitous . . . is really hard. It’s really hard to do. They—it’s almost—it’s almost—it lands offensive. It doesn’t even—

PF You’re going against marketing; you’re going against community.

RZ You’re going against community. I think that’s a big part of it; I think the way these trends sort of catch fire within these communities is really hard to pull off and you’re trying to be like, you know, a pragmatic business person and say, “Well, let’s pause here and think about things.” It’s very hard to penetrate. I mean I—I don’t bother.

PF Well, and let’s be clear: our stack, the tools that we use here are five years ahead of where most of our clients are. Like, our big legacy organizations [mm hmm], they—they are just getting around to adopting a lot of the stuff we use and we sit here and people are like, “What are we doin’ . . . still writin’ Javascript?” [Rich laughs] “What are we animals?”

[16:27]

RZ Yeah. No, that’s true.

PF Yeah.

RZ And I think the only reason business does it is like, “Oh my God, everyone’s moving this way. If I don’t move this way, I’m—I’m dead.”

PF Well, this is it. I mean, we were talking to Adam, not with each other but this [yeah]—[stammers] it becomes really hard to hire too.

RZ Yeah.

PF Right? Like there’s all these other external pressures where you go, “Ok.” Nobody wants to rewrite the whole freaking thing. But you have to because no one is around to support the old version and everybody tells you you have to do the new way.

RZ Yeah. Program Manager is in front of you. I mean what’s—help them through this, right? This is—I mean not a lot has changed, I mean what you’re describing in terms of the arrogance and sort of makin’ the same mistakes in the eighties as the seventies and the sixties, I think we’ll continue to make the same [laughing] mistakes.

PF It’s not just engineers. It’s humans. It’s just [it’s humans] so happens that this industry is the one that exploded.

RZ Yeah.

PF Yeah.

AB As you said, if you’re using this Javascript package and somebody says, “Oh no, that’s six months old. You should use this other Javascript package because it’s better in some way,” be a little skeptical of that. I mean, yes, there may be some benefit but programmers are just not really good at actually thinking about, “Ok, these are the things that matter to me and therefore I should choose my tools or my language or whatever, based on these criteria.” It’s more, “Oh hey, that sounds neat,” or—often just, “I used that in the last project and it was ok, so I guess I’ll keep doing it.” You know it’s a—I mean—in more established industries, as you said, it’s all happened so fast, and so I mean in one generation almost it’s had these massive changes but then old school people are still around. There’s still people who think that C is a great programming language, that sort of thing. So—so they’re out there causing trouble, and then [Rich giggles] you’ve got the people moving super fast, and more established industries I think just move a little slower and have a bit more of a burden of proof to show that this new thing is actually useful. And as I said earlier: there’s probably some study about it, not just, “Oh wow. I like the way they case their variable names or something. I think I’ll switch.”

[18:25]

RZ It sound—I mean your book’s title is The Problem With Software. It’s called The Problem With Software but it really, this is, I mean, all we’ve been talking about so far on this podcast is people. I mean it sounds like The Problem with People is the second edition of this book.

AB There you go. Yeah, that’s good. I’ll take it [laughter]. The real problem is people, yes. I guess I could summarize most things as—as the problem is other people [Rich laughs].

PF Especially the users. They’re—they’re bad too.

AB Yeah, users are always finding bugs. No, no, yes, a lot of is—is personal interactions and a lot of the—a lot of the writing—a way to solve this stuff is more about communication and realizing how people work together and—and not just about the latest technology. Well, one big . . . realization that Microsoft and other companies eventually got it was that the person in the corner, who was cranking out code, who used to be revered at Microsoft, certainly, if you never left your office, you must be a genius. And now it’s realized that blasting out a bunch of code that only you understand without talking to anybody else, first of all, probably—might not be meeting the customer’s need because you’re not the customer and, second of all, is going to be a nightmare to maintain when you stop working on the project or get bored and move onto something else. So, that’s been a big change, recognizing that a lot of the issues, especially around maintenance and readability and all that, yes, it’s about other people interacting with your code, not about your code as a stand alone object.

PF Are we gonna—are we doomed to repeat the cycle or can we—

RZ I think we’re repeating it. I think it’s—

PF Can we break out and—and make better software? Better humans?

RZ Better humans.

PF Better users.

RZ I think, yeah, I mean—

PF Maybe there’s—you know [stammers] the fantasy is always like, “No, there’s some IDE you can use. There’s some framework.” But that’s not gonna fix it. So, I mean, Adam, what do we—what do we do as an industry? . . . I’m askin’ ya.

[20:17]

AB Well, it’s interesting because of course you had—you had a situation where you needed to work at a company to have a computer in the 1970s, everyone got a PC and they could develop on their own, but then it sort of turned into, ok, now everything’s going into the cloud, and you sort of need some cloud infrastructure or some way to distribute your software. Now it’s expensive. But—but wait a minute, now you can so easily get on the AWS free tier and put up a website all by yourself from your bedroom. So maybe there will be a whole bunch of—another generation where . . . it’s so easy to do stuff that people, again, don’t realize what others have learned before. In this case, it’d be more about how to host something and how to secure it and that sort of thing because anyone can put up a website and you don’t know what they’re doing with their data, and what they’re doing with privacy and all that. If they’re gonna have a data breach. So there may be some cycle. I’m hoping at least wisdom is gradually seeping in; I think things are getting better, people are realizing that software is not just pure goodness, it sure is super useful but—but there’s some negatives too. There’s some risks involved and you have to be careful in certain ways. So I think overall we are getting smarter but there will still be a lot of mistakes made; there will still be a lot of data leaked out where it’s not supposed to.

RZ Yup.

PF You know it’s tricky here though, you got . . . three people who are kinda mid-career, and the engineers coming in are like 22 years old. Did you—I never listened to anything anyone ever said when I was 22.

AB Yeah I certainly probably didn’t either. Yes, you’re 22. But if you’re a 22-year-old doctor . . . aspiring doctor, or—or lawyer or civil engineer. You do have some sense at a professional level, anyway, you should listen to—your—your—those who came before you and  you should actually study—

RZ In fact, you have to. Yeah, I mean, there’s a very actually narrow track, as a lawyer or a doctor.

PF They won’t—they won’t let you avoid it.

RZ Or certain engineering, right? Like certifications of certain types.

PF You can’t build a bridge just cuz you like bridges.

RZ No, no. I think that’s what’s unusual about this particular—about software engineering is that you could just go. I mean I think that’s awesome in a way because some of the most interesting things ever, you know, created in software happened because someone was curious. But I think you’re right, I think we’re starting to butt up against ok, do we put some guardrails around this? Like is this—this is getting a little banana—especially now we’re seeing what—what you do when you really let this stuff loose, and the kind of damage it can cause.

[22:45]

PF It’s like you can’t really have an amateur doctor. That’s a bad scene. But you can have an amateur or early stage programmer who does lots of really interesting fun work or can add lots of value but then there’s the stuff that shows up around security or—

RZ Privacy.

PF Yeah or just long term roadmaps for very expensive, very large products.

RZ Containability. Yeah. All of that.

PF Yeah, and so the professionalism becomes more and more of a requirement.

RZ Yeah.

AB Right, and I mean there used to be, two or three hundred years ago, there were amateur doctors in the US and that’s all there were, maybe they apprenticed with somebody but basically they were—they had no real—there wasn’t medical school and that’s . . . sort of where we are with software. And I mean it’s hard to hire people because getting a CS degree doesn’t mean the same thing as having a civil engineering degree or a medical degree, so people resort to all kinds of crazy questions but ideally you’d get to where yes, having a CS degree meant you were understood to have this certain set of skills and knowledge and you wouldn’t have to worry about interviewing essentially . . . starting from scratch when you interview. Microsoft would occasionally hire a music major as a software developer. I mean a music major who had dabbled in software, of course, on their own, and they’d say, “Wow! This is great. Look: we found this person.” Everybody else ignored them. They wouldn’t talk to them because they’re a music major and, “We—we found this diamond in the rough,” which is great, I guess, but it’s also really weird if you think about it.

RZ Yup. We’re—we’re almost out of time, Adam, but I do want you to—I wanna give you two minutes to give us one really good Microsoft war story.

AB So, I could tell you—I worked under Dave Cutler, the head of Windows NT for years. And at one point there was a problem with the build not even compiling. The Windows build wouldn’t even compile and the Windows build took hours and hours to produce. Even on a fast machine for the day. So—so Dave Cutler decided what the solution was he would sit in the build lab and personally approve all check-ins. And so at one point there was a bug in the build, something not—not a build break but something was not working, that I realized I wasn’t initializing a variable to zero. So it was getting a random value and something was breaking. So, I told Dave, “Oh! This is an easy fix. I’ll just go back to my office and check it in.” He’s sitting in the build lab. So I go to my office, I check out the file, I add “equals zero” semicolon to the variable declaration and check it back in. I go back to Dave in the lab and Dave goes, “Ok,” and he sinks it and builds it, and it doesn’t compile because it’s a large integer and which is a structure in C and so you have to say “equals . . . curly brace, zero, comma, zero, closed curly brace,” to initialize it. And Dave kinda looks at me, like, “Did you compile this before you checked it in?” Of course I said, “No,” because obviously I hadn’t. And he starts ty—so he fixes it on a machine which is very generous of him not making me go back to my office one more time, and he fixes it on a machine, and then when you check it in you have to type a check-in comment and he starts typing, “Fixed Adam’s f-u-c-k,” and then he backs up and just writes, “Fixed build break.” And then submits it.

[25:50]

PF A little moment of grace at the end.

RZ [Sighs heavily] I mean a little humility there.

PF Yeah.

RZ Yeah. Yeah.   

PF Ugh it’s just—seen so many of those.

RZ See I thought there was just gonna be blood on the walls at the end of this story. That wasn’t too bad, actually, [that was good] sometimes people are kind.

PF But for a minute there was no Windows NT [Rich laughs].

AB Yes, Dave, really, I mean I have to say somebody asked about this, “Was he really super grumpy?” He actually really wasn’t super grumpy . . . once you got to know him and if he trusted you and I’d been working on the project for a couple of years but—but yeah, see certainly it could be a bit prickly if you made a stupid mistake.

PF Just a couple years. Just a couple years to get [Rich laughs] someone to just relax a little and enjoy your company. Alright so people should go on the internet or maybe even to the—

RZ Book store.

PF To the book store and buy The Problem With Software by Adam Barr from MIT Press. I think that’s the only thing they should do.

AB Well they could also follow me on Twitter @adamdavidbarr. I’m trying to build up my followers. You’re out of the phase where you get a free toaster if you follow me but not by much. So you can . . . hear my wit and wisdom as it were on Twitter. But yes! Buy the book! I mean, as you said, once the solution—obviously if all—if all 10,000,000 programmers or whatever it is in the US bought my book it would solve—well, it would solve my problems. But it might make software better too, so.

[27:10]

PF Congratulations [music fades in] on the book and yeah, we’re gonna get a copy for a library at Postlight.

RZ Thanks again, Adam.

AB Thank you very much for having me.

RZ Take care. I love the old war stories, Paul.

PF Oh my God! I mean, it’s a struggle.

RZ It’s a struggle but, you know, that’s the real shit.

PF Ah, that was the stuff.

RZ When you get into the real stuff.

PF Compiling Windows NT is the real deal.

RZ Can you imagine? That must’ve taken a day and a half.

PF It did I think. I think it took forever. And you [stammers] got a crabby, like someone sitting under the bridge going, “You shall not pass!”

RZ NT is a landmark in software.

PF Yeah, they really did. They—it suddenly—that’s the base for all the Windows that came after.

RZ After. Correct. Anyway. A lot of fun.

PF Yeah! Someone who bore witness to history.

RZ Yeah.

PF Alright [both laugh]. Hey, Rich—

RZ You know where there isn’t problems in software?

PF Postlight.

RZ Inside the walls of Postlight, Paul.

PF That’s right. 101 5th Avenue.

RZ Yes.

PF You know what people should do? They should come by the office May 21st.

RZ May 21st we’re having a really fun event. It’s a Postlight Labs is gonna release a flurry of little experiments.

PF We’re working on the deck right now; there’s so many slides for so many things, but don’t worry we’re only gonna talk for a few minutes. It’s just a lot—

RZ We’re only gonna talk for a few minutes but it’s a lot of good stuff, some for engineers, some for just people who want cool tools—

PF And food and drinks—

RZ—free stuff. So come to event. It’s on May 21st. And we’ll be launching everything that night.

PF Mm hmm.

RZ Really cool stuff. Platform stuff. Salesforce stuff. Airtable stuff. Slack stuff.

PF Weird little experiments. One like micro app that could change your life.

RZ Forever.

PF It’s true. So you should come check us out. Go to postlight.com/events [yes] and you will get all the info. It’s in the evening, early evening. Right after work.

RZ And if we can help you with our amazing software and design skills, let us know, [says email together with Paul] hello@postlight.com.

PF—dot com. That’s all you need to do. And you know what? We haven’t asked for it for a while: if you’re enjoying the podcast, go ahead and give us a good rating on iTunes. It’s a gift. It helps us in the rankings. Goodbye.

RZ Buh bye! [Music ramps up, plays alone for five seconds, fades out to end.]