I think this is the first time I've seen a list like this with no books that I've read. I will have to pick some of these up and see if they're any good.
Second this. One of my favourite programming books. The advice is applicable to pretty much every domain of software engineering, and the lessons are philosophical (as the name suggests) rather than technical and specific, so they serve as a great jumping off point for many specific issues you might face in programming. It’s also very short which helps!
Deep Work by Cal Newport is near the top of that list - I have to warn anyone who might buy it that it is an incredibly disappointing and derivative book written with all the rigor of a BuzzFeed list. Read Flow by Mihaly Csikszentmihalyi instead - where the only decent ideas in Deep Work are taken from.
Andrew Kelley (ziglang lead) recommended Data-Oriented Design (think: Mechanical Sympathy) on twitter once [0]. I read the first few chapters and found it to be pretty neat [1].
Besides, JavaScript: The Good Parts remains one of the best programming books I've read (direly in need of a new edition).
> Besides, JavaScript: The Good Parts remains one of the best programming books I've read (direly in need of a new edition).
My opinion is that at this point you wouldn't read JavaScript: The Good Parts to become more effective with the language (the books original intent).
Modern JavaScript is substantially different from what's illustrated in that book both in terms of language design and popular style. The ecosystem built around the web has moved on as well. Very few programmers spend their day manually manipulating the DOM anymore - almost always there's a library in between doing that.
The reason I _would_ recommend JavaScript: The Good Parts to someone is that it's one of the best examples of a well written technical book that I'm aware of. It's at once clear, deep, and concise. It's an easy read that assumes very little in terms of the reader's prior knowledge.
So many technical books are frankly very poorly written but Crockford, whatever you think of him, is exceptionally gifted at illustrating technical topics in a way that is easy to understand.
FWIW, I'm an experienced developer without JS knowledge, but I decided it was time to write a Firefox extension, and I needed to finally learn JS. I chose "Modern JavaScript for the Impatient" (Horstmann) because its target audience is developers coming from other languages. He mentions Corckford's book, and says
"Crockford’s JavaScript: The Good Parts2 was a wake-up call in 2008, but much of its message has been internalized in subsequent changes to the language."
And the Rhino book is too large for what I need to accomplish.
I spent far too much time trying to help confused people understand the Design Patterns book. At the end I knew less than I did at the start.
People come to DP thinking they are going to understand the structure and maintenance of 'good code'. None of that is in that book. In fact given how we have demolished a couple of patterns that are laid out in that book (notably, Singletons as harmful), less than none of that is in that book.
I started telling people they should read Refactoring instead. And if they wanted a second recommendation for something to read after Refactoring, that they should read Refactoring a second time.
Design patterns don't have much to do with 'good code'.
Many(most?) 'design patterns' are just standard ways of coming up with abstractions that your language does not provide. It's no wonder that particular book became popular at around the same time a particular programming language saw large adoption.
People like to read Christopher Alexander because he decomposes problems and you understand why. So many people compared the two but in hindsight I think they were trying to say, "Read this, it's much better" without calling out the GoF book directly. Unfortunately what I felt and observed in others was that some sort of equivalence was being made, adding to and drawing out the confusion.
I've found the OG Design Patterns book to be verbose and opaque.
I strongly recommend => Refactoring Guru https://refactoring.guru/design-patterns/python
It's a lot of patterns with _short_ clear descriptions, and lots of diagrams! Recommended even if you're not doing Python. An excellent investment, and a bunch of it is free.
On its face that implies that Gamma was a kid, and so the work is purely academic, but he's around 8 years too old to have been starting a PhD in '91 without any prior industry experience. It's still mostly his work (otherwise it's not his PhD) with the other 'authors' consulting and copy editing.
No idea why people keep recommending Refactoring. It is super outdated showing low-level refactoring techniques in a 20 year old version of Java. If your IDE doesn't already have all these techniques built-in then you should get a new IDE.
The 2nd edition is much more recent (2018), and re-written with examples in modern(ish) Javascript.
Even if what you say about IDEs is true (which I don't think it is), it's still instructional to know the "why" of a refactor, and when to apply it. Perhaps it's too basic for you personally, but there's much wisdom Fowler is passing on to the world here.
I finally got around to it, as my whole team kept raving about it.... turns out its basically leetcode for you if you woke up in a nightmare and were the inanimate "refactor" tool in VisualStudio/Jetbrains.
"Domain Driven Design" is very poorly written. It's 500 pages of small print with small margins, so realistically it's closer to 750-1,000 pages. Evans is a terrible, verbose writer. I read Domain Driven Design, but I can't recommend it. Surely there's a shorter version someone could recommend? There's only a handful of good ideas in the book which I'm sure could be easily distilled.
Domain Driven Design is also a dangerous paradigm to apply everywhere. In fact I suspect that the majority of the time it's a mistake. Specifically the act of hard coding business concepts (products and processes) as first class citizens (classes, services) into your software. This makes your business inflexible and requires engineering effort to iterate on your business processes. It's a poison, and the deeper you build it into your architecture, the deeper the poison seeps, locking you into stale business concepts.
Domain Driven Design should be analyzed much more critically than it is, especially given how much time engineers waste slogging through the ramblings of Evan's clouded mind. I highly recommend https://dev.to/cheetah100/domain-driven-disaster-147i for further reading.
Someone correct me if I'm wrong, but it seems like it should be fine. Copyright applies to specific concrete representations and not things like abstract underlying ideas.
Yes. It applies to what you do / make. You can’t copy (parts of) the written text, but you can act (write your own interpretation) with the ideas in that text.
“Copyright is intended to protect the original expression of an idea in the form of a creative work, but not the idea itself.”
Been wondering the same since I came across DDD while reading Team Topologies. I’ve heard similar feedback on the original book, and my search led me to a recent O’Reilly book:
Learning Domain-Driven Design, by Vlad Khononov
It’s 340 pages and has good reviews on Amazon etc, but I’d be especially interested in feedback from anyone within a good understanding of the topic who’s read the O’Reilly book.
> I’d be especially interested in feedback from anyone within a good understanding of the topic who’s read the O’Reilly book.
You're winter project is constructing a 3000 word amazon review on the book that will amass 500 likes across the next 20 years. you can look back on it when you retire and smile.
Code is data and any data that specifies business processes and defines their outcome is code.
If you can't iterate on the specification of business at the speed business itself needs to change, that's a problem, but it's a process problem, not something inherent in specifying business process in code.
Configuration is still code, but maybe in a non-Turing-complete language (but maybe not, depending on where we are in the cycle of configuration fashions at the moment.)
As much as possible, build horizontal, functionality based services. As much as possible, avoid coding anything business specific into your core. Avoid product names, role names, user types, etc, in your code, databases, classes, files, APIs, services, etc. Create systems where those things can be entered as data, so configuration can be provisioned and updated by end users. Push the "domain" as far into user-land as you can (users entering data and configuration). Imagine how bad and inflexible bug tracker software would be if there were "product manager" and "software engineer" domains and services. Or how bad Amazon S3 would be if it had a "startup" or "video provider" domain. That's why he argues Excel is so successful, there is no core domain nonsense, it's a functional piece of software that users can use to create whatever domain they want. As much as possible, avoid Domain Driven Design, except for the minimal useful parts (like using the same name for things in the same context).
You end up trying to debug/understand logic that slips through your hands like wisps of smoke.
It’s a trade off, just realize you are building a system that’s harder to reason about and add more observability and/or an ability to interact with the live system.
I don't believe in this: if you follow through on that, you will end up with a low-code or no-code platform. Or basically, you are creating a programmable platform where your "configuration" is actually gonna be code.
When you create software to support a business, you automatically support business processes. The better you try to support those processes, the better the user experience and the more "tied" the software becomes to those processes.
Often, when you create the software and analyse the needs, it is also a learning experience for the business because they are forced to think about the business processes they have and about the business processes they want to move to.
If, in that business context, certain needs or flows change, it is natural that it requires changes on the code, but those changes should rarely be so dramatic that you have to rewrite big parts of the application. When that happens, there must have been a serious flaw with the analysis and design, or the code was simply bad.
And yes, for certain things, there is a bit of a balance in whether it should be configuration or code. But from the analysis, for most things it will be very black-and-white on whether it should be configuration or code.
> Or how bad Amazon S3 would be if it had a "startup" or "video provider" domain.
I don't understand this comment. Amazon S3 on its own would be very bad to support the business processes of a video provider. And software to support a video provider business would be very bad as a general blob storage solution.
Obviously there is a difference between a general "product" that you want to make usable for a target audience as big as possible and a customised solution to support a business in the best way possible. But both are also different domains. So, yeah, if you create something for a certain domain, it will be an issue if you want to use it for a completely different domain.
on a side note. looking for a solid book on networking basics (tcp, http, grpc, dns resolution, etc) with focus on relevant content for day to day backend/infra level SWE work.
Working effectively with legacy code, The design of everyday things, The Pragmatic Programmer, Peopleware, A Philosophy of Software Design, Hacknot, SICP
I wish there was a book about how all the best practices emerge from mathematical category theoretic constructs. Once I tried mentioning it and got fired. Because only great gurus like Martin Fowler and Eric Evans are allowed to see patterns.
By seeing best practices emerge from eternal structures of mathematics, often we are able to derive situations when best practices do not work too.
> Changes in hardware and the growing complexity of software are forcing us to rethink the foundations of programming. Just like the builders of Europe’s great gothic cathedrals we’ve been honing our craft to the limits of material and structure. There is an unfinished gothic cathedral in Beauvais, France, that stands witness to this deeply human struggle with limitations. It was intended to beat all previous records of height and lightness, but it suffered a series of collapses. Ad hoc measures like iron rods and wooden supports keep it from disintegrating, but obviously a lot of things went wrong. From a modern perspective, it’s a miracle that so many gothic structures had been successfully completed without the help of modern material science, computer modelling, finite element analysis, and general math and physics. I hope future generations will be as admiring of the programming skills we’ve been displaying in building complex operating systems, web servers, and the internet infrastructure. And, frankly, they should, because we’ve done all this based on very flimsy theoretical foundations. We have to fix those foundations if we want to move forward.
One of my favourites is Michael Feather's "Working effectively with legacy code".
It is slightly out of date by now, which carries the risk people reading it and interpreting its advice "literally" (which by definition will take your code back by 15 years). But the main message of the book is as relevant today as then, and a great way to think about writing code and how to approach large complex codebases that need to be tamed.
46 comments
[ 0.23 ms ] story [ 113 ms ] threadBesides, JavaScript: The Good Parts remains one of the best programming books I've read (direly in need of a new edition).
[0] https://archive.is/199Eo
[1] book: http://www.dataorienteddesign.com/dodbook/dodmain.html / more: https://github.com/dbartolini/data-oriented-design
[2] also: https://news.ycombinator.com/item?id=2275899
My opinion is that at this point you wouldn't read JavaScript: The Good Parts to become more effective with the language (the books original intent).
Modern JavaScript is substantially different from what's illustrated in that book both in terms of language design and popular style. The ecosystem built around the web has moved on as well. Very few programmers spend their day manually manipulating the DOM anymore - almost always there's a library in between doing that.
The reason I _would_ recommend JavaScript: The Good Parts to someone is that it's one of the best examples of a well written technical book that I'm aware of. It's at once clear, deep, and concise. It's an easy read that assumes very little in terms of the reader's prior knowledge.
So many technical books are frankly very poorly written but Crockford, whatever you think of him, is exceptionally gifted at illustrating technical topics in a way that is easy to understand.
"Crockford’s JavaScript: The Good Parts2 was a wake-up call in 2008, but much of its message has been internalized in subsequent changes to the language."
And the Rhino book is too large for what I need to accomplish.
1. Structure and interpretation of computer programs
2. Software architecture the hard parts
3. Designing data intensive applications
People come to DP thinking they are going to understand the structure and maintenance of 'good code'. None of that is in that book. In fact given how we have demolished a couple of patterns that are laid out in that book (notably, Singletons as harmful), less than none of that is in that book.
I started telling people they should read Refactoring instead. And if they wanted a second recommendation for something to read after Refactoring, that they should read Refactoring a second time.
Many(most?) 'design patterns' are just standard ways of coming up with abstractions that your language does not provide. It's no wonder that particular book became popular at around the same time a particular programming language saw large adoption.
I strongly recommend => Refactoring Guru https://refactoring.guru/design-patterns/python It's a lot of patterns with _short_ clear descriptions, and lots of diagrams! Recommended even if you're not doing Python. An excellent investment, and a bunch of it is free.
https://www.zdnet.com/article/erich-gamma-a-pattern-of-succe...
On its face that implies that Gamma was a kid, and so the work is purely academic, but he's around 8 years too old to have been starting a PhD in '91 without any prior industry experience. It's still mostly his work (otherwise it's not his PhD) with the other 'authors' consulting and copy editing.
Even if what you say about IDEs is true (which I don't think it is), it's still instructional to know the "why" of a refactor, and when to apply it. Perhaps it's too basic for you personally, but there's much wisdom Fowler is passing on to the world here.
Domain Driven Design is also a dangerous paradigm to apply everywhere. In fact I suspect that the majority of the time it's a mistake. Specifically the act of hard coding business concepts (products and processes) as first class citizens (classes, services) into your software. This makes your business inflexible and requires engineering effort to iterate on your business processes. It's a poison, and the deeper you build it into your architecture, the deeper the poison seeps, locking you into stale business concepts.
Domain Driven Design should be analyzed much more critically than it is, especially given how much time engineers waste slogging through the ramblings of Evan's clouded mind. I highly recommend https://dev.to/cheetah100/domain-driven-disaster-147i for further reading.
“Copyright is intended to protect the original expression of an idea in the form of a creative work, but not the idea itself.”
https://en.m.wikipedia.org/wiki/Copyright
Learning Domain-Driven Design, by Vlad Khononov
It’s 340 pages and has good reviews on Amazon etc, but I’d be especially interested in feedback from anyone within a good understanding of the topic who’s read the O’Reilly book.
You're winter project is constructing a 3000 word amazon review on the book that will amass 500 likes across the next 20 years. you can look back on it when you retire and smile.
If you can't iterate on the specification of business at the speed business itself needs to change, that's a problem, but it's a process problem, not something inherent in specifying business process in code.
Does anyone have any experience or info on how to bring our Business logic out from domain classes and structures, into configuration?
Any examples or sample code?
You end up trying to debug/understand logic that slips through your hands like wisps of smoke.
It’s a trade off, just realize you are building a system that’s harder to reason about and add more observability and/or an ability to interact with the live system.
When you create software to support a business, you automatically support business processes. The better you try to support those processes, the better the user experience and the more "tied" the software becomes to those processes.
Often, when you create the software and analyse the needs, it is also a learning experience for the business because they are forced to think about the business processes they have and about the business processes they want to move to.
If, in that business context, certain needs or flows change, it is natural that it requires changes on the code, but those changes should rarely be so dramatic that you have to rewrite big parts of the application. When that happens, there must have been a serious flaw with the analysis and design, or the code was simply bad.
And yes, for certain things, there is a bit of a balance in whether it should be configuration or code. But from the analysis, for most things it will be very black-and-white on whether it should be configuration or code.
> Or how bad Amazon S3 would be if it had a "startup" or "video provider" domain.
I don't understand this comment. Amazon S3 on its own would be very bad to support the business processes of a video provider. And software to support a video provider business would be very bad as a general blob storage solution.
Obviously there is a difference between a general "product" that you want to make usable for a target audience as big as possible and a customised solution to support a business in the best way possible. But both are also different domains. So, yeah, if you create something for a certain domain, it will be an issue if you want to use it for a completely different domain.
http://deliberate-software.com/page/books/
By seeing best practices emerge from eternal structures of mathematics, often we are able to derive situations when best practices do not work too.
This book is good: https://bartoszmilewski.com/2014/10/28/category-theory-for-p...
Relevant quote from the preface:
> Changes in hardware and the growing complexity of software are forcing us to rethink the foundations of programming. Just like the builders of Europe’s great gothic cathedrals we’ve been honing our craft to the limits of material and structure. There is an unfinished gothic cathedral in Beauvais, France, that stands witness to this deeply human struggle with limitations. It was intended to beat all previous records of height and lightness, but it suffered a series of collapses. Ad hoc measures like iron rods and wooden supports keep it from disintegrating, but obviously a lot of things went wrong. From a modern perspective, it’s a miracle that so many gothic structures had been successfully completed without the help of modern material science, computer modelling, finite element analysis, and general math and physics. I hope future generations will be as admiring of the programming skills we’ve been displaying in building complex operating systems, web servers, and the internet infrastructure. And, frankly, they should, because we’ve done all this based on very flimsy theoretical foundations. We have to fix those foundations if we want to move forward.
It is slightly out of date by now, which carries the risk people reading it and interpreting its advice "literally" (which by definition will take your code back by 15 years). But the main message of the book is as relevant today as then, and a great way to think about writing code and how to approach large complex codebases that need to be tamed.