Book Club: A Philosophy Of Software by John Ousterhout. At least it's better than 'Clean Code'

In this edition of Book Club, we talk about A Philosophy of Software Design, 2nd Edition
by John K. Ousterhout.

It's MUCH better than "Clean Code." But it still leaves a lot to be desired.

What's more important,. though, is what this book doesn't say, and what those omissions say about our industry.

Links from the video:
@coffeecodeandchat podcast I was on:

My video on Clean Code, and why that book is trash:

My video on Software Testing that no one wants to watch:

00:00 A Philosophy of Software Design
01:16 Chapter 1 & 2
02:58 RE: Google and VMWare - LOLOL
03:17 Abstractions and what's "important"
04:03 Unix and TCP/IP
04:55 Classitis
05:14 Chapter 10: Error Handling 😡
06:34 Second System Syndrome
07:02 On comments
07:22 Naming and Renaming
08:46 More about comments
09:17 Chapter 19: Why even bother?
10:04 Chapter 20: Design vs Performance
11:29 What the book doesn't cover
11:51 An industry wide problem
12:01 Don't be these guys
13:27 Delusions programmers want to believe
15:50 The vicious cycle of bugs, willful ignorance and doom
16:50 Should you read this book?
18:13 Prioritizing your time

[KuzzatAltay]

As someone who has been in tech for the last 13 years, I wish to see your videos at least once a week. Your videos are so valuable for people like us. I just want to genuinely thank you for what you do.

[speedychicken]

Who knew we programmers needed a no-BS programming youtuber.

[johnkonecny]

Your focus on error handling is spot on. When I started writing code that assumed all IO will fail, my life got so much easier. It almost feels like cheating when it comes to debugging production problems.

[mateuszkorus]

I member at my first software job in a publishing company, the CTO was boasting during an all-hands meeting that the devs move fast and don't bother with corner cases. I member thinking that they might not be his problem, because it won't be his phone that would ring at night when something inevitably gets broken. I was in the team responsible for the edge servers and seeing how often my team would get called by monitoring system for bugs that wouldn't get prioritized, because there always were some new features being requested. I'm grateful for that job, it taught me a lot, but I didn't stay there very long.
Thank you for the quality content you put out, Carl.

[shafo]

"Try not to need it" So much wisdom in that sentence

[jaqen_hgar]

I don't really understand aversion to debugging. I am a hardware designer, and 70% of my job is error handling. Almost everything I learned I learned because of debugging. If my project works perfectly there is no need to turn on my oscilloscope or any of my tools. I also got into programming not long ago, and same thing applies. I find my knowledge solidifies so much better if i am fixing a difficult bug. I am forced to think about issues i never considered and understand better the tool i use. Debugging forces you to go deep. There is no other way to become better than learning on the mistakes you make.
Having said that I am here to listen to you dunk on fake AI startups not to watch you start your little book club. :) Get to it!
Just joking, Thanks for the video, your insights are always fantastic.

[JoaquimDornelles]

You're my favorite new youtube channel, keep up the great work, big fan from Brazil

[onetruetroy]

I’ve watched many of your videos and like almost all of the content. Thank you so much for breaking the myths of having the most perfect way to develop software, and that not every book is ‘the’ book you must have.
—
My programming experiences have been varied and usually a necessity employed to support or maintain a project already developed. What I learned is to not start with the code, but with the end users who rely on it for their livelihoods. Just candid conversations with no managers or others listening in. Unsurprisingly, the non-programmers have greater insight on how software should work for them. No code is written or modified until there is a complete plain English document detailing everything about the project. If I can’t repeat back to a client what they want the software to do, then how I can I be confident that I can write the program? When I start with the final end-user and work towards the beginning, I know that even if my code may not be optimized or conform to an acronym, it does the job well.
—
I’m so glad you stated the importance of error-handling. Problem-solving skills are always valuable, especially for those problems that haven’t happened.

[asdkoda]

I genuinely think that this is the best channel on Software Development. Huge thank you for your content!

[mbunkus]

Your point about naming & renaming is soooo spot on. I have an example from outside the software development world: routers (as in, the things routing internet traffic for small/medium sized businesses). We currently have to switch to a different model than the old one we're used to & love as the manufacturer's discontinuing that model. The new one has many drawbacks (completely different OS), but the most glaringly obvious one is: after having created a network interface & assigned it to an underlying network card (think "eth0" in Linux), you cannot rename that interface anymore. Never. This works fine if all you have is one internal interface (LAN, usually "eth0") & one internet-facing interface (often "ppp0" here in Germany where even fibre is done via PPP), but it completely fails apart for our slightly larger customers who have around 20 interfaces, some even close to 50 (with a lot of taggged VLAN ones). Think of how fun it is to create firewall rules & having to select between "eth4", "eth5", "eth6"… in the drop-down list.

Naming fucking matters, especially if those names are exposed to users!

[vsemsimpa]

I feel like I am being lectured by the teacher who cares about my future and genuinely trying to teach me something valuable. Thank you, sir. Would be awesome to know a book or a course that can improve the error handling skill. Or maybe a video going through a sample repo and hearing your opinion about the code and what you would do different

[JohnDoe-sqnv]

Thank you for this video! It is fantastic! In the past I was working on a team responsible for solving bugs in legacy as they were, triggered, discovered and threatened to stop the release. I worked with threat of weekend work basically every day for some years, because you never knew when that one bug would be discovered.

Tests are criminally undervalued. Too many times are they seen as separate from production code, too many times seen as onboarding tasks, as afterthoughts, as existing to fulfill a metric. And too many times are they implicitly introducing new requirements, protecting bugs, protecting dead code, blocking refactors and give false confidence. I believe that automated tests should be the way that programmers talk about the function of their code.

[sqryvxt]

I've been in tech for such a long time and still, your experience dwarfs mine. We really need more veterans talking about software, but it is so rare to see someone this experienced that hasn't moved on from tech.

[moopoo]

You are my favourite YouTuber on software topics: articulate, high information density / unit time, first principles ❤

[mitdebo]

Would absolutely love a video (or recommendation at least) about the best error handling book out there, though from the sounds of it, there's probably not many

[CurtisDyer]

I work in IT and i still think about about how frustrating it was to support a critical piece of hospitality software for a former client that would crash on start up on workstations simply due to not having a default printer chosen within Windows. If I recall, it would just display a hex string and quit lol. As far as I'm aware, the vendor never fixed the issue, even between major versions upgrades.

[peduran]

Man i really love the end of this video when you talk about how you hate buggs. I feel the same way. I was at a lengthy interview where I talked a lot about how important testing is, not only because of refactoring but also preventing buggs and having a stable system. They basically laughed a little and though I was being extreme. It's a sad business minded world we live in where $ is the only thing that matters :(

[rseed]

You're awesome! Hopefully you keep making these videos, they are gems!

[josevargas]

You just saved me from possibly spending so many hours reading a book I was unsure I should of read. That's so much value!

[PixelHyde]

Neat video, you hit the nail on the head with many problems I had with the book, and highlighted some crucial stuff that I had overlooked. It's a good book to reference sometimes, but people are not looking for that, they want a Programming Bible that they can refer to in every single circumstance.

The fact that SOLID is such a neat acronym that has been in use for 20 years tells you all you need to know about the priorities of many people. All encompassing "philosophies" that sound neat and are easy to regurgitate are prioritized over actual case-by-case solutions and thinking. How much time was spent looking for five different principles that made up an actual word, and how many of those have been prioritized for 20 years instead of other, more important stuff, just because we needed an "L" to fill up the word "SOLID"?