Code Complete with Steve McConnell

The Pragmatic Engineer

0:00

-1:30:16

Code Complete with Steve McConnell

Steve McConnell, author of Code Complete, shares timeless lessons from his classic software engineering handbook, what he’s updated since, and the career principles every engineer should know.

Gergely Orosz

Sep 10, 2025

Transcript

Stream the latest episode

Listen and watch now on YouTube, Spotify, and Apple. See the episode transcript at the top of this page, and timestamps for the episode at the bottom.

Brought to You by

•⁠ Statsig ⁠ — ⁠ The unified platform for flags, analytics, experiments, and more. Statsig built a complete set of data tools that allow engineering teams to measure the impact of their work. This toolkit is SO valuable to so many teams, that OpenAI - who was a huge user of Statsig - decided to acquire the company, the news announced last week. Talk about validation! Check out Statsig.

•⁠ Linear – The system for modern product development. Here’s an interesting story: OpenAI switched to Linear as a way to establish a shared vocabulary between teams. Every project now follows the same lifecycle, uses the same labels, and moves through the same states. Try Linear for yourself.

—

In this episode

The Pragmatic Engineer Podcast is back with the Fall 2025 season. Expect new episodes to be published on most Wednesdays, looking ahead.

Code Complete is one of the most enduring books on software engineering. Steve McConnell wrote the 900-page handbook just five years into his career, capturing what he wished he’d known when starting out. Decades later, the lessons remain relevant, and Code Complete remains a best-seller.

In this episode, we talk about what has aged well, what needed updating in the second edition, and the broader career principles Steve has developed along the way. From his “career pyramid” model to his critique of “lily pad hopping,” and why periods of working in fast-paced, all-in environments can be so rewarding, the emphasis throughout is on taking ownership of your career and making deliberate choices.

We also discuss:

Top-down vs. bottom-up design and why most engineers default to one approach
Why rewriting code multiple times makes it better
How taking a year off to write Code Complete crystallized key lessons
The 3 areas software designers need to understand, and why focusing only on technology may be the most limiting
And much more!

Steve rarely gives interviews, so I hope you enjoy this conversation, which we recorded in Seattle.

One topic Steve has never written about — but finds important

A topic Steve has been thinking a lot about, but has not written or talked until this interview is this:

Focused personal energy makes up for a lot of things. In his words (starting at 53:30 in the podcast)

“A topic that I don't think I've ever written about, but that is worth just throwing on the table, is that focused application of personal energy makes up for a lot of other deficiencies.
In startup mode, when you're talking about not having well-defined roles, if everybody's actually working in a focused way and they care about getting work done and they're applying a lot of energy: mistakes aren't a big deal! You just go in and you fix it. You've got the energy to do it.
If you're working in a super process-oriented way and people are thinking half about their home life, and they're checked out, and now they're 45 instead 27. Not that that's a universal pattern or anything, but if you don't have the same level of personal energy to correct mistakes, the mistakes linger. They affect more people, affect more downstream products, work products, and it just becomes a much bigger deal.
When I was at Microsoft, the core Windows team was under 15 people. And of course this was a much earlier version of Windows, but at the time there was a project going on at IBM. Well, Microsoft and IBM were jointly developing operating system called OS2.
IBM had something like 10 times the staff, maybe more than that, that Microsoft had. And Microsoft was really frustrated at how slow IBM was on their side! The reality is you can get a lot of stuff done with the right 10 people who are all super focused.
Even if you just start thinking about it in terms of number of communication paths, how many people do I have to interact with on a day-to-day, hour to hour basis? If I've got 9 or 10 people, how many does it take to make a decision that sticks? How many does it take to fully consider an issue? If I have a decision, where, on a 10-person team I need four people to weigh in, I've now heard everything with four people. If I've got a hundred people on the team, I've got 30 that need to weigh in. That's an entirely different proposition!
You can get an awful lot done with a high level of energy. And I don't think in the technical space, I haven't read much at all on people talking about the role that energy plays.”