Live data from Hacker News

Software engineering books to read and reread

quentin.delcourt.be

11–20 of 47 posts

Re: Software engineering books to read and reread

#11
"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.

Re: Software engineering books to read and reread

#12

"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…

What’s the copyright law on taking ideas and principals from a book like that, and rewriting it?

Re: Software engineering books to read and reread

#14

"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.

Re: Software engineering books to read and reread

#15

"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.

Re: Software engineering books to read and reread

#16
post #9

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.

It was updated in 2018. It does not use Java anymore and now uses Javascript.

Re: Software engineering books to read and reread

#17

"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…

What’s the copyright law on taking ideas and principals from a book like that, and rewriting it?

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.

Re: Software engineering books to read and reread

#18
post #9

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.

Re: Software engineering books to read and reread

#20

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). [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 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.

Post reply on HN