# The Philosophy of Software Design – with John Ousterhout

An episode of [The Pragmatic Engineer](https://invisiblenetwork.ai/podcast/1769051199), 9 Apr 2025, 1 h 21 min.

Audio: https://api.substack.com/feed/podcast/160951999/f989a39e6084aa27e7e27c94e198a033.mp3

Supported by Our Partners • CodeRabbit — Cut code review time and bugs in half. Use the code PRAGMATIC to get one month free. • Modal — The cloud platform for building AI applications. — How will AI tools change software engineering? Tools like Cursor, Windsurf and Copilot are getting better at autocomplete, generating tests and documentation. But what is changing, when it comes to software design? Stanford professor John Ousterhout thinks not much. In fact, he believes that great software design is becoming even more important as AI tools become more capable in generating code. In this episode of The Pragmatic Engineer, John joins me to talk about why design still matters and how most teams struggle to get it right. We dive into his book A Philosophy of Software Design, unpack the difference between top-down and bottom-up approaches, and explore why some popular advice, like writing short methods or relying heavily on TDD, does not hold up, according to John. We also explore: • The differences between working in industry vs. academia • Why John believes software design will become more important as AI capabilities expand • The top-down and bottoms-up design approaches – and why you should use both • John’s “design it twice” principle • Why deep modules are essential for good software design • Best practices for special cases and exceptions • The undervalued trait of empathy in design thinking • Why John advocates for doing some design upfront • John’s criticisms of the single-responsibility principle, TDD, and why he’s a fan of well-written comments • And much more! As a fun fact: when we recorded this podcast, John was busy contributing to the Linux kernel: adding support to the Homa Transport Protocol – a protocol invented by one of his PhD students. John wanted to make this protocol available more widely, and is putting in the work to do so. What a legend! (We previously covered how Linux is built and how to contribute to the Linux kernel) — Timestamps (00:00) Intro (02:00) Why John transitioned back to academia (03:47) Working in academia vs. industry (07:20) Tactical tornadoes vs. 10x engineers (11:59) Long-term impact of AI-assisted coding (14:24) An overview of software design (15:28) Why TDD and Design Patterns are less popular now (17:04) Two general approaches to designing software (18:56) Two ways to deal with complexity (19:56) A case for not going with your first idea (23:24) How Uber used design docs (26:44) Deep modules vs. shallow modules (28:25) Best practices for error handling (33:31) The role of empathy in the design process (36:15) How John uses design reviews (38:10) The value of in-person planning and using old-school whiteboards (39:50) Leading a planning argument session and the places it works best (42:20) The value of doing some design upfront (46:12) Why John wrote A Philosophy of Software of Design (48:40) An overview of John’s class at Stanford (52:20) A tough learning from early in Gergely’s career (55:48) Why John disagrees with Robert Martin on short methods (1:10:40) John’s current coding project in the Linux Kernel (1:14:13) Updates to A Philosophy of Software Design in the second edition (1:19:12) Rapid fire round (1:01:08) John’s criticisms of TDD and what he favors instead (1:05:30) Why John supports the use of comments and how to use them correctly (1:09:20) How John uses ChatGPT to help explain code in the Linux Kernel — The Pragmatic Engineer deepdives relevant for this episode: • Engineering Planning with RFCs, Design Documents and ADRs • Paying down tech debt • Software architect archetypes • Building Bluesky: a distributed social network — See the transcript and other references from the episode at https://newsletter.pragmaticengineer.com/podcast — Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@pragmaticengineer.com. Get full access to The Pragmatic Engineer at…

## Transcript

[0:00] SPEAKER_00: Right now, there is a huge explosion of AI and LLM tools.
[0:03] SPEAKER_00: How might this change software engineering?
[0:06] There's things that seem relatively clear and things that seem
[0:08] less clear.
[0:09] I think on the relatively clear side is that the AI tools will
[0:12] make it easier to
[0:13] SPEAKER_01: churn out low-level code.
[0:14] SPEAKER_01: You should call it autocomplete.
[0:15] SPEAKER_01: Autocomplete will get better and better.
[0:17] SPEAKER_01: It could actually be reasonably high-quality code that gets churned out.
[0:20] SPEAKER_01: So it seems like that will probably happen.
[0:22] SPEAKER_01: And the big question is,
[0:23] to what degree can the AI tools actually replace the
[0:26] higher-level design tasks?
[0:28] SPEAKER_01: I don't know the answer to that.
[0:30] So far,
[0:30] I don't see anything in the current tools that makes me think
[0:34] they're going to do that.
[0:36] SPEAKER_01: But what's interesting about this,
[0:37] SPEAKER_01: I think,
[0:37] SPEAKER_01: is that by handling more and more of the low-level programming tasks,
[0:42] SPEAKER_01: what software designers do is going to be more and more design.
[0:45] SPEAKER_01: I think software design is going to become more and more important.
[0:48] That'll be a larger and larger fraction of where developers
[0:51] spend their time,
[0:52] which makes it even more sad that we don't really teach
[0:54] software design at our
[0:55] SPEAKER_01: universities at all.
[0:56] John Osterhauld is the author of a philosophy of software
[0:58] design and currently a
[1:00] SPEAKER_00: professor of computer science at Stanford.
[1:02] SPEAKER_00: John Kohl founded two tech companies,
[1:04] SPEAKER_00: worked at some microsystems,
[1:05] SPEAKER_00: created a TCL scripting language,
[1:07] and invented the RAF consensus algorithm that is used across
[1:10] databases and systems
[1:11] SPEAKER_00: like MongoDB,
[1:12] SPEAKER_00: CockroachDB,
[1:13] SPEAKER_00: Kafka,
[1:13] SPEAKER_00: and others.
[1:14] SPEAKER_00: In our conversation,
[1:15] we cover the impact of AI on software engineering and why
[1:19] software design could
[1:19] SPEAKER_00: become more important than before.
[1:22] SPEAKER_00: the concept of deep and shallow modules,
[1:24] and why deep modules are so important to deal with complexity
[1:26] in software,
[1:28] SPEAKER_00: John's advice on error handling,
[1:29] SPEAKER_00: commenting,
[1:30] SPEAKER_00: and why he suggests avoiding test-driven development,
[1:33] SPEAKER_00: and many more topics.
[1:35] SPEAKER_00: If you're interested in practical software design tactics and strategies,
[1:38] SPEAKER_00: and want to take a step back from tactical coding,
[1:41] SPEAKER_00: this episode is for you.
[1:42] If you enjoy the show,
[1:43] please subscribe to the podcast on any podcast platform and on YouTube.
[1:47] SPEAKER_00: Welcome to the podcast.
[1:48] SPEAKER_00: Thank you.
[1:49] SPEAKER_00: I'm excited to be here.
[1:50] SPEAKER_00: You have been working in academia at Stanford for quite a while,
[1:53] SPEAKER_00: but you were in the industry beforehand.
[1:55] SPEAKER_00: What made you change from working at tech companies,
[1:58] SPEAKER_00: from founding your own companies to academia?
[2:00] SPEAKER_00: And why did you do it?
[2:03] SPEAKER_01: I've always wanted to do both academia and industry.
[2:07] SPEAKER_01: When I got my PhD,
[2:08] I debated what to do because I love the creative freedom of
[2:13] academia and I love
[2:14] SPEAKER_01: teaching also.
[2:15] SPEAKER_01: But I also love building real software.
[2:19] SPEAKER_01: Coding is one of the passions that I live for in my life.
[2:22] SPEAKER_01: And so I always kind of figured I'd probably do both over my career.
[2:25] SPEAKER_01: But when I got my PhD,
[2:26] SPEAKER_01: the advice I was given was,
[2:27] SPEAKER_01: if you're going to do both,
[2:29] it's always better to do academia first because it's easier to
[2:31] switch from academia
[2:33] SPEAKER_01: to industry than the other way around.
[2:35] SPEAKER_01: So I went to Berkeley, had a fabulous 14 years there.
[2:37] But over time,
[2:39] this nagging feel for wanting to build commercial software had
[2:42] built up.
[2:43] SPEAKER_01: And so I finally decided to take the plunge.
[2:44] SPEAKER_01: I gave up my position at Berkeley,
[2:46] SPEAKER_01: moved to Silicon Valley,
[2:47] SPEAKER_01: worked at Sun for a few years,
[2:48] SPEAKER_01: started a couple of only moderately successful companies,
[2:52] SPEAKER_01: and had a great time doing that.
[2:54] SPEAKER_01: Just learned a ton of stuff doing startups.
[2:58] But over time,
[2:59] the nagging of the call of industry kind of built up in me.
[3:03] SPEAKER_01: And I gradually realized,
[3:05] SPEAKER_01: although I liked doing startups,
[3:07] SPEAKER_01: that I think being a professor,
[3:09] SPEAKER_01: that's my real true passion in life.
[3:12] So after doing startups for 14 years,
[3:14] I was fortunate enough to get a position at Stanford.
[3:16] And I've had another 14 or 15 years back at Stanford where I've
[3:19] been really happy.
[3:20] SPEAKER_01: So it's been really fun, really fun getting to see both sides.
[3:24] SPEAKER_01: And honestly, I think...
[3:25] SPEAKER_01: You know, doing both has actually made me better at both.
[3:29] SPEAKER_00: What you see,
[3:30] SPEAKER_00: I talk with a lot of people,
[3:32] SPEAKER_00: obviously,
[3:33] who are only in the industry and maybe they're thinking of one
[3:36] day doing academia.
[3:38] SPEAKER_00: I at some point thought of this myself.
[3:40] SPEAKER_00: My dad is a university teacher, was a university teacher.
[3:44] SPEAKER_00: And obviously there's people in academia.
[3:45] SPEAKER_00: Having them both,
[3:47] SPEAKER_00: what are big differences between,
[3:49] SPEAKER_00: you know,
[3:49] SPEAKER_00: as we call the tech world,
[3:50] SPEAKER_00: which is industry and academia?
[3:52] SPEAKER_00: Yeah.
[3:53] Well,
[3:53] first,
[3:53] it wasn't as different as I thought it was going to be when I
[3:56] went to industry.
[3:57] SPEAKER_01: Really?
[3:59] SPEAKER_01: Because in both cases, you're working with a relatively small team.
[4:04] You're trying to do something relatively new,
[4:08] trying to build software that really works.
[4:09] SPEAKER_01: Even when I was in academia,
[4:10] SPEAKER_01: we tried to build stuff that really works,
[4:12] SPEAKER_01: not just throwaway research prototypes.
[4:15] SPEAKER_01: So in many ways, it wasn't that different.
[4:17] SPEAKER_01: But in other ways,
[4:18] SPEAKER_01: it was in that you deal with a much broader spectrum of people,
[4:21] SPEAKER_01: you know,
[4:22] SPEAKER_01: salespeople and marketing people and financers and venture capitalists.
[4:26] That was one of the fun things about it is seeing a much
[4:28] greater diversity of people.
[4:30] SPEAKER_01: I would say the difference that contributed to my going back to academia,
[4:35] SPEAKER_01: I would say one of the downsides of industry,
[4:39] is that there's tremendous pressure in startups particularly to
[4:43] make yourself look
[4:44] SPEAKER_01: bigger and better than you are.
[4:45] SPEAKER_01: You know, you're trying to survive and get funding.
[4:48] SPEAKER_01: And so there's a lot of pressure to...
[4:52] SPEAKER_01: spin your company and exaggerate and market yourself.
[4:57] SPEAKER_01: I mean, everybody does it to some degree.
[4:59] SPEAKER_01: Some people do it in ways so stream it's illegal.
[5:01] SPEAKER_01: They get in trouble.
[5:03] SPEAKER_01: But that kind of bothered me.
[5:06] And within my companies,
[5:08] of course,
[5:08] we had to market ourselves externally.
[5:10] SPEAKER_01: But internally, we tried to be very honest.
[5:12] I don't want to hear lies and spinning internally because that
[5:14] puts our company at
[5:15] SPEAKER_01: risk if you do that.
[5:17] SPEAKER_01: But nonetheless,
[5:18] SPEAKER_01: the thing I like about academia is you do a project,
[5:21] SPEAKER_01: some of them work,
[5:22] SPEAKER_01: some of them don't.
[5:23] If a project doesn't work,
[5:24] you just say,
[5:25] oops,
[5:26] okay,
[5:26] that wasn't a good idea.
[5:27] SPEAKER_01: Here's why.
[5:28] SPEAKER_01: And you go on to the next thing.
[5:29] In a company,
[5:30] if it's not working,
[5:31] you can't really say,
[5:33] oops,
[5:33] that didn't work.
[5:34] SPEAKER_01: Sorry, everybody, we're shutting down tomorrow.
[5:35] SPEAKER_01: You try and somehow figure some way around it.
[5:37] So I think that was the thing,
[5:39] the one thing about industry that I liked least.
[5:42] SPEAKER_00: This episode was brought to you by CodeRabbit,
[5:44] the AI code review platform transforming how engineering teams
[5:47] shift faster without
[5:48] SPEAKER_00: sacrificing code quality.
[5:50] SPEAKER_00: Code reviews are critical, but time consuming.
[5:53] CodeRabbit acts as your AI co-pilot providing instant code
[5:56] review comments and
[5:57] SPEAKER_00: potential impacts of every pull request.
[6:00] SPEAKER_00: Beyond just flagging issues,
[6:02] CodeRabbit provides one-click fix solutions and lets you define
[6:05] custom code quality
[6:06] SPEAKER_00: rules using AST graph patterns,
[6:08] SPEAKER_00: catching subtle issues that traditional static analysis tools might miss.
[6:13] SPEAKER_00: CodeRabbit has so far reviewed more than 5 million pull requests,
[6:16] SPEAKER_00: is installed on 1 million repositories,
[6:19] SPEAKER_00: and is used by 50,000 open source projects.
[6:22] Try CodeRabbit free for one month at coderabbit.ai using the
[6:26] code pragmatic.
[6:27] SPEAKER_00: That is coderabbit.ai and use the code pragmatic.
[6:33] This episode is brought to you by modal,
[6:34] the cloud platform that makes AI development simple.
[6:37] SPEAKER_00: Need GPUs without the headache.
[6:39] SPEAKER_00: With modal,
[6:40] SPEAKER_00: just add one line of code to any Python function and boom,
[6:43] SPEAKER_00: it's running in the cloud on your choice of CPU or GPU.
[6:46] SPEAKER_00: And the best part, you only pay for what you use.
[6:50] SPEAKER_00: With sub-second container start and instant scaling to thousands of GPUs,
[6:54] SPEAKER_00: it's no wonder companies like Suno,
[6:55] SPEAKER_00: Ramp,
[6:56] SPEAKER_00: and Substack already trust modal for their AI applications.
[6:59] SPEAKER_00: Getting an H100 is just a pip install away.
[7:02] SPEAKER_00: Go to modal.com slash pragmatic to get $30 in free credits every month.
[7:07] SPEAKER_00: That is modal.com slash pragmatic.
[7:11] SPEAKER_00: Now,
[7:11] SPEAKER_00: thanks to you having worked in academia as well,
[7:14] SPEAKER_00: and you taught a course,
[7:16] SPEAKER_00: which we'll later talk about,
[7:17] SPEAKER_00: but you wrote this book,
[7:19] SPEAKER_00: The Philosophy of Software Design.
[7:20] And a lot of people in the tech world who I talk with point to
[7:23] this book as one of
[7:25] SPEAKER_00: the best books that gives them specific,
[7:29] SPEAKER_00: actionable things,
[7:30] SPEAKER_00: ways to think about software design.
[7:32] SPEAKER_00: I just want to go into some of the things into the book.
[7:35] SPEAKER_00: People who've read it will find this refreshing,
[7:37] SPEAKER_00: and people who haven't might find it as new ideas.
[7:40] SPEAKER_00: In the very beginning of the book,
[7:42] SPEAKER_00: in chapter,
[7:43] SPEAKER_00: I think two or three,
[7:45] SPEAKER_00: in the first 10 or 15 pages,
[7:46] SPEAKER_00: you write about something called tactical tornadoes.
[7:49] SPEAKER_00: And let me just quote a little bit from this.
[7:53] SPEAKER_00: You wrote,
[7:53] a tactical tornado is a prolific programmer who pumps out code
[7:56] faster than others works,
[7:58] SPEAKER_00: but does it in totally tactical fashion.
[8:00] SPEAKER_00: When it comes to implementing a quick feature,
[8:03] SPEAKER_00: nobody gets it done faster than a tactical tornado.
[8:05] SPEAKER_00: In some organizations, management treats tactical tornadoes as heroes.
[8:09] SPEAKER_00: However,
[8:09] SPEAKER_00: tactical tornadoes leave a wave of destruction behind,
[8:13] and typically other engineers must clean up the messes left by
[8:15] this tactical tornado.
[8:16] So I wanted to ask you,
[8:18] first of all,
[8:18] how did you come across your first tactical tornado?
[8:22] SPEAKER_00: And...
[8:23] Why do you think these types of folks are still around in most companies?
[8:28] Because I had an aha moment when I was like,
[8:30] oh yeah,
[8:31] I know the tactical tornadoes as well.
[8:33] I can't point to a specific incident or person,
[8:36] and I wouldn't want to identify them anyway.
[8:38] SPEAKER_01: But I've encountered them over my career.
[8:40] I bet everybody who has significant software development
[8:43] experience has encountered
[8:44] SPEAKER_01: these people over your career.
[8:46] SPEAKER_01: And just kind of observing them and the frustration with that,
[8:51] SPEAKER_01: I think it's just a particular personality type.
[8:54] SPEAKER_01: There are people who are very detail-focused and closers,
[8:59] SPEAKER_01: want to get absolutely everything right,
[9:00] SPEAKER_01: and they finish everything.
[9:02] And there's people who love getting started on projects and
[9:06] doing the first 80% or 90%,
[9:08] SPEAKER_01: but that last 10% or 20% doesn't matter to them so much,
[9:11] SPEAKER_01: and they're not.
[9:13] You know,
[9:13] there's just like there's neater people and there's sloppier
[9:16] people in the world.
[9:16] SPEAKER_01: So, the technical owners are just sort of sloppy.
[9:18] SPEAKER_01: They don't care about, you know, leaving cruft behind.
[9:21] SPEAKER_01: It doesn't really bother them at all.
[9:23] SPEAKER_01: It's just a personality type.
[9:25] SPEAKER_01: So,
[9:25] SPEAKER_01: I suspect they'll always be there,
[9:27] SPEAKER_01: particularly because some organizations value speed above all else.
[9:33] SPEAKER_00: Especially startups, right?
[9:34] SPEAKER_01: Yeah, a lot of startups.
[9:37] There are startups that are probably completely staffed by
[9:39] tactical tornadoes.
[9:40] SPEAKER_00: You call them tactical tornadoes,
[9:41] but some of the synonyms that came into my mind as I was
[9:46] thinking of what people use,
[9:47] SPEAKER_00: sometimes they use a 10x engineer.
[9:49] SPEAKER_00: Especially when management sees, oh, they just get things faster.
[9:52] SPEAKER_00: Sometimes,
[9:53] SPEAKER_00: you know,
[9:53] like it's a hacky way of doing things or someone who just hacks
[9:56] quickly or at some point,
[9:58] SPEAKER_00: maybe a decade ago,
[9:59] SPEAKER_00: people call it a hacker,
[10:01] SPEAKER_00: but in a way of working fast.
[10:02] SPEAKER_00: But I don't think we have that anymore.
[10:04] SPEAKER_00: But there are a lot of cases.
[10:06] SPEAKER_00: It is a positive thing.
[10:08] SPEAKER_00: Indeed.
[10:09] SPEAKER_00: Well, I was seen as a positive initially.
[10:12] SPEAKER_01: When I think of 10X engineers and the way Google defined it,
[10:15] SPEAKER_01: I don't think of these as tactical tornadoes.
[10:17] I think of these are people who come up with the really clean
[10:20] designs that can be
[10:22] SPEAKER_01: implemented in very small amounts of code.
[10:25] SPEAKER_01: And so they might actually write less code per day than other people,
[10:30] SPEAKER_01: but the functionality that they implement is way higher,
[10:34] SPEAKER_01: and it comes with higher stability and evolvability and so on.
[10:37] SPEAKER_01: So to me, at least, that's the 10X engineer.
[10:41] SPEAKER_00: I agree with you.
[10:42] I'll just add the note that I think the 10x engineer is so
[10:45] ambiguous that it means
[10:46] SPEAKER_00: different for every person.
[10:48] And especially so when I've seen it was mostly less technical
[10:53] CEOs refer to my 10x
[10:55] SPEAKER_00: engineer who was a tactical tornado because what they saw is,
[10:58] SPEAKER_00: oh,
[10:58] SPEAKER_00: I'm getting output.
[10:59] SPEAKER_00: They're not saying no, they're building it.
[11:01] SPEAKER_00: But of course,
[11:02] SPEAKER_00: they had trouble understanding the tech depth that is going into there,
[11:05] SPEAKER_00: how it's slowing others down.
[11:06] And some of the people that you talked about in this
[11:08] environment might have not
[11:09] been perceived as a 10x engineer by this person who is not that
[11:14] close to the code.
[11:15] SPEAKER_00: And I totally agree with you, by the way.
[11:17] SPEAKER_00: But this is probably a good reminder of everything is relative, right?
[11:22] SPEAKER_00: Everything is based on your vantage point.
[11:23] If you are close to the code,
[11:25] you're technical,
[11:26] you will value other things.
[11:27] SPEAKER_00: You should value other things.
[11:28] SPEAKER_00: Yeah.
[11:30] SPEAKER_01: You know, I think a lot of this comes down to strategic versus tactical.
[11:34] SPEAKER_01: Again,
[11:34] there are people who value all the short-term stuff and there
[11:36] are people who value,
[11:38] SPEAKER_01: place more emphasis on the long-term stuff.
[11:40] SPEAKER_01: And my view of design is all about the long-term stuff.
[11:43] But as you've said,
[11:43] there are many people who think of it all in terms of
[11:46] short-term stuff.
[11:47] And so I can see how they would have a different idea of what a
[11:49] 10X engineer is.
[11:51] SPEAKER_00: And speaking of long-term versus short-term,
[11:53] SPEAKER_00: one thing that came to my mind,
[11:55] SPEAKER_00: rereading this tactical tornado part,
[11:58] SPEAKER_00: is right now there's a huge explosion of AI and LLM tools,
[12:02] SPEAKER_00: which are,
[12:03] SPEAKER_00: as you're probably seeing it,
[12:05] SPEAKER_00: they are really good at generating code rapidly.
[12:07] SPEAKER_00: A little bit like the tactical tornado, to be honest.
[12:09] SPEAKER_00: You can prompt them,
[12:10] SPEAKER_00: they can do short,
[12:11] SPEAKER_00: they can do long,
[12:11] SPEAKER_00: they can do autocomplete,
[12:13] SPEAKER_00: they can do all skeletons.
[12:14] SPEAKER_00: I was wondering,
[12:16] SPEAKER_00: so far what you've observed,
[12:17] SPEAKER_00: what do you think the long-term impact of these tools,
[12:21] SPEAKER_00: if we assume that this is how they're going to stay,
[12:22] SPEAKER_00: let's just assume that,
[12:24] SPEAKER_00: you know,
[12:25] every engineer will have tactical tornadoes at their fingertips
[12:28] and who do not say
[12:29] SPEAKER_00: no and they will,
[12:30] SPEAKER_00: you know,
[12:30] SPEAKER_00: churn out code.
[12:32] SPEAKER_00: How might this change software engineering personally?
[12:37] SPEAKER_01: That's a really interesting question, and I wish I knew the answer.
[12:41] SPEAKER_01: I don't.
[12:41] SPEAKER_01: I can only guess.
[12:43] SPEAKER_01: I think we're going to see big changes over the next five to ten years,
[12:47] SPEAKER_01: and it's really hard to predict what direction they're going to go.
[12:51] There's things that seem relatively clear and things that seem
[12:53] less clear.
[12:54] I think on the relatively clear side is that the AI tools will
[12:58] make it easier to
[12:59] SPEAKER_01: churn out low-level code.
[13:01] SPEAKER_01: As you call it, autocomplete.
[13:02] SPEAKER_01: Autocomplete will get better and better.
[13:04] SPEAKER_01: And I think it won't necessarily be sort of tactical tornado stuff.
[13:08] SPEAKER_01: It could actually be reasonably high-quality code that gets churned out.
[13:11] SPEAKER_01: So it seems like that will probably happen.
[13:14] SPEAKER_01: And the big question is,
[13:17] to what degree can the AI tools actually replace the
[13:20] higher-level design tasks?
[13:23] SPEAKER_01: And I don't know the answer to that.
[13:26] So far,
[13:26] I don't see anything in the current tools that makes me think
[13:31] they're going to do that.
[13:32] SPEAKER_01: But never underestimate what could happen.
[13:37] SPEAKER_01: But what's interesting about this,
[13:38] SPEAKER_01: I think,
[13:39] SPEAKER_01: is that by handling more and more of the low-level programming tasks that
[13:45] SPEAKER_01: What software designers do is going to be more and more design.
[13:49] SPEAKER_01: So I think software design is going to become more and more important.
[13:54] That'll be a larger and larger fraction of where developers
[13:56] spend their time,
[13:58] which makes it even more sort of sad that we don't really teach
[14:02] software design in
[14:02] SPEAKER_01: our universities at all.
[14:04] So the skills we're teaching students may actually be the
[14:07] skills that are going to
[14:08] SPEAKER_01: be replaced by the AI tools.
[14:12] SPEAKER_00: Can we just double click on software design?
[14:16] SPEAKER_00: How do you see software design?
[14:18] SPEAKER_00: What is it and why is it important?
[14:21] SPEAKER_00: And the reason I'm asking the question,
[14:23] SPEAKER_00: it might seem like a naive question,
[14:25] but these days you really can get started building an
[14:28] application by taking a template,
[14:32] SPEAKER_00: using it.
[14:33] You will soon be able to prompt an AI tool that will generate
[14:38] things for you.
[14:39] SPEAKER_00: How do you think about it?
[14:40] SPEAKER_00: software design?
[14:43] SPEAKER_00: It's abstract, right?
[14:44] SPEAKER_00: By nature.
[14:44] SPEAKER_01: So, well, I think of it as it's a decomposition problem.
[14:50] SPEAKER_01: It's how do you take a large,
[14:52] complicated system and divide it up into smaller units that you
[14:56] could implement
[14:57] SPEAKER_01: relatively independently?
[14:59] SPEAKER_01: And by the way,
[15:00] SPEAKER_01: to me,
[15:02] SPEAKER_01: when I give talks,
[15:02] SPEAKER_01: I often ask people,
[15:03] SPEAKER_01: what do you think is the most important idea at all of computer science?
[15:06] SPEAKER_01: And ask the audience.
[15:07] SPEAKER_01: To me, I think decomposition.
[15:09] That's the key thing that threads through everything we do in
[15:11] computer science.
[15:12] SPEAKER_01: How do you take large, complicated problems and break them up?
[15:14] SPEAKER_01: And that's design.
[15:15] SPEAKER_01: And then implementation is when you go about the individual pieces.
[15:19] But again,
[15:19] you may do more design of those to break them up into still
[15:22] smaller pieces.
[15:23] SPEAKER_01: But that's the way I think about software design.
[15:26] SPEAKER_00: Now,
[15:26] an interesting thing that I've noticed over the past few
[15:29] decades is about 20 years
[15:32] SPEAKER_00: or so,
[15:33] SPEAKER_00: maybe a little bit more,
[15:34] there was a lot of focus on architectural practices that felt
[15:38] closer to software design.
[15:39] Things like TDD,
[15:40] test-driven development,
[15:42] architecture approaches like architecture patterns.
[15:45] SPEAKER_00: I think they were called design patterns,
[15:46] SPEAKER_00: a gang of four,
[15:47] SPEAKER_00: different like factory,
[15:48] SPEAKER_00: et cetera,
[15:49] SPEAKER_00: patterns.
[15:49] SPEAKER_00: However...
[15:51] SPEAKER_00: The focus seems to be moving away, at least in the industry.
[15:56] SPEAKER_00: There's fewer people referencing these models, these ideas.
[16:00] From your observation,
[16:01] both in academia and industry,
[16:03] why do you think this might have been?
[16:04] Why did we have such a big focus on architecture design topics
[16:09] 10 or 20 years ago?
[16:11] And maybe just we're talking about it less or maybe even
[16:14] thinking about it less.
[16:15] SPEAKER_00: Yeah.
[16:15] SPEAKER_01: Well,
[16:15] SPEAKER_01: you know,
[16:16] SPEAKER_01: of course,
[16:16] there's always fads that everybody gets excited about and they
[16:18] gradually fade away.
[16:20] SPEAKER_01: So maybe that's part of it.
[16:22] SPEAKER_01: Now, to me, the things you mentioned, TDD and patterns...
[16:27] SPEAKER_01: I don't think of those as design, certainly not TDD.
[16:32] In fact,
[16:33] I would argue if you want to get into a TDD discussion,
[16:35] we could have that.
[16:35] SPEAKER_01: But I would argue it actually works against design.
[16:38] SPEAKER_01: Design patterns, that's an alternative to design.
[16:41] That is,
[16:42] rather than designing something,
[16:43] you pull something off the shelf.
[16:46] SPEAKER_01: Where it works, it works.
[16:47] Certainly,
[16:47] there's areas where,
[16:48] of course,
[16:49] if a pattern works,
[16:50] you should just use it.
[16:51] But to me,
[16:51] that only addresses a tiny,
[16:53] tiny fraction of what I think of as software design.
[16:56] There's so much more to design than just picking one of a half
[16:59] a dozen patterns.
[17:00] SPEAKER_00: When you're building new software and you're saying,
[17:05] SPEAKER_00: okay,
[17:05] SPEAKER_00: I'm going to start to design,
[17:07] SPEAKER_00: how do you start designing?
[17:09] SPEAKER_00: Is it sitting down pen and paper?
[17:11] SPEAKER_00: And if we can talk about something specific,
[17:14] SPEAKER_00: I think that could be even useful if there was a project that you did.
[17:18] SPEAKER_00: Because I'm just really curious about your thinking.
[17:21] SPEAKER_01: I can't give a recipe for design.
[17:23] SPEAKER_01: I wish I could.
[17:24] SPEAKER_01: Follow these steps in this order and you'll get a great design.
[17:28] SPEAKER_01: I wish I could.
[17:29] But,
[17:29] you know,
[17:30] there's two general approaches,
[17:32] each of which has its pitfalls.
[17:33] SPEAKER_01: This is the top-down approach and the bottom-up approach.
[17:36] SPEAKER_01: I think what people tend to use,
[17:38] particularly less experienced engineers or people who are in a
[17:43] domain that they're
[17:44] SPEAKER_01: not familiar with,
[17:45] SPEAKER_01: is you do bottom-up.
[17:46] SPEAKER_01: You just say, okay...
[17:48] SPEAKER_01: I'm going to need this functionality in this system.
[17:50] I have no idea what the overall system is going to look like,
[17:52] but I need this piece.
[17:53] SPEAKER_01: I'll just build this piece.
[17:55] SPEAKER_01: Then you pick another piece and you build it.
[17:57] Then you start trying to put the pieces together and you
[17:59] gradually layer in your design.
[18:02] SPEAKER_01: That's the bottom-up approach.
[18:04] The top-down approach is you start at the top and you try and
[18:07] break the system up
[18:08] into what you think are relatively independent components and
[18:10] then decompose those
[18:11] SPEAKER_01: until you eventually get something that you can design.
[18:16] SPEAKER_01: And by the way,
[18:17] SPEAKER_01: in the 1970s,
[18:18] SPEAKER_01: back when I was in graduate school,
[18:19] there was a big discussion about should you do design top-down
[18:22] or bottom-up,
[18:22] SPEAKER_01: and people argued about it.
[18:24] SPEAKER_01: My personal opinion is that it's hard to do either one pure,
[18:27] that the actual process of design is some combination where you
[18:31] think about big pieces,
[18:32] SPEAKER_01: and then you start thinking about some little pieces,
[18:34] SPEAKER_01: and you build some stuff,
[18:35] SPEAKER_01: and you discover it actually didn't work very well,
[18:37] SPEAKER_01: so you throw it away,
[18:38] SPEAKER_01: and you build some more stuff.
[18:39] SPEAKER_01: And it's this iterative kind of back-and-forth process.
[18:42] SPEAKER_01: Yeah.
[18:45] SPEAKER_00: It's interesting that you mentioned the two ways,
[18:48] SPEAKER_00: because in the book,
[18:49] the book itself starts with you writing how design is all about
[18:54] managing complexity,
[18:56] SPEAKER_00: and then you bring these two approaches.
[18:58] SPEAKER_00: What were the two approaches to complexity?
[19:00] So one is that there are certain things you can do in design
[19:03] that simply eliminate
[19:04] SPEAKER_01: complexity completely.
[19:06] SPEAKER_01: Eliminating working on special cases and things like that.
[19:09] SPEAKER_01: So those are the best, most powerful approaches.
[19:12] SPEAKER_01: But you can't eliminate all complexity.
[19:15] SPEAKER_01: So then the second approach is where you use modular design,
[19:19] SPEAKER_01: where you basically try and hide the complexity.
[19:21] SPEAKER_01: That is,
[19:21] you take things that are relatively complicated and put them
[19:24] off to the side where
[19:25] SPEAKER_01: somebody can solve this problem and deal with this complexity,
[19:28] SPEAKER_01: and nobody else in the system has to be aware of that complexity.
[19:32] SPEAKER_01: So those were the two overall ways of dealing with complexity.
[19:37] And good software design will help us deal,
[19:42] like,
[19:43] wrangle complexity,
[19:44] right?
[19:44] SPEAKER_00: Do I sense that that's one of the... It will do with both of those.
[19:47] SPEAKER_01: It will both give you ideas for how to eliminate it and also for how to,
[19:51] SPEAKER_01: again,
[19:52] modularize it so most people don't have to be aware of most of
[19:55] the complexity.
[19:57] One interesting idea that resonated with the book is you wrote
[20:01] about how it's worth
[20:03] SPEAKER_00: designing things twice.
[20:05] SPEAKER_00: In fact, this is a whole chapter in the book, chapter 11.
[20:07] SPEAKER_00: It's called Designing It Twice.
[20:09] SPEAKER_00: And you wrote,
[20:10] SPEAKER_00: I'll quote from you,
[20:12] SPEAKER_00: Unfortunately,
[20:12] I often see smart people who insist implementing the first idea
[20:15] that comes to mind,
[20:16] SPEAKER_00: and this causes them to underperform their true potential.
[20:19] SPEAKER_00: It also makes them frustrating to work with.
[20:23] SPEAKER_00: How did you come across this observation?
[20:26] And one more thing that you added is it doesn't take more time
[20:31] to design twice than
[20:33] SPEAKER_00: what most people think.
[20:36] SPEAKER_01: Yeah.
[20:36] SPEAKER_01: So first,
[20:38] the way I came across this is because I've been a professor at
[20:40] both Stanford and Berkeley,
[20:41] SPEAKER_01: which are two of the top universities in the world.
[20:45] SPEAKER_01: And both places get brilliant graduate students.
[20:48] And I've noticed it's common for students at both places to
[20:51] have bad work habits.
[20:53] And the reason is,
[20:55] all their lives,
[20:56] everything's always been easy for them.
[20:58] SPEAKER_01: They've always been the best at everything they did.
[21:00] SPEAKER_01: In high school, they were smarter than their teachers.
[21:02] SPEAKER_01: In college, perhaps as smart as their professors, top of their class.
[21:06] SPEAKER_01: Their first ideas,
[21:07] just the first thing that came off their mind was always good
[21:09] enough to get great grades.
[21:12] SPEAKER_01: And so there's never been any real incentive for them to think twice.
[21:17] And I think they start kind of latching on to the idea that
[21:21] whatever comes to my
[21:22] SPEAKER_01: mind is going to be good.
[21:24] But,
[21:24] you know,
[21:24] as you get into harder and harder problems,
[21:27] that characteristic goes away.
[21:29] SPEAKER_01: And particularly when we're doing research at top universities,
[21:33] SPEAKER_01: honestly,
[21:33] SPEAKER_01: we're working on really hard problems.
[21:35] SPEAKER_01: Nobody's first idea is going to be the best idea.
[21:38] And so I often have to work with students to force them to
[21:42] think about things.
[21:44] SPEAKER_01: And so, for example, a common technique I will use is I will say,
[21:48] suppose I told you that you may not implement this thing you
[21:51] just suggested.
[21:51] SPEAKER_01: And if you try and do it,
[21:52] SPEAKER_01: I'm going to stop funding you and have you thrown out as a grad student.
[21:56] SPEAKER_01: What would be your second approach?
[21:58] Would you come up with something or would you say,
[21:59] okay,
[21:59] I better look for a new advisor?
[22:02] SPEAKER_01: And the interesting thing is,
[22:03] SPEAKER_01: and by the way,
[22:03] SPEAKER_01: I say this typically when I think there's a better way of doing it.
[22:06] SPEAKER_01: And when I force them,
[22:08] SPEAKER_01: And they go away and come back.
[22:09] SPEAKER_01: The second idea is always better.
[22:11] SPEAKER_01: It's better.
[22:12] SPEAKER_01: And I've seen this myself.
[22:15] The best example I can think of over my whole career was when I
[22:18] was designing the
[22:19] SPEAKER_01: TK Toolkit,
[22:20] SPEAKER_01: which is part of the TK system.
[22:24] And I was trying to figure out what should be the API for
[22:27] programming graphical widgets.
[22:30] SPEAKER_01: And I spent, actually, I think it was mostly a long airplane ride.
[22:35] SPEAKER_01: And I basically did two designs.
[22:37] SPEAKER_01: I did kind of the first idea that came to mind.
[22:40] SPEAKER_01: And then I said, okay, suppose I'm going to throw that out.
[22:41] SPEAKER_01: What would be something that's really different that I could do?
[22:44] SPEAKER_01: I did a second one.
[22:46] SPEAKER_01: And after comparing them, I ended up choosing the second idea.
[22:49] And honestly,
[22:50] that was one of the best ideas I've had in my professional career.
[22:55] SPEAKER_01: One of the things that made TK popular was the API for TK.
[22:58] SPEAKER_01: It was just a very sweet, simple, powerful API.
[23:02] SPEAKER_01: And it was my second choice.
[23:04] SPEAKER_01: It was the second thing that came to my mind.
[23:06] SPEAKER_01: So I have that example.
[23:07] SPEAKER_01: That always motivates me.
[23:09] And when I'm doing new things,
[23:10] I usually try and force myself to think of two ways.
[23:13] SPEAKER_01: Even if I think one of them is really bad,
[23:15] even come up with what you think is a bad alternative and
[23:18] compare it to what you did,
[23:20] SPEAKER_01: you'll learn something from that.
[23:22] SPEAKER_01: And you may discover the bad thing wasn't as bad as you thought it was.
[23:26] SPEAKER_00: I'm actually starting to realize,
[23:28] SPEAKER_00: when I worked at Uber,
[23:29] SPEAKER_00: we had this concept of design docs,
[23:31] SPEAKER_00: RFCs,
[23:32] SPEAKER_00: where you were expected to just write down why you're doing something,
[23:37] SPEAKER_00: how you're doing it,
[23:37] SPEAKER_00: etc.
[23:39] SPEAKER_00: And after a while, we started to add a thing called trade-offs.
[23:44] SPEAKER_00: Or alternatives considered.
[23:46] SPEAKER_00: And we were asking people like,
[23:47] SPEAKER_00: write down at least one,
[23:49] SPEAKER_00: ideally multiple alternatives considered.
[23:52] SPEAKER_00: And we did it because we got better designs,
[23:56] SPEAKER_00: ideas,
[23:56] SPEAKER_00: plans,
[23:57] SPEAKER_00: et cetera,
[23:58] SPEAKER_00: and better discussions as well,
[23:59] SPEAKER_00: because it was clear why you wouldn't do it.
[24:02] SPEAKER_00: And now I'm just reflecting on what you said on like,
[24:05] SPEAKER_00: yeah,
[24:05] SPEAKER_00: well,
[24:05] SPEAKER_00: we were kind of doing a little bit of what you were saying,
[24:08] SPEAKER_00: forcing people to not stop,
[24:10] either not get their first idea or put down others as well and
[24:13] compare them.
[24:14] SPEAKER_00: What you said,
[24:15] SPEAKER_00: oftentimes it will be people just doing,
[24:17] SPEAKER_00: you know,
[24:17] SPEAKER_00: okay,
[24:17] SPEAKER_00: here's some things that will surely not work.
[24:20] SPEAKER_00: And usually, fair enough, it doesn't work.
[24:21] SPEAKER_00: But then sometimes they're like, oh, actually, that's a simple thing.
[24:24] SPEAKER_00: And we could just use that instead.
[24:25] SPEAKER_01: Or maybe we combine these two things together.
[24:27] SPEAKER_00: Yeah.
[24:28] And,
[24:29] you know,
[24:29] you asked about,
[24:29] does this take a lot of time and slow down the process?
[24:32] SPEAKER_01: Well, it will take some extra time, of course.
[24:35] SPEAKER_01: Nothing is free.
[24:36] SPEAKER_01: But honestly, the design at this level is a very high level design.
[24:41] SPEAKER_01: It's not like we're completely building a second alternative.
[24:45] SPEAKER_01: I kind of think at the high level.
[24:47] SPEAKER_01: So with Tickle and TK,
[24:48] SPEAKER_01: this TK design,
[24:49] I might have spent maybe a few days on the design thinking
[24:54] about these two
[24:54] SPEAKER_01: alternatives and comparing them.
[24:56] SPEAKER_01: But then it took a year to implement TK or more than that.
[25:00] So we're talking something on the order of 1% or 2% of the
[25:04] total time to build a system.
[25:07] SPEAKER_01: It's just not that big of a deal.
[25:09] SPEAKER_01: And if it gives you a better design, you get back way more than 1% or 2%.
[25:13] SPEAKER_00: Yeah, I feel this is less than that.
[25:17] SPEAKER_00: People, teams, engineers learn again and again.
[25:20] You know,
[25:20] first,
[25:21] there's always a point where you jump into coding,
[25:22] I'm faster.
[25:23] SPEAKER_00: And then when it's complex enough,
[25:25] SPEAKER_00: you learn,
[25:25] SPEAKER_00: oh,
[25:26] SPEAKER_00: we probably should have planned a little bit better.
[25:27] SPEAKER_00: I would have saved myself time.
[25:28] SPEAKER_00: And then after a while,
[25:30] the cycle goes into like too much planning or people feel it's
[25:34] too much planning
[25:35] SPEAKER_00: and then it starts again.
[25:36] SPEAKER_00: So I feel there's a little bit of never ending cycle,
[25:39] SPEAKER_00: you know,
[25:39] SPEAKER_00: there people still talk about waterfall,
[25:41] SPEAKER_00: which used to be a thing like 20 or 30 years ago.
[25:44] SPEAKER_00: It's not really a thing, but people like
[25:47] SPEAKER_00: There is some disdain,
[25:48] especially for fast-moving teams in planning too much because
[25:51] it's seen as too much
[25:52] SPEAKER_00: talking and not enough doing.
[25:55] SPEAKER_01: Well, and I get that too.
[25:59] I think the fundamental thing about design is it always
[26:01] involves trade-offs.
[26:03] SPEAKER_01: And if you take any one idea and you push it too far,
[26:06] SPEAKER_01: you're probably going to end up in a bad place.
[26:08] So this idea about doing multiple designs,
[26:11] again,
[26:11] you could certainly take that too far also.
[26:14] And I think one of the things that separates the really good
[26:18] designers from the not
[26:19] as good ones is they kind of know how to make those trade-offs
[26:21] and how to combine
[26:23] SPEAKER_01: these different ideas and different phases and balance them off.
[26:26] And that's the kind of thing probably you just have to learn
[26:30] from experience.
[26:31] SPEAKER_01: You try both approaches and see the bad problems with them,
[26:34] SPEAKER_01: and then you eventually get a gut feel for what the trade-offs are.
[26:38] SPEAKER_00: Now,
[26:38] SPEAKER_00: in the book,
[26:39] one idea that stuck with me is this concept of deep modules and
[26:42] shallow modules.
[26:44] SPEAKER_00: And you introduce this concept that a deep module is something,
[26:47] SPEAKER_00: a piece of code or functionality,
[26:50] SPEAKER_00: or a module that has a pretty simple interface,
[26:52] SPEAKER_00: but it has a lot of depth to it.
[26:53] SPEAKER_00: It has a lot of functionality complexity.
[26:56] And then a shallow module is something that has a wide interface,
[26:59] but it doesn't do too much.
[27:01] SPEAKER_00: So it kind of...
[27:03] It might be even transparent in some points that it doesn't do
[27:07] much hiding.
[27:09] And in the book,
[27:09] you emphasize how deep modules are important for good software design.
[27:15] SPEAKER_00: Why is this so?
[27:16] SPEAKER_00: And how did you, again, come across this realization?
[27:19] SPEAKER_01: Well, it all comes back to complexity.
[27:21] And everything in the book really derives from this idea about
[27:25] how do we eliminate
[27:28] SPEAKER_01: or manage complexity,
[27:29] SPEAKER_01: right?
[27:30] SPEAKER_01: And so a deep module is what gives us leverage against complexity.
[27:37] SPEAKER_01: And the way it does that is it provides this very simple interface.
[27:40] So people using the module have almost no cognitive load,
[27:43] very easy to learn.
[27:45] SPEAKER_01: But inside the module,
[27:47] there's a tremendous amount of functionality and complexity
[27:50] that is hidden from
[27:50] SPEAKER_01: everybody else.
[27:54] SPEAKER_01: In the deep notion, I was trying to capture the trade-offs
[27:58] SPEAKER_01: And basically,
[27:59] SPEAKER_01: it's this trade-off between two things,
[28:02] the complexity of the interface and how much functionality you
[28:04] have in the module.
[28:06] And so what you want to do is get the most functionality you
[28:10] can for the simplest
[28:12] SPEAKER_01: possible interface on top.
[28:15] SPEAKER_00: In the book, you have a chapter titled, Defining Errors Out of Existence.
[28:18] SPEAKER_00: And in this one, you talk about error handling.
[28:21] What is your take on error handling and how to design for
[28:25] sensible error handling?
[28:26] SPEAKER_01: Right.
[28:27] SPEAKER_01: So again, this comes back to the complexity issue.
[28:30] And anybody who's built a lot of software knows that error
[28:32] handling is a huge
[28:34] SPEAKER_01: source of complexity.
[28:36] Basically,
[28:37] it's all the special cases,
[28:38] all these weird special cases you have to deal with.
[28:41] And so it's easy for error handling to impose tremendous
[28:44] complexity on software.
[28:46] So then the question I'm constantly asking myself is,
[28:49] how can we reduce error?
[28:51] SPEAKER_01: the impact.
[28:52] SPEAKER_01: I mean, we do have some situations we have to deal with.
[28:54] SPEAKER_01: There's some, you know, there's many exceptions.
[28:57] SPEAKER_01: You simply can't be avoided.
[28:58] SPEAKER_01: They're fundamental to the systems.
[28:59] SPEAKER_01: You have to deal with them.
[29:01] SPEAKER_01: Other cases where they're not so important.
[29:03] SPEAKER_01: So in that chapter, what I was trying to argue is that
[29:07] SPEAKER_01: Exceptions, having more exceptions is not better.
[29:12] SPEAKER_01: It is sometimes necessary.
[29:14] But I sometimes think that designers think that the more
[29:17] exceptions I throw from a class,
[29:19] SPEAKER_01: the better a programmer I'm being.
[29:21] SPEAKER_01: I'm being a more cautious, careful programmer.
[29:23] And I would know the problem is every exception you throw is
[29:27] imposing complexity on
[29:28] SPEAKER_01: the users of your class.
[29:31] SPEAKER_01: And so if you can, if you can reduce the number of exceptions you throw,
[29:37] the number of special cases you generate,
[29:39] that will reduce system complexity.
[29:41] SPEAKER_01: I gave a bunch of examples in that chapter where,
[29:44] SPEAKER_01: in fact,
[29:45] SPEAKER_01: by just a slight change in the design of the system,
[29:49] SPEAKER_01: whole classes of errors simply disappear.
[29:52] SPEAKER_01: They can't happen.
[29:52] SPEAKER_01: There is no error to deal with.
[29:56] SPEAKER_01: But I will say,
[29:56] SPEAKER_01: this is something that happens occasionally,
[30:01] SPEAKER_01: but you have to be very careful about this.
[30:03] SPEAKER_01: And in the class I teach on software design,
[30:07] SPEAKER_01: students have virtually every class,
[30:09] SPEAKER_01: there are people that misunderstand this.
[30:12] SPEAKER_01: And in the first project, they have essentially zero exception handling.
[30:15] SPEAKER_01: They're building a distributed server where machines can crash,
[30:17] SPEAKER_01: and they don't even check for errors in the network.
[30:20] SPEAKER_01: I say, you have no error checks here.
[30:22] SPEAKER_01: What happens if a system crashes?
[30:24] SPEAKER_01: They say, oh, we just defined those errors out of existence.
[30:29] SPEAKER_01: I say, well, no, the errors are still there.
[30:34] SPEAKER_01: You're just ignoring them.
[30:35] SPEAKER_01: You can't do that.
[30:37] SPEAKER_01: So anyhow, I think this is a chapter I have to warn people about.
[30:40] SPEAKER_01: It's really easy to take this one in bad directions.
[30:45] SPEAKER_01: It's kind of like a spice.
[30:47] SPEAKER_01: They use tiny amounts of it in your cooking, and you get a good result.
[30:49] SPEAKER_01: But if you use very much, you end up with a mess.
[30:51] SPEAKER_00: Yeah, but I feel errors, exceptions, things going wrong.
[30:57] They're one of the things that we don't really talk enough
[31:00] about it when we think about design.
[31:03] SPEAKER_00: When I look at outages,
[31:05] SPEAKER_00: I remember a lot of outages that we had specifically at Uber,
[31:08] SPEAKER_00: but even at other companies.
[31:10] A lot of the times when we looked into what caused it,
[31:12] it was like a mishandling of an error.
[31:15] SPEAKER_00: It came from one system.
[31:17] SPEAKER_00: We mapped it incorrectly as a success.
[31:19] SPEAKER_00: And there was a lot of these edge cases which were,
[31:22] SPEAKER_00: We misunderstood either errors or unexpected responses.
[31:26] SPEAKER_00: You know, they're all the same thing.
[31:27] SPEAKER_00: It was something with errors.
[31:28] SPEAKER_00: And I think we struggled to put a finger on it.
[31:30] SPEAKER_00: You know, we looked at ways of like, okay, let's map responses better.
[31:35] SPEAKER_00: Let's have whitelists, let's have blacklists.
[31:39] SPEAKER_00: During the planning phase, I don't really remember.
[31:41] SPEAKER_00: I feel for planning,
[31:43] SPEAKER_00: people tend to be optimistic of,
[31:44] SPEAKER_00: here's how it works,
[31:45] SPEAKER_00: here's how these things will communicate.
[31:47] And I rarely recall planning sessions where we thought,
[31:51] okay,
[31:51] what could go bad?
[31:54] SPEAKER_00: How will we catch it?
[31:55] SPEAKER_00: How will we recover?
[31:57] SPEAKER_01: So it's just- I think you make a good point in that I think people don't,
[32:01] I don't think exception handling is top of people's mind when
[32:06] they are doing the
[32:06] SPEAKER_01: overall system design.
[32:09] It just sort of happens tactically as people discover potential problems.
[32:15] SPEAKER_00: Yes, I think you're putting what I'm trying to put as this observation.
[32:21] SPEAKER_00: It's just a very interesting one.
[32:23] So the one general piece of advice I have for people is that
[32:27] when you're building a
[32:28] module and thinking about what kinds of special cases and
[32:32] exceptions you're going
[32:33] SPEAKER_01: to export through your interface...
[32:36] should think about how you think the callers are going to deal
[32:42] with these and try
[32:43] and put yourself in the mindset of the user as you're thinking
[32:48] through these.
[32:48] SPEAKER_01: And see,
[32:50] SPEAKER_01: rather than having 10 different exceptions,
[32:53] SPEAKER_01: there's only really two different ways people are going to handle this.
[32:56] And so I can boil it all down into two kinds of exceptions
[33:00] rather than 10 kinds of exceptions,
[33:01] SPEAKER_01: for example.
[33:04] So I think the key thing is to think about it from the caller's standpoint.
[33:08] SPEAKER_01: By the way,
[33:09] that brings me to what I think is one of the most important
[33:13] attributes of a really
[33:14] SPEAKER_01: good designer,
[33:16] which is they can change their mindset and think about things
[33:21] from very different
[33:22] SPEAKER_01: point of views.
[33:23] So when I'm designing a module,
[33:26] I'm thinking about all of the details of that module.
[33:29] SPEAKER_01: But then I can change my mindset to think about the user of this module.
[33:34] SPEAKER_01: and realize I don't want to have any awareness of those details.
[33:38] SPEAKER_01: And in particular,
[33:38] SPEAKER_01: when I'm using a module,
[33:40] I don't want to take advantage of things I might know about the
[33:42] inside of that module.
[33:43] SPEAKER_01: I only want to use things in the interface.
[33:46] And so being able to shift your mindset and think about things
[33:50] at one point,
[33:50] but then completely put those out of your mind and take a
[33:53] totally different view
[33:55] SPEAKER_01: some other time,
[33:56] SPEAKER_01: that's really powerful.
[33:57] SPEAKER_01: That's how you come up with good designs, I think.
[33:59] SPEAKER_01: Again,
[34:00] SPEAKER_01: when you're designing something,
[34:01] you can also think about it from the standpoint of somebody
[34:04] that's going to be
[34:05] SPEAKER_01: using it.
[34:07] SPEAKER_00: Interesting.
[34:08] So are you saying that having empathy and being able to put
[34:14] yourself in the shoes
[34:15] SPEAKER_00: of another role,
[34:16] SPEAKER_00: may that be a customer,
[34:18] SPEAKER_00: another developer,
[34:20] SPEAKER_00: another developer who will be working on this,
[34:23] SPEAKER_00: that could make us a better software engineer?
[34:25] SPEAKER_00: I was about to say the word empathy.
[34:28] SPEAKER_01: Yes.
[34:29] What I was going to say is I think this skill set has
[34:32] tremendous value in social
[34:34] SPEAKER_01: context as well as in engineering context.
[34:37] SPEAKER_01: The ability to think about things from some other person's viewpoint.
[34:41] SPEAKER_01: By the way,
[34:42] SPEAKER_01: one of the things I love about computer science,
[34:45] SPEAKER_01: people think of us as these sort of geeky,
[34:48] SPEAKER_01: nerdy people,
[34:50] but many of the ideas that we use in computer systems actually
[34:54] have interesting
[34:54] SPEAKER_01: analogies in social systems as well.
[34:57] SPEAKER_00: Yeah,
[34:58] SPEAKER_00: it's just interesting because when I,
[35:01] SPEAKER_00: you know,
[35:03] SPEAKER_00: I'll start off like you on the software engineering journey,
[35:06] SPEAKER_00: you know,
[35:07] SPEAKER_00: start to learn to code,
[35:08] SPEAKER_00: go to college,
[35:09] SPEAKER_00: get my first job,
[35:10] SPEAKER_00: et cetera.
[35:11] SPEAKER_00: And initially I thought the hard part is the coding.
[35:13] And every developer I talked to or every engineer I talked to
[35:16] above a certain years,
[35:19] we always have this discussion that the hardest part in
[35:21] software engineering,
[35:22] SPEAKER_00: computers and programming is the people.
[35:24] SPEAKER_00: Yeah.
[35:25] SPEAKER_00: You know,
[35:25] SPEAKER_00: when we think back of after your first few years,
[35:28] SPEAKER_00: once you get the syntax and you learn how to debug and those things,
[35:31] SPEAKER_00: you think about what was the hardest project I was?
[35:34] SPEAKER_00: What was the biggest problem?
[35:35] SPEAKER_00: What caused me the most headache?
[35:36] SPEAKER_00: And it's oftentimes miscommunication.
[35:38] SPEAKER_00: You know, like we misunderstood each other.
[35:41] SPEAKER_00: The spec was off, et cetera.
[35:45] SPEAKER_00: Of course,
[35:45] SPEAKER_00: there's outages as well,
[35:46] SPEAKER_00: but usually the root cause is we did not expect this to happen.
[35:50] SPEAKER_00: We didn't have the empathy for the user.
[35:54] And the biggest one is conflicts with teammates,
[35:59] with people that you work with.
[36:01] SPEAKER_00: It's all human things.
[36:03] SPEAKER_00: So it's interesting.
[36:05] SPEAKER_00: There's this joke that the hardest thing in computer science are,
[36:07] SPEAKER_00: I think,
[36:08] SPEAKER_00: caching and naming things,
[36:09] SPEAKER_00: but I will add people as well.
[36:12] SPEAKER_01: Yeah, that sounds interesting.
[36:13] SPEAKER_01: Yep.
[36:15] SPEAKER_00: One thing that in your book you don't touch on,
[36:18] SPEAKER_00: of course,
[36:19] SPEAKER_00: the book cannot touch on anything,
[36:20] but it's a practice that a lot of teams and tech companies use
[36:24] is these things
[36:24] SPEAKER_00: called design reviews and discussions.
[36:26] SPEAKER_00: The idea is that someone before building a system will write down a plan.
[36:31] SPEAKER_00: People will either have a meeting.
[36:33] Amazon famously has this writing culture where people get into
[36:37] a room and they read
[36:39] SPEAKER_00: the plan and then they discuss.
[36:40] SPEAKER_00: In other places, it's done with Google Docs.
[36:43] SPEAKER_00: And even some others like Figma,
[36:45] SPEAKER_00: they use their own tools to kind of like draw visuals and comment on it.
[36:50] SPEAKER_00: What is your take of,
[36:52] SPEAKER_00: before building a system,
[36:55] SPEAKER_00: explaining a plan,
[36:56] SPEAKER_00: either whiteboarding or other ways,
[36:57] SPEAKER_00: and kind of criticizing each other's plans?
[37:00] SPEAKER_00: Have you either done this to some of the things that you do?
[37:03] SPEAKER_00: Do you encourage students in your class on design classes to do this?
[37:07] SPEAKER_01: Oh, yeah.
[37:08] SPEAKER_01: We do this certainly in all the projects I work on.
[37:11] SPEAKER_01: And certainly when I was doing startups, we would do design reviews.
[37:14] SPEAKER_01: They were relatively informal.
[37:16] SPEAKER_01: We didn't have lengthy written documents.
[37:19] SPEAKER_01: But we'd get together and talk about ideas.
[37:22] And this is where,
[37:23] again,
[37:23] you get the multiple designs and you talk about the trade-offs.
[37:27] SPEAKER_01: And it's just...
[37:28] SPEAKER_01: If you can get multiple minds to think about a topic,
[37:32] it's pretty clear you're going to come up with better ideas
[37:35] than if just one person
[37:36] SPEAKER_01: does it.
[37:37] SPEAKER_01: Again,
[37:37] this is an area where smart people sometimes have to get past
[37:40] their history because
[37:42] they've been for much of their life in environments where they
[37:45] couldn't expect to
[37:46] SPEAKER_01: get a lot of useful input from other people.
[37:48] But when you're working at the very highest level with very,
[37:50] very smart people,
[37:52] you know...
[37:54] SPEAKER_01: Two minds are better than one, clearly.
[37:55] SPEAKER_01: So I'm all for it.
[37:56] SPEAKER_01: Again, you don't want to get caught in analysis paralysis.
[38:01] SPEAKER_01: And so trying to figure out what's the right place to do it,
[38:04] SPEAKER_01: how much time to spend on it,
[38:05] SPEAKER_01: there's a certain art to getting just the right level.
[38:07] SPEAKER_01: But I'm all for that.
[38:08] SPEAKER_01: Yeah.
[38:10] And I think this might have changed in the last few years
[38:12] because of remote work.
[38:13] We've had an explosion of remote work,
[38:14] and now it's a bit of a contraction.
[38:16] SPEAKER_00: But I remember before 2020,
[38:19] SPEAKER_00: some of the most innovative companies,
[38:22] SPEAKER_00: when you went into their thing,
[38:23] SPEAKER_00: or startups who were gaining momentum,
[38:25] SPEAKER_00: what they had...
[38:26] SPEAKER_00: is whiteboards and these erasable whiteboards everywhere.
[38:30] SPEAKER_00: And what would happen in these places,
[38:32] SPEAKER_00: actually,
[38:32] I even had one of my older teams where we actually requested a whiteboard,
[38:36] SPEAKER_00: is people,
[38:37] SPEAKER_00: you know,
[38:37] SPEAKER_00: you're just doing your thing.
[38:39] SPEAKER_00: Someone says something, you're like, hold on.
[38:41] And then you go to the whiteboard,
[38:42] you start whiteboarding and,
[38:44] you know,
[38:44] you can erase it.
[38:45] SPEAKER_00: Sometimes you leave it there.
[38:46] SPEAKER_00: Sometimes you photograph it.
[38:47] Basically,
[38:48] it's just like on demand when there's a...
[38:50] It could be any trigger.
[38:51] SPEAKER_00: It could be just mishearing.
[38:53] SPEAKER_00: It can be doing...
[38:54] SPEAKER_00: You just have people come together,
[38:56] SPEAKER_00: do their ideas,
[38:57] SPEAKER_00: and there's something special about,
[39:00] SPEAKER_00: there have been startups who try to replicate this digitally,
[39:02] but there's something special about in-person just getting your
[39:07] ideas out there,
[39:08] especially when we're talking about something like software
[39:10] where boxes and arrows
[39:12] SPEAKER_00: do help.
[39:13] SPEAKER_01: I totally agree.
[39:14] SPEAKER_01: I love whiteboards and I like having meetings that are in person.
[39:18] SPEAKER_01: I've also,
[39:19] SPEAKER_01: over my career,
[39:19] SPEAKER_01: developed a technique for using whiteboards to resolve complex issues,
[39:25] SPEAKER_01: which may or may not even be technical,
[39:27] SPEAKER_01: other kinds of management issues in a company.
[39:30] And what I found is that oftentimes people get in meetings and
[39:32] they just kind of
[39:33] SPEAKER_01: talk past each other,
[39:34] SPEAKER_01: repeat the same arguments and counter arguments.
[39:37] And it just goes round and round and round and never reaches a conclusion.
[39:41] So what I do in these situations is I stand at the whiteboard
[39:46] and basically I list,
[39:48] SPEAKER_01: typically we're arguing for or against something,
[39:51] SPEAKER_01: just list all the arguments for and all the arguments against.
[39:54] And the rule of the discussion is you can make any argument you
[39:58] think is reasonable.
[40:00] SPEAKER_01: No one is allowed to tell you your argument has to be removed.
[40:03] SPEAKER_01: It's a bad argument.
[40:03] SPEAKER_01: Every argument goes on the board.
[40:06] But you are not allowed to repeat an argument that is already
[40:09] on the board.
[40:11] SPEAKER_01: And this is really important.
[40:12] SPEAKER_01: So having the arguments up so everybody can see.
[40:15] SPEAKER_01: Everybody's argument is valid.
[40:17] SPEAKER_01: Everyone's allowed to contribute.
[40:18] SPEAKER_01: No one can stop you from putting your argument on the board.
[40:21] SPEAKER_01: So everybody's arguments goes up.
[40:23] And then the discussion just naturally reaches a point where
[40:25] nobody has anything more to say.
[40:27] SPEAKER_01: And so this shortens the discussion.
[40:30] SPEAKER_01: And then what I do after that is I take a straw poll.
[40:33] SPEAKER_01: And what's amazing to me,
[40:36] SPEAKER_01: you should try this sometime because it's really,
[40:38] SPEAKER_01: it's quite shocking,
[40:40] is that people will be arguing violently on both sides and
[40:43] you'll think there's
[40:44] SPEAKER_01: total disagreement.
[40:46] SPEAKER_01: And then at the end,
[40:47] SPEAKER_01: then we do a straw poll,
[40:48] SPEAKER_01: you tell everybody,
[40:48] you get to weight these arguments in any way that you think is appropriate.
[40:52] SPEAKER_01: You decide which ones you value, which ones you don't value.
[40:55] SPEAKER_01: Should we do A or B?
[40:57] SPEAKER_01: we almost always end up with a really, really strong consensus.
[41:00] SPEAKER_01: It's shocking.
[41:01] Like I said,
[41:02] I'll be in these meetings where I think we have total
[41:04] disagreement here.
[41:05] SPEAKER_01: And then we do the vote and poop, it's unanimous.
[41:09] SPEAKER_00: Well, it sounds, I have not done it.
[41:10] So it's,
[41:11] you know,
[41:11] it sounds one of those things where I don't believe,
[41:13] I wouldn't believe you.
[41:14] SPEAKER_00: I'm sorry.
[41:14] SPEAKER_00: I do believe you.
[41:16] But yeah,
[41:16] as you said,
[41:17] I think,
[41:17] you know,
[41:17] I'm going to try to try this out.
[41:19] SPEAKER_00: It's the whiteboard.
[41:19] SPEAKER_01: It's all about that whiteboard, I think.
[41:22] Yeah,
[41:22] and I think anyone listening or watching,
[41:24] this is why I love these discussions.
[41:27] SPEAKER_00: It's just like getting a tactic that you can try out.
[41:29] And now that more and more companies are doing at least a few
[41:34] days in the office,
[41:34] SPEAKER_00: you get a whiteboard,
[41:35] SPEAKER_00: try it out.
[41:36] SPEAKER_01: By the way,
[41:36] this works best in environments where people are first
[41:41] generally pretty smart and
[41:42] SPEAKER_01: reasonable and goal aligned.
[41:43] SPEAKER_01: Like,
[41:44] SPEAKER_01: you know,
[41:44] SPEAKER_01: in a startup,
[41:44] SPEAKER_01: for example,
[41:45] SPEAKER_01: or an engineering team,
[41:46] SPEAKER_01: you're typically goal aligned.
[41:47] SPEAKER_01: You all want to achieve the same result.
[41:49] SPEAKER_01: You know, would this work in Congress with opposing political parties?
[41:53] SPEAKER_01: No, no, not in political environments.
[41:56] SPEAKER_01: Fortunately, we don't operate mostly in those environments.
[41:59] SPEAKER_00: Well,
[41:59] SPEAKER_00: yeah,
[41:59] SPEAKER_00: and I think,
[42:00] SPEAKER_00: you know,
[42:01] one nice thing about how the tech industry seems to be evolving
[42:03] from my perspective
[42:04] SPEAKER_00: is it's more and more common and accepted,
[42:07] SPEAKER_00: even at large companies,
[42:08] SPEAKER_00: that you do want teams to have clear goals,
[42:10] SPEAKER_00: like have those goals,
[42:11] SPEAKER_00: because if you don't have it,
[42:12] SPEAKER_00: you know,
[42:13] SPEAKER_00: everyone's going to go in different directions.
[42:14] SPEAKER_00: So I think it's becoming more common.
[42:16] SPEAKER_00: Also, companies don't do it.
[42:17] SPEAKER_00: They fizzle out pretty quickly.
[42:19] SPEAKER_00: Yeah.
[42:20] SPEAKER_00: Similar question on design.
[42:23] SPEAKER_00: There's two schools of thoughts when it comes to design.
[42:26] One is let's design up front and the other one is let's not
[42:28] design up front.
[42:29] Let's just do prototyping or just build something and let the
[42:32] code decide.
[42:33] SPEAKER_00: Do you subscribe to either of these approaches?
[42:36] SPEAKER_00: Taking time up front or just dropping into and prototyping?
[42:39] Or have you seen times or types of projects where one just
[42:43] works better than the other?
[42:45] My personal belief is that design permeates the entire
[42:49] development process.
[42:50] SPEAKER_01: You do it upfront,
[42:51] SPEAKER_01: you do it while you're coding,
[42:52] SPEAKER_01: you do it while you're testing,
[42:54] SPEAKER_01: you do it while you're fixing bugs,
[42:55] SPEAKER_01: that you should constantly be thinking about design.
[43:00] SPEAKER_01: I think you should always do at least a little bit of design upfront.
[43:04] SPEAKER_01: Again, not waterfall method.
[43:08] It's important to realize that our software systems are so
[43:11] complicated that we are
[43:13] SPEAKER_01: not able to predict the consequences of our design decisions.
[43:17] SPEAKER_01: We simply can't.
[43:18] But I think it's really important to do some design and to have
[43:22] some hypotheses to work from.
[43:25] SPEAKER_01: And then you start implementing.
[43:27] SPEAKER_01: And of course,
[43:27] SPEAKER_01: once you get in battle,
[43:28] all your plans kind of fall apart and you'll discover lots of
[43:31] problems with it.
[43:32] And so you have to be prepared to revise as soon as you
[43:35] discover problems.
[43:36] SPEAKER_01: But if you don't do any design up front,
[43:37] I think you're wasting your time on code that's just very
[43:41] unlikely to be useful.
[43:43] The only time I'd argue for coding without design is if you're
[43:46] so young and
[43:47] SPEAKER_01: inexperienced that you really have no clue how to do design.
[43:50] SPEAKER_01: Then you may just have to write some code and start learning from it.
[43:54] But in any case,
[43:55] absolutely be prepared to redesign as you discover problems.
[44:00] SPEAKER_00: Yeah.
[44:01] SPEAKER_00: I had one of my colleagues a long time ago, many years ago.
[44:05] He said something super interesting because we were talking
[44:07] about why software is hard.
[44:09] SPEAKER_00: And we were experienced engineers at this point.
[44:11] Why do some projects take a lot longer even if we do proper
[44:14] planning up front?
[44:15] SPEAKER_00: Why are some projects actually pretty easy?
[44:18] SPEAKER_00: And he said something interesting.
[44:18] SPEAKER_00: He's like, software...
[44:20] Like building software is a little bit like we're in a terrain
[44:24] and we need to march
[44:26] SPEAKER_00: to that location.
[44:28] SPEAKER_00: We see the target, but the terrain is unknown.
[44:31] SPEAKER_00: And sometimes you just walk there and it's exactly how you'd expect.
[44:34] SPEAKER_00: Other times you're walking and oh,
[44:36] suddenly there's a big kind of boulder appears out of nowhere
[44:39] and you kind of climb
[44:40] SPEAKER_00: over it.
[44:40] SPEAKER_00: Then another one comes.
[44:41] SPEAKER_00: Sometimes you walk and like a mine explodes right in front of you.
[44:44] And suddenly you have this massive hole and you didn't know
[44:47] this was a minefield.
[44:49] SPEAKER_00: And he said,
[44:50] and this analogy kind of resonated with me because I realized a
[44:55] lot of it is about
[44:57] SPEAKER_00: like how,
[44:58] SPEAKER_00: how much unknowns are unknowns.
[45:00] SPEAKER_00: And the approach is just very different, right?
[45:02] Like if you're building a tech stack or product that you've
[45:04] done before versus
[45:06] SPEAKER_00: something that is completely new,
[45:07] SPEAKER_00: if are using new technology,
[45:09] SPEAKER_00: are using a beta version of a framework that could have issues,
[45:12] SPEAKER_00: but maybe it'll work and so on.
[45:14] Yeah,
[45:15] I think a lot of it has to do whether you're in a domain you've
[45:18] been in before or not.
[45:20] SPEAKER_01: It's not that you got lucky and there was a flat field.
[45:23] SPEAKER_01: I think it's more that,
[45:24] SPEAKER_01: oh,
[45:25] I've actually walked through this mountain range before and so
[45:27] I know the right paths.
[45:29] SPEAKER_01: And so,
[45:30] SPEAKER_01: you know,
[45:30] if you're building a driver for a new device and you've built
[45:34] drivers for five
[45:35] SPEAKER_01: devices before that,
[45:36] SPEAKER_01: you kind of know what the main problems are and the process is much more
[45:40] SPEAKER_01: predictable and smooth.
[45:42] SPEAKER_01: If you're in a new environment...
[45:44] SPEAKER_01: Well, I don't know.
[45:45] SPEAKER_01: Maybe I'm just unlucky,
[45:46] but I don't think I've ever had a smooth experience when I'm in
[45:49] a new environment.
[45:50] SPEAKER_01: It's just too hard to predict.
[45:52] SPEAKER_00: Neither have I.
[45:53] SPEAKER_00: The only kind of new environment,
[45:55] SPEAKER_00: but it's not really a new environment,
[45:56] like a new version of the framework and it's not a big change
[45:59] or a new language release,
[46:02] which is backwards compatible with all the important stuff and
[46:05] you're not using the
[46:05] SPEAKER_00: new features,
[46:06] SPEAKER_00: that kind of stuff.
[46:06] SPEAKER_00: But it's kind of fake, right?
[46:07] SPEAKER_00: It's kind of the same as before.
[46:12] SPEAKER_00: One thing I'd like to get into is the writing of this book.
[46:15] SPEAKER_00: Because again,
[46:16] SPEAKER_00: this book,
[46:17] SPEAKER_00: it feels to me,
[46:17] SPEAKER_00: it has just a lot of really kind of practical insights.
[46:21] SPEAKER_00: Now,
[46:22] SPEAKER_00: first of all,
[46:23] I haven't seen many books written about software design or
[46:26] software architecture specifically.
[46:28] How did you get the idea to even start writing a book about
[46:32] this pretty hard to tangle domain?
[46:37] It's kind of a long process,
[46:38] but the path leads through the course I taught at Stanford.
[46:42] SPEAKER_01: So the background for this is, as I mentioned earlier, I love coding.
[46:46] SPEAKER_01: I'm one of the few professors that still writes large amounts of code.
[46:50] SPEAKER_01: I try to write 5,000 or 10,000 lines of code a year, at least.
[46:52] SPEAKER_01: It's been a significant fraction of my time coding.
[46:55] SPEAKER_01: And I love design.
[46:56] SPEAKER_01: I think design is one of the most amazing, creative...
[47:01] SPEAKER_01: forms that has ever existed in the history of humankind.
[47:04] SPEAKER_01: It's just really fascinating, beautiful, challenging domain.
[47:09] SPEAKER_01: And so I've often, I thought, think about it.
[47:12] I try to think what is a good design and how do I get to,
[47:15] how do I design software that's good?
[47:16] SPEAKER_01: What are the techniques for that?
[47:19] SPEAKER_01: But over time I noticed to my shock, nobody teaches it.
[47:24] SPEAKER_01: Literally other than the course I eventually started at Stanford,
[47:27] SPEAKER_01: I don't think there's a single course anywhere in the world
[47:30] SPEAKER_01: where software design,
[47:32] SPEAKER_01: not tools or processes,
[47:33] SPEAKER_01: but the act of software design is the primary element of the course.
[47:36] And so this just kind of graded on me for,
[47:39] I don't know,
[47:40] a decade or more.
[47:41] SPEAKER_01: And once I got back to academia at Stanford,
[47:44] SPEAKER_01: and now I'd had this experience in industry,
[47:46] so I'd had a lot more software development experience and more
[47:48] ideas myself,
[47:50] SPEAKER_01: I started thinking about this,
[47:51] SPEAKER_01: and I finally decided I'm just going to,
[47:54] SPEAKER_01: who knows what's going to happen,
[47:55] SPEAKER_01: but I'm just going to try teaching a course and see what I can do.
[47:58] And so that forced me to start thinking about my ideas and try
[48:01] and capture them in
[48:03] SPEAKER_01: simple principles.
[48:04] SPEAKER_00: You said no one teaches design.
[48:06] SPEAKER_00: I'll tell you the perspective from someone working at a tech company.
[48:12] Usually we don't interview new grads or people with a few years
[48:16] of experience on
[48:17] SPEAKER_00: software architecture topics.
[48:18] Usually there's interviews coding and then software
[48:20] architecture or design a complex system.
[48:22] SPEAKER_00: And the reason being,
[48:23] SPEAKER_00: well,
[48:24] you need to work in the industry for several years to start to
[48:27] get a sense for this thing.
[48:29] SPEAKER_00: But I have a feeling you kind of, you know, you turned this upside down.
[48:32] SPEAKER_00: You've kind of proven or,
[48:34] SPEAKER_00: well,
[48:34] you're attempting to do with the class that design can be
[48:38] taught even for students
[48:41] SPEAKER_00: who have recently learned to code.
[48:44] What was your approach and what has your response been from the
[48:47] people who've done it,
[48:48] SPEAKER_00: especially now that,
[48:49] SPEAKER_00: you know,
[48:49] some of those folks have been out in the industry for years and
[48:52] I'm sure they're
[48:53] coming back with some of their experience because they now have
[48:55] a skill set that,
[48:56] SPEAKER_00: you know,
[48:56] SPEAKER_00: a lot of their peers do not.
[48:58] SPEAKER_01: Yeah, so I decided to teach this class.
[49:00] SPEAKER_01: And then the question is, well, how do I teach it?
[49:02] SPEAKER_01: And the model I used was my English writing classes from high school.
[49:07] SPEAKER_01: I don't know if this is the way it's still done today.
[49:08] SPEAKER_01: But back when I took English,
[49:10] SPEAKER_01: the way you learn to write is you would get an assignment,
[49:12] SPEAKER_01: you'd write something,
[49:13] SPEAKER_01: your teacher would mark it up.
[49:14] SPEAKER_01: And then you would rewrite it and submit it again.
[49:16] SPEAKER_01: And you might do several iterations on it.
[49:19] SPEAKER_01: And I think the key elements are first getting feedback.
[49:23] SPEAKER_01: So you have somebody that can criticize your work.
[49:27] SPEAKER_01: And then second, redoing to incorporate that feedback.
[49:30] SPEAKER_01: And it's the process of redoing something,
[49:33] SPEAKER_01: I think,
[49:34] SPEAKER_01: where you really internalize the feedback and the concepts.
[49:39] SPEAKER_01: So that's the way the class is taught.
[49:40] SPEAKER_01: It's over a course of a quarter.
[49:42] SPEAKER_01: People do basically three stages where they build something significant.
[49:45] SPEAKER_01: And then we do extensive code reviews.
[49:46] SPEAKER_01: For example,
[49:47] SPEAKER_01: I read every line of code from all the teams in the class,
[49:49] SPEAKER_00: which means that- And what do people build?
[49:51] SPEAKER_00: What is the project?
[49:52] SPEAKER_00: Or what was one of the projects?
[49:54] SPEAKER_01: So actually,
[49:55] the first two projects happen to be the Raft consensus protocol
[49:57] divided up into two phases.
[49:58] And that actually turns out to have some really interesting
[50:01] design problems that
[50:02] SPEAKER_01: confound students and lead to lots of mistakes.
[50:04] So it's this process of,
[50:06] and when they start off,
[50:07] I give them no clues,
[50:08] no hints,
[50:09] no structure.
[50:10] SPEAKER_01: They have to do it completely from scratch.
[50:12] This is the first time in their lives they've ever done
[50:14] anything like that.
[50:15] SPEAKER_01: So it's actually both very fun and very scary for the students.
[50:20] And then we do this extensive code review where they review it
[50:23] in class and other
[50:24] SPEAKER_01: students read their projects and give feedback.
[50:27] And then I read every line of code and I spend about an hour
[50:29] with each team.
[50:30] They typically get 50 to 100 comments from me on their 2,000 to
[50:34] 3,000 lines of code
[50:35] SPEAKER_01: they've written.
[50:36] SPEAKER_01: And then they go back and they rework.
[50:38] SPEAKER_01: And I think that's when the aha moments come from students,
[50:41] SPEAKER_01: when they get the feedback from me where I can point out
[50:45] SPEAKER_01: code that's complicated.
[50:46] SPEAKER_01: People generally know that code is complicated.
[50:48] SPEAKER_01: But then I can point out, here's why it's complicated.
[50:50] SPEAKER_01: Because you didn't follow this principle that we've been talking about.
[50:54] SPEAKER_01: And here's how, if you apply the principle, you can make it simpler.
[50:59] And then they come back with their second projects,
[51:01] and the second projects are so much better.
[51:03] And you can tell the students are really excited because they
[51:08] can kind of feel their power.
[51:10] SPEAKER_01: They can feel that I was able to make this a lot better.
[51:14] And so,
[51:15] you know,
[51:16] I was worried about how the students would react to the class.
[51:18] SPEAKER_01: So it's an extremely positive experience for the students.
[51:21] SPEAKER_01: You can tell over the course of the quarter,
[51:23] SPEAKER_01: the way they think about software has changed really in significant ways.
[51:27] SPEAKER_01: And actually, I warned them at the end of the quarter.
[51:30] SPEAKER_01: I say,
[51:31] SPEAKER_01: I just want to warn you,
[51:31] SPEAKER_01: when you go into companies,
[51:33] you're going to find you know a lot of stuff that people in the
[51:35] companies don't know,
[51:36] SPEAKER_01: even much more senior engineers.
[51:38] So then we talk about how do you deal with that because as a
[51:40] junior employee,
[51:41] SPEAKER_01: you may not have much ability to change the company.
[51:43] SPEAKER_01: But anyhow, so I totally, totally believe design can be taught.
[51:49] SPEAKER_01: Now, you still need experience.
[51:50] It's not like you're not going to be a world-class programmer
[51:53] after one quarter in my course.
[51:54] SPEAKER_01: Oh, yeah.
[51:55] But I think they can start the process in motion and give you a
[51:59] new way of thinking
[51:59] about software that you've never thought about in your classes
[52:02] up till now.
[52:03] SPEAKER_00: Yeah,
[52:03] SPEAKER_00: and I think you can probably,
[52:04] SPEAKER_00: like,
[52:05] SPEAKER_00: my sense is that the students who go through this class and,
[52:09] SPEAKER_00: you know,
[52:10] SPEAKER_00: they build up their experience.
[52:11] SPEAKER_00: They also learn about themselves.
[52:13] SPEAKER_00: They learn how they can challenge themselves, how they can talk about it.
[52:18] SPEAKER_00: Other software developers take,
[52:20] SPEAKER_00: you know,
[52:20] SPEAKER_00: like when you enter the industry,
[52:22] SPEAKER_00: like in the first few years,
[52:23] SPEAKER_00: you're just going to like learn the hard way.
[52:25] SPEAKER_00: Like I remember that when I was a new grad or a junior developer,
[52:30] SPEAKER_00: you know,
[52:30] SPEAKER_00: started out of college,
[52:31] SPEAKER_00: right?
[52:32] SPEAKER_00: I was actually still doing college,
[52:33] but I was working at a workplace and a senior developer told me
[52:37] I need to do this.
[52:37] SPEAKER_00: You know, did the planning.
[52:39] SPEAKER_00: We're going to use this technology.
[52:40] SPEAKER_00: You need to implement this and this.
[52:42] SPEAKER_00: And I just had a bad feeling about it, but I did it.
[52:46] SPEAKER_00: And it just became worse and worse and more and more complicated.
[52:49] And the solution that it was some in-house database and it had
[52:53] performance issues,
[52:54] SPEAKER_00: it got really bad.
[52:56] SPEAKER_00: And the senior developers stepped away.
[52:59] SPEAKER_00: And in the end...
[53:01] SPEAKER_00: Weeks into the project,
[53:02] SPEAKER_00: the customer is frustrated because like a page load took 15 seconds,
[53:07] SPEAKER_00: which is like it's not it was not OK.
[53:10] SPEAKER_00: And then I just like over a weekend, I worked.
[53:13] SPEAKER_00: I must have worked for like, I don't know, 20 plus hours.
[53:15] SPEAKER_00: I just rewrote the whole thing the way I would have done it.
[53:19] SPEAKER_00: And it all of the things were fixed, etc.
[53:21] SPEAKER_00: But.
[53:23] It felt to me like I was kind of like,
[53:25] I was thinking like,
[53:26] am I being crazy?
[53:27] SPEAKER_00: Like, like this experienced person told me to do this.
[53:30] SPEAKER_00: I just didn't really have the vocabulary.
[53:31] SPEAKER_00: I didn't have the, the faith in myself as well that, that I can do this.
[53:37] SPEAKER_00: So, and yeah,
[53:38] SPEAKER_00: Everyone goes through these things eventually, right?
[53:40] SPEAKER_00: Like you kind of learn,
[53:41] SPEAKER_00: you burn yourself,
[53:42] but I feel you might be giving those students a bit of a
[53:45] shortcut to maybe avoid
[53:47] SPEAKER_00: some of these pitfalls.
[53:49] SPEAKER_01: I suspect that experience was really good for you.
[53:52] SPEAKER_01: Oh, it was really good, totally.
[53:53] The opportunity to do it the wrong way and see your gut feeling validated.
[54:00] So next time around,
[54:01] you can probably kind of put some words to that and talk more...
[54:07] SPEAKER_01: with more authority about why that's a problem,
[54:10] and then going back and doing it the right way and seeing how
[54:12] much better it is.
[54:12] SPEAKER_01: I mean, that must have been a really great experience for you.
[54:15] SPEAKER_00: The cool thing is that I think all these things are really good learning.
[54:19] SPEAKER_00: Salvation through suffering, maybe.
[54:21] SPEAKER_00: Yeah, but I feel sometimes that's the most memorable learning, no?
[54:25] SPEAKER_01: Honestly, I think almost all learning is about making mistakes.
[54:31] That the way you learn,
[54:32] the most powerful ways to learn are to make mistakes,
[54:37] SPEAKER_01: see, understand why there are mistakes and then fix them.
[54:40] SPEAKER_01: And to me,
[54:41] SPEAKER_01: education,
[54:42] it's about basically creating a safe space where people can
[54:46] make mistakes and learn
[54:47] SPEAKER_01: from them.
[54:48] SPEAKER_01: And I tell the students in the class about this.
[54:50] I tell them,
[54:50] you know,
[54:50] you're going to get a tremendous amount of criticism.
[54:52] SPEAKER_01: I tell them, I am going to pick every single knit with your coat.
[54:57] SPEAKER_01: You're going to probably be mad at me for things I'm picking,
[54:59] but I'm going to show you every single thing that's wrong
[55:01] because I want you to be
[55:02] SPEAKER_01: aware of that.
[55:03] And one of the things I hope students get out of the class is
[55:06] realizing that's a
[55:07] SPEAKER_01: really productive experience.
[55:09] SPEAKER_01: It's actually good for me to have people come in and challenge me,
[55:12] SPEAKER_01: scrutinize my code,
[55:13] SPEAKER_01: and give me feedback.
[55:13] SPEAKER_01: Because I think a lot of developers out there are kind of sensitive.
[55:18] SPEAKER_01: Maybe they worry that if somebody criticizes their code,
[55:22] SPEAKER_01: maybe that means they weren't such a good coder.
[55:24] Or maybe they think if I have to come up with a second idea,
[55:27] maybe I'm not that smart.
[55:29] SPEAKER_01: Only dumb people have to do things twice.
[55:31] SPEAKER_01: Smart people always get things right the first time.
[55:33] And so then you latch onto this,
[55:34] I can't ever admit that my first idea isn't great.
[55:37] SPEAKER_01: And so I think it's really important.
[55:38] SPEAKER_01: The whole idea of making mistakes is so important and so constructive.
[55:43] SPEAKER_01: We need to honor that, I think, as engineers.
[55:47] slightly different topic but you and uncle bob robert martin
[55:51] had an interesting
[55:52] discussion about his book clean code online where you you you
[55:55] both like wrote uh
[55:58] your thoughts on different parts and there were a few parts
[56:01] where you your opinions
[56:03] diverged and i was interested in getting into some of these so
[56:07] first was on short
[56:09] SPEAKER_00: methods and the methods doing just one thing you know
[56:12] SPEAKER_00: Robert Martin is a big fan of doing so.
[56:15] He's saying this will lead to cleaner code,
[56:17] clear responsibility,
[56:18] and so on.
[56:19] SPEAKER_00: And you had a slightly different take on this.
[56:23] SPEAKER_01: Boy, I sure do.
[56:24] SPEAKER_01: So I mentioned earlier on that design is about trade-offs.
[56:28] And if you take any idea and take it to the extreme,
[56:32] you end up in a bad place.
[56:34] SPEAKER_01: And so I think clean code has done that in many places.
[56:38] SPEAKER_01: This was my biggest overall concern.
[56:41] SPEAKER_01: Method size is one of them.
[56:43] SPEAKER_01: Of course,
[56:43] I think we agree that really long methods are probably harder
[56:47] to understand and
[56:48] SPEAKER_01: deal with than shorter methods.
[56:50] There's some value in shortness,
[56:54] but it isn't the method length per se that's most important.
[56:57] SPEAKER_01: To me, it's this notion of depth.
[56:59] SPEAKER_01: Are we hiding complexity?
[57:01] And so what happened in clean code is that shortness was taken
[57:06] as an absolute good
[57:08] SPEAKER_01: with no limits on it.
[57:09] SPEAKER_01: The shorter, the better.
[57:11] And so a three-line method is better than a five-line method,
[57:14] according to clean code.
[57:16] SPEAKER_01: And the problem with that is that
[57:19] SPEAKER_01: Well,
[57:20] SPEAKER_01: maybe that one method is a little bit easier to understand,
[57:23] SPEAKER_01: but by having shorter methods,
[57:25] SPEAKER_01: you now have a lot more methods.
[57:27] SPEAKER_01: And so you have a lot more interfaces.
[57:29] And now the complexity of the interfaces ends up actually
[57:33] making the system more
[57:34] SPEAKER_01: complicated than it was before.
[57:37] SPEAKER_01: And in particular, his style...
[57:40] SPEAKER_01: He is comfortable if methods are entangled,
[57:44] SPEAKER_01: having multiple short methods where,
[57:46] SPEAKER_01: in fact,
[57:46] they're so entangled that you can't understand one method
[57:50] without actually looking
[57:50] SPEAKER_01: at the code of the other methods at the same time.
[57:53] SPEAKER_00: Yeah, so this might as well.
[57:54] SPEAKER_01: To me, I see no benefit of that.
[57:55] SPEAKER_01: I think, to me, that has made things worse, not better.
[57:58] That if things are really related,
[58:00] you're better off pulling them together.
[58:02] So the thing about the notion of depth is it kind of captures
[58:06] the trade-offs.
[58:07] SPEAKER_01: That we want to have a lot of functionality,
[58:10] SPEAKER_01: but it needs to have a relatively simple interface.
[58:13] And so I think that notion will keep you from going astray in
[58:19] either one direction or the other.
[58:20] SPEAKER_01: Whereas this,
[58:21] SPEAKER_01: for example,
[58:22] SPEAKER_01: the single responsibility principle,
[58:25] SPEAKER_01: the do one thing principle,
[58:26] that just pushes you relentlessly in one direction without any
[58:29] bounds and you get
[58:30] SPEAKER_01: in trouble that way.
[58:32] SPEAKER_00: And it's interesting how you talked about methods being short,
[58:38] SPEAKER_00: doing one thing,
[58:38] SPEAKER_00: and you can have a lot of them,
[58:40] SPEAKER_00: or you can group them and have bigger methods that do more things,
[58:43] SPEAKER_00: but they're more sensible.
[58:44] SPEAKER_00: I was thinking,
[58:45] SPEAKER_00: as you're talking about this,
[58:47] SPEAKER_00: in the industry,
[58:47] SPEAKER_00: we've had a similar thing with microservices.
[58:50] So I happened to work at Uber at the time where it was
[58:52] popularized that the company
[58:54] SPEAKER_00: had more than 5,000 microservices.
[58:56] SPEAKER_00: And we had a lot of really small microservices.
[58:58] SPEAKER_00: And what happened over the years is,
[59:01] SPEAKER_00: at least in my,
[59:02] SPEAKER_00: I cannot speak for the whole company,
[59:03] SPEAKER_00: but I can talk about the domain I was,
[59:04] SPEAKER_00: which was in the payments domain.
[59:06] SPEAKER_00: We had a lot of small services because they were easy to spin up.
[59:09] SPEAKER_00: They did like one thing or two things or a few things.
[59:11] SPEAKER_00: And after a while, we realized like, huh, it's,
[59:14] SPEAKER_00: It's just really tough to maintain,
[59:16] SPEAKER_00: to know which lives there,
[59:18] SPEAKER_00: a lot of communication back and forth.
[59:19] SPEAKER_00: So we started to just pull them together and create,
[59:21] SPEAKER_00: I would say,
[59:23] SPEAKER_00: mid-sized services that kind of had a domain responsibility.
[59:28] SPEAKER_00: And it wasn't either extreme, but I think we saw that one extreme.
[59:32] SPEAKER_00: It sounds good.
[59:33] SPEAKER_00: It sounded really good, by the way, initially, and it has benefits.
[59:36] SPEAKER_00: But over time, it just wasn't as practical.
[59:38] SPEAKER_00: So it's pretty...
[59:39] somewhat similar to what to what you say like extremes on one
[59:43] end are not great
[59:44] it's not great to have like one massive service that does
[59:46] everything you know we
[59:48] uber used to have that it was called api and it did everything
[59:51] and then it got
[59:51] broken into smaller things and then it came back into like kind
[59:54] of domains or
[59:55] reasonably sized one so so you could actually keep track in
[59:58] your head you could
[59:59] understand here are the different parts that are there okay you
[1:00:02] can go inside and
[1:00:04] SPEAKER_00: then you can understand the part so there's i think there's a level of
[1:00:08] SPEAKER_00: When does it make sense?
[1:00:10] SPEAKER_00: How can you follow those kind of things as well?
[1:00:12] SPEAKER_01: I think there's a,
[1:00:13] SPEAKER_01: you know,
[1:00:15] SPEAKER_01: again,
[1:00:15] SPEAKER_01: you can err on both sides,
[1:00:16] SPEAKER_01: but I think these days people often err on the side of over decomposing.
[1:00:20] SPEAKER_01: And I think,
[1:00:22] SPEAKER_01: so clean code,
[1:00:23] SPEAKER_01: for example,
[1:00:24] advocates that what I consider to be over decomposing that
[1:00:26] causes problems.
[1:00:28] And so one of the things I tell my students is often you can
[1:00:32] make something deeper
[1:00:33] SPEAKER_01: by actually combining things together.
[1:00:36] SPEAKER_01: If they were closely related,
[1:00:39] you may discover that if you bring them together into one class
[1:00:41] or one method or
[1:00:42] SPEAKER_01: one module or one subsystem,
[1:00:44] you end up with the combined functionality but with a simpler
[1:00:47] overall API and
[1:00:50] without having two separate things with a lot of dependencies
[1:00:52] between them,
[1:00:52] SPEAKER_01: which is really bad.
[1:00:54] SPEAKER_01: Again, you can overdo this.
[1:00:57] SPEAKER_01: Everything is trade-offs,
[1:00:58] but you can often make things better by making the units a
[1:01:01] little bit larger.
[1:01:02] Another area of disagreement was test-driven development that
[1:01:06] we touched on a little bit.
[1:01:09] SPEAKER_00: Robert Martin is a big fan of using TDD as a way to write code,
[1:01:13] SPEAKER_00: write the test first,
[1:01:14] SPEAKER_00: then write the code that makes it pass.
[1:01:16] SPEAKER_00: This method was also pretty popular in the early 2000s.
[1:01:20] SPEAKER_00: It's kind of gotten a little bit out of style.
[1:01:22] SPEAKER_00: Your take was different as well.
[1:01:25] SPEAKER_01: Yeah, I'm not a fan of TDD because I think it works against design.
[1:01:30] SPEAKER_01: So again, to me, tests are important.
[1:01:32] SPEAKER_01: I love unit tests.
[1:01:33] SPEAKER_01: I write them for everything I do.
[1:01:34] SPEAKER_01: They're essential.
[1:01:35] If you're a responsible developer,
[1:01:37] you write unit tests with very high coverage.
[1:01:39] SPEAKER_01: So let's agree on that.
[1:01:42] SPEAKER_01: But we want the development process to be focused on design.
[1:01:45] I think that should be the center of everything we do in
[1:01:48] development should be
[1:01:49] SPEAKER_01: organized towards getting the best possible design.
[1:01:52] And I think TDD works against that because it encourages you to
[1:01:56] do a little tiny
[1:01:57] SPEAKER_01: increment of design.
[1:01:58] I write one test and then I implement the functionality to make
[1:02:02] that test pass.
[1:02:03] SPEAKER_01: Then I write one more test.
[1:02:06] SPEAKER_01: and write the functionality to make that test pass.
[1:02:08] There's no point in the process where you're encouraged to step
[1:02:11] back and think
[1:02:12] SPEAKER_01: about the overall task,
[1:02:14] SPEAKER_01: the big picture.
[1:02:16] SPEAKER_01: How do all these pieces fit together?
[1:02:18] SPEAKER_01: What's the most pleasing,
[1:02:19] SPEAKER_01: simple,
[1:02:20] clean architecture that will solve 10 problems rather than
[1:02:24] coming up with 10 point
[1:02:26] SPEAKER_01: solutions to individual problems?
[1:02:28] And so it results in what I believe the risk is you can end up
[1:02:32] in an extremely
[1:02:33] SPEAKER_01: tactical style of development that produces just a horrible mess.
[1:02:37] SPEAKER_01: So that's my concern.
[1:02:39] SPEAKER_01: And we had this long back and forth about it.
[1:02:40] And I think the main reason that Bob likes TDD is it ensures
[1:02:45] that the tests get
[1:02:46] SPEAKER_01: written because you have to write the test before the code.
[1:02:49] SPEAKER_01: And so I agree the test should be written.
[1:02:51] But I don't think there's anything – he was not able to
[1:02:53] convince me that there's
[1:02:54] SPEAKER_01: any particular advantage
[1:02:56] in writing the test before the code other than ensuring that
[1:02:59] the tests get written.
[1:03:01] SPEAKER_01: I can't see any reason that makes the design better.
[1:03:03] SPEAKER_01: And I can see a lot of reasons why it might make the design a lot worse.
[1:03:07] I think an interesting question is,
[1:03:08] what should be your units of development?
[1:03:10] SPEAKER_01: Development is always in chunks of work.
[1:03:12] SPEAKER_01: What should those chunks be?
[1:03:13] And I would argue those chunks should be abstractions,
[1:03:17] not individual tests.
[1:03:18] SPEAKER_01: That's too small of a chunk again.
[1:03:20] SPEAKER_01: You want to think in a big enough chunk that you can consider trade-offs
[1:03:26] and try and come up with a fairly general purpose solution that
[1:03:29] will solve many problems.
[1:03:32] SPEAKER_01: By the way,
[1:03:33] SPEAKER_01: one of the most important elements of design,
[1:03:36] SPEAKER_01: I think,
[1:03:36] is pushing yourself towards general purpose to avoid
[1:03:39] specialization as much as you
[1:03:40] SPEAKER_01: possibly can.
[1:03:42] And so the TDD approach encourages you to do something very
[1:03:45] specialized to pass
[1:03:46] each test rather than thinking about the general purpose thing
[1:03:49] that solves many
[1:03:50] SPEAKER_01: problems in one place.
[1:03:51] SPEAKER_00: Oh, all right.
[1:03:53] SPEAKER_00: Yeah, that is true.
[1:03:54] SPEAKER_00: That is true.
[1:03:54] SPEAKER_00: In fact,
[1:03:55] I remember at some point when we did some TDD mobbing where we
[1:03:59] would pass the
[1:03:59] SPEAKER_00: keyboards around and someone would write a test,
[1:04:02] SPEAKER_00: someone would make it pass.
[1:04:03] It felt a bit artificial because when you wrote more code that
[1:04:07] you needed to come,
[1:04:08] SPEAKER_00: they're like,
[1:04:08] SPEAKER_00: no,
[1:04:09] SPEAKER_00: don't write that.
[1:04:09] SPEAKER_00: That doesn't make, just make the test pass.
[1:04:11] SPEAKER_00: So it almost felt a little bit of artificial.
[1:04:14] SPEAKER_00: And again,
[1:04:15] SPEAKER_00: I'm sure there are times and cases where it could be useful,
[1:04:18] SPEAKER_00: maybe in a more formal way,
[1:04:20] SPEAKER_00: maybe where it's more about adding,
[1:04:23] SPEAKER_00: extending additional code where it's like very heavy in business logic.
[1:04:26] SPEAKER_00: Maybe that could be a good fit, but...
[1:04:30] There might be a reason that it kind of slowly became less
[1:04:33] popular and we're not
[1:04:34] SPEAKER_00: talking about it too much these days.
[1:04:35] The one place where I'd recommend writing the test first is
[1:04:40] when you're fixing a bug.
[1:04:42] SPEAKER_01: I would argue write the test that will detect the bug and then fix it.
[1:04:47] Although actually what I typically do is I honestly I kind of
[1:04:50] cheat on this one.
[1:04:52] SPEAKER_01: I write the fix and then I write the test for the fix.
[1:04:57] SPEAKER_01: And then I back out the fix and make sure the test fails.
[1:05:02] But anyhow,
[1:05:03] that's one place where I think doing the test early can be useful.
[1:05:08] SPEAKER_00: Now, one more area that you disagreed is comments.
[1:05:11] So Uncle Bob says,
[1:05:15] unsurprisingly,
[1:05:16] that you should have as few comments in the code.
[1:05:18] SPEAKER_00: The code should speak for itself.
[1:05:21] SPEAKER_00: You also did not fully subscribe to this one.
[1:05:24] SPEAKER_01: If the code could fully speak for itself, that would be wonderful.
[1:05:27] SPEAKER_01: I would have no objection.
[1:05:29] SPEAKER_01: But it can't, and it never will, as far as I'm concerned.
[1:05:32] SPEAKER_01: There's just so much stuff that can't be described in the code itself.
[1:05:37] SPEAKER_01: And we ended up discussing examples where he said, look at this code.
[1:05:40] SPEAKER_01: It needs no comments, right?
[1:05:41] And then I said,
[1:05:43] well,
[1:05:43] here's five questions people have that I don't see answered in
[1:05:45] this code.
[1:05:48] SPEAKER_01: Then he kind of hedged about that.
[1:05:49] SPEAKER_01: I don't know.
[1:05:52] SPEAKER_01: He's very, very biased against comments.
[1:05:54] SPEAKER_01: I'm not sure why, if he has some scarring experience.
[1:05:59] I believe he basically said he thinks that people lose more
[1:06:04] time by being misled by
[1:06:06] comments that are out of date than time lost because you
[1:06:11] haven't had adequate comments.
[1:06:13] SPEAKER_01: That certainly is not my experience.
[1:06:16] SPEAKER_01: Occasionally there are comments that are out of date,
[1:06:18] SPEAKER_01: but rarely and even then there's usually useful information.
[1:06:22] SPEAKER_01: And then he also argued that,
[1:06:24] SPEAKER_01: well,
[1:06:24] SPEAKER_01: if you're working on a project that you and other developers work,
[1:06:27] you don't need any comments because everybody's got it all
[1:06:29] loaded into their minds.
[1:06:31] SPEAKER_01: And I just don't agree with that.
[1:06:33] SPEAKER_01: Now,
[1:06:33] SPEAKER_01: maybe his mind is better than my mind,
[1:06:35] SPEAKER_01: but,
[1:06:36] SPEAKER_01: you know,
[1:06:36] I can't keep everything in my mind that I forget code within a
[1:06:39] few weeks of when
[1:06:40] SPEAKER_01: I've written it.
[1:06:40] SPEAKER_01: So I need those comments.
[1:06:42] So the bottom line is there's just a lot of stuff that you
[1:06:45] can't get from the code.
[1:06:46] SPEAKER_00: And then what is your kind of approach on like, how do you do comments?
[1:06:51] SPEAKER_00: What do you like to put into comments?
[1:06:53] Or is it just like whenever you feel like it just put there
[1:06:55] because it's going to
[1:06:57] SPEAKER_00: be additional information that could help later?
[1:06:58] SPEAKER_00: Yeah.
[1:07:00] SPEAKER_01: Well,
[1:07:00] SPEAKER_01: again,
[1:07:01] the number one rule is comments should tell you things that
[1:07:04] aren't obvious from the code.
[1:07:08] SPEAKER_01: There are a lot of bad comments out there where people are basically just
[1:07:11] SPEAKER_01: duplicating stuff that's obvious from the code.
[1:07:13] SPEAKER_01: So no need for comments in those situations.
[1:07:16] SPEAKER_01: In my student projects in my class,
[1:07:18] SPEAKER_01: I often take comments out,
[1:07:19] SPEAKER_01: tell students,
[1:07:19] SPEAKER_01: this comment just repeats the code.
[1:07:20] SPEAKER_01: You don't need it.
[1:07:22] SPEAKER_01: I think where comments are most important is for interfaces.
[1:07:25] SPEAKER_01: This is where they're really, really important because...
[1:07:29] The assumption of interface is you don't want people to have to
[1:07:31] read the code of
[1:07:32] SPEAKER_01: the thing that you're communicating with,
[1:07:35] SPEAKER_01: talking with.
[1:07:35] SPEAKER_01: You just want to look at the interface.
[1:07:38] It is impossible in the functional signatures of a module to
[1:07:44] provide all the
[1:07:44] SPEAKER_01: information people need to use that module.
[1:07:47] SPEAKER_01: That's where comments are most important there.
[1:07:49] SPEAKER_01: To me, that's the most important.
[1:07:51] The second most important thing is documenting the member
[1:07:54] variables of classes.
[1:07:56] SPEAKER_01: That needs really extensive documentation.
[1:07:58] SPEAKER_01: And then I tend to find that inside methods,
[1:08:02] I don't tend to need a lot of comments because if you know what
[1:08:05] the method's trying
[1:08:06] SPEAKER_01: to do,
[1:08:06] SPEAKER_01: the code typically speaks for itself pretty well there.
[1:08:11] I tend to have comments where things are tricky or where there
[1:08:13] was unexpected stuff
[1:08:14] SPEAKER_01: I'd only discovered when there were bugs and things like that.
[1:08:17] SPEAKER_01: But often my methods won't have any internal comments.
[1:08:20] SPEAKER_01: They'll just be the interface comment.
[1:08:22] SPEAKER_00: I think comments are going to have a bit of a resurgence of this debate,
[1:08:26] SPEAKER_00: potentially,
[1:08:27] SPEAKER_00: because AI tools increasingly generate more code.
[1:08:30] SPEAKER_00: They often generate whole methods.
[1:08:33] SPEAKER_00: And what I'm noticing is when I'm telling one of these AI assistants,
[1:08:38] SPEAKER_00: like generate something that does this for me,
[1:08:40] SPEAKER_00: it generates the code,
[1:08:40] SPEAKER_00: but it often adds inline methods,
[1:08:42] SPEAKER_00: which explains what it does.
[1:08:44] SPEAKER_00: And actually,
[1:08:45] SPEAKER_00: in that case,
[1:08:45] SPEAKER_00: because it's just coming so quickly,
[1:08:47] SPEAKER_00: it actually kind of helps me because I'm
[1:08:50] SPEAKER_00: I know these tools hallucinate,
[1:08:52] and I actually want to make sure what it does so it kind of
[1:08:54] helps me understand.
[1:08:56] SPEAKER_00: At the same time, it's a good question of why it's doing it.
[1:08:58] SPEAKER_00: You know,
[1:08:58] SPEAKER_00: these are trained on typically code that's out there,
[1:09:01] SPEAKER_00: either open source or who knows what kind of licensing.
[1:09:04] SPEAKER_00: So it probably is copying however it's seen it.
[1:09:08] SPEAKER_00: But this,
[1:09:10] SPEAKER_00: you know,
[1:09:11] SPEAKER_00: usually I would agree with you,
[1:09:12] SPEAKER_00: but in this case,
[1:09:13] SPEAKER_00: maybe comments are not a bad thing.
[1:09:15] SPEAKER_00: Who knows?
[1:09:16] SPEAKER_00: It's an interesting area.
[1:09:17] SPEAKER_01: Yeah, so I...
[1:09:19] I'm a little hesitant to say this because I'm fearing I may be
[1:09:22] justifying bad habits.
[1:09:23] But one thing I found is that AI tools can,
[1:09:28] to some degree,
[1:09:29] compensate for the lack of comments.
[1:09:31] So I've been working in the Linux kernel,
[1:09:34] building a new network transport.
[1:09:36] SPEAKER_01: And you know,
[1:09:38] SPEAKER_01: Linux kernel is not a bad piece of software,
[1:09:40] SPEAKER_01: but it's pretty significantly under commented in my view.
[1:09:43] And I spent a lot of my time just trying to figure out what is
[1:09:46] going on in Linux.
[1:09:47] SPEAKER_01: What are the interfaces?
[1:09:48] SPEAKER_01: How do I hook into this?
[1:09:49] SPEAKER_01: ChatGPT has become my very best friend.
[1:09:53] It's amazingly capable at answering questions about the Linux
[1:09:57] kernel that I can't
[1:09:58] SPEAKER_01: answer via Google search or any other way.
[1:10:01] SPEAKER_01: It's not always correct.
[1:10:02] SPEAKER_01: Sometimes it hallucinates, but it's often right.
[1:10:05] SPEAKER_01: And even when it's wrong,
[1:10:07] it typically gets me in the right vicinity and helps me to
[1:10:10] figure out where to look
[1:10:11] SPEAKER_01: to figure out how to answer my questions.
[1:10:13] SPEAKER_01: So I think the AI tools may be able to help.
[1:10:18] SPEAKER_01: But even saying that,
[1:10:20] SPEAKER_01: if the Linux had just spent a little,
[1:10:22] SPEAKER_01: a tiny amount of time putting comments in,
[1:10:24] it would have made things so much easier than using ChatGPT to
[1:10:28] try and figure it out.
[1:10:29] SPEAKER_01: So I don't think the need for comments is going to go away completely.
[1:10:33] And we shouldn't use AI tools as an excuse for people not to
[1:10:36] write comments.
[1:10:36] SPEAKER_01: At least not yet.
[1:10:40] SPEAKER_00: So before the podcast,
[1:10:41] one interesting thing that you mentioned is you are actively
[1:10:44] writing code.
[1:10:44] In fact,
[1:10:45] after this podcast,
[1:10:46] I think you're going to be getting back to writing code.
[1:10:49] SPEAKER_00: What are you working on right now?
[1:10:51] SPEAKER_00: You mentioned something with the Linux kernel.
[1:10:53] SPEAKER_01: Yeah.
[1:10:54] SPEAKER_01: So one of my PhD students,
[1:10:56] SPEAKER_01: Ben Montessori,
[1:10:57] SPEAKER_01: as his PhD dissertation six or eight years ago,
[1:11:01] SPEAKER_01: developed a new transport protocol called HOMA,
[1:11:03] SPEAKER_01: H-O-M-A.
[1:11:05] SPEAKER_01: which is intended for use in data centers.
[1:11:07] SPEAKER_01: And the results he got in his dissertation are really fabulous.
[1:11:10] It's 10 to 100 times faster than TCP for a whole lot of
[1:11:13] interesting cases.
[1:11:15] SPEAKER_01: And so rather than let this just come and go as a
[1:11:20] SPEAKER_01: PhD project that nobody ever cares about.
[1:11:21] I've taken it as my own personal project to see if it is
[1:11:25] actually possible to bring
[1:11:26] this into widespread use and displace some of the TCP traffic
[1:11:30] in data centers.
[1:11:31] So I have developed a Linux kernel implementation of that,
[1:11:34] which I'm continuing to enhance.
[1:11:36] SPEAKER_01: And I'm now in the process of upstreaming that into the kernel.
[1:11:40] And so actually what I'm really dealing with is a whole bunch
[1:11:41] of comments I've
[1:11:42] gotten from the Linux kernel developers about this and trying
[1:11:44] to fix all the
[1:11:45] SPEAKER_01: problems they pointed out.
[1:11:46] SPEAKER_01: Here's another example of code reviews and the benefits of all of that.
[1:11:50] SPEAKER_01: And indeed,
[1:11:50] SPEAKER_01: this afternoon,
[1:11:51] I'm getting ready to submit my next round of patches to the
[1:11:55] NetDev mailing list.
[1:11:56] SPEAKER_00: How are you finding,
[1:11:57] is this your first contribution to a Linux kernel or have you
[1:11:59] previously worked on it?
[1:12:01] SPEAKER_01: Yeah, this is my first involvement with a Linux kernel.
[1:12:04] SPEAKER_00: How are you finding the process?
[1:12:05] SPEAKER_00: Because we just had an episode on Linux.
[1:12:09] SPEAKER_00: with one of the main Linux kernel maintainers.
[1:12:13] SPEAKER_00: And I'm curious, is it overwhelming?
[1:12:16] SPEAKER_00: Is it easier?
[1:12:17] SPEAKER_00: Is it harder than what you thought?
[1:12:18] So I've been warned that it might be difficult and painful and
[1:12:22] take a long time.
[1:12:25] SPEAKER_01: It's taking a fair amount of time.
[1:12:27] I think it's been,
[1:12:29] we may be coming up on six months since I made my first
[1:12:31] submission of this.
[1:12:32] SPEAKER_01: But I have to say that the people have been very reasonable.
[1:12:37] SPEAKER_01: And the feedback I've gotten has been high quality feedback.
[1:12:40] SPEAKER_01: So I've had to fix a lot of things.
[1:12:42] But these were all things where either I misunderstood
[1:12:45] something about the kernel
[1:12:47] or they show me better ways to do it or pointed out
[1:12:50] complexities in my design,
[1:12:51] SPEAKER_01: which there were plenty of.
[1:12:53] SPEAKER_01: And so I have no objection to the process so far.
[1:12:56] SPEAKER_01: And I'm actually pretty happy with it.
[1:12:59] SPEAKER_01: And HOMA is getting a lot better because of this.
[1:13:01] I hope will eventually reach closure and it'll find its way
[1:13:04] into the kernel.
[1:13:05] SPEAKER_01: But it has seemed pretty reasonable to me so far.
[1:13:09] SPEAKER_00: This is really encouraging to hear and good luck with that.
[1:13:13] What are ideas from the history of software design or even
[1:13:16] software engineering
[1:13:17] that you think might make a renaissance in the near future as
[1:13:20] we're looking at
[1:13:22] SPEAKER_00: focus on tooling,
[1:13:22] SPEAKER_00: distributed systems,
[1:13:24] SPEAKER_00: obviously AI tooling?
[1:13:26] I'm not sure I can think of any idea that has come and gone and
[1:13:30] is going to come back again.
[1:13:31] SPEAKER_01: So I think,
[1:13:34] SPEAKER_01: you know,
[1:13:34] I think there are ideas that have come and gone because we've
[1:13:37] learned how to do
[1:13:38] SPEAKER_01: things better.
[1:13:41] SPEAKER_01: But hopefully we're getting better and better at this.
[1:13:44] SPEAKER_01: We're not just oscillating from good to bad, good to bad, back and forth.
[1:13:47] SPEAKER_01: So I can't think of,
[1:13:50] SPEAKER_01: there's no idea I can think of,
[1:13:52] SPEAKER_01: you know,
[1:13:52] SPEAKER_01: that people have forgotten about,
[1:13:53] SPEAKER_01: wants to do and forgot about this,
[1:13:54] SPEAKER_01: going to come back into play again.
[1:13:57] And then the book,
[1:14:00] this was first published in 2018,
[1:14:02] so that's coming up seven years now.
[1:14:05] SPEAKER_00: If you were to write this book today,
[1:14:08] are there parts that you would add to it that you would rewrite
[1:14:11] or even remove?
[1:14:13] SPEAKER_01: Yeah.
[1:14:14] SPEAKER_01: So first of all, I never actually finished the explanation of the book.
[1:14:16] SPEAKER_01: So the book came about after the class.
[1:14:18] When I started giving talks about the class,
[1:14:19] people said,
[1:14:20] you should write a book about this.
[1:14:22] SPEAKER_01: And so I had a sabbatical in whatever it was, 2017, 2018.
[1:14:25] SPEAKER_01: I used my sabbatical to write the book.
[1:14:29] SPEAKER_01: So feedback on those.
[1:14:30] SPEAKER_01: So first of all,
[1:14:31] there have been some things where I've adjusted my opinion
[1:14:34] since writing the book,
[1:14:35] but there's already been a second edition of the book where I
[1:14:37] fixed most of those.
[1:14:40] SPEAKER_01: And the
[1:14:41] SPEAKER_01: And hopefully the book you have is actually the second edition,
[1:14:43] SPEAKER_01: in fact,
[1:14:44] SPEAKER_01: if you've gotten it in the last couple of years.
[1:14:46] SPEAKER_00: It is first edition.
[1:14:47] SPEAKER_00: I need to update the book.
[1:14:48] SPEAKER_00: OK.
[1:14:49] SPEAKER_01: It has not changed dramatically.
[1:14:51] But the biggest change is more emphasis on this notion of being
[1:14:55] general purpose and
[1:14:57] SPEAKER_01: eliminating specializations.
[1:14:59] And that's something I learned actually not from the book but
[1:15:01] from the class,
[1:15:02] SPEAKER_01: from observing student projects in the class over a period of years.
[1:15:05] I realized this idea is really fundamental to teaching students
[1:15:09] how to write less
[1:15:09] SPEAKER_01: complicated code.
[1:15:11] SPEAKER_01: So that's already in the book.
[1:15:14] SPEAKER_01: There's no big thing that I would want to change right now.
[1:15:20] SPEAKER_01: As I mentioned earlier,
[1:15:21] I think the part of the book that is most dangerous is this
[1:15:26] part of exception handling,
[1:15:27] SPEAKER_01: which,
[1:15:27] SPEAKER_01: as I mentioned,
[1:15:28] is easy for people to misinterpret and apply in ways that I
[1:15:31] actually wouldn't agree with.
[1:15:33] SPEAKER_01: So if I were rewriting the book from scratch –
[1:15:38] I might think about that more carefully to make sure I choose
[1:15:41] my wording more
[1:15:42] SPEAKER_01: carefully to help people avoid misinterpretation of that.
[1:15:46] SPEAKER_01: Now,
[1:15:47] SPEAKER_01: one thing I hoped when I wrote the book,
[1:15:49] one thing I was hoping was that people would come in with new
[1:15:51] ideas that I hadn't
[1:15:51] thought of and that I would learn from that and then get more
[1:15:55] ideas and gradually,
[1:15:56] SPEAKER_01: you know,
[1:15:56] SPEAKER_01: I'd be adding more and more stuff to the book.
[1:15:59] SPEAKER_01: So that has not happened very much so far.
[1:16:03] SPEAKER_01: I would have been delighted to have more.
[1:16:05] SPEAKER_01: I'd love for people to come and say, you are totally wrong.
[1:16:08] SPEAKER_01: This idea here in the book is totally wrong.
[1:16:09] SPEAKER_01: Here's why.
[1:16:10] SPEAKER_01: Here's how you should do it instead.
[1:16:11] And there's not actually been as much of that as I had actually
[1:16:15] hoped for when I wrote the book.
[1:16:18] I have a theory about why this might happen,
[1:16:22] which is that your class is so unique.
[1:16:25] SPEAKER_00: Software design in the wild is typically,
[1:16:27] SPEAKER_00: you have a problem,
[1:16:29] SPEAKER_00: you build a solution,
[1:16:30] SPEAKER_00: you might explore some different trade-offs on the whiteboard,
[1:16:33] SPEAKER_00: but then you build it,
[1:16:34] SPEAKER_00: and then you move on,
[1:16:35] SPEAKER_00: and then you might go back and fix it,
[1:16:37] SPEAKER_00: you might have to maintain it,
[1:16:38] SPEAKER_00: you're going to learn about it.
[1:16:40] What you don't have is you don't have this ideal situation
[1:16:43] where let's say you have
[1:16:43] like two or three different teams building different things and
[1:16:46] then you compare it
[1:16:47] SPEAKER_00: because in the industry or in tech companies,
[1:16:49] SPEAKER_00: you just don't have that luxury.
[1:16:50] SPEAKER_00: And even if it's a bit wasteful.
[1:16:54] SPEAKER_00: So you never really have a situation where you can repeat something.
[1:16:57] SPEAKER_00: My sense was that with your class, you actually could do this.
[1:17:00] SPEAKER_00: You could have a group of students go through.
[1:17:03] SPEAKER_00: Well, actually in the class.
[1:17:06] SPEAKER_00: Same problem, people solve it different ways.
[1:17:08] SPEAKER_00: You can now see the differences, they can see the differences.
[1:17:11] And I'm wondering if it's just a thing that maybe this setup
[1:17:16] needs to happen in
[1:17:17] SPEAKER_00: some level of either academia or nonprofit or somewhere where it is...
[1:17:22] doable I'm not sure because I have been thinking of because
[1:17:26] this this makes this
[1:17:27] book really special like your observation was not just like a
[1:17:30] lot of software
[1:17:30] architecture books are like oh here's stuff that I found over
[1:17:33] working on these
[1:17:34] projects which are all one-offs but I learned these things and
[1:17:37] you're saying I've
[1:17:38] seen this thing work better across the students and those who
[1:17:43] did it you know had
[1:17:45] SPEAKER_00: better outcome repeatedly
[1:17:47] Yeah,
[1:17:47] that's something we can do in academia,
[1:17:49] I think,
[1:17:50] better than industry.
[1:17:51] SPEAKER_01: Because in industry, you don't have time for the revision.
[1:17:55] SPEAKER_01: And you're right.
[1:17:55] One of the things about the class I think that is really good
[1:17:58] is there are nine teams,
[1:17:59] SPEAKER_01: nine two-person teams in the course.
[1:18:01] SPEAKER_01: They all do the same projects.
[1:18:05] SPEAKER_01: And then they review each other's projects.
[1:18:07] SPEAKER_01: So during the code reviews,
[1:18:09] SPEAKER_01: each student will read not the whole project,
[1:18:12] SPEAKER_01: but a big chunk of two other projects and then review them in class.
[1:18:16] SPEAKER_01: And so your partner is reviewing two different projects also.
[1:18:20] So between the two of you,
[1:18:21] you've seen basically half of the rest of the work in class.
[1:18:25] SPEAKER_01: And I think that's also a really great source of learning from students.
[1:18:27] SPEAKER_01: They really enjoy looking at each other's code and thinking about it.
[1:18:31] SPEAKER_01: And then after the first project,
[1:18:32] SPEAKER_01: they ask me,
[1:18:32] SPEAKER_01: they say,
[1:18:34] am I allowed to use ideas from this other project when I revise
[1:18:37] my project?
[1:18:38] Because normally in classes,
[1:18:39] you can't use anybody else's ideas in your work.
[1:18:41] SPEAKER_01: And I say, oh, absolutely.
[1:18:43] SPEAKER_01: You are encouraged to steal and cannibalize all the best ideas.
[1:18:47] SPEAKER_01: So that's something I think,
[1:18:49] SPEAKER_01: yeah,
[1:18:49] SPEAKER_01: where I think actually doing it in academia,
[1:18:52] SPEAKER_01: we can probably do a better job in industry.
[1:18:54] SPEAKER_01: In industry, you don't have enough time.
[1:18:56] SPEAKER_01: You can't let a student,
[1:18:57] SPEAKER_01: a person spend whatever it is,
[1:18:59] SPEAKER_01: 15 hours a week for 10 weeks going through an exercise like this.
[1:19:03] SPEAKER_01: You have too much other stuff for them to do.
[1:19:06] SPEAKER_00: But the outcome has been really nice.
[1:19:08] SPEAKER_00: So as closing,
[1:19:10] what are one or two books you'd recommend for software
[1:19:12] engineers to get better at
[1:19:13] SPEAKER_00: their craft?
[1:19:14] SPEAKER_00: Well, obviously, we have your book, but outside of these.
[1:19:18] So unfortunately,
[1:19:20] there's not a lot of other stuff out there that I really like.
[1:19:24] SPEAKER_01: There are a couple of things.
[1:19:25] SPEAKER_01: Unfortunately, I don't remember the names of them.
[1:19:28] SPEAKER_01: But if people go to my homepage on the web and look,
[1:19:31] SPEAKER_01: there's a link from there that will take you to the software design book.
[1:19:34] SPEAKER_01: And there's a short web page there.
[1:19:36] And that has some other recommendations at the bottom that
[1:19:38] people can look at.
[1:19:40] SPEAKER_00: We're going to link this in the show notes below.
[1:19:43] SPEAKER_00: And how could listeners be helpful to you or help you?
[1:19:46] SPEAKER_01: Well, I'm always interested in constructive criticism.
[1:19:50] SPEAKER_01: I don't claim to have all of the answers.
[1:19:52] SPEAKER_01: I have my experiences and things I think I've learned,
[1:19:55] SPEAKER_01: but we're not done with software design yet.
[1:19:59] SPEAKER_01: I'm sure there's a lot more to learn about that.
[1:20:01] So I'd love to hear if people have ideas or if you think
[1:20:04] something I say is wrong,
[1:20:06] SPEAKER_01: I'd like to hear about it.
[1:20:06] SPEAKER_01: I'd love to hear...
[1:20:08] SPEAKER_01: What you think is wrong and why you think that's wrong.
[1:20:11] SPEAKER_01: The main thing,
[1:20:12] SPEAKER_01: you know,
[1:20:12] SPEAKER_01: both in the class and in the book,
[1:20:14] what I'm hoping to do is to encourage more awareness and
[1:20:19] consciousness about
[1:20:20] SPEAKER_01: software design in the developer community.
[1:20:22] SPEAKER_01: Get people thinking and talking about it.
[1:20:25] SPEAKER_01: And if we do that,
[1:20:26] I'm hoping that we can raise the overall level of design in the
[1:20:29] software that we build.
[1:20:31] SPEAKER_00: Yeah,
[1:20:31] SPEAKER_00: and I'm thinking,
[1:20:33] especially now that we're going to see more code generated just
[1:20:36] by nature.
[1:20:36] SPEAKER_00: As you mentioned,
[1:20:38] SPEAKER_00: design will be more important at all levels,
[1:20:41] SPEAKER_00: not just like the senior engineering level,
[1:20:43] SPEAKER_00: but as you're like creating your own thing.
[1:20:45] SPEAKER_00: So hopefully we'll see more of this.
[1:20:47] SPEAKER_00: Well, John, this was really nice and really interesting discussion.
[1:20:51] SPEAKER_00: And thank you so much for spending your time on this.
[1:20:53] SPEAKER_00: Thank you for inviting me.
[1:20:54] SPEAKER_00: I really enjoyed the discussion as well.
[1:20:56] SPEAKER_00: I hope you enjoyed this conversation as much as I did.
[1:20:58] SPEAKER_00: Thanks very much to John for sitting down with us.
[1:21:01] If you've not read his book,
[1:21:02] A Philosophy of Software Design,
[1:21:03] I can very much recommend it.
[1:21:05] SPEAKER_00: For more in-depth reading on software design,
[1:21:07] SPEAKER_00: design docs and related topics,
[1:21:09] SPEAKER_00: check out the Pragmatic Engineer Deep Dives,
[1:21:10] SPEAKER_00: which are linked in the show notes below.
[1:21:13] SPEAKER_00: If you've enjoyed this podcast,
[1:21:14] SPEAKER_00: please do subscribe on your favorite podcast platform and on YouTube.
[1:21:18] SPEAKER_00: A special thank you if you also leave a rating.
[1:21:20] SPEAKER_00: Thanks and see you in the next one.

Shows are listed from Apple Podcasts' charts and directory, and Podcast Index where it is used. Every show and episode belongs to its publisher and plays from the publisher's own feed; this site hosts none of them.