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.
Not a book but check out jvns.ca for some inspiration.
Software engineering books to read and reread
31–40 of 47 posts
Re: Software engineering books to read and reread
#32"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?
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).
Re: Software engineering books to read and reread
#33Earlier quoted context omitted.
> 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?
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.
Re: Software engineering books to read and reread
#34Earlier quoted context omitted.
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.
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.”
Re: Software engineering books to read and reread
#35"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 always found it ironic that a book that advocates concise documentation and diagrams over text looses itself in way too much narrative.
Re: Software engineering books to read and reread
#36No 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's literally the worst (tech) book I have ever read.
Re: Software engineering books to read and reread
#37Growing Object Oriented Guided by Tests would be my contribution
Re: Software engineering books to read and reread
#38I 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://ba…
You got fired just for mentioning category theory? Where were you working? There has to be more to that story.
Re: Software engineering books to read and reread
#39No 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.
And despite never having written a line of javascript, I've found it tremendously useful.
Re: Software engineering books to read and reread
#40One 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.