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 <a href="https://nocomplexity.com/documents/reports/SimplifyIT.pdf" rel="nofollow noreferrer">https://nocomplexity.com/documents/reports/SimplifyIT.pdf</a><p>I also keep a very sort overview of imho good resources on Problem Solving Methods at <a href="https://www.bm-support.org/problem-solving-methods/" rel="nofollow noreferrer">https://www.bm-support.org/problem-solving-methods/</a>
Out of the tar pit changed how I look at everything.<p>Relational modeling can be the ultimate answer for wrangling complexity. It supports real world messy things like circular dependencies without a hitch. You can achieve the same in OOP, but then go and try to serialize or persist an instance of such a thing... you will find a very unhappy variety of dragon lurking in that stack trace.
Good question. Good answers. I'll add one :)<p>If considering not just software, but engineering or systems overall, best of all I seen is Goldratt, Theory of Constraints (usually named TOC).<p>Resources (mostly books) are many, they even created their own accounting system and simulation software. For intro good books The Goal (1,2,3), they are for different markets and shows look on different aspect of TOC, and easy to read.
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.
Great question, I personally recommend:<p>1. Simple Made Easy by Rich Hickey (video <a href="https://www.infoq.com/presentations/Simple-Made-Easy/" rel="nofollow noreferrer">https://www.infoq.com/presentations/Simple-Made-Easy/</a>)<p>2. Thinking in Systems by Donella Meadows (pdf <a href="https://wtf.tw/ref/meadows.pdf" rel="nofollow noreferrer">https://wtf.tw/ref/meadows.pdf</a>)<p>3. Raymond Hettinger’s content about CHUNKING is classic for this (one example video <a href="https://youtu.be/UANN2Eu6ZnM?si=TnLLj1CASwubkAS2" rel="nofollow noreferrer">https://youtu.be/UANN2Eu6ZnM?si=TnLLj1CASwubkAS2</a>)<p>4. The classic tome on Abstraction is Gödel, Escher, Bach: an Eternal Golden Braid, by Doug Hofstadter (<a href="https://en.m.wikipedia.org/wiki/Gödel,_Escher,_Bach" rel="nofollow noreferrer">https://en.m.wikipedia.org/wiki/Gödel,_Escher,_Bach</a>)<p>5. Finally, I’ll cut myself at lucky number five by pointing you toward Jüergen (You-Again!) Schmidhuber’s fascinating webpage: <a href="https://people.idsia.ch/~juergen/" rel="nofollow noreferrer">https://people.idsia.ch/~juergen/</a><p>Honorable mention to Margaret Hamilton’s T-Maps and F-Maps. Use a hierarchical numbered outline.<p>Zoom in and out of the fractal network. Remember your working memory holds seven (7) concepts, plus or minus two (2) … so chunk size around five (5) or less is ideal for cognitive accessibility.
I swear I got this recommendation here, but I can't remember who to credit and can't find the post.<p>Anywho, this is arguably the overarching reason <i>Design Rules: The Power of Modularity</i>[1] was written, at least in the abstract way you are asking it.<p>The book tells you about the process that led to the creation of IBM's System/360, and it shows how a set of patterns and rules have converged in parallel industry sectors. It was honestly one of the most interesting books I've ever read, and that's <i>exactly</i> what it is about. Highly recommend this book to virtually anyone on this board.<p>[1] ISBN10: 0262024667
<a href="https://www.manning.com/books/grokking-functional-programming" rel="nofollow noreferrer">https://www.manning.com/books/grokking-functional-programmin...</a><p>the concepts here are re: functional programming, but they apply to everything tbh.<p>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.
Not software engineering exclusively, but this article in system domain in general <a href="https://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/" rel="nofollow noreferrer">https://donellameadows.org/archives/leverage-points-places-t...</a>
I recommend David's Shapiro series on Systems Thinking that can be found here: <a href="https://www.youtube.com/@Systems.Thinking" rel="nofollow noreferrer">https://www.youtube.com/@Systems.Thinking</a><p>It deals with more than just software, as it can be applied in many systems.
Principles of Computer System Design<p><i>This textbook, an introduction to the principles and abstractions used in the design of computer systems, is an outgrowth of notes written for 6.033 Computer System Engineering over a period of 40-plus years. Individual chapters are also used in other EECS subjects. There is also a web site for the current 6.033 class with a lecture schedule that includes daily assignments, lecture notes, and lecture slides. The 6.033 class Web site also contains a thirteen-year archive of class assignments, design projects, and quizzes.</i><p><a href="https://ocw.mit.edu/courses/res-6-004-principles-of-computer-system-design-an-introduction-spring-2009/" rel="nofollow noreferrer">https://ocw.mit.edu/courses/res-6-004-principles-of-computer...</a>
Take Leslie Lamport's TLA+ course. [1]<p>And learn TLA+. The core idea of TLA+ is that any problem, how ever complex can be represented as a state machine i.e a sequence of variables or states that change over time.<p>It can be used to describe software, hardware and theoretical concepts like consensus algorithms.<p>I suspect one low hanging fruit for TLA+ is to use it for describing physical phenomena gravity, magnetism, boiling etc. This I haven't seen work using it for that yet.<p>[1]: <a href="https://lamport.azurewebsites.net/video/videos.html" rel="nofollow noreferrer">https://lamport.azurewebsites.net/video/videos.html</a>
SICP.<p>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.<p>SICP is about managing complexity.
The greatest advancement in computing, IMO, was structured programming. Ifs, Loops, Functions. What do they have in common? They got rid of goto spaghetti.<p>Erlang actors excel in part because they are structured in supervision trees. There's that word again.<p>If you can, structure things as a tree. If it is not possible, make a DAG. Only use arbitrary graphs as a last resort.<p>This is why so many OO codebases turn into a mess, every object has references to who knows what, forming a complex dependency graph full of action at a distance.
You don't mention where you're at.<p>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.<p>Commonly used and recommended books would be GoF (if you're not familiar with the patterns already), Code Complete, and The Pragmatic Programmer.
Useful heuristic for me: Organize everything so that it doesn't require more than 4 chunks of short term memory to work with.<p><a href="https://hiandrewquinn.github.io/til-site/posts/the-rule-of-four/" rel="nofollow noreferrer">https://hiandrewquinn.github.io/til-site/posts/the-rule-of-f...</a>
Butler Lampson's 2020 expansion of his 1983 paper <i>Hints and Principles for Computer System Design</i> [1]<p>[1] <a href="https://arxiv.org/abs/2011.02455" rel="nofollow noreferrer">https://arxiv.org/abs/2011.02455</a>
Takes more of a humanities approach to technical domains, but there's <a href="https://unintendedconsequenc.es/" rel="nofollow noreferrer">https://unintendedconsequenc.es/</a>