3 ms·

I find the article falls in its own pitfall of justifying every section with "it's hard / misleading for a new joiner / beginner". I almost never do architectu

I find the article falls in its own pitfall of justifying every section with "it's hard / misleading for a new joiner / beginner". I almost never do architecture diagrams for new joiners or beginners, I do them for the other experts of my team, and they perfectly understand that subscriptions go in the Subscription table in DDB because they've all worked on this system. A lot of those points go against probably the most important point "Too many overlapping concerns". The point of a diagram is to get a point across, and I don't believe there's any universal rule that will make this easier, because there's no universal audience.

lanstin 2y ago
I joined a company a few years ago, and there was a long term dev that had been there forever and was now a manager and did live trainings on webex with Lucid chart, where there was no prepared docs or whatever, but he drew the architecture diagram as the training, providing detailed explanations and answering questions as the diagram went. It was astonishingly effective at getting the points driving the architecture (and the salient business context driving the architecture). Each detail and each big overarching principal stuff would come at at the time when its context was right there on the evolving diagram. i was so inspired I bought a Lucid subscription, tho I never have done such good presentations, having some pictures I find makes it easier to communicate with more people.