@Tango-tt6dx
This is a "UML" intro talk with some tipps how to integrate it in projects or work. I feel like we are entering the next circle of "hate uml, design, architecture" over "f*** our apps are buggy, what can we do?" to "oh, we can visualize complexity to manage it and plan extensions" I am all in for describing and reducing complexity but the reality is, you need to be very selective with whom you are gonna discuss over it. I see people rather like being ignorant and increasing complexity than "seeing" and managing it.
@TimotheeHowland
41:28 A gross generalization is stated here, and the diagram shown is perfectly functional. It's meant to be used at multiple levels of detail or to communicate multiple, orthogonal yet interelated aspects of information. By focussing in turn on the different aspects communicated, one easily understands the information, and one advantage of this method is that all the interelated information is in one place, or, specifically, close to each other, so one can easily learn or analyze the different aspects together. The boxes and arrows are one level. Using colors is another level of aspect communicated. The icons another, etc. The two other examples of "bad diagrams" are also silly. They are fine. Finally, the pen and paper recommendation is misguided -by a study that was not about diagrams, and did not show that diagraming with a tool was any less effective for understanding or retention Electronic diagraming has a much higher speed of creation and of making changes , and greater ease of storing,, retrieving , sharing, collaborating... It's great to see the rare person excited about diagraming! We need more pianists in software engineering!
@Tony-dp1rl
Diagram are almost never useful outside of high-level overviews. They just are never kept up to date, and don't scale with detail.
@GOTO-