[HN Gopher] Ask HN: Best resources on abstracting and dealing wi...
___________________________________________________________________
Ask HN: Best resources on abstracting and dealing with complexity
What would be your recommendations on resources that teach on how
to abstract away and cope with complexity and hierarchy in
technical domains?
Author : tinktank
Score : 20 points
Date : 2023-12-13 20:56 UTC (2 hours ago)
| golfinho23 wrote:
| This is a manual solution. Create system sequence diagrams of
| your domain as you'll learn a great deal in the process and have
| a visual heuristic to revisit when needed.
| valand wrote:
| Not software engineering exclusively, but this article in system
| domain in general https://donellameadows.org/archives/leverage-
| points-places-t...
| mnode wrote:
| This is great! Thanks for sharing.
| Layvier wrote:
| In software, "A Philosophy of Software Design" is a must read
| imo. Otherwise Rich Hickey's talks are always very insightful.
| yuvadam wrote:
| This. By far the most important book any developer should read,
| no other book even comes close.
| EdwardCoffin wrote:
| Butler Lampson's 2020 expansion of his 1983 paper _Hints and
| Principles for Computer System Design_ [1]
|
| [1] https://arxiv.org/abs/2011.02455
| whalesalad wrote:
| https://www.manning.com/books/grokking-functional-programmin...
|
| the concepts here are re: functional programming, but they apply
| to everything tbh.
|
| whether your system is a single monolith or a bunch of
| microservices, the core ideas hold true: think about your system
| in the form of actions (mutations), calculations/computations
| (reads), and data as data.
| taeric wrote:
| I have lately been asserting that so much of computing
| interfaces is essentially materialized views into a database.
| Whether that database is relational or not really doesn't
| matter. Aggregation rollups and flat data entry are easy to see
| in that world with transformation from the flat data store that
| users directly write to into somewhat normalized backend
| systems that are all constantly running jobs to materialize the
| views that the rest of the systems use.
|
| To that end, I heavily stress that there is no single "data as
| data" view of any data in the system. It is all a
| transformation of some sort from somewhere.
|
| This is not to say that I disagree with your general statement.
| I would stress that the same "data" can have multiple
| representations in the "data" world. (This is not uncommon for
| outside of programming, either. Easy to consider that 1/3 is
| .33333... or 3.3...e-1, etc. Canonical formats for any data
| item are things you have to work to build, they do not come for
| free.)
| whalesalad wrote:
| At the end of the day, it is data. It might get read out of 3
| different underlying systems, enriched by some kind of
| computation (dynamic or computed attributes vs ones that are
| actually persisted to a db, etc) but it is data.
|
| If you can think in data, as you say the underlying
| mechanisms for storing and retrieving that are less
| important. They are when it comes to performance and
| persistence guarantees, but if you abstract things correctly,
| that becomes easier.
|
| To add to my initial comment... Two things that come to mind
| as vital to a healthy system: SOLID principles
| (https://en.wikipedia.org/wiki/SOLID) and Clean Architecture
| (https://blog.cleancoder.com/uncle-bob/2012/08/13/the-
| clean-a...), and Hexagonal Architecture (https://en.wikipedia
| .org/wiki/Hexagonal_architecture_(softwa...) come to mind.
|
| Recently I saw a post here that clean architecture was dead.
| This is hilarious to me and not true. If you are writing a
| low-level script, sure you can avoid that and optimize ...
| but for larger systems (ie, anything that is outside of a
| single process), clean+hexagonal is the way to go.
| 3np wrote:
| You don't mention where you're at.
|
| You're describing a major part of Software Engineering. Most
| reasonable university/college SE 101 courses will focus here.
| Which is to say, if you haven't (or it's been a while), check
| reading lists for university SE classes and pick the ones that
| focus on modeling. steer clear of process/agile material.
|
| Commonly used and recommended books would be GoF (if you're not
| familiar with the patterns already), Code Complete, and The
| Pragmatic Programmer.
| waynesonfire wrote:
| SICP.
|
| I will never forgive my college professors for not teaching this
| to me. Many years later, when I discovered SICP on my own, I
| recognized that my high-school CS teacher wanted expose me to
| this. I was too young at the time to understand. Bummer.
|
| SICP is about managing complexity.
| runningmike wrote:
| I created my own guide after reading too much books: Simplify IT,
| The art and science towards simpler IT solutions , it's cc-by on
| https://nocomplexity.com/documents/reports/SimplifyIT.pdf
|
| I also keep a very sort overview of imho good resources on
| Problem Solving Methods at https://www.bm-support.org/problem-
| solving-methods/
| bionhoward wrote:
| Great question, I personally recommend:
|
| 1. Simple Made Easy by Rich Hickey (video
| https://www.infoq.com/presentations/Simple-Made-Easy/)
|
| 2. Thinking in Systems by Donella Meadows (pdf
| https://wtf.tw/ref/meadows.pdf)
|
| 3. Raymond Hettinger's content about CHUNKING is classic for this
| (one example video
| https://youtu.be/UANN2Eu6ZnM?si=TnLLj1CASwubkAS2)
|
| 4. The classic tome on Abstraction is Godel, Escher, Bach: an
| Eternal Golden Braid, by Doug Hofstadter
| (https://en.m.wikipedia.org/wiki/Godel,_Escher,_Bach)
|
| 5. Finally, I'll cut myself at lucky number five by pointing you
| toward Juergen (You-Again!) Schmidhuber's fascinating webpage:
| https://people.idsia.ch/~juergen/
___________________________________________________________________
(page generated 2023-12-13 23:00 UTC)