Working effectively with legacy code, The design of everyday things, The Pragmatic Programmer, Peopleware, A Philosophy of Software Design, Hacknot, SICP
I can recommend The Pragmatic Programmer by Thomas and Hunt
Software engineering books to read and reread
41–47 of 47 posts
Re: Software engineering books to read and reread
#42I 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.
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-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.
Re: Software engineering books to read and reread
#43I 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…
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.
Re: Software engineering books to read and reread
#44When 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-t...
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.
Re: Software engineering books to read and reread
#45When 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-t...
Can't wait to get to #8 there. "Harry Potter: Hogwarts Hardcover Journal" -- I bet I could read that whole thing in one night.
Re: Software engineering books to read and reread
#46Earlier quoted context omitted.
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…
There’s a downside to this as well though.
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.
Re: Software engineering books to read and reread
#47Earlier quoted context omitted.
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…
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.