The Pragmatic Engineer - Code Complete with Steve McConnell

Episode Date: September 10, 2025

Brought to You By:•⁠ Statsig ⁠ — ⁠ The unified platform for flags, analytics, experiments, and more. Statsig built a complete set of data tools that allow engineering teams to measure the impact of their work. This toolkit is SO valuable to so many teams, that OpenAI - who was a huge user of Statsig - decided to acquire the company, the news announced last week. Talk about validation! Check out Statsig.•⁠ Linear – The system for modern product development. Here’s an interesting story: OpenAI switched to Linear as a way to establish a shared vocabulary between teams. Every project now follows the same lifecycle, uses the same labels, and moves through the same states. Try Linear for yourself.—The Pragmatic Engineer Podcast is back with the Fall 2025 season. Expect new episodes to be published on most Wednesdays, looking ahead.Code Complete is one of the most enduring books on software engineering. Steve McConnell wrote the 900-page handbook just five years into his career, capturing what he wished he’d known when starting out. Decades later, the lessons remain relevant, and Code Complete remains a best-seller.In this episode, we talk about what has aged well, what needed updating in the second edition, and the broader career principles Steve has developed along the way. From his “career pyramid” model to his critique of “lily pad hopping,” and why periods of working in fast-paced, all-in environments can be so rewarding, the emphasis throughout is on taking ownership of your career and making deliberate choices.We also discuss:• Top-down vs. bottom-up design and why most engineers default to one approach• Why rewriting code multiple times makes it better• How taking a year off to write Code Complete crystallized key lessons• The 3 areas software designers need to understand, and why focusing only on technology may be the most limiting • And much more!Steve rarely gives interviews, so I hope you enjoy this conversation, which we recorded in Seattle.—Timestamps(00:00) Intro(01:31) How and why Steve wrote Code Complete(08:08) What code construction is and how it differs from software development(11:12) Top-down vs. bottom-up design approach(14:46) Why design documents frustrate some engineers(16:50) The case for rewriting everything three times(20:15) Steve’s career before and after Code Complete(27:47) Steve’s career advice(44:38) Three areas software designers need to understand(48:07) Advice when becoming a manager, as a developer(53:02) The importance of managing your energy(57:07) Early Microsoft and why startups are a culture of intense focus(1:04:14) What changed in the second edition of Code Complete (1:10:50) AI’s impact on software development: Steve’s take(1:17:45) Code reviews and GenAI(1:19:58) Why engineers are becoming more full-stack (1:21:40) Could AI be the exception to “no silver bullets?”(1:26:31) Steve’s advice for engineers on building a meaningful career—The Pragmatic Engineer deepdives relevant for this episode:• What changed in 50 years of computing• The past and future of modern backend practices• The Philosophy of Software Design – with John Ousterhout• AI tools for software engineers, but without the hype – with Simon Willison (co-creator of Django) • TDD, AI agents and coding – with Kent Beck—Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [e-mail]. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

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 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 me 900 pages. Code Complete is a single-buss 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 Pat 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. This podcast episode is presented by Statsig, the Unified Platform for Flags, Analytics Experiments, and more. Check out the show notes to learn more about them and our other season sponsor. If you enjoy this show, please subscribe to the podcast on any podcast platform and on YouTube. Steve, welcome to the podcast. It's so good to meet you in person. Yeah, thanks for having me. 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 how thorough it is. And the other big surprise I had, I assumed 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?

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 never published anything. And so I thought, 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 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. looking through a card catalog and requesting materials through inner library loan. I mean, it's quite a different process. And so there was actually some skill involved in that. So basically 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 so 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 didn't set out to write a 900-page book, which was the first edition. 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. At this point, I only had two chapters written. And 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 for the first time estimated the page count of the book. And it came out to me 900 pages. And I thought that can't possibly be right.

I'm not writing a 900 page 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 900 page 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, 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 five years out, five years out of college at that point. 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 five years earlier. And it was recent enough that I could still remember where I was five years earlier and what I didn't know five 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? Did you remember, like, initially and then a couple years later? Yeah, 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 was pre-Amazon, right? They trickled in way pre-Amazon.

And so the reviews were great. And I attended a book signing here in Bellevue. and one of the people from Microsoft Press came in and said, said, oh, this is our sleeper book. And 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 in-depth book. But they assumed it wouldn't really sell very well.

So the sales have been a nice surprise for everybody. You must have learned about a really interesting, inspiration the book had on the blog called Coding Horror. I don't remember exactly when it was. It was, I don't remember. 2005, 600, somewhere in there. Something like that, by Jeff Affwood. He started the blog, or he 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 blogger. 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 image on it. And, of course, his blog did really, really well. And, you know, led to a lot of good things for him.

And I think it had a positive impact on the world, too. I think at some point it might have been the most popular developer blog. He published that's about something like 100,000 requests per day. Wow. I was reading it. So when I was early career, I read the 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 that helped him meet people, Joel 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 start a blog, which inspired or helped create this very special website Stack Overflow, which Stack Overflow obviously now has helped train some of the AI agents. Sure. Like, it's just all trickling all down.

Yeah. Well, I think, 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, you know, you kind of start the book. I'll quote a little bit from it. You say at one time, software development and coding were thought to be one the same, but as distinct activities in the software development lifecycle have been identified, some of the best binds in the field has spent time analyzing and debating methods of project management, requirements, design, and testing. They rushed to study these identified, but it left code construction as the ignorant cousin of software development. I wanted to ask, what is code construction? I mean, the book is about

code construction, but I think it helps us recap on, and how it's different to, let's say, software develop in or how it's similar to it. Yeah, it was pretty deliberate in the book in trying to capture the space of software construction and a space that's distinct from writing code, or not distinct from, but is not the same as writing code. I think that the idea of just jumping and encoding is something that maybe you do when you're first learning how to program. 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 in the full set, the universe of topics that come to bear on the actual code itself, the readability and all aspects of readability. I think that much of the literature before I wrote Code Complete, there were a couple things out there that were decent things on coding style, but that was kind of it. It was coding style. It wasn't really about, you know, 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 what would have been at one time 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 necessarily taking place in terms of thinking about the activities that are adjacent to coding, but not to.

quite big enough to qualify for a book or a name of their own. And then just to be clear, like, these thoughts are so clearly, like, obviously, we write the code, but it's everything that encapsulates until I get something that is ready to ship, that is ready, you know, like, literally we have the planning or requirements or business requirements. And then it starts from, like, me thinking about, like, how I'm going to structure my code as I build it, I iterate, I debug, I check that it's running, I think about longer-termainting. These are all part of code construction.

I'm just like double-checking that I'm understanding because I feel that code construction in the book, you definitely cover it, but since then, I don't think we talk about cold construction that much. I would probably make it a little narrower than what you just described. I think that some of what you just described I would probably characterize as a higher-level design and but on any given project, depending on how the project evolves or how it emerges, the design level of thinking 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, 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 suitways are like so just I understand is one of, like, could you just spell out again the two different ways of corking?

You could think of it. generally is top down versus bottom up. So you could think of it, or inductive versus deductive. I believe that most programmers, meaning the majority, not like 99%, but 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 had. Steve was just talking about how there are different ways to get to the good design of a software system. Some developers do, a top-down, others do it bottoms up. But how do you know if a well-designed system works as expected in the real world? This is where analytics and experimentation are so important, and it's why

companies like meta, Uber, and others build complex experimentation systems themselves. These are far more advanced of what engineers that most companies could have access to. Until recently, that is, when Statsic became available. Statsic is our presenting partner for the season and they built a complete set of data tools that allow engineering teams to measure the impact of their work, focus on outcomes, and create bottoms of products culture. This includes advanced AB testing, product analytics, feature flags, plus tools like session replays, a user store, and more. With Statsic, every time you release a new feature,

you can see exactly how it moves a product or infometrics that you care about, and then you track progress over time using the same dataset. This toolkit is so valuable to so many teams at OpenAI, who was a huge user of Statsig, decided to acquire the company recently. Talk about validation. Statsic has an incredible. incredibly generous free tier, a pro tier for teams starting at $150 per month, and scalable enterprise pricing. To learn more, go to staticsac.com slash pragmatic.

Yeah, this is really interesting because, you know, for example, these days at a lot of scale-ups tech companies, it's becoming increasingly expected of engineers to start with a design document, which is a software design document. And when I work, for example, at Uber, like we kind of operate it like this, but a lot of times, it just feels like a nag. Like, I know what I want to write, which kind of makes me realize, I think, your point on some people up or differently. They're always the same developers or engineers who wrote the code, did the thing, and I'm like, okay, I'll write a design document just to like check the box. But the code is already written. Right.

And at the time, I tried to explain these people, especially eventually I became a manager to some of these people. Like, you need to start, you know, highlight your high-level thing. And I didn't appreciate it at the time. And I was like, why? Because I guess maybe I am fine operating like this. I'm probably in this first group. I didn't appreciate this until now. Yeah. There's a great paper, really old paper by Dave Parnas called A Rational Design Process, How and Why to Fake It. And the gist of the past, so this paper is from, I think, the mid-70s. 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 the paper also says the how and why to fake it part was at the end of that, you described what you did. And the description is not necessarily going to show you all of the mistakes and dead ends and so on. And so it's going to look like it was a more rational process than it was. But 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. Yeah.

And I do sense that in the industry these days. We've kind of forgotten a little bit about the design or the iteration or even things like, I have to remember who's who says. this, I think it was John Alsterhout, who in his book on software design, a philosophy of 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. 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 you had two,

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. By that time, he would be applying all the lessons he learned. Then he spent 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'd have a backup, whatever, right? It 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. Well, these days, I think it happens a bit less saying to get being everywhere, a committee. But I've had this earlier in my career. And as you said, first of all, you blow up. You're like so mad.

Like, I think it was a file loss or deleted or something like this. And as you said, you're thinking, oh, it's going to be so much work. I don't even want to do it. But when I now remember the same lesson. I spent some time on the school board here in Bellevue. And one of the surprising learnings I got from the school board was that one of the best ways to build reading proficiency is to have kids read things they already have read. This repetitive reading builds confidence and builds skill. And so I think you can kind of apply the same idea to rewriting the same code you've already written that maybe there's a lost opportunity there because we're always trying to do something new.

And we don't often get the chance to go back and just redo the thing we just did. Yeah, and I think this is one of the things where I wonder if we're talking a lot less about software design in the industry because we just ship ones. We don't even go back to rewrite the whole thing, especially with web-based software, you know, mobile is becoming that. You can ship it, you can change it any time. You know, there's startups, lean startups from 2010 gave this concept an MVP minimum viable product. You know, it doesn't need to be good. It just needs to be good enough. And I guess the most mature companies, which hit so-called product,

market-fitted product that works. Over time, they will do a rewrite or maybe a second rewrite through a series of migration, technology choices, so they will get actually a lot better. But that's kind of it. So I think there's a lesson we can probably all just consider. That's not a bad thing to rewrite. So your career path, we know that you wrote this book early career. What was your professional development story up to the book and then after the book?

What happened after? Basically, up to the book, I had worked for a small insurance consulting company. I'd work for a large, briefly for a large insurance company. I had worked at Boeing on a defense project. I'd work at a startup mode for a company that was kind of doing just a startup 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, 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 period. And, you know, I put a lot of time into those as well. I had started out being kind of interested in programs, but not super interested in it, notwithstanding the fact that I seemed to spend a lot of my essentially hobby time on it anyway. 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 entrepreneurial streak. So I kept doing startup stuff in that mode.

And 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 had to figure out what I'm doing. And I think at the time, for the first couple years, I had a little bit of imposter syndrome because I didn't have a degree in computer science. I didn't know at the time. Oh, really? Oh, well, of course. What was your degree in? In philosophy. Yeah, I had minors in math and computer science.

But at the time, less than half the people working in the field had degrees in computer science. That didn't change for a long time. But I didn't realize that that was common. I thought that was unusual. So I started trying to develop or acquire some skills so that I could basically be more professional. So I started going to user group meetings. I had one friend who was as interested in the programming stuff as I was. So we go to these things together and talk about them.

And then I got the chance to be, I'd worked at Boeing and I was like, okay, I'm not seeing a whole lot here that really looks like qualitatively different professional programming to me. And then I got inside Microsoft, and I thought, okay, I'm finally going to see what real professional programming looks like. Yeah, the best of the industry, right? Like Microsoft back then was a bit like what OpenAI is now or Google in like 2000, I don't know, four. It was just the 800-pound gorilla and there was nothing else even close at the time. And 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?

are on the Windows and DOS and that era, right? Windows was not really popular yet, although that's what I worked on. But it was sort of the, it was sort of the last phase of the DOS era. Which Microsoft was dominated? Beginning phase of Windows, yeah. Yeah. And they weren't super dominant in applications the way they are,

the way they are now. So I got inside Microsoft, and what I discovered was, number one, people were really, really smart. So that was a factor. And number two, you have 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 print. but on printing to one device.

So, I mean, that was a lot of it. It's just 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 one had already seen. So you got it to Microsoft. You write the book.

At this point, how did you think about your career? I think you had a talk earlier, which is not required. but about the mental model on how you viewed your career at the time and then figure it out what next? At the time I wrote Code Complete, I was still trying to decide if I really wanted to be a programmer at all. And if you can believe that. And so 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. So you did research on, like, you had a full-time job and on the side you were doing.

And then you, like, took off time to write. I did. I took a year off. Wow. Yeah. The dot not looks scary. I mean, suddenly you were there with, with, you know, like no job just writing this book. Yeah, I really wanted to write the book.

That was the main thing I wanted to do by then. And I knew it was a big project because by then I'd figured out it was 900 pages. and with the 250 page that I'd been carrying around my mind, that could have been maybe a part-time, but 900 pages I knew I needed to take some dedicated time to do it. And I wanted to do it. I'd save money, and I could, you know, I could afford to take some time off.

I had basically, I was living a very low overhead life at the time. I didn't own a house. I wasn't married. I didn't have a dog, you know, so I could live really cheaply if I needed to, which I did. And so I spent about a year. writing full-time. And at the end of that, number one, it was a terrific experience. At the time, I felt like I'd gotten three years of experience in one year by writing the book. I would say I learned so much more about what I was doing just through the process of the writing's

only 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 because the end phase of that was just painful. And so then I worked for a couple years and the memory of the pain faded. And I was kind of getting an itch to write something again. 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 liked the variety. 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 start.

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 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 kind of organized the software universe into the base of the pyramid was all programmers, like 100% of the programmers, and my focus was on U.S. 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 essentially a 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 move toward. And so I used that partly to guide what I did on the second book because I had a variety of books I was interested in writing. And the book that would have made the most sense after code complete would have been design complete. I could have written it at the time, but I felt like I would get pigeonholed as just a pure tech guy if I did that.

The other book I really wanted to write was performance optimization in Windows, which was a fun topic. But again, it was a little bit too bits and bytes. And so I decided to hop over and write something. It was a little bit more management-oriented because I wanted to kind of triangulate on the top of the pyramid. And by the way, this pyramid you shared with me so will also share it so beautiful. Yes. Yeah. I thought it was such a good or interesting mental model that I haven't seen many people think.

And I really appreciated that you kind of zoomed out and looked like, all right, where am I? Where would I like to go? How do I go there? Now, as part of this, you mentioned, again in this talk, you mentioned the concept of lily pat hopping. Yeah. What is that? And how did you apply it to your career? Well, I think that the pyramid was, in essence, the antidote to lily pat-hopping.

What I had noticed, I noticed it a lot more later, but even at the time I'd realize that programming didn't really feel like a career. It felt like a job. And the reason it felt like 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 and 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. And, you know, maybe that's interesting and stimulating. And there's 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 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 wanted to be essentially more than the sum of the parts. And 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're going to put in the same effort 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. I really like this thing, especially because as developers, I think we forget or our software engineers that we have a lot of freedom on the job. For example, when I was a manager to engineers, if an engineer came to me and said on my team and said, like, hey, I'm really interested in this area. First of all, if they said that, I would be thinking, how can I help them with that?

But even more so, but sometimes that would be tricky to do or not a simple ability to say, like, hey, I'm interested in this other project. I'd love to work on it because I think it would help my skill set. So if they kind of did the work to just look around, understand, you know, the limitation of the team, whatnot, like, my answer was, like, amazing. And I also thought, wow, this is a person who's really taking initiative. Let me help them because because as their manager, I think, you know, I'm not sure if people still have the notion of, like, the boss who's something negative. Like, as a manager, you really want everyone to thrive. You want people to grow professionally because guess what?

They'll have better output, more motivation. It makes your team better. And as a manager, that's your goal. So I think the more people realize that you can think about where you want to go, even at the workplace, you can almost always make some of it happen, if not all of it. I think that's right. I think, you know, there's saying that most people live in a box that they build for themselves. 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 the corollary to that is your managers already think that you're going to do whatever needs to be done to do your job well.

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've 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 more strategic way. And I think this is just becoming, it's starting to become more of a baseline expectation. So one thing I noticed is when we're hiring people at Uber, Uber, we had the,

we had a culture that was very startupy, experimental. We had the same, be an owner or not a renter, you know, do what needs to be done. And I have people who joined from like consultancies, places where it was common for the client or someone to sign tickets to them, for example, GER tickets, you know, and they would work on it. And they got used to they weren't really allowed to go and ask questions. It was kind of like, don't question it. And so when some of those people came over, they found it really hard to adjust because they were like, oh, you know, what tickets should I saw? And I was like, well, like, don't tell me. You tell me.

But it's interesting how, how there, that's the first time I saw that there was a divide where people at some point in their career, they got told, you know, like, this is the box. Stay inside the box. Yeah. And then they found it really hard to, oh, I can actually, oh, there's nothing here. I can actually go outside. My first summer job that I got paid for programming is an internship. And 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. And you have to put up a picture so people know what those are. 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, 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, when the owner of your company, tells you what the next most useful thing to do is, you've 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 completely 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, all kinds of stuff. Just to see how baseline it is, you know, like at Uber, I didn't know if we were exceptional or not. But just a few weeks ago, I talked with someone at OpenAI about, in fact, I talked with the head of engineering at OpenAI.

And, you know, they're now one of the hottest companies right now, a bit like how Microsoft was in the 90s or Google later or maybe Uber, we were even at some point. And I asked the head of engineer, like, how are you structuring, you know, like your teams, engineers, et cetera. And he told me something interesting how, like, they don't really have roles anymore because they actually have some of the designers write code, obviously with the help of AI.

Some of the engineers, like do the product requirements or even do design. And it's all becoming really fluid. And he said that the model they follow is, you know, everyone should pick up both what they think is the most important. and thing to do. And so suddenly what used to be a pretty well-defined role of software engineer, product manager, designer, they're all kind of murky. I mean, people still have their expertise. And this is one of the most innovative companies right now. I'm seeing service do more and more of this. They're now calling it actually a product engineer, which means you are a software engineer,

but your job is not just to write code. Your job is to understand what we do. And then, you know, build solutions for the most pressing problems. And now it is spreading across that more and more startup, start are like only hiring for these folks. And if you're used to, you know, being told what to do or you're looking for it, they'll be like, yeah, sorry, we're not looking for these types of folks. Yeah. We just talked about how open AI works differently than many companies, even than the roles they have. One other thing they're different is in the tools engineers that the company used to get things done. They use linear, who are the season sponsor of this podcast, and a big reason for their choice was the need to harmonize all the different ways

their product team was working. Picture this. You're an engineer working on a critical project. You need to coordinate with another engineering team on a shared dependency. But here's the problem. Your team tracks work in Jira. They use GitHub issues, and the product team writes specs in Google Docs. Every handoff requires you to translate not just the work, but the entire way of thinking about the work. This slows you down massively.

One Open AI engineer described it as an archipelago, where each team is on their own island using their own language, which sounds funny, but from my experience at Uber, it's super accurate. So their switch to linear was driven by the need to establish a shared vocabulary between teams. Every project now follows the same life cycle, uses the same labels, moves through the same states. When an engineer from one team needs to understand what another team is working on, they don't have to learn a new system or decode different workflows. Their usage of linear in this way is how they can move so fast despite being quite a large company. And to close,

linear is just so simple to use. Their team needed no formal training. Try it for yourself by heading to linear.app slash pragmatic. Well, what comes to my mind when you say that is, I think companies go through 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 great. When you've got most of the things. 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 other companies start to do things that rely heavily on the reliability, not just the innovation, but they need different things. 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 ambiguity or flexibility in the roles and stuff, that's no longer a positive. And so my prediction with the scenario you described is the 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 characteristics of the staff change, it just doesn't work anymore. And so you just need to be a little bit more explicit about it. And I think 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. But adding the right kind of bureaucracy at some point becomes necessary to sustain an organization of a larger size.

I think they're very much right, especially because it is popular now. Obviously, I also talk with a lot of basically start. Sometimes there's scale of zero larger, but they're still very young, growing, especially on AI. It's a new topic. And if you look at companies, there's this joke that goes into tech industry, eventually every company becomes IBM. And now, like, when you look at Google in some ways, well, they're behaving awfully

a lot like IBM used to, but if you look at Google, it's now 30 or, well, it's going to turn 30 years old. It's a massive business. It has 100, 200,000 people, et cetera. Like, as you said, the things don't work. And one model I've heard which I don't know who to attribute it to, but there's the pioneer settler and city builder, which also is one variation of what you said.

And I had age on top of that. When I was at Microsoft in the early 90s, the campus age was aging 0.8 years per calendar year. And so when I was at Microsoft, I was 27. the average age on campus was 27 point something or 26 point something. I was about half a year off the average age on campus. And that's average. That's not median.

That's average. And so if we've got one guy who's 60, you need a lot of guys who are like 22 to get the average down to 27. And so the average, you know, misrepresented how old the campus was, really. It was probably younger than younger than. The media must have been younger. Yeah. So when I was there, when I was there, there were about 50. 15,000 people total, and the dev staff was about 2,000.

So, but aging 0.8 demographic years per calendar year, fast forward 15 years. Now the campus is 40, not 27, and now people have got houses and they've got kids and they've got spouses and, you know, it's just all this other stuff that's more on the kind of technical, technology, code base, customer base. There's all the business stuff, but I think the demographics of the staff, staff matter. And the reality is the people in the company age as the company ages. And that has some pretty big impacts. Yeah. And some of the companies that have been the hottest and fastest growing startups all the time. I'm thinking of Amazon, of Google, of meta. You know, like their CEOs and

their staff is now, you know, they used to be 20 when they started or even I think Facebook 19, something like that. Now they're, you know, 40, 45, 50. As, as you say, it's all growing with it. Yeah. It's good to keep in mind. Now, also in this kind of career advice talk that you did, you outline 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 can you get good at them? And if you had to take a stab at which ones are becoming more important as a developer is getting more experience,

in your experience, which one more important either for you or the people you work with. They all matter to some degree at all times. 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. If you're a little bit less junior developer, maybe you've worked for the same company for, 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 one area or another. And so I think the most career limiting, unless you're in just a super techie organization, is to just go all in on the technology side. There are some places where that's going to work, but that's the exception. Going all in on the business side is a really good background for moving into more of a company-level architect role.

You understand how the different pieces fit together for both the technology and the business. You're able to make technical decisions on a business basis, and not very many people are good at that. And so I think 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 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 into more of a manager role. Anyway, I think either of those second focus areas can be viable and valuable paths to focus on. And I think one thing I mentioned in that talk was that it's just it's very useful to think through, which one do you want to be? And 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 pass, 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 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. Yeah, and it's interesting with the manager path. I think we've had about 10 years where looking back, we had zero interest rates and companies were growing really fast investing. Investment in the technology was huge thanks to the mobile revolution, smartphone revolution, thanks to cloud, thanks to startup returns and IPOs, which is just being big. And going at the manager path used to be seen as a very low risk one, as one where you could go

in, you could manage people, maybe make a bit more money, open your options because now you could go to found a startup, say I have management experience, you could go back to being an engineer later as well. But what happened now? Well, some of those people who thought, oh, I'll just go into management for a little bit and see how it is and I'll go back. They ended up, you know, going higher and higher again with this high growth area, earnings potential was higher. But now the reality is hitting where teams are not growing as fast. In fact, there are. some companies are scaling back. So managers are finding themselves formally technical people in this really awkward position where they're not that technical anymore.

Their past few years of experience is scaling fast-growing teams, which is no longer needed. So I've had some friends who saw this coming a little bit earlier, head of engineering or director of engineering. And some of them went back to individual contributor roles or to tech lead roles where technically they took a step down. but some of them are actually happier for it. And it just gives a lot more stability. You know, there's still a lot of engineers who need to be hired, but just fewer managers and especially fewer managers without a warm referral. Yeah.

I don't have enough knowledge of sales staff or general business staff to know how it looks on that side of the fence. But from the reading I've done, I feel like technical staff have a couple of interesting attributes as they move into management. I don't read about in general management literature. 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, it could have done the management thing this way, it could have 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. 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 C.O. What's likely, if you aspire to anything, is you aspire to having the VP technology role at a cooler company.

And that's it. And so it's funny because I think for general business people, this doesn't really compute. You know, they're 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 of technology. Yeah. And there are some really interesting stories as well.

The founder and for a long time CEO of HashiCorp, Michael Hashimoto, he was the CEO of the company for a while, I think because he needed, I think he took over from his co-founder. And then he went back to being an individual contributor. at the same company, which is uncommon, but it comes to show, and now he's actually, he went back to writing. You know, he founded Hachicorp by writing software, I think Terraform or some of the others,

and now he's back to just writing software. It just shows that he just loves building. Yeah. You know, there's a great leadership book called What Got You Here Won't Get You There. And the gist of, it's really aimed at organizational leaders. And the gist of the book is, here are all the things you did to kind of get to where you are.

and they were all great for that role, but you're not in that role anymore, and so to be successful in your new role, you have to operate differently. And some people don't want to operate differently. So the ones that actually have some self-awareness do what you describe. They go back into a different role. I think the specific scenario you described of the founder of the company going back into a contributor role, organizationally, we've seen that as super messy, just because it's hard to disembate.

agree with the owner and all that stuff. And it can be incredibly, incredibly randomizing for the organization. But if that same person instead goes off and starts the next new thing, that can be great. You know, they can take advantage of everything they learn the first time. I do think that a lot of tech founders don't really think or even talk or consume literature or learnings from other companies. you know, there's a lot of like first-timers. Why not?

So there are some drama and conflicts and learning. Sometimes it works out. Sometimes it doesn't. Yeah. But I wonder if this is engineering specific words. And any company has this tendency of like, look, I know what I'm good at, which is engineering. And you assume that you're going to be good at other stuff as well, which you don't. Sometimes you are.

Sometimes you're not. Yeah. Yeah. Well, I think, you know, a topic that I don't think I've ever written about, 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 in startup mode, when you're talking about not having well-defined 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 process oriented 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, you know, if you don't have the same level of personal energy to correct mistakes, the mistakes linger. They affect more people, affect more downstream products, work products, and it just becomes a much bigger deal. And, you know, when I was at Microsoft, the core Windows team was under 15 people. Of course, this was a much earlier version of Windows,

but at the time there was a project going on it 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 reality is you can get a lot of stuff done with the right 10 people who are all super focused. And even if you just start thinking about it in terms of number of communication paths,

how many people do I have to interact with on a day-to-day hour-to-hour basis of I've got nine or 10 people, how many does it take to make a decision that sticks, how many does it take to fully consider an issue? You know, I hear if I have a decision that on a 10-person team, I need four people to weigh in,

I've now heard everything with four people. if I've got 100 people on the team, I've got, you know, 30 that need to weigh in. That's an entirely different proposition. And 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 training your different people and technology and so on. And if I just think back of, you know, the past like just 20, 30 years, the ones that I've seen, repeatedly, regardless of technology, regardless of, you know, right now we have AI earlier, we have like code generators in terms of tools or, or Intellisense that just auto-complete your thing, you know, all these tools that make teams productive. But whatever tools we have, if I think back from the 90s all the way to like today, we always see these things where there's a, you know,

a five, 10-person team comes out of nowhere, builds this thing. And so, you know, I would think in the gaming, there's the team that built its software. You know, they built Doom with, I think, like, three core people, nine people, and it was a huge hit. Then in social media with Instagram, which was 10 people, Facebook acquired them because they were growing so fast, they would have been bigger on the face of WhatsApp. Again, it was a small team, but I think there were 50 people by the end when they got bought. Right now we have a social media, a platform called Blue Scout. which again, they're with 12 engineers,

they're growing really fast, open AI when they're a small and so on. And it feels that it doesn't really matter what the tech stage is, like, what connects them is, well, energy, focus, yeah, and I've not read anything about this. You know, there's always the interview people and, like, how did you do it?

And they tell you some kind of story. And when you ask people about, like, so right now I have been talking with, like, some people, for example, to open AI, because right now they're the hottest one. I asked them, like, what is it special? How do you ship so fast? Like, Alpuna is still outshipping some smaller startups as a larger organization.

And the answer I get sounds cliche, but they're telling you true. They say, well, it's the people. And how everyone's so focused and motivated. They don't say energy, but yeah, that as well. Yeah. And so during the era I was at Microsoft, I think 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 sweatshop.

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 because, number one, you were developing it at Microsoft. Number two, everybody else who was doing anything interesting wanted to come to Microsoft to show it to you. And so you were constantly in one mode at work where you were seeing the future. And then when you went home or talked to somebody from a different company, they were a year or two behind where you were. So it's incredibly exciting, stimulating place to be.

And of course, you just naturally want to spend all your time working. But you can't replicate that through good management where you're just trying to somehow motivate people that 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 a super high marquee company like Microsoft I was at that time, then 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 it in those companies.

Every once in a while you'll see some individual project where somebody, does a halfway decent job of replicating it for a short time. But yeah, so all the examples that you gave resonate with me because they're all kind of in this same mold of super exciting time to be there. Part of something, you know, you're creating the state of the art, advancing the state of the universe. Unfortunately, it doesn't last forever. And so, you know, it's cool to be a part of it while it lasts.

Yeah, and I think, you know, those of us, for example, I've had opportunities to be part of a team where at the time, I mean, we weren't changing the universe, but we were doing something really exciting and felt we're up against the world. It felt a bit impossible as well. Those are relationships where I still keep in touch with some of the people. You know, like, it's like friendships are made through these crazy times. And it's weird because it is crunch time, but a little bit of self-inflicted, sometimes it's external pressure, but I would never advocate for that, but I'm also very glad that I did it that I had. Like, I do want some times in my life like that.

You know, like, not all the time because that's burnout, but also, like, if you have none of it, like, it's just a nine to five then. Like, I don't want that. 100%. Yeah. And it was funny because we saw the Agile movement go through the same kind of maturing of its view of sustainable pace that my company had gone through. We originally, as a company, really before Agile existed, had started out thinking 40-hour work week. but the first guy that I hired, who ended up being the CTO for 20 years, 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. 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 experienced that, I would really feel like I had missed out on something

if I couldn't have been in that mode, at least some. I came up with this analogy, which is imperfect, but I used to do sports at a competitive level and this involves swimming and running, especially with running, because it is something where you can be injured. You know, when you're training, like you have when you're actually sprinting or you're doing the competition,

but even during training, you're doing that part. You're also doing the kind of endurance part where you're not giving all that. And then you're also like resting. And a coach will instruct an athlete to go like, okay, go all out, give me 70%, give me 50% rest for this much. And if I think about our professional career,

if I had a coach who was looking to maximize my impact on the long term, right? I mean, for athletes, it's only 10 years for us. We have 40 years. they would actually tell me the same. And yet, when we're in a job, we feel that, I mean, either we feel bad about kind of coasting a little bit after, you know, a hard project. But we probably should be doing this. I mean, maybe, you know, don't advertise it because there's a bad stigma these days when you say, like, oh, I'm doing.

But, like, after you do something, like, really tough, et cetera, I mean, yeah, like, it's kind of okay. Yeah. As long as that's not, you're not getting stuck in that, right? Yeah. You know, I didn't really spend that long at Microsoft, but for some reason this keeps coming back to that topic. And I think being part of that is exciting for a while. But as you say, when it becomes a marathon or becomes multiple marathons back to back, it doesn't really work as well. And, you know, Microsoft in that era had a lot of stuff going on that wasn't really that exciting.

And so there's this background culture that people have participated in where they're working themselves to death. And after a couple of years, they're like, I don't really want to do this anymore. And so, you know, there were cases where, as the years went by, they're sort of developed an expectation that that was going to be the work mode. We're now in a completely different space when there's an expectation that it's going to occur rather than just the individuals doing it because that's what they want to do. And Microsoft, because they were so successful, got into a mode where they basically had to go to people on key products and say, you know, we need. you for one more release because we've identified that we need to carry forward at least two of the key people from the last release to be successful in the next release. And they were basically saying, look, we'll give you enough stock to make you rich, but we need you one more release on

this. And so now that's just a completely different vibe on the project than the one before. So you mentioned that one topic you didn't write about maybe it could have been a good idea in hindsight is a rule of energy. I wanted to ask you, Since the second edition has been published, that must have been 20-something years as well, what 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 really gets into the limitation of where I am professionally now. And I really have not been active in software at the Code Complete level 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. I think, you know, we've talked quite a bit in this conversation about design three times. And I think one thing that has worked out really well for Code Complete second edition is really that it is the second edition. and then I published it 11 years after the first edition. And so I think that was really kind of an ideal amount of time between the two editions because I had learned a lot in 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, shorter-lived. And the whole point of the book was to try to capture the longer-lived best practices that would span 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 I think when the second edition came out in,

in 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 XP. Scrum really hadn't emerged as the dominant practice at that point. And so I think one of the challenges for me in the second edition was trying to figure out, okay, well, how much do I really want to talk about Agile and how much do I really want to talk about XP in particular?

I decided, really, I only used XP in one example in the book. So I'm pretty happy with how that worked out. But in the first edition, that consideration had really been about object-oriented because when I was writing the first edition, object-oriented was well-established in academic circles, but not well-established in practice. And so I made a decision to really not do very much with it. And in the intervening 10 years, it became so well-established

that it wasn't really a separate topic. I originally thought I'd have some separate treatment of it, but really it just ended up weaving its way in really throughout the book, and it didn't make sense to try to treat it as a separate topic. So I feel like the first edition had aged more in 10 years than the second edition has aged in 20 years. Yeah, and I actually, like, I just collected a few topics. We don't need to go through, but the things that I thought did not age or actually aged well,

so it's very applicable. The parts are managing complexity. You go through how you can use things like abstraction, clear conventions to reduce cognitive load. Our brains have not gotten bigger in the last 20 years. No, cohesion and coupling, how cohesion within modules, but also loose coupling between the modules

help for more maintainable software also has not changed. I wanted to ask you, like, in the book goes into the value of iteration and continuous improvement. Was this, because I feel, feel this is like, duh, like, this is how we work. But at the time, when you wrote it, was this a bit less accepted still or a bit more novel of India? Because it's interesting to see things that were like today, like, obviously, but these are not how ideas start, right? Yeah, no, it's a really interesting question. And it does take me back to kind of the state of the world in 2004. In 2004,

the reason we were talking about incrementalism and iteration had nothing to do with product delivery. It really had to do with efficient technical practices and a virtuous learning cycle. But kind of around 2004, we started to go from Internet brochureware to actual meaningful, more rich functionality websites. So the idea of CICD wasn't really a concept in 2004. No, too. But we had done work for Amazon in about that same time frame. And at the time, AWS didn't exist, at least not by name. But what we'd observed in the work for Amazon was,

I thought they were okay at the technical programming level, but I thought they were probably the best in the world at operations, as we called it at the time. And their concept of just, if it doesn't work, we'll roll it back. There just weren't a lot of organizations back then that could do that. And so, yeah, in the last 20 years with mobile, well, Internet at first and then mobile and just functionality getting rolled out continuously, these two, what's good for the learning cycle and for containing errors at the development level has merged very nicely with how you

deliver functionality, yeah, the product. Yeah. And so, you know, today, like when I was writing my book, the software engineer, guidebook that was published two years ago. One topic I was really unsure of should I include it or not a little bit to your agile thing was Gen A.I because Chad GPT had come out about a year before, like before, when I finished my manuscript like six months before, and you could already see that it was big. It was great for learning.

It was good at generating code. So I figured, should I add this or not? And in the end, I added it because it felt to me already, all developers I knew were already using it, even if justice explained things. And since then, one of the biggest changes how Gen. AI is becoming, I'm not going to talk about the generic stuff, but for coding, it turns out it is very good at generating code. And for example, in the book, one technique that you encourage, and what I've used before is the pseudocode programming process where you come up with pseudocode. And for example, when you do that, you could, it's great at giving it the more detailed pseudicode the better. And you can tell it generate Java, Kotlin, Rust, whatever.

it does a great job of doing so. So I just want to get your thoughts into the first principles. Now that I know you've not been as embedded in software in the past few years, but knowing that there's this tool, which is very good at generating code, it's a weird intelligence. It's not intelligent per se. It generates the next token, but it does it really well. And what we're seeing is it spits out code really, really quickly,

oftentimes good, sometimes not. I think some people, like I compared when I talk with John Osterhauer with the tactical tornado of doing so. And there is some scare with some developers of like, wow, it's actually coding better than I do.

If you were, you know, like an early career professional in this industry, seeing that there's this tool that is actually good at spitting out code, not perfect, but pretty good code, how would you think of making the most out of it for your career, to understand how to tame this and how this might even change software development if it will. Maybe it won't. Yeah, well, I think it's pretty clear it will. I think it's totally unclear how it will. In my mind, we're still in the pretty early

stages 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 guardrails you put in place, the better result you're going to get. There was a funny LinkedIn post yesterday from somebody who said the learning's about using AI and software are you've got to be really clear about your requirements. You've got to really define your test case as well. You've got to define all the exception cases really well. And the gist of it was, huh, this just sounds like good software development fundamentals. And only we are now, you know, AI is the thing that's finally after 75 years forcing us to do

this. And maybe it hasn't been 75 years that has been. It has been 60 plus. Yeah. So, I mean, I think that that's funny, but it's also true. You know, one of the things that I think is true of software developers is developers are so tech-oriented. If you give them a tool to do something,

that works a lot better than giving them some rules or guidelines. And so if AI is a tool and now to get the tool to work, you've got to go through these software fundamentals, yeah, maybe that is the thing that finally makes that happen. My other feeling about it, and I would love it if you correct me, if you feel like I'm off base on 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? 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 A.A.A. AI isn't 100% lined up with 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. So I have to agree because I think we should not forget. Like obviously, the interesting thing with AI, I talk with the really experienced engineer, Simon Willis, and he created the Django framework. He has a very productive engineer for about 20 or 25 years, just like codes a lot and writes really good code. And he's been using ChatGPC and all the other tools

since they've come out, so coming up three years now. And he told because I asked, like, hey, Simon, is it worth like understanding a theory? Because I took time to understand how this thing works. It's just matrixes everywhere, which is why GPUs works. well with them because it turns out, you know, 3D operations are also just matrix multiplications. So it's a huge matrix that are hard for us to understand and they predict

the next token. And he said, actually, it might be a little bit harmful in his experience because you need to get a feel for how this works because now it does work. And he says that it just takes a lot of time to figure out where it works and where it doesn't. Now, in his case, and I think for a lot of us more experienced engineers, it can be super helpful because as it works, like, I will call BS. I'll be like, this is bad. And it often gets things really bad. So as long as I just use it as like this,

people think about it. I think Ken Beck said he thinks of it as his genie where you ask you, it grants your wish, but sometimes it's really funny ways. Yeah. In really unexpected, for example, you tell like, oh, make this work. And it does or make it work and the test should not fail.

And sometimes it will just go and delete the test when it cannot. When I, early, early in my career on the, when I was at Boeing, we had a CDC cyber supercomputer. And the way the cyber supercomputer was explained to me is it's a very powerful, very literal giant that will do exactly what you tell it to do. And, but it's so literal that it has no ability to do anything other than exactly its interpretation of what you tell it to do. And I kind of feel like AI is in that same space. It's incredibly powerful. And, you know, your comment about sometimes it's glaringly off.

I don't worry about that case. I worry about it being subtly off. Yes. And it is off subtly a lot. So there are already some small stories that are going viral, which are, it could have happened to human, but a good example is startup. You know, they use one of the many agents, which does stuff. It created a PR.

It looked good. And, you know, it's after a while when it generates good stuff, you're like, looks good to me. You commit it. So it just made a small change that added. up observably logging to one of their things that was unnecessary. And this agent cost $500 a month and in a month that generated an extra $800 for nothing. And the guy was like, oh, okay. And I think we're going to see a lot of these things.

I think we'll have to ask ourselves, again, like, what is software engineering? Because now what I'm hearing for teams that are using more of those AI is review and code is super important. Yeah, yeah. But of course, it is hard to, like, I remember when I, again, I worked at Uber is like, the more you got to know an engineer, sometimes you realize they're really reliable. So eventually, in Code Review, we needed two thumbs up or two people to accept.

And when that person came and wrote their stuff and it was a long pull request, you tended to say LGTM looks good to me without reading it. And of course, the shorter it is, we also started to have this rule. I don't have a long poll request because, like, for a 500 line change,

most people were like, looks good to me because I just don't have the mental capacity. For five lines, you get like 50, comment saying, hey, what about this? What about that, et cetera? So it feels like we, I don't know when, but I think we're going to come back to some of the earlier learnings on soft rangeer, because this thing will not change whether it's a machine doing it or whether it's a human doing it or whether a machine that is acting able to take on some things that a human can do, won't go anywhere. Yeah, so sometimes programmers have difficulty just getting started. You mentioned the

pseudocode programming process. I think that's something where AI can be pretty helpful. Your staff to say, hey, look, what are the steps I should, what are the different topics I should consider when I'm designing this? Okay, what sequence would make sense? You can basically dialogue and say, you know, give me 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 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 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 I think, I mean, 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. Yeah, these are definitely also one other thing that seems to be very useful is explaining things. May that be a language, a framework technology.

Obviously, you always need to double check, but some of them are already giving you references. So like, like it can speed you up a lot and help you. And you know, one thing I I'm seeing, it seems to be happening across the industry is engineers are going to be more full stack in the sense of you might remember the time where it was like Java engineer and dot net engineer and they didn't mix. And then later at my time when I, when I started to work, we now had backend engineers work across languages. You could do multiple and I was kind of expected. But still back end and the front and mobile were separate. And now with the help of these things, you know, like a back and then you can generate a mobile poll request and so on.

Yeah, and you know, one of your questions or one of the threads has been kind of what's changed over the years. I think what you just described is a huge change where first edition of code complete, a lot of readers would have learned one programming language when they read the book. By the second edition, maybe, you know, maybe it was more common or more universal for people to have learned two or three. But the idea that it's just assumed that you're going to learn a few because you, you need to be using a few on a day-to-day basis in your job as a full-stack engineer, that's just a complete change. And I think the mental development that goes along with that of understanding what's

common and what's different across languages, I mean, that's just really valuable. Yeah, and I also wonder if it will be really valuable now because I feel, you know, the breath keeps increasing, but don't forget, you know, back in 30 or 40 years ago, the people who learned one language, they were just as smart as the people now. I guess the differences, and they probably store equal knowledge. They need to determine way more details or a lot more this and that. So I wonder if it'll be more really valuable. We now have a lot more breadth for sure.

But you cannot have as much depth. So the people who are able to balance this end, even though you have access to this, you know, genie that can explain everything, actually taking the time to understand and have that mental model, you'll probably go further. Yeah, I think, you know, in thinking about the Fred Brooks' no silver bullets paper,

which is pretty interesting to think about in terms of AI because the whole premise, the whole concept of a silver bullet is any single innovation technology development method that by itself is capable of producing an order of magnitude improvement over 10 year period. You know, AI might very well be the thing that, that is the exception to the rule in that paper. But, you know, the basic argument is that the real world messiness and other sources of essential complexity aren't going away. And unless you find a tool that can deal effectively and utterly reliably with all those details, the corner cases, the off by one cases, all that stuff, you know, programming, we don't get to be approximately

right. We have to be exactly right. And so, you know, that's really, I think, to me, the gist of it. If AI can get to the point where it's exactly right, then, you know, maybe we really do start to replace programming jobs with AI. But the whole history of programming, as languages have gotten more powerful and more expressive, tools have gotten more powerful and more expressive, I think that the defining characteristic of a programmer is being the person whose job it is to figure out what is exactly right. And if AI just basically changes the playing field, so now you're trying to identify what's exactly right with AI generated output, to me, it's almost the same job it always was.

And don't forget that AI generates code, and that code at some point needs to be understood, especially because they can get into loops. You know, again, they can get confused because, again, just how it works once we understand that. So there is valuable, both than that. But also, I feel like there's this thinking as well. I'm not sure I. So try to follow that.

but how, you know, we used to have assembly as the programming language, machine code, then there was C or C++, then we had compiled languages. We have some visual languages or visual basic. And this can be seen as like yet another layer where English translates to this, except it's not a one-on-one-mapping like all the other ones. So it's a lot more thing. We'll see where it goes. It's changing things.

But I think the history of programming has been layers upon layers of. You add an abstraction. more people can get started. I mean, you know, Coble apparently was invented to make it a lot easier for developers to get started. Everything was invented to eliminate programming. All the programming was invented to eliminate programming, including Fortran, yeah.

So I would take what you say, and I would look at it from a slightly different angle, which is I think the history of programming is a history of increasing levels of aggregation. So you started out with assembly or machine-line, language, and then you had aggregation into assembly, and that was one level of aggregation. Then you had aggregation into macro assembly, so it was a second level of aggregation. Then you had this amazing invention called the subroutine, 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. And now, I think you have a combination. of like these reasonable functionality or like things that you know like some of the AI

can definitely spit out things that had seen a lot and actually we even had like some templates so we'll see how it goes but I like this idea I think it makes sense you know and maybe it is truly that above and you know there were lots of attempts to have the next level of aggregation way back when Ada had a notion of packages

and C Sharp had notion namespaces and you know there have been other attempts and maybe there's is an environment out there that I don't know about, which is entirely possible that has done a great job of aggregating packages with their own interface and their own behavioral rules and so on. But, you know, if AI ends up being the way to achieve the next level of aggregation, that would kind of make sense.

Well, maybe, but, you know, don't forget one thing that I think we just didn't need of us mentioned, a huge difference with AI and everything else that came before it is it's nondeterministic. Yeah. And in programming, we have been used to, and I think we've gotten really good at making the most of deterministic. And non-determinism always has its dangers, it's flaws, it's harder to work with. And often, especially when you have a non-determinic system and you want a deterministic outcome, you need to do a bunch of work around that. So maybe that will keep us busy for a while.

And sometimes it's not possible, by the way. As closing, you've had a long and successful career. You've written a book that actually kicks turn at a lot of people. people's careers. I had one of my colleagues from one of my companies tell me that in their first few years as a developer actually served as a military and they read the book and it really helped them. What suggestions would you have for an engineer to have a durable career, principles that worked for you, probably independent of technology? When I was writing the first edition of the book, one of the things I tried to keep firmly in mind was that the guiding principle for writing the book

and the principle it 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 left him out. 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 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 that's, you know, that's 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, 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 I think that's a virtuous thing. And you close the book with how you emphasize how craftsmanship is important for professional growth. And you write how curiosity, continuous learning are essential traits of great software engineers. to me that it feels this is just as relevant as ever. I just think 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 I wouldn't change that. Steve, it's been both a really good conversation and a privilege. Thank you so much. Thanks so much for having me. It was such a blast interview, Steve. After the interview, we grabbed dinner in one of his favorite local restaurants,

and he told me more about why he decided to make a shift and leave the software industry after a successful 30-plus-year career to try something different. Steve's energy levels, positivity, and thoughtfulness run deep, and I hope this came across through the podcast as well. For more observations on how the software engineering industry, has changed the last few decades, check out really deep dyes into Pragmatic Engineer,

which are linked in the show notes below. If you've enjoyed this podcast, please just subscribe on your favorite podcast player and on YouTube. This helps more people discover the podcast, and a special thank you for a rating. Thanks, and see you in the next one.