Learn by doing? Certainly helpful. But I feel like the real secret is to work with others who are good at software architecture. You can learn very efficiently that way.
Learning Software Architecture
31–40 of 133 posts
Re: Learning Software Architecture
#32With AI we all have to make the switch from programmer to software architect, I suppose.
Re: Learning Software Architecture
#33With AI we all have to make the switch from programmer to software architect, I suppose.
With the amount of shit code generated it ain't gonna happen anytime soon.
Re: Learning Software Architecture
#34Software design/architecture is a strange beast. It feels that if you want to learn it, you should spend time in legacy systems and large codebases of rewrite a project 3 times to explore counterfactuals. A lot of books on the subjects are abstract and give such simple examples, they are useless.
>Software design/architecture is a strange beast
Yes. At one point I thought a set of good programs can be composed into a good architecture. Then at another stage- with agile, etc.- I was thinking about evolutionary architectures.
But experience and dealing with different kind of problems and systems work best. Also, I have seen Conway's law hold when many other patterns, principles fail.
Books like Garlan Shaw are good but help if you have some experience. Some other books/ courses like Neal Ford's help, but for me those helped only to know the terms/ ideas. Practice and rewrites, tech-upgrades helped more. Also, books like Michael Nygard's Release It.
Re: Learning Software Architecture
#35Software design/architecture is a strange beast. It feels that if you want to learn it, you should spend time in legacy systems and large codebases of rewrite a project 3 times to explore counterfactuals. A lot of books on the subjects are abstract and give such simple examples, they are useless.
My example here is: it’s impossible to know what spaghetti code is until you experience it, and are on the hook for its bugs and outages.
We hear a lot about it prior and upon experiencing it I could name it. (Like love, I suppose?)
Re: Learning Software Architecture
#36[deleted]
Re: Learning Software Architecture
#37I'll give you the cheat sheet:
- Good design is a single idea pervaded throughout.
- More generally, your goal should be to minimize surprise.
- If your system allows it, people will do it.
- Everyone will not just. If your solution starts with "if everyone will just..." then you don't have a solution.
- Isolate the parts of your system that transform data from the ones that use it. Data models outlive code.
- Coupling is the root of most evil.
- Versioning is inevitable.
- Make state explicit.
- Every piece of information should have a single source of truth.
- You should spend more time thinking about naming things correctly.
- If testing is difficult, the design is wrong.
- You will regret every undocumented decision.
- Communication is a tax that you should justify before paying it.
Remember that the job of an engineer at any level is to use rules of thumb to solve problems for which there is incomplete information.
Re: Learning Software Architecture
#38The recommendations are often very good, for example Ousterhouts A Philosophy of Software Design , but seem to be on software development in general, not actually software architecture in particular. For that, I would recommend the classic texts, such as Software Architecture: Perspectives on an Emerging Discipline (Shaw/Garlan) and really anything you can find by Mary Shaw. Including more recent papers that explore…
> if procedure calls are the assembly language, what might a high level language look like?
I’m not well versed in PLT and SWE tooling, but isn’t that the base concept around lambda calculus, LISP, APL, clojure, TCL,…? You only need a few data structures and types, a small collection of fundamental functions, then you compose them.
If there’s one thing that I like about Lisp is that more complex type are always opaque (especially the ones from FFI). I would love to see CLOS implementation for a C-like language, where when you define a struct, what you get is a standard collection of functions.
Re: Learning Software Architecture
#39I'll give you the cheat sheet: - Good design is a single idea pervaded throughout. - More generally, your goal should be to minimize surprise. - If your system allows it, people will do it. - Everyone will not just. If your solution starts with "if everyone will just..." then you don't have a solution. - Isolate the parts of your system that transform data from the ones that use it. Data models outlive code. - Coupli…
I'd add
- data migrations are inevitable and should be planned for (corollary of versioning)
- planning is good, sometimes you just have to try things out
- everything costs money. Designing without costs in mind will force hard choices down the line
Re: Learning Software Architecture
#40[flagged]
> Laozi gives the complementary warning: “In pursuing learning, every day something is added. In pursuing the Tao, every day something is dropped.” Mastery is not only accumulation. It is also subtraction: removing unnecessary abstraction, ceremony, cleverness, and control. Well, your (or your LLM's) interpretation is a bit less nuanced than the original. The verse from DDJ you mention is more about letting go and li…
Definitely a 'your LLM' case here.