Mastering Design Reviews in Tech Teams

This chapter focuses on the significance of design reviews in tech teams, highlighting methods for collaborative evaluation and improvement of design plans. It discusses the role of tools like Google Docs and Figma in facilitating feedback, while also emphasizing the value of in-person brainstorming sessions. The episode dives into the complexities of software design education, sharing insights from the speakers' journeys in teaching design principles and enhancing students' understanding through feedback-driven methodologies.

Transcript

chevron_right

Play full episode

chevron_right

Transcript

Episode notes

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