7 ms·

Software engineering books to read and reread

110 points by kant312 4y ago

xupybd 4y ago
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.
siddontang 4y ago
I highly recommend "A Philosophy of Software Design", the book teaches me a lot about how to manage complexity in programming.
- mindwok 4y ago
  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!
atlgator 4y ago
When I'm looking for a good book to read, I always reference this site that aggregates HN recommendations: https://hacker-recommended-books.vercel.app/category/0/all-time/page/1/0 https://hacker-recommended-books.vercel.app/category/0/all-t...
- tomdell 4y ago
  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.
- mejthemage 4y ago
  Can't wait to get to #8 there. "Harry Potter: Hogwarts Hardcover Journal" -- I bet I could read that whole thing in one night.
ignoramous 4y ago
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 https://archive.is/199Eo [1] book: http://www.dataorienteddesign.com/dodbook/dodmain.html http://www.dataorienteddesign.com/dodbook/dodmain.html / more: https://github.com/dbartolini/data-oriented-design https://github.com/dbartolini/data-oriented-design [2] also: https://news.ycombinator.com/item?id=2275899 https://news.ycombinator.com/item?id=2275899
- CSMastermind 4y ago
  > 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.
  - rschachte 4y ago
    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?
    - clumsysmurf 4y ago
      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.
gchamonlive 4y ago
In addition to that: 1. Structure and interpretation of computer programs 2. Software architecture the hard parts 3. Designing data intensive applications
hinkley 4y ago
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.
- outworlder 4y ago
  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.
  - hinkley 4y ago
    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.
- john-tells-all 4y ago
  I've found the OG Design Patterns book to be verbose and opaque. I strongly recommend => Refactoring Guru https://refactoring.guru/design-patterns/python 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.
  - hinkley 4y ago
    The DP book is a published version of Gamma's PhD thesis, which I learned in a class with someone closer to the story. It's corroborated here: https://www.zdnet.com/article/erich-gamma-a-pattern-of-success/ 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.
guelo 4y ago
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.
- Jtsummers 4y ago
  It was updated in 2018. It does not use Java anymore and now uses Javascript.
  - disgruntledphd2 4y ago
    And despite never having written a line of javascript, I've found it tremendously useful.
- lastofus 4y ago
  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.
- abledon 4y ago
  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.
- danwee 4y ago
  It's literally the worst (tech) book I have ever read.
stevebmark 4y ago
"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 https://dev.to/cheetah100/domain-driven-disaster-147i for further reading.
- kumarvvr 4y ago
  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?
  - stevebmark 4y ago
    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).
riceluxs1t 4y ago
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.
- rschachte 4y ago
  Not a book but check out jvns.ca for some inspiration.
x86x87 4y ago
Working effectively with legacy code, The design of everyday things, The Pragmatic Programmer, Peopleware, A Philosophy of Software Design, Hacknot, SICP
- hellectronic 4y ago
  I can recommend The Pragmatic Programmer by Thomas and Hunt
JackMorgan 4y ago
Here's my list of great programming books http://deliberate-software.com/page/books/ http://deliberate-software.com/page/books/
evelynsalt 4y ago
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. This book is good: https://bartoszmilewski.com/2014/10/28/category-theory-for-programmers-the-preface/ 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.
- thraxil 4y ago
  You got fired just for mentioning category theory? Where were you working? There has to be more to that story.
ngcazz 4y ago
Growing Object Oriented Guided by Tests would be my contribution
tpoacher 4y ago
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.

110 points by kant312 4y ago

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.

siddontang 4y ago

I highly recommend "A Philosophy of Software Design", the book teaches me a lot about how to manage complexity in programming.

mindwok 4y ago
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!

atlgator 4y ago

When I'm looking for a good book to read, I always reference this site that aggregates HN recommendations: https://hacker-recommended-books.vercel.app/category/0/all-time/page/1/0 https://hacker-recommended-books.vercel.app/category/0/all-t...

tomdell 4y ago
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.
mejthemage 4y ago
Can't wait to get to #8 there. "Harry Potter: Hogwarts Hardcover Journal" -- I bet I could read that whole thing in one night.

ignoramous 4y ago

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 https://archive.is/199Eo [1] book: http://www.dataorienteddesign.com/dodbook/dodmain.html http://www.dataorienteddesign.com/dodbook/dodmain.html / more: https://github.com/dbartolini/data-oriented-design https://github.com/dbartolini/data-oriented-design [2] also: https://news.ycombinator.com/item?id=2275899 https://news.ycombinator.com/item?id=2275899

CSMastermind 4y ago
> 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.
- rschachte 4y ago
  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?
  - clumsysmurf 4y ago
    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.

gchamonlive 4y ago

In addition to that: 1. Structure and interpretation of computer programs 2. Software architecture the hard parts 3. Designing data intensive applications

hinkley 4y ago

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.

outworlder 4y ago
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.
- hinkley 4y ago
  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.
john-tells-all 4y ago
I've found the OG Design Patterns book to be verbose and opaque. I strongly recommend => Refactoring Guru https://refactoring.guru/design-patterns/python 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.
- hinkley 4y ago
  The DP book is a published version of Gamma's PhD thesis, which I learned in a class with someone closer to the story. It's corroborated here: https://www.zdnet.com/article/erich-gamma-a-pattern-of-success/ 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.

guelo 4y ago

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.

Jtsummers 4y ago
It was updated in 2018. It does not use Java anymore and now uses Javascript.
- disgruntledphd2 4y ago
  And despite never having written a line of javascript, I've found it tremendously useful.
lastofus 4y ago
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.
abledon 4y ago
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.
danwee 4y ago
It's literally the worst (tech) book I have ever read.

stevebmark 4y ago

"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 https://dev.to/cheetah100/domain-driven-disaster-147i for further reading.

kumarvvr 4y ago
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?
- stevebmark 4y ago
  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).

riceluxs1t 4y ago

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.

rschachte 4y ago
Not a book but check out jvns.ca for some inspiration.

x86x87 4y ago

Working effectively with legacy code, The design of everyday things, The Pragmatic Programmer, Peopleware, A Philosophy of Software Design, Hacknot, SICP

hellectronic 4y ago
I can recommend The Pragmatic Programmer by Thomas and Hunt

JackMorgan 4y ago

Here's my list of great programming books http://deliberate-software.com/page/books/ http://deliberate-software.com/page/books/

evelynsalt 4y ago

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. This book is good: https://bartoszmilewski.com/2014/10/28/category-theory-for-programmers-the-preface/ 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.

thraxil 4y ago
You got fired just for mentioning category theory? Where were you working? There has to be more to that story.

ngcazz 4y ago

Growing Object Oriented Guided by Tests would be my contribution

tpoacher 4y ago

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.