My Lectrofan noise machine works wonders for covering up all kinds of noise

My Lectrofan noise machine works wonders for covering up all kinds of noise

Oh definitely! I’m amazed that it’s not spoken about more. The value of the research output alone from another team would be huge.

They should stick to overpriced sugar water

I overwrote then deleted all of my comments a few weeks ago—they were all back in their original form last week. I’ve since run the process again and already old comments are starting to reappear

In England we drink straight from the tap. I live in London which has incredibly hard water so it’s not the nicest tasting and it will leave white residue on the glass but it’s not bad for you.

Not at all. I find it useful for certain tasks, but I’m a huge introvert and spending a long period of time with someone physically exhausts me to the point where I can’t muster coherent speech or thought. Depending on the depth of thinking required too, it’s often better for me to do that individually then bring my findings to someone else to validate.

But I’ve already regarded it

I find keeping C4 diagrams in wikis often leads to them falling out of sync with the codebase. Ideally you’d keep the markup for the diagram in the relevant component repo and have a CI/CD process that keeps your diagrams up to date. I wrote a PlantUML Docker image for exactly that: https://github.com/robbell/plantuml-docker

Alternatively, Mermaid support is becoming more common—available in GitHub and Backstage TechDocs, and that allows you to embed diagrams in Markdown. Both PlantUML and Mermaid have support for linking to other diagrams I believe, and you could put your API definitions in your owning repos too using OpenAPI to keep everything together and in sync.

I’ve used it with a lot of success at my current and previous companies. To address a few of your cons:

• Engineers are quickly comfortable with the tooling and VS Code plugins give you quick feedback. You can also point the plug in at a hosted instance to avoid running a local instance in Docker

• Separation of different types of diagram is often a bonus—too often have I seen architects try to cover too many concepts in a single diagram—instead a Context diagram should define your system and its neighbours, a Container diagram the major pieces of your system, a Component diagram verges on design and is a good place for engineers and architects to converse. If a container or component has a particularly complex workflow, then a supplementary flow diagram helps. If it uses an extraordinary pattern, then a class diagram might help, and so on.