Here's my list of great programming books
Software engineering books to read and reread
21–30 of 47 posts
Re: Software engineering books to read and reread
#22"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 da…
I think its required reading for inheriting large legacy codebases from the early 2000s written in Java; all the insanity suddenly makes sense
Re: Software engineering books to read and reread
#23No 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.
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.
Re: Software engineering books to read and reread
#24"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 da…
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.
Re: Software engineering books to read and reread
#25"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 da…
The attached article is great.
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?
Re: Software engineering books to read and reread
#26"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 da…
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
Re: Software engineering books to read and reread
#27I 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…
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.
Re: Software engineering books to read and reread
#28I 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.
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.
Re: Software engineering books to read and reread
#29Earlier quoted context omitted.
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
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.)
Re: Software engineering books to read and reread
#30Andrew 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). [0] https://archive.is/199Eo [1] book: http://www.dataorienteddesign.com/dodbook/dodmain.html / more: https://github.co…
> 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 ecosyst…
I read this book years ago and was interested in rereading. Any good JS books you would recommend for modern day that would be just as good?