[GuestHNUser]

For those not familiar with the author, this is Daniel Lemire, a high performance software expert. He has done lots of work about squeezing as much performance out of a CPU as possible; see his work on SIMD JSON parsing[0]. I imagine he wrote this out of frustration for the software industry's seeming inability to identify who actual experts are in the field. It doesn't take much work to see how much books like Design Patterns and Clean Code have negatively shaped the industry.

[0] https://lemire.me/blog/2021/09/25/new-release-of-the-simdjso...

[Mkengine]

I am currently finising my PhD and will start next month as a software architect. Among others I also looked into these books. What is the problem with them and what would you recommend instead?

[charleslmunger]

This lecture is a decent criticism of "clean code" and other non-expert advice.

https://youtu.be/7YpFGkG-u1w

[GuestHNUser]

The issue with those books is that they don't have any concrete data that affirms that they are worth following. And, in fact, that style of code is largely to blame for why modern software feels so sluggish. They often reduce performance by 10x if not 100x or worse. I like this video on the topic for reasons not to follow SOLID principles[0]. Muratori also has an excellent talk on writing APIs that are flexible and performant[1]. As for books on understanding the hardware performance, Computer Systems: a Programmer's Perspective, is the best example (not the international edition though, according to the author's recommendation).

I'm not aware of any architecture books recommended by anyone that cares about performance unfortunately. Most high performance software is written iteratively, meaning they aren't assuming a code structure from the start. Andreas Fredriksson, a lead engine programmer at Insomniac Games, has an excellent quote on how he writes high performance software[2]:

> Work backwards from hard constraints and requirements to guide your design. Don’t fall into the trap of designing from a fluffy API frontend before you’ve worked out how the thing will handle a worst case. Don’t be afraid to sketch stuff in while you’re proving out the approach.

> The value is what you learn, never the code. Hack it and then delete the code and implement “clean” or whatever you need. But never start there, it gets in the way of real engineering.

> As an industry we spend millions on APIs, documentation and abstraction wrapping a thing that isn’t very good to start with. Make the thing good first, then worry about fluff.

Casey Muratori also has written blogs about his programming style[3]. (He also runs a great course about performance at computerenhance.com). Abner Coimbre has a great article on how NASA approaches writing software[4]. Of course, there is also Mike Acton's famous CppCon talk about Data-Oriented Design[5].

The standard advice usually boils down to this: focus on the problem you have to solve, and be aware how damaging solving the wrong problem can be. It's a good idea to focus on what data your program receives and focusing on handling worst cases.

Since it is difficult to tell who is worth listening to, I suggest always investigating what actual software the person speaking has written. Those that write real time software or software that must not fail under any condition tend to speak very differently about typical industry practices for good reason.

[0] https://youtu.be/tD5NrevFtbU?si=Jkg6VKBHns32_IU_

[1] https://youtu.be/ZQ5_u8Lgvyk?si=tMuPFxKbrboKrBFr

[2] https://twitter.com/deplinenoise/status/1782133063725826545

[3] https://caseymuratori.com/blog_0015

[4] https://www.codementor.io/@abnercoimbre/a-look-into-nasa-s-c...

[5] https://youtu.be/rX0ItVEVjHc?si=buLbaqoc3Zugfwr7