#57 Adam Barr roots for more humility in our careers
Transcript
⚠ The following transcript was automatically generated.
❤ Help us out, Submit
a pull-request to correct potential mistakes
Tim Bourguignon 0:06
Hello, and welcome to developer's journey. The podcast shining a light on developers lives from all over the world. My name is Tim Bourguignon, and today I received Adam bar. Adam worked with en for Microsoft for more than two decades. There, he worked on various versions of Windows PowerShell, and office, as well as in the engineering excellence team. In 2018, Adam started working as a consultant at crosslake company doing technical due diligence for acquisitions. Adam is the author of Proudly serving my corporate masters, finding the bug. And recently his new book, the problem with software. I'm sure we're going to talk about this today. Adam, welcome to DEF journey.
Adam Barr 0:55
Thank you glad to be here.
Tim Bourguignon 0:56
Let's go. And right away started talking about Microsoft. Was it always your idea to work for Microsoft? How did you end up there,
Adam Barr 1:04
so I actually did want to work in Microsoft starting and in high school, we got our first IBM PC in 1982, which was less than a year after the first PC came out. And Microsoft was providing DDoS for that, and then a few games decathlon and adventure. And I thought it sounds like a cool place to work, even though at the time was a very small company. It's hard to imagine. But Microsoft was kind of the underdog in software back then. And really, a lot of people hadn't heard of it. But I wanted to work there. I went to college. I studied computer science, and I interviewed at Microsoft in the spring of my senior year. And I got turned down by Microsoft, they said no, which was a little upsetting. So I went to work for a small company in New Jersey. But then eventually, a year and a half later, I did in fact, interview again at Microsoft and got a job there in early 1990. So, so my dream did come true.
Tim Bourguignon 2:09
Why wasn't your dream because of this underdog, or because of this emotional link to your to your past? Right? It
Adam Barr 2:18
just seems like at the time, there weren't a lot of software companies that just did software, what I interviewed, I interviewed at IBM and Hewlett Packard and a TMT that sort of who is out there. And the companies were mostly doing mainframe software. And so Microsoft, which was doing personal computer stuff, and I mean, they had languages by then. And it just seemed like a kind of a neat environment compared to working on these big, big companies who had a software division, but they weren't a software company, there just weren't a lot of pure software companies out there. So. So Microsoft seemed like it would be a cool place to work. And it was, in fact,
Tim Bourguignon 2:54
a cool place to work. What position Did you apply for in the very first time when you were rejected?
Adam Barr 2:59
Well, I applied to be a developer got turned down, I interviewed again, I actually was offered two jobs one was working on on DOS, actually, as a developer, and one was working as a what they call the performance developer, which was focusing on performance as opposed to writing the code itself. For various reasons. I didn't accept the job right away. And then when I came back and said, Okay, I want to I want to work there, the developer Job had gone away. And so I was offered the performance job, which wasn't quite what I wanted to do, I kind of want to really work on the software itself. But I figured I should get my foot in the door. And in fact, it turned out that literally the week I, I showed up, my manager who had interviewed me on the Performance Team said, Oh, I'm leaving on Friday to start a independent software company, and, and the group is kind of breaking up. And I just wound up becoming a developer, regular, plain old developer starting in week two. So really, that turned out not to matter at all.
Tim Bourguignon 4:00
Looking back, what was the difference between the first interview and the second interview? I couldn't tell you.
Adam Barr 4:07
As you probably know, software interviews can be a little random. You get asked a bunch of Whiteboard questions. Back then it was really early in Microsoft and people are still asking why are manhole covers round and, and things like that? I didn't get that question. But I got some other kind of brain teaser questions both times. And I malefic. I was a vastly better developer. A year and a half later. I think it just happened that the I gave slightly better answers to the questions a second time I don't think it was anything dramatic. I it's unfortunate when you have questions like that, that are did you have to sometimes have just a flash of insight to answer them that you might get one wrong or get it right based essentially on luck. And so I think I just got a little luckier the second
Tim Bourguignon 4:54
it's, it's part of the performance. Um, what was it like to start Being a developer in the was it he early The Late Late 80s? Early 90s.
Adam Barr 5:06
Yeah, it was it was March of 1990. It was really good. I have to say one of the things that made Microsoft really appealing once I got around to interviewing, even the time I got turned down for the offer, it still looked like a neat place was it it was very developer focused. It was a software company. As I said, typically, I was interviewing the other companies were these hardware companies. And they had a software branch. I remember I interviewed at at&t and which was doing the phones phone system. And I think every single person told me about this particular debugging handset they use for something which I'm sure was really cool. But it got a little repetitive. And Microsoft talked to a bunch of different people, and we're all working on different stuff. And, and everybody has their own office, which back then was was considered very progressive. Now, I guess it's, it's needed to have an open space. But all the other companies that open space in cubicles, and Microsoft gave everyone a private office, and that was kind of neat. And just the way the campus looked, again, this is all sort of standard that companies have a campus that looks kind of like a college campus. But Microsoft was doing that way back then. And companies like IBM and Hewlett Packard had these big, large buildings with many floors, stuffed full of engineer. So Mark is a Microsoft just came across this as a much neater, cooler place to work. And it really was focused on developers. So the company was arranged around making developers productive and making their jobs enjoyable. And so it was a great place to be in the 1980s. I still think it's a great place now. But certainly, there's a lot of other companies like that now. But it was somewhat unique back then, and really focusing on on software development.
Tim Bourguignon 6:40
That's, that's fascinating. I love this kind of stories. I'm a child of the 80s. So there was a big before my time. But that's that's fascinating to see how the how this evolved into what what Microsoft became today, with Satya and that allowed him and the new Microsoft were leaving in the in these days. That's, that's very interesting,
Adam Barr 7:00
right? I mean, back then. So Windows NT, which is the first product I really worked on, had, I think, 30 developers, something like that. And so you're one of 30 people working on an operating system. Now, Windows has thousands of developers. And it's a, it's a little more of a, of a process, but you had a lot of freedom, then you owned large areas of software, and you work with a bunch of really smart people. And you could really see the effect when of what you did when Microsoft did a demo at a conference or something. And they demo the networking software, which is what I worked on, I knew that that was my code run, I had written that little component. They were they were using, it wasn't a team of many people who had worked on it was just me owning the low level networking code.
Tim Bourguignon 7:46
That must be an amazing feeling.
Adam Barr 7:49
Well, it's actually nerve wracking, I would watch demos, they, they do a launch or something or some demo, and it's okay, now we're gonna connect over the network. And it didn't always do something that was sort of risky, like, we're connecting over the network from this conference center in San Francisco back to Microsoft's campus in Redmond, Washington. And we're going to use the, the network to do that. And, and I would always sit there with my fingers crossed, like, Oh, I hope this works. We didn't really test this exact scenario. And it actually made me a little stressed. But I can't recall a time that that my code actually blew up during a demo. But back then our quality practices were a little lacking. And, and probably there was a few, a few risks taken during demos. And there were stories of things failing during a demo. And, you know, having to quickly switch to another computer or something because your first computer had crashed.
Tim Bourguignon 8:46
What do you mean exactly by your quality practices were lacking?
Adam Barr 8:49
Well, we, we really tried to write good software. We weren't, we weren't being careless about it. But there was there was a test team. But compared to what's done now, with automated testing, we're very, very limited the amount of automated testing that was done. Just a lot of the coding practices, we didn't write unit tests, people weren't really talking about unit tests then. So things worked in general, because we were smart. And we did work pretty hard and everything but but really, we probably got a little lucky that that more things didn't break because we didn't have any of the any of the real hardcore testing. It's done. Now, I think when when Microsoft had an early, earlier product called land manager, which was the network server that I actually worked on very briefly when I got there before I moved over to Windows NT. And they used to run a stress test on it. That was just a bunch of clients connecting and disconnecting and copying files. And they, their goal was to get the thing to not crash for 24 hours. Just have one server that could run for 24 hours under stress and they actually hit that goal. The day before they shipped before that, they'd always had some problem trying to stress for 24 hours. So, I mean, we got a little better. And over the years, it got more and more solid. And obviously now computers can stay up for a long, long time. But things weren't quite as reliable back dentists, as they are now. Also, they weren't as critical to the infrastructure of the planet, as they are now. So people still bought the software. But it clearly was not as high quality as that, as it is today.
Tim Bourguignon 10:32
Do you? Do you remember how it evolved? Or was this quality slowly came to be?
Adam Barr 10:37
Well, we just I think invested start to invest more and more in better design. So the NT group was fairly focused on quality, I think back when even when I was in the beginning, they they really wanted the software to be very reliable, the goal is to have something that would not crash. But certainly when people start writing unit tests, that helped a lot, because you could detect a lot of problems right away on the developers machine, instead of having to fail in a in a test environment have to go figure out what happened. better investment in automation certainly helps. So rather than having users have to manually stress the, the software, you could do it automatically. But even in fairly early days of Mt, we did have a program, we'd run overnight on our developer machines, which would try to stress the system just by doing random file operations, graphic operations, network operations, and basically, seeing if it crashed, if you if you came in in the morning, and your machine was sitting there with a blue screen, which was your main developer box, you'd have to wait until somebody came by and debugged it, because you wouldn't want to lose that repro case. And if you got a call that somebody else's machine had crash in your code, you had to hustle over there and debug it pretty quickly, because they were sitting there doing nothing holding their machine for you, says a bunch of things. But it was it was just gradually so the system evolved. So it got as it had been around for longer. newer versions, there was a core that was fairly stable. So that just gradually got got better and better. Just from from being worked on over the years and having more and more time for any bugs to to pop up. So it was just a it's just a gradual process. I think a lot of things that people do now, like unit testing is a big one. That's just assumed, I hope that's part of developing, we just really didn't think about we did a lot of reading the code, try to find bugs and stuff like that, which is helpful. But there's there's other practices that can help as well.
Tim Bourguignon 12:41
So you worked on Windows NT, and then on Windows 2000. That's
Adam Barr 12:45
correct, right, I worked on NT the first two versions, three, one and three, five. And then did a couple other things at Microsoft and came back for Windows 2000, which was going to be called Windows NT five, but was was renamed at some point. And then I left Microsoft, just after windows 2000 ships, I worked on XP for about six months, I left I took about three years off, I came back actually as a program manager. So not a developer, but a program manager, which is a job at Microsoft that it's still technical working with programmers, but you're not actually a developer. But I was working on PowerShell, which is a language. So it was in fact a fairly technical program management job. worked on that worked on I was actually instructor inside Microsoft for a while this group called engineering excellence, which did internal training, that I went back to being a regular developer, definitely dev manager on Office for about six years. And and then I left a second time in early 2017. And I think I have to say doing the other jobs being a program manager actually helped a lot with being a good developer because it put you more in contact with the customer. And the consulting training job was may have been the the place where I learned the most about development, just being able to go around the company and see what all these teams were doing and realizing that teams had different practices. And there were better and worse ways to engineer software. And also just having to try to explain things when you're teaching, having to write things down in a format, you can explain them as a good way to collect your thoughts and make sure you actually have a good understanding of what you yourself do when you're writing software. So you can give advice to other people,
Tim Bourguignon 14:25
if you don't mind like to to unpack a bit with what we chose and studying with it was a definition of a program manager at Microsoft. What exactly is this role?
Adam Barr 14:33
So the role is there's generally one program manager per dev lead is usually about the ratio. So one little team of programmers love a program manager. And they're meant to be the connection to the customer. So they typically write the spec, try to reflect the needs of the customer. Of course Microsoft has millions of customers for their software. So it's it's a bit of a balance. It's not just like Pure Scrum where you have one customer, you just figure out what they want and, and implement it. So the programmatic does that they also track, you typically track dependencies on other teams that talk to other program managers for other teams. So the devs can focus on, on the coding and quality. They typically track the schedule. And it's jelly describes, they sort of do what's needed to get the software done, except for the part where you where you write the code and test it. So it's a bit of a filling in the gaps. And it's, it's harder to describe than a developer job because it, it changes a lot based on what team you're on. Microsoft tends to use a title program manager to meet a lot of different things, but the sort of classic program managers this person on the engineering team, but they're not the people doing the coding or testing. So in PowerShell, for example, I was designing language features, this is how the PowerShell language will work. This is the syntax of of this part, without actually then implementing it. But then of course, I'd write a lot of PowerShell code itself, because I had to try out the things in the language. So as I said, that's a pretty technical program management job. I still was writing code. I just wasn't writing the underlying PowerShell code. I was coding in PowerShell.
Tim Bourguignon 16:17
Yeah, make sense? What did you would we would the the most important things you learned in this position that helps you for the for the future?
Adam Barr 16:24
Well, I think what I really learned as a program manager, you mean specifically, yes. I think that that that really made me realize that I think I started programming, I know, I started programming as a kid, because it was just fun. I liked solving problems. And that moment when your code works, is really cool. And I really even go to college, get into Microsoft two beginning, I was working on very low level networking stuff. So it was again, kind of a mental challenge. And being a program manager on PowerShell, we go to conferences, we talk about it, we had early users of the software, it made you realize, oh, wow, you're actually doing this because people want to use it. And they will solve real world problems with it. And it will make their lives better and their their users lives better. And there's a real reason you're doing this not just because it's it's a cool challenge. And I think that's very useful for developers to realize that there's actually a point to this. It's not just, it's not just for fun. And also to realize, I think developers sometimes have an attitude about users that they're maybe not as smart as developers, if they can't figure out how to use the software, well, that's their problem. They should just all be developers, but for a lot of customers, while they're not programmers, and if the software is confusing, it's not their fault, it means the software is badly designed. So being a program manager is really good for establishing that customer connection and realizing that there is a point for this and, and you're not just doing it, because because you like solving the technical challenges, I think that was very helpful. And I would actually say, if if any program has a chance to do a job like that, something that connects them directly to customers and see how they're actually using the software, it's actually quite valuable. Even if you just go back to being a developer to have made that connection with customers,
Tim Bourguignon 18:11
using going back and forth like a pin loom, would be a good idea.
Adam Barr 18:15
Well, career wise, I think it's good to eventually focus on one or the other, it's good to sort of become an expert in one job function, whether it's programming or testing or program management. But I think it's good to bounce back and forth. A little bit beginning Microsoft, when they hired program managers it was it was the exact same people that they would hire as developers. So it was people with CS degrees, experience using computers, they they wanted program managers, in general, who were programmers who could write code, even if they didn't wind up doing that. So they understand the technical aspects of what the developers were talking about. So I think it is useful to, to try out one and the other early in your career, you could try being a tester as well, that would also be valuable experience. But from a career perspective, it's probably better at some point, like I said, to focus on something and, and and build up the deeper skill in that area.
Tim Bourguignon 19:07
And let's go over to the to the engineering excellence, part of your of your career, if you don't mind. You're all there was to do some kind of internal teaching.
Adam Barr 19:18
Right? Right. So we actually there actually was a developer excellence team, which I worked on, there was a program management excellence team, a test excellence team, UX excellence, a couple others. That's user experience, the designers of the actual UI. And the interesting part was it made me realize that a lot of what I thought about programming was just things that had worked for me in the past and I hadn't really examine deeply whether I was doing things the right way. I mean, when I started programming, on IBM PC, basic, basic is really it turns out kind of a terrible language for writing large scale software, but I always was pretty competent in it. And I wrote a few games. And then I got to college, I was like, Hey, this is great. I'm a programmer. And even at the beginning of Microsoft, I was essentially using the same skills, and just get my code to work. And really work in engineering excellence made me realize, oh, wow, there's a lot of other ways to write code. And smart people are doing things, different ways. And some of my assumptions about what the best way to write code are documented, or the right way to test it were just what I had been successful with. But it didn't mean they were the best way. And look at around Microsoft. And as I said, having to explain in class how to do something which requires you to have some justification of why you're telling people to do this really forced me to re examine, re examine some of those assumptions, I've been making it and in a way led to my most recent book, The problem was software, because I realized, while everybody else is also kind of just working on their own assumptions based on their experience, which hasn't really been formally tested in any empirical way, and they're probably doing some good stuff and some bad stuff. Also, and this is sort of a general problem with software, you got a bunch of people who are figuring out as they go along, rather than relying on on codify dollars the way you'd expect from a job that calls itself engineering. And that's really what I talked about is that, in the problem of software is is how a lot of these things are really more like things. We believe that rather than things that have been scientifically proven,
Tim Bourguignon 21:37
very much, so it's very true. And we're still in the infancy of, of our craft, I think there's a lot to discover.
Adam Barr 21:45
Yeah, we are early on. I mean, if we compare it to, in fact, I draw an analogy with, with airplane design. If Orville Wright were still around, managing a software company, he probably look at certain things suspiciously. Maybe it's saying that, oh, I don't know, if aluminum aircraft bodies are a good idea. If jet engines are a good idea. He, he'd looked back in the day when everybody could build an entire airplane themselves. And we boost out a little bit of that now, because software has happened so fast. Really, in the last 3040 years, basically, everything's been replaced that you got a lot of people who grew up in this more the early days of software and still have some opinions about how to write software that are that are that are probably obsolete at this point. But they've never had a reason to have to re examine them. So I think the comparison with with aviation is interesting. But But aviation has been around for over 100 years. So it's had time to work out some of these these problems and figuring out what's actually science and what's just, you know, kind of magic or craftsmanship or whatever you want to call it, but but not really engineering. And of course, recently we've had this problem, if you follow the the Boeing max plane problem, we essentially had an airplane company that worked in this very formal engineering process, kind of running into software, which was a little more loosey goosey. And unfortunately, the software attitude seems to have won out. In this one case, very tragically, where they really just didn't do the, the formal engineering you should have done. And, you know, I'm not sure exactly what happened. But, but clearly, for situations like that, you need to adopt more of the the airplane company attitude and not the software, company attitude, because people's lives are at stake.
Tim Bourguignon 23:38
Using we're headed for more problems of that kind before it gets better.
Adam Barr 23:43
I think we are I mean, you think about self driving cars and the amount of control they have over people's lives. Even just basic security things now that cars have all this software in them, you read about cars that can be you can use the Bluetooth stack in the car as an exploit. And then because people haven't been careful about separating out the different systems on a car, you can tunnel through there and actually control the the steering wheel or the or the accelerator because now cars have that under software control for certain situations, they they want to be able to apply the brake in an emergency let's say or, or wiggle the steering wheel if they think you're leaving the lane. But that means that now the steering wheel and the other controls are under software control. And if you can brake in over some wireless network, you can control the car. So there's all these situations like that, that are using software in an environment that it wasn't really designed for and probably isn't secure enough and reliable enough to really work it out environment but people are running ahead, trying to make self driving cars because there's a lot of interesting applications but hopefully they'll slow down a bit and focus a little bit more on on the engineering aspects.
Tim Bourguignon 24:59
I remember Robert Martin, Uncle Bob, say something like five or six years ago, already talking about this and saying I something like that I have to paraphrase. I'm not sure exactly what he said, but we like, let's hope that we managed to organize ourselves. Before we have a major failure and the government's step in to organize us. I, I kind of hope we're gonna not gonna go this way. But I wouldn't know where to start to organize or industry into a more mature engineering practice that would say,
Adam Barr 25:36
yeah, that's that's part of the problem with software is there's what what's taught in schools for software engineers is not what's taught in schools for civil engineers and aviation engineers, where it's based on empirical studies and years of experiments and trying out what works and doesn't work. So if we said, as some people have said, we should certify software engineers, we need licensing, we need to have this body of knowledge and these known good practices, and that will help. Yeah, you wouldn't know where to start. Because it would just be different people saying, Oh, no, no, this is the way you do it. And somebody else saying, Oh, no, no, you're wrong. This is the way it works. And really, they're just explaining what's worked for them and their particular environments. And, and nobody can say, okay, when you're doing software for a car, you need to focus on this, and this and that, and, and these languages are good. And these languages are bad language choice is something that I, I talked about also in the book that people still there's still people running around saying that c++ is a good language. And I mean, I know there's not a lot of empirical knowledge, there's not a lot of statements in software you can make with 100% confidence. But I am 99.99% confident that at this point, c++ is a terrible language. And nothing should be written in c++, except in very, very specific situations. But there's still people going out there saying, Oh, no, c++ is great. And at the time, it was great in the late 80s. It was it was brilliant. It was a breakthrough. It's what caused object oriented software to happen. But that was a long time ago. And, you know, the Wright brothers plane was also a breakthrough. But we've, we've kind of moved past that now. And we should sort of move past c++ as well. But you've got a bunch of people who, who know it and are comfortable with it. And they're out there talking about how it's a good thing. So yeah, it's a it's a tricky situation, because we need some, we need some some knowledge in a hurry. And unfortunately, knowledge takes a while to acquire. This is where you're telling me that c++ is your favorite language and all that but yeah, sorry,
Tim Bourguignon 27:34
don't worry, I've done my fair share of c++, but I'm happy. It's it's, it's behind me. I actually switch gears a bit. And I'm more in the on the people side of engineering now. So I haven't coded much in the last years, I'm actually more and more playing with the no coding tools more and more and trying to push those in as much as I can and try and try to see if I can produce some some some products that really qualify as products with without writing any line of code. This is the kind of challenges I take myself right now. So don't work.
Adam Barr 28:15
For I'm a software consultant and author. So I haven't written any code. I haven't earned my living writing code for a couple years. Anyway, I've I play around with software to learn new things. But I haven't coded for money recently, either.
Tim Bourguignon 28:30
And I wanted to ask you, your first book was Proudly serving my corporate masters, right? Yes,
Adam Barr 28:37
yeah. So that was actually about the time. I worked at Microsoft in two, two times that the first 10 years, then another, another 13 years. And so that's about the first 10 years, I was just sort of by random observations about work at Microsoft, I talked a bit about hiring, how hiring even still, then certainly when I interviewed I sort of random and why do we ask these brain teaser questions? I talk a bit about sort of how software is developed, it was probably just explained, this is what's going on inside the sausage factory. There are some issues with quality, you know, some Microsoft stories. So it's just sort of my you know, the summary of that. And I mean, the book came out almost 20 years ago, but I think it's I think it's still interesting that you know, a lot. Unfortunately, things haven't changed as much as you might hope. Since back then. So a lot of it's still relevant. I even talked about Linux, even back then Linux was a competitor to to Windows and what was Microsoft, Microsoft going to do about Linux and a bit about why open source? There's no reason open source couldn't be just as good as, as a software made by a closed source company. And I guess in that case, it seems that Microsoft has finally completely embraced Linux. And so that was demonstrated to be correct.
Tim Bourguignon 29:55
How was it to write a book that is actually pretty I said not critical. But But yeah, I still still don't have the English word for this. Going against maybe what Microsoft had been doing for the last 10 years, saying saying the hard truth that shouldn't maybe be told. And in publishing this as a book. Did you have any any any second thoughts about this?
Adam Barr 30:25
I might have every second thoughts I was I wasn't directly criticizing people there, there's a couple people that maybe came across in a slightly negative light that I actually talked to ahead of time. Just to make sure they, they didn't think I'd really miss represented them. But no, I think I've talked about Microsoft actually have had people who contacted me and said, I liked your book, it got me interested in working there. I think it's better to talk about things and suggest improvements, rather than just assume that the way things are is is the way they should be. And I never got, certainly when I went back to Microsoft, I never had people say, Oh, I can't believe you're the guy that was there was criticizing Microsoft. When I interviewed, nobody said, oh, we're not going to hire you because of this book he wrote, that's partly because I don't think they'd be like, organized enough to make that connection necessarily. But see, I think it I think it's, it's good. Even the current book, I mean, problem is software. Again, I'm, I'm, in a way critical of certain things, but but not directly of individual people, maybe individual programming languages, but not individual people. And I think what I'm saying deserves to be heard. So and I'm happy to, to defend it if asked. So yeah, I mean, you know, I think it's, it's a, you write something you might offend somebody, but that maybe that's a good sign, it means you're actually saying something that requires them to think a bit about what they believe. Absolutely, that's true. That's true.
Tim Bourguignon 32:01
Let's go back to your to your last book for a minute. Who did you write it? For? Who did you in mind when you wrote it?
Adam Barr 32:08
Well, it's sort of two audiences. One is one is actual developers, I hope programmers read it and reflect a bit and think a bit about that, what they think about software development, and maybe get a little, a little humility. Certainly people coming right out of college to recognize it. Yes, you have a CS degree, but there's a lot to learn about working in industry, and those things that you find annoying, like doing code reviews, and, and having a you have to wait a bit to deploy your code until the QA team finishes that sort of thing. Those are actually good, not not just annoying. So So developers, but also I think if there's people who are, who are non technical, and are willing to read the book, I do have some code examples, some very brief code examples in there. Because I think it's important to understand exactly why c++ has problems, for example. Rather than try to just use analogies, I try to show the real code but somebody who's non technical, but is willing to invest a bit and understanding it, it's meant to be readable by a non programmer. So somebody who's just curious about software, and why are there bugs? And I described the book as it is software really hard, or are programmers just not that good at it? So somebody who's curious about that question, as a non programmer, I think we'd get a lot out of it to to understand what's going on, and recognize that, in fact, programmers are fairly smart. But they also could do a better job of engineering software. It's not just one or the other.
Tim Bourguignon 33:37
Do you have a secret hope for the book call success metric for yourself?
Adam Barr 33:41
Yes, my secret help, which I'm so far, not quite achieving is now really that then it starts to get recognized as sort of one of the, you know, this is a book you should read, like, you know, the practical pragmatic programmer kind of books where it's like, Hey, if you're a programmer, you should probably read this at some point. It's a long way from that, but but just yeah, it's got its gets recognized as sort of a valuable contribution to the writing about software and, and maybe then a couple universities, a couple of computer science programs, people read it and start to think more about, hey, how can we sync up more with industry? How can we focus more on large scale software development instead of just small scale software development that you typically do in a class because because they're very different, and maybe do more empirical studies actually studying programmers, things like commenting and variable names and code formatting, which seemed kind of simple, but even those are, are debated over endlessly these days and try to get some answers on that stuff. There was there were actually studies people are starting to study that back in the 70s. Back when you needed to have a mainframe computer or some large computer to program so typically, it was done by large companies and because that's who had the hardware and they were interested in applying engineer learning processes to it. So people started studying that. And then basically what happened was the personal computer came along, everyone could program on their own, they didn't need to be at a large company, they were just messing around with it. I'm as guilty of this as anyone. And they essentially ignored all that and started writing code in whatever style works for them. And they weren't worried about maintainability, because it was just their own personal code. And then, you know, they just got it working. And that's kind of the boat I was working in at first. And they were using languages like basic, which really weren't that suited for large scale development. So unfortunately, a lot of that got lost. And one of the hopes of my book, I do talk a lot about empirical studies. Most of the books I quote, are, are 30 or 40 years old, because it's the same things that are going on now. And hopefully, there'll be a little appreciation of the history of software and that we should start studying this stuff again.
Tim Bourguignon 35:57
Oh, yes, we should. I've seen a talk a couple of weeks ago from from a German speaker. And he picked only papers from the 60s and swept some words in there. So papers about about system design, and how to to avoid redundancy and stuff like this. And then swept words with with microservices and and Clintonite containers and stuff like this. And the papers are so actual, we're solving exactly the same problem that were sold four years ago, 50 years ago. Yep.
Adam Barr 36:35
Oh, yeah. Yeah, I mean, IBM, back in the 60s, I mean, of course, the sophomores was smaller, in general, that the tools are worse languages are worse. But I mean, in terms of the human element, and how you management, how you manage it, how you coordinate between teams, things like that, how you ensure quality, for whatever level of quality your customers want, it's all the same stuff. So yeah, and I mean, even when I went to school in the 80s, and these books were fairly recent, the PC revolution that just happened, we didn't study that stuff in school, either. We just kind of hacked away on our programs, and maybe studied algorithms, but nothing about all the other stuff about quality and, and scalability and working in teams and all that stuff. And so we've, you know, computer science has forgotten more about, about how to engineer software, then, you know, that people learn nowadays, unfortunately,
Tim Bourguignon 37:31
you probably have countless advices in your book. And if you could be one advice to give to, to students coming just out of their of their universities, or the or the boot camps or trying to you to enter the market? Which is one advice out of your book, would that be?
Adam Barr 37:49
Well, of course, I'd have to buy the book first. So that would obviously be the the zero advice. No, I think I think it's too It's too, I think I mentioned it earlier, just just be a little, a little humble and recognize that the the things that seem to be slowing you down, compared to the the Happy Days of programming, and college or, or programming on your own were just seemed like fun. And you don't have to worry about about testing and all that stuff. Those are actually good things. And they're there things you should learn and do and not just complain about. Certainly, as I did, the first time I did a code review. When I was at Microsoft, and I had never done a code review before. Even my small company I work for didn't do code reviews. The first time I did a code review, I thought it was just the most ridiculous thing and what a waste of time. And, you know, I'm a genius coder, who could find a bug but, but I quickly realized that they were useful. And it was so that that would be my advice is is that the process is that that seemed like it's taking the fun out of writing software are actually useful. And you should, you know, buy into them. When you when you start working in industry.
Tim Bourguignon 39:03
Fantastic. Fantastic. And then your book is to be found in every bookstore already. I would say online Barnes and Nobles in the US and etc.
Adam Barr 39:13
Yep, yep. amazon.com it's published by MIT Press. So I've seen it in some bookstores in the Seattle area, but it's certainly available online I think pretty much anywhere you can you can buy books online,
Tim Bourguignon 39:25
and where should the the listeners reach out to you if they want to continue this discussion with you?
Adam Barr 39:31
Well, I'm on Twitter. I'm trying to focus my social media presence such as soon as on Twitter so it's it's Adam David bar it's just my full name spelled out So Adam bar with middle name David, no spaces, dashes bogus kind of spaces in a Twitter handle but no dashes or dots or anything just Adam David bar run together and you can you can work on increasing my my massive Twitter follower count, hopefully in two Uh, into four digits at some point so But yeah, I blog there I, I talk about various I'm a blogger I tweet there I, I talk about various things related to software so I try to highlight empirical studies when I can find them. I'm a little bit obsessed with the Boeing M. CASS software problems. I tweet about that a fair bit and whatever other topics I I find it interesting.
Tim Bourguignon 40:24
And do you have anything on your plate coming up in next weeks or months where people should? No,
Adam Barr 40:31
no, no, no, no presentations. I've been trying to work the software presentation, you know, the software conference, circuit to get some talk at some conferences. I've actually been slacking a bit on, on sending in proposals. So I need to get that going. But yeah, nothing, nothing. Nothing planned right now. Okay, cool. But if you're if you're somebody organizes a conference, and you want somebody to talk about software engineering and a little historical context and explain why containerization is actually a great idea. You know, I, I may be your guy so, so get a hold of me,
Tim Bourguignon 41:04
and then know where to reach out to you. Well, and I'm Fantastic. Thank you very much for this fantastic story. Yes. Thank you very much for having me. It was our pleasure. And this has been another episode of developer's journey. And we'll see each other next week. Bye bye.
Dear listener, if you haven't subscribed yet, you can find this podcast in iTunes, Google music, Stitcher, Spotify, and much more, head over to www dot journey dot info. To read the show notes, find all the links mentioned during the episode. And of course, links to the podcast on all these platforms. Don't miss the next developer's journey story by subscribing to the podcast with the app of your choice right now. And if you like what we do, please rate the podcast, write a comment on those platforms, and promote the podcast and social media. This really helps fellow developers discover the podcast and those fantastic journeys. Thank you