I thought this book would already have been written by someone and I wanted to see this book so that I could use it as material for an article. In my mind, I was going to write a 250 page book. So, for the first time, I thought since I'd never published anything, I should probably make it look like I knew what I was doing. And so, I created a detailed plan for the book and estimated the page count of the book and it came out to be 900 pages.

Code Complete is a single bus book on code construction which includes coding, debugging, detailed design, testing, and many more topics. It's also the most detailed one with an impressive 900 pages. The second edition of the book was published in 2004 and 20 years later the book remains a bestseller in software engineering. I sat down with the author of the book, Steve McConnell in Seattle.

In this episode, we get into the history of writing code complete and how the publisher did not expect the book to sell well. The difference between software construction and coding. Steve's mental model of career development for software engineers and why he considers the concept of lily pad hopping harmful. The impact of AI on software engineering topics that Steve left out of code complete but now talks about in-depth and many more. Steve rarely gives interviews so I hope you enjoy this special one.

So, you wrote this book, Code Completed, and I'm going to show it here. I was amazed when I first got my hands on the physical version on how long it is, how extensive it is and and how thorough it is. And the other big surprise I had, I assume that whoever wrote this must have been a really seasoned tech professional, you know, working 10, 20, probably 30 or 40 years, but I learned that you wrote this somewhat early career. How did you write it? And why did you even come up with the idea of writing such a massive and extensive book?

So I didn't start out to write a book. I started out to write an article and I'd never published anything. And so I thought uh I I'd wanted to I'd wanted to write and I thought about writing all different kinds of things and I was active as a programmer so I thought write about what you know and uh so I started doing research. I'm a good researcher which is funny in today's context but back then that involved going to a research library and looking through a card catalog and requesting materials through inter library loan. I mean it's quite a different process and uh and so there was actually some skill involved in that.

So basically I thought I thought this book would already have been written by someone and I wanted to see this book so that I could use it as material for an article and uh so I I basically just started doing research and after reading about I think I read about 80 articles and a handful of books I convinced myself that this book didn't exist and this was just baffling to me because there were books on requirements design testing project management But there wasn't a book on the main thing that programmers do, which is software construction.

And so I just kind of shifted gears and I I didn't set out to write a 900page book, which was the first edition. I I I thought, you know, it's funny because in my mind, I was going to write a 250 page book because all the other books I'd read in that space had been 250 to 350 pages. And so I did background research. I wrote a couple sample chapters. I got ready to submit my proposal to the publisher. And at this point, I only had two chapters written.

And so the f for the first time, I thought since I'd never published anything, I should probably make it look like I knew what I was doing. And so I created a detailed plan for the book and for the first time uh estimated the page count of the book. And it came out to be 900 pages. And I thought that can't possibly be right. I'm not writing a 900page book. I'm writing a 250 page book.

And so I estimated it a different way and I came up with something like 875 pages. So I thought, okay, I think I'm writing a 900page book. I think the thing about that is that if I had thought a year earlier that it was going to be 900 pages, it never would have occurred to me to even try and uh but by that time I was too far into it. I was mentally and emotionally committed and so I decided to just go ahead and do it.

and just help us imagine what stage of your career were you, you know, like in terms of work experience, college, those kind of things.

So, I was about 5 years out uh 5 years out uh of college at that point. Uh I'd been programming professionally for you could call it six years I guess because I took some time off in the middle of college. I actually think that was the perfect time to write the book because I think it's really important in writing a book to have a really clear sense of the target audience. And for me, my target audience was me 5 years earlier. And it was recent enough that I could still remember where I was 5 years earlier and what I didn't know 5 years earlier. I think for somebody who was 20 or 30 years into their career, it'd be really hard to know. Plus, you'd just be out of date in terms of what you needed to know.

after the book came out, what was the impact of it? Do you remember like initially and then a couple years later?

Yeah. The um so the book came out and it started to get really good reviews and at that time the reviews of course were in magazines which people got in the mail on paper. This is pre Amazon. they trickled in way pre- Amazon and uh and so the reviews were great and I attended a book signing here in Belleview and one of the people from Microsoft Press came in and said uh said, "Oh, this is our sleeper uh book." And uh I learned that they never expected it to actually sell very well. That they decided to publish it because they thought it would be good for the catalog to have a more scholarly uh in-depth book, but they they assumed it wouldn't really sell very well. So uh the sales have been a nice surprise for everybody.

You you must have learned about a a really interesting inspiration the book had on the block called Coding Horror.

Huh. I don't remember exactly when it was. It was I don't remember 2005 somewhere in there. Something like that by by Jeff Affwood. He he he started the blog or he re renamed it. I'm not sure. I think he conceived it from the beginning as coding horror. And he reached out to me and said, "Hey, I'm writing this blog. I want to call it coding horror. Can I have permission to use the coding horror icon from your book?" And I was like, "Yeah, sure." And I think he sent me a t-shirt or something with the coding horror uh image on it. And of course his blog did did really really well and uh you know led led to a lot of good things for him and I think had a positive impact on the world too.

I think at some point it might have been the most popular developer blog. He published about something like 100,000 requests per day. I was reading it. So what when I was early career I read coding horror almost like every day or like you know every other day he published an article and then of course that led to stack overflow or or that helped him meet people Joel and and others and that led to Stack Overflow. So it's just kind of incredible how indirectly obviously but you know your book inspired someone else to to start a blog which inspired or or helped create this very special size Stack Overflow which Stack Overflow obviously now has has helped train some of the AI agents. So like it's just all trickling all down.

Yeah. Well, I think uh you know, I don't know that I believe in karma literally, but I definitely believe in the general idea that if you put out good things into the world that there are positive ripple effects and you never know what exactly is going to happen, but probably more good things than bad will happen. And so it sounds like that's part of what happened with that.

And so the book is on the concept called software construction. And and you know, you kind of start the book, I'll I'll quote a little bit from it. You you say at at one time software development and coding were thought to be one and the same but as distinct activities in the software development life cycle have been identified some of the best spines in the field has spent time analyzing and debating methods of project management requirement design and testing they rush to study these identified but it left code construction as the ignorant cousin of software development. I wanted to ask what is code construction? And I mean the book is about code construction but I think it helps us uh recap of and and how it's different to let's say software development or how it's similar to it.

Yeah, I was pretty deliberate in the book in trying to capture the space of software construction and and a space that's distinct from writing code uh or not distinct from but is not the same as as writing code. Uh I think that the idea of just jumping in and coding is something that maybe you do when you're first learning how to program. Uh but as you get a little bit more advanced, I think there's a level of intermediate thought that includes thinking about how you're going to test what you're writing, thinking about how you're going to design in the details what you're writing, actually doing the coding and then the full set the universe of topics that come to bear on the actual code itself, the readability and the uh all aspects of readability.

I think that that uh much of the literature before I wrote code complete there there were a couple things out there that were decent things on coding style uh but that was kind of it. It was coding style. It wasn't really about you know we had we had books on software design but the software design really stopped short of the level of design thinking that you would get into at uh what would have been at one time the the routine level and then later was really the class level. And it just seemed to me like there was just a lot of thought that wasn't necessarily guided or or necessarily taking place in terms of thinking about the uh activities that are adjacent to coding but not quite big enough to qualify for a book or a name of their own.

I would probably make it a little narrower than what you just described. Uh I think that some of what you just described I would probably characterize as a higher level design. uh and uh but on any given project depending on how the project evolves or how it emerges the design level of thing it could happen at the beginning or it could happen incrementally as you go it could happen by somebody who is good at that kind of thinking or it could happen by the people who are actually doing the implementation

I think one of my learnings over the years and I didn't really understand this when I wrote the first edition of code complete is really that different people's brain brains work differently and some people really are capable of thinking about design abstractly and then implementing the design and some people are really good at just writing the code and learning the lessons in the small and then building up from that and some people are good at both but I don't think a lot of people are actually good at both I think much more commonly you find people who are good at one or the other

and then I think there's often a disconnect between the people who have ability in one area and not the other. And I've seen cases where people think that it's just not possible to work the other way because they're not able to do it and they just can't imagine that somebody else could be able to work that way and yet we've got all kinds of instance proofs of people working in both ways and having it work out fine.

And then the two ways are like so just I understand is is one of like could you just spell out again the the two different ways of of working?

You could think of it generally as top down versus bottom up. Mhm. Uh so you could think of it at word inductive versus deductive. Um I believe that most most programmers meaning the majority not like 99% but you know 51% or maybe 70%. I believe most programmers are pretty detail- oriented. And so I made a conscious design decision as I was writing code complete that I would write the book inductively. I wouldn't start out making a bunch of general statements and then demonstrate the specifics. I would start out talking about a lot of specifics and then build up to the general statements at the end. I just felt like more programmers than not were more oriented that direction. But what I didn't appreciate at the time I was writing that was how big the disconnect was and the idea that I think a lot of people just aren't capable of operating the other direction, whichever the other direction is.

Yeah, there's a great paper, really old paper by Dave Parnes called the irrational design process, how and why to fake it. And the the gist of the p so this paper is from I think the mid70s. I don't remember exactly. It was a really old paper, but the gist of the paper is that design is a sloppy process and nobody gets it right. It's not linear. You don't start out and march your way in a straight line toward getting a good design. And so number one, the paper sort of gave permission to experiment, try stuff, make mistakes, learn from the mistakes, iterate.

But then then the paper also says the how the how and why to fake it part was at the end of that you describe what you did. And the description is not necessarily going to show you all of the mistakes and dead ends and so on. So it's going to look like it was a more rational process than it was. But um so I think both halves of that paper are are worth keeping in mind and it sounds like your experience would kind of bear that out that it's not even really possible to get it right the first time in most cases.

I think it was John Alistster Sterhout who in in his book on software design a Philadelphia software design his suggestion was design it twice because the second time you'll get a better design than the first time. These are just things that some people might still do but

I would say three times but yeah and I'm serious about that. So when I was at Microsoft there was a programmer inside Microsoft who was famous at the time who was well known for rewriting everything three times. And the basic gist of it was if he had two weeks to do an assignment, he would spend the first six days coding and making all kinds of mistakes and not doing it very well. And then he just throw it out and spend the next three days rewriting it. And by that time, he would be applying all the lessons he's learned. Then he'd spend the last day or day and a half writing a third version and it would be perfect.

And you know, if you think about your own experience, if you've ever, you know, this should never happen in theory, but it still happens where you've done a bunch of work and somehow you lose it. It gets deleted. You have a backup, whatever, right? Should never happen, but sometimes it does. And you think, "Oh, this is awful. I just spent a whole day working on this. It's going to take me forever." And then you rewrite it in 45 minutes. And as you go, you remember all the lessons that you learned and all the stuff you wish you'd done the first time. It actually turns out probably better than if you'd never lost it in the first place and had to keep what you wrote initially.

So your your career path uh we know that you wrote this book early career. What what was your professional development story up to the book and then after the book? What what happened after?

Basically up to the book I had worked for a small insurance consulting company. I'd worked for a large briefly for a large insurance company. I had worked at Boeing on a defense project. I'd worked at a startup mode uh for company that was kind of doing a just a startup uh shrink wrap product. And then I was about to start working on the book full-time and I got an offer to go to Microsoft just initially for a summer and I thought h at the time Microsoft was the hot tech company and so I thought yeah if I get a chance to see what's going on inside Microsoft I should do that it'll make my book better. So I ended up being at Microsoft for a year. That was essentially my background. I'd also done I always had some kind of startup project of my own going throughout that that period. uh and you know I put a put a lot of time into those as well.

I had started out being kind of interested in programming but not super interested in it uh notwithstanding the fact that I seem to spend a lot of my essentially hobby time on it anyway. Uh and so I started out just kind of thinking I wasn't really sure if I wanted to do this as a job. And then I thought well but I had a little bit of an entrepreneurial streak so I kept doing startup stuff in that mode. Uh, and I at some point in there I kind of switched over from thinking I don't know if I really want to do this as a job to thinking if I'm going to do this as a job I probably ought to figure out what I'm doing.

And I I think at the time for the first couple years I had a little bit of imposttor syndrome because I didn't have a degree in computer science. I didn't know at the time that Oh, really? Oh, well, of course this was What was your degree in in philosophy? Yeah, I had minors in math and computer science, but uh but at the time less than half the people working in the field had degrees in computer science. That didn't change uh for a long time. Uh so I but I didn't realize that I that that was common. I thought that was unusual. So I I started trying to develop or acquire some skills so that I could basically be more more professional.

And then I got inside Microsoft and I thought, okay, I'm finally going to see what real professional programming looks like, the best of the industry, right? Like Microsoft back then was a bit like what Open AI is now or Google in like 200 I don't know four. It it was just the 800 lb gorilla and there was nothing else even close at the time and uh I don't know what percentage of all software share of the all market software share they had but it had to be a pretty high percentage. This was around the peak right around the wi windows and doss and and that era, right?

So I got inside Microsoft and what I discovered was number one the people were really really smart. So that was a factor. Uh and number two, you had like one person working on the printer device driver for one specific printer. And so the difference between that and my experience was my experience up to that point had been you're working for a company and you've got responsibility for figuring out how to get things to print, figuring out how to load and save files, figuring out how to display stuff on the screen. And it's like, oh, I've got like a whole person, not just on printing, but on printing to one device. So, I mean, that was a lot of it. It's just the the projects were broken down into much much smaller pieces and so people could put a lot more time into it. And then, yeah, they were really really bright. But qualitatively in terms of programming practices, you know, there wasn't really anything different than what I'd already seen.

At the time I wrote code complete, I was still trying to decide if I really wanted to be a programmer at all. And uh if you can believe that and uh and so I'd spent I spent a year full-time writing code complete but I'd spent two years doing background research before I spent the year full-time. I did. I took a year a year off. Yeah, I really wanted to write the book. That was uh that was the main thing I wanted to do by then. And uh and I knew it was a big project because by then I'd figured out it was 900 pages.

And at the end of that, uh number one, it was a terrific experience. At the time, I thought I felt like I'd gotten three years of experience in one year by writing the book. I I would I would say I learned so much more about what I was doing just through the process of the the the writing is only not not the main part of it. The thinking about what I wanted to write was the main part of it. But then I went back into hands-on programming role and I felt like, oh, this is great. you know, I like the writing, but I'm so glad I'm doing hands-on programming again because I was kind of sick of the writing at that point.

By the time I published Code Complete, I was convinced I was never going to write another book. And uh because the end phase of that was just painful and uh so then I worked for a couple years and the memory of the pain faded and uh I was kind of getting an itch to write something again. And so then I wrote my second book, Rapid Development. And I kept thinking, I was going back and forth. I kept thinking, do I like writing better? Do I like programming better? I kind of liked whatever I was doing at the time better. It took me a while. Eventually, I realized I liked the back and forth. I like the variety. Um, but not the variety on a day-to-day, week to week, month-to-month basis. I liked having big blocks of time to concentrate, dive in, go really deep.

So before I wrote rapid development at that point I was starting to think all right yeah I think this programming thing might be a good direction for me and maybe I am a little committed to the career and so I I started to think about where do I think my career should go and what do I want to do and so I have no idea how I came up with the idea but I created what I thought of as the career pyramid

and I just I kind of organized the the software for universe into the base of the pyramid was all programmers like 100% of the programmers and my focus was on us and then the second level up was programmers who had maybe actually gotten a degree in programming which I had not and then the next level up was maybe advanced degree in programming or maybe written some magazine articles or were in a lead or manager position and so anyway the pyramid kind of went up to where there were just a very small number of people at the top who had a essentially a lif lifetime of significant contributions to the field.

And so I thought, okay, just in terms of setting a direction, I'll just aim for the top of the pyramid. And it wasn't so much because I thought I wanted to get to the top of the pyramid. It was just more to have a point on the horizon that I could I could move toward. And uh and so I used that partly to guide what I did on the second book because I had a variety of books I I was interested in writing. And uh the the book that would have made the most sense after code complete would have been design complete. Uh I could have written it at the time but I felt like I would get pigeonholed as just pure tech guy if I did that.

The other book I really wanted to write was performance optimization in Windows. Uh, which was a fun topic, but again it was a little bit too, you know, a little bit too uh, bits and bites. And so I decided to hop over and write something that was a little bit more management oriented. And uh, because I wanted to kind of triangulate on the top of the pyramid

as as as part of this you you mentioned again in this talk you mentioned the concept of lily pad hopping. What is that and and how did you apply it to your career?

Well, I think that the pyramid was in essence uh the antidote to lily pad hopping. And what I had noticed, I noticed it a lot more later, but even at the time, I'd realized that programming didn't really feel like a career. It felt like a job. And the reason it felt like a a job rather than a career was I didn't get the sense that it was going anywhere. I saw people who'd work on one project and they'd work on the next project, then they'd work on the next project. That's the lily pad hopping part. But it didn't add up to anything. It was just different. It was kind of like difference for the sake of difference.

And you know, they're probably learning things. They're learning a new business area. They're learning new technology. Uh, and you know, maybe that's interesting and stimulating. And there's some definitely some personal growth that goes on there. But I always felt like if I'm going to put the effort into learning something and growing, I'd like it to to add up. I'd like it to accumulate. I don't want it to just be a bunch of different things that are all the same in a way. I really want it to be essentially more than the sum of the parts.

And uh so part of the reason for me coming up with the pyramid in the first place was really just trying to think about okay, how do I get past this idea of I've worked on this project, I've worked on that project, I know a lot more stuff now than I used to, but I'm no more marketable. I'm really no more valuable. I don't have the ability to really contribute on any individual project or organization more than I used to have. So, how do I essentially build my skills in such a way that I become increasingly valuable as time goes by? You know, you're going to put in the same effort either either way. And so, it's almost back to the design question where it's like, if I'm going to put in this much effort, I can either have it add up to this or I can have it add up to that where that is a lot more than this. if I put some thought into it. So

I think that's right. I think uh you know there's the there's saying that most people live in a box that they build for themselves. And uh and then Larry Constantine, who's one of the founders of structure design, if that term even means anything, had a saying that I like, which he says, "Nobody needs to give you permission to do your job well." And and the correlary to that is your managers already think that you're going to do whatever needs to be done to do your job well. They they assume that you believe that you have permission to do it. Meanwhile, on the ground, a lot of people live in that box they built for themselves and they think, "Oh, I got to do this the same way that they did it last time." There's no reason they think that. It's just I guess it's human nature for people to just kind of constrain themselves that way.

So I think you're absolutely right that in the vast majority of software jobs that I've ever been aware of, people can design a lot of their own job or their own day-to-day work in such a way that they can learn a lot and grow a lot in a in a more strategic way.

my first summer job that I got paid for programming as an internship and uh I basically finished all the work they had for me halfway through the summer. So, they had to make up stuff for me to do. And my boss gave me the assignment. He just handed me a box of floppy discets. You have to put up a picture so people know what those are. Oh. And and he said, "I want you to do something useful with this box of discets." And my response was, "Well, what do you want me to do?" and he said, "I don't know what I want you to do. Part of your job is to figure out what I should want you to do. So, you take this away and, you know, do something useful with it."

And at the time, I was incredibly frustrated. I felt like the boss wasn't delegating anything to me. He wasn't giving me clear direction. I really felt like he'd sort of abdicated his responsibilities as a boss. But as the years went by and certainly by the time I started my own company, that was basically the model for 99% of my day, which is nobody nobody when you're the owner of your company tells you what the next most useful thing to do is. You got to figure that out. In fact, it's really mainly your job to be the one who's looking at the whole landscape and saying, "What do I do next? What's the next most useful thing to do?"

So, yeah, I I completely uh agree with that and identify with it. And it's funny how as a junior person, you can feel like the ambiguity in that assignment is a real liability, but really that's incredibly valuable training for what you deal with as you get into higher positions of responsibility. And when I say responsibility, I'm not just talking about for people. I'm talking about product direction, health of the organization, uh, all kinds of stuff

Well, what comes to my mind when you say that is I think companies go through uh maturing process. When I say maturing in this case, I'm not even saying more mature is better than less mature. Sometimes less mature is better, but you have certain personalities that work well in startup mode and you have other personalities that work better as you get into slow growth or sustaining mode.

And so what you described I think is just is great when you've got most of the staff that's self-motivated, self-driven, and they're part of something exciting and it's growing and they're probably young and they're probably hired directly out of school or a couple years out of school. There's a lot you can do in that mode. As the company gets bigger, as it gets installed client-based, as companies start to other companies start to do things that rely heavily on the reliability, not just the innovation, but they they need different things. They don't they no longer need what's latest and greatest and coolest. They need the thing to work the same way it did yesterday because they've made assumptions that depend on it.

Then you get essentially you're calling for a different kind of staff to work on that. So, as time goes by, some of the staff that were the biggest contributors early on get bored and frustrated with all the restrictions and they leave and then all that uh ambiguity or flexibility in the roles and stuff. Uh that's no longer a positive.

And so my prediction with the scenario you described is that 10 years from now that organization will need what my company called a roles and responsibilities workshop because it's just so common that you start out in a way that that works. But you get to a point where as things scale up and as the character characteristics of the staff change, it just doesn't work anymore. And uh and so you just need to be a little bit more explicit about about it. And I think these, you know, these are all just natural pendulum swings that happen as time goes by. And it's not that one is better or worse than the other. It's really fit for purpose which in startup mode you know having a lot of bureaucracy in startup mode is a great recipe for never getting started. Uh but adding the right kind of bureaucracy at some point becomes necessary to sustain a an organization of of a larger size.

And one model I've heard which I I don't know who to attribute it to, but there's the pioneer settler and citybuilder. Yeah. Which which also is one variation of what you said.

you you outlined three areas that you've noticed that software developers should become proficient in technology knowledge business domain knowledge and software best practices knowledge in your experience like how important are these and how how can you get good at them and and if if you had to you know take a stab at which ones are becoming more important as a developer is getting more experience which in your experience which one was, you know, like one more important either for you or the people you work with.

They all matter to some degree at all times. Uh if you're a junior developer, you're not very good at all of them or any of them, but you're probably the strongest in the technology area. uh if you're a little bit less junior developer, you know, maybe you've worked for the same company for uh five years, then you could be pretty strong in the software best practices or pretty strong in the business in addition to being pretty strong on the technology side. I mean, five years is a long time in the software world.

At some point, the vast majority of software professionals I've ever met, they end up concentrating in in one area or another. And so I think the most careerlimiting unless you're in just a super techy organization is to to just go all in on the technology side. There are some places where that's going to work, but it's that's the exception.

Uh going all in on the business side is a really good background for moving into more of a like company level architect role. You understand how the different pieces fit together for both the technology and the business. you're able to to make technical decisions on a business basis and not very many people are good at that and so I think that can be that can be super valuable useful career path.

The best practices path which is my path is actually probably a little bit more limited in the vast majority of companies. It's less limited if you're a consultant or a trainer, but uh inside a company, you know, you can still be valuable, but you're probably going to move into more of a coach role or possibly move move into more of a manager role.

Anyway, I think either of those either of those second focus areas can be uh viable and valuable uh paths to focus on. Um, and I think one thing I mentioned in that talk was uh that it's just it's very useful to think through which one do you want to be? And I I don't know that a lot of people actually think about it that much. They kind of they get an opportunity to be a manager. And so they're like, okay, that seems like a step up. And they don't necessarily realize, oh yeah, if I take the manager path, part of what goes with that is I need to get better at the people side of it, and then I also need to get better at the business side of it.

If I go high enough on the manager path, at some point the business needs come into conflict with the technology needs and my role is going to require me to favor the be the needs of the business. And a lot of technical people can't make that transition because they're too wedded to the technology and they just can't conceive of the idea that the business would take precedence over the best, you know, that's in quotes, the best technical decision.

One is that I think a pretty common pattern for technical staff is going into management for a year or two, deciding they don't like it, going back into a technical contributor role, enjoying it, but going back to thinking about, huh, here I could have done the management thing this way, I could have done it that way, and then they make a second attempt at manager, and then they actually really like it and they do well. I've seen that pattern many times. Uh, and so just the idea of kind of bouncing up against the ceiling, coming back, regrouping, and then taking a second run at it a few years later. And some of those people end up being really, really effective managers.

Another attribute that I find to be really uncommon is that most technical managers at any level don't have any aspiration to general management positions. If you're at a VP of technology role, VP of software role, it's unlikely that you aspire to be the CEO or the COO. What's likely, if you aspire to anything, is you aspire to having the VP technology role at a cooler company. Uh, and that's it. And so, it's funny because I think for uh general business people, this doesn't really compute. You know, they like, hey, if I'm a VP, I want to be the CEO. I want to move into the sea level. But for whatever reason, I don't think technical people think that way. I don't read about it outside technology.

a topic that I I don't think I've ever written about uh but that I think is worth just throwing on the table is that and it is that focused application of personal energy makes up for a lot of other deficiencies and and in startup mode when you're talking about not having well- definfined roles and so on. If everybody's actually working in a focused way and they care about getting work done and they're applying a lot of energy, you know, mistakes aren't a big deal. You just go in and you fix it because you've got the energy to do it.

If you're working in a super processoriented way and people are kind of thinking half about their home life and they're checked out because now they're 45 instead of 27. Not that that's a universal pattern or anything, but um but you know, if you don't have the the same level of personal energy to correct mistakes, the mistakes linger, they affect more people, uh affect more downstream products, work products and and it just becomes a much bigger deal.

And you know, when I was at Microsoft, the core Windows team was under 15 people. And of course this was you know much earlier version of Windows but uh at the time there was a project going on at at IBM. Well Microsoft and IBM were jointly developing operating system called OS2 and IBM had something like 10 times the staff maybe more than that and Microsoft was really frustrated at how slow IBM was on their side. And the the reality is you can get a lot of stuff done with the right 10 people who are all super focused.

so yeah you can get an awful lot done with the right with a high level of energy and I don't think in the technical space I haven't read much at all on people talking about the role that energy plays it's all about process and uh training your training your different people in technology and so on.

And so during the era I was at Microsoft I think uh the the culture at Microsoft when I was there was if you were awake you were working. And the thing that it looks from the outside like it's a sweat shop, but from the inside it's just they were doing an incredible job at that time of hiring people who really didn't want to do anything other than work on the next generation of software. And it was a great time to be there because you felt like you were at least a year ahead of the rest of the world

But you can't replicate that through good management. Yeah. Uh where you're just trying to somehow motivate people to want to work 100% of their waking hours. You really have to just put the pieces in place so that people want to do it. And if you're if you're a a super high marquee company like Microsoft I was at that time, then you know it happens kind of automatically. Really the manager's job is not to mess it up. But if you're a regular just business or a sustaining mode company, I don't think it's possible to replicate in those companies.

We originally as a company really before agile existed uh had started out thinking 40hour work week. But the first guy that I hired uh who uh ended up being the CTO for 20 years, um eventually he and I realized neither of us had ever worked in a 40-hour work week. We both naturally worked in burst mode and we both did our best work in burst mode. And so it's not about having a steady state. It's about having a sustainable pattern.

Uh and you know what you described I resonates with me 100% in that you don't want it all the time but yeah if you had to go through your whole career and never experience that I would really feel like I had missed out on something if I I couldn't have been in that mode at least some.

So you mentioned that one topic you you didn't write about but maybe it could could have been a good idea in hindsight is rule of energy. I wanted to ask you since you know the the since the second edition has been published and that must have been 20some years as well. Uh what are what is are one or two other topics that you know if you wrote this book today you might have added into it?

Yeah. So I think that that really gets into the limitation of where I am professionally now and and I really have not been active in software at the code complete level um for several years now. I mean the irony of it is I've spent more time actually doing hands-on programming just for my personal use the last five years than I did for probably 15 years before that. But it's really just one person project me personally doing it.

Um I think uh you know we've talked quite a bit in this conversation about design three times and I think one one thing that has worked out really well for code complete second edition is really that it is the second edition and then I I published it 11 years after the first edition and so I think that was that was really kind of an ideal amount of time between the two editions because I had learned a lot in the intervening 10 years. the industry I think had matured quite a lot and when I went back and started working on the second edition I had a great vantage point for looking at okay what has changed since the first edition and really thinking through well what insights does that give me about the kinds of things that are shorterd and the whole point of the book was to try to capture the longer lived best practices that would span te uh generations of technology and span programming languages and so on.

So the 10 years between those two, there was some stuff in the first edition, it's like, yeah, okay, this really wasn't lasting. This needs to go. There was other stuff it's like, wow, you know, it's been 10 years. This really hasn't changed much at all. And uh I think when the second edition came out in in uh 2004, agile was really it was beyond infancy. It was kind of at the toddler stage at that point, maybe a little beyond that, but we were still mostly focused on on XP. scrum really hadn't hadn't uh emerged as the the dominant practice at that point.

So I feel like the first edition had aged more in 10 years than the second edition has aged in 20 years.

If you were, you know, like an early career professional in in in this industry, seeing that there's this tool that is actually good at spitting out code, not perfectly, but pretty good code, how would you think of making the most uh out of it for for your career for to to understand how how to tame this and and how how this might even change software development if it if it will. Maybe it won't.

Yeah. Well, I think it's pretty clear it will. Uh I think it's totally unclear how how it will. In my mind, we're still in the pretty early stages of of how we would use any kind of AI for help with software development or really for help with anything. I think, you know, at this point in time, the lessons I feel like I've learned are the more guard rails you put in place, the better result you're going to get.

There was a funny LinkedIn post yesterday from somebody who said the learnings about using uh AI and software are you've got to be really clear about your requirements. You've got to really define your test cases well. you've got to define uh uh all the exception cases really well and the gist of it was huh this just sounds like good software development fundamentals and uh only we are now you know AI is the thing that's finally after 75 years forcing us to do this

my other feeling is that I think writing the gold path or the happy path through the code has always been the easy part of coding. And you know, understanding which which exception cases did I forget about or was I unaware of or did the requirements never capture in the first place. uh you know Fred Brooks published a paper called no silver bullets and he talks about the difference between accidental complexity and essential complexity and a lot of the essential complexity comes from the real world because the real world is messy

and to the degree that uh AI isn't 100% lined up with the the messiness of the real world then the programmer job of being the party that fully vets all of the exception cases and the corner cases and the off by ones and so on. That's the other thing that's concerning is I still think AI can't count and so off by one errors seem like they're just probably

Yeah. So uh sometimes programmers have difficulty just getting started. You mentioned the pseudo code programming process. I think that's something where AI can be pretty helpful. your hey look what are the the steps I should what are the different uh topics I should consider when I'm designing this okay what sequence would make sense you you can basically dialogue and say you know give me a a breakdown of this space and show me what the class design would look like okay I don't like that give me a different breakdown show me what that would look like the ability to iterate super quickly and and insert your own brain into those iterations I think is incredibly valuable and for that matter It's incredibly stimulating to be the human in that in that loop. And then of course you can also say what test cases should I consider you know you can kind of pit it against itself and and I think at least my own experience with that is you know I haven't tried it on anything super complicated but I think the general concept seems to work.

I think the history of programming is a history of increasing levels of aggregation. So you started out with assembly or machine language and then you had aggregation into assembly and that was one level of aggregation. Then you had aggregation into macro assembly. So as a second level of aggregation then you had this amazing invention called the subruine which was an aggregation of callable functionality and then you had an aggregation into classes where you had a combination of data and functionality and then I don't know it kind of you know at least that's kind of where my knowledge of it my direct involvement of it kind of stopped

Well maybe but you know don't forget one thing that I think we just didn't neither of us mentioned a huge difference with AI and everything else that came before it is it's non-deterministic. Yeah. And in programming we have been used to and I think we've gotten really good at making the most of deterministic. And nondeterminism always has its its dangers it its flaws. it's uh it's it's harder to work with

What suggestions would you have for an engineer to have a durable career principles that that worked for you probably independent of of technology?

When I was writing the first edition of the book, um, one of the things I tried to keep firmly in mind was that the guiding principle for writing the book and the principle that answered every question was, does this make the book more valuable for the reader? And so there were some things that I kind of liked but maybe were idiosyncratic to me. I ultimately decided that doesn't make it more valuable for the reader. So I I left them out. um design elements of the book, content of the book, everything was about what makes this more valuable for the reader. And as I iterated on that over the course of writing the book, I think that iteration with that in mind, just add it up to something.

And uh I think the same thing would my career advice would be exactly the same. What makes you more valuable to your organization or to the world at large? And you know, it's not like anybody I would think someone's a bad person if they don't think that way. But if everything you're doing is just to scratch some personal itch, it's idiosyncratic. You're interested in it, but it doesn't add up to something. Just be aware that that's, you know, that's a a lost opportunity.

And if on the other hand, every time you think about, well, what project should I do next? What do I want to do next in the organization? Sometimes you don't get a choice. Sometimes you do get a choice between option A and option B. Does option B open up more doors possibly than option A? Well, maybe you should choose option B for that reason. Does one of them make you more valuable? Uh, you know, choose it for that reason. And I don't think this is just about personal development or personal success. I think it's about making the world better. If you're making yourself more valuable, you're increasing your ability to contribute to the world. And uh and I think that's a virtuous thing.

Yeah. And you close the book with with the how you emphasize how craftsmanship is important for professional growth and you you you write how curiosity, continuous learning are essential trait of great software engineers and to me that it feels this is just as relevant as ever.

I just think it's it's part of the human experience. And I think that programmers probably more than average are curious people who like to learn, who are attracted to novelty, who want to learn what's new and what's cool, and who want to explore what's possible with what's new and cool. A lot of our conversation today about AI has been all about exploring what's possible with what's new and cool. I think this is just the way programmers are and and I wouldn't change that.