I've been playing with often asking Claude to generate visualizations for me of what it's doing in the sense of diagrams of different types. Sometimes it's as simple as "show me what you're doing using an infographic". Othertimes I'll ask it for sequence or class diagrams or bipartite graphs if it's designing some sort of mapping. Bipartite graph is also very helpful for following the plan of a big branch rewrite or squash which I often do before making a PR to get rid of all those confusing in-between commits.
I find forcing it to visualize things immensely helpful. I'm usually studying git diffs but when working of a big feature or refactor that can just be too hard.
I've never been very pro "visual programming" and always hated UML et al, but part of me is starting to wonder if it's time for us to give it another serious go.
UML is not a terrible idea from a systems architecture point of view but UML is absolutely terrible at describing business logic. And in today’s age of CRUD apps and frameworks, for some devs, business logic is the entire problem to be solved.
What is “valid” input? What is the failure scenario at the boundary for the consumers of your application? How are exceptions in the business handled? All of these are questions that might have a somewhat obvious answer, but if your goal as a business is to do something radically different compared to your competition, the “obvious” answer might be the wrong one.
The usefulness of UML is highly reliant on the names you choose. And current LLMs are really, really bad at naming things. "The collector's refresh cycle has a bug: when the cache hydrates, the Cartesian grouping is misaligned" type nonsense - it absolutely will name a class "CartesianMisalignmentHandler" if you let it, good luck understanding what that is on a UML diagram
I find forcing it to visualize things immensely helpful. I'm usually studying git diffs but when working of a big feature or refactor that can just be too hard.
I've never been very pro "visual programming" and always hated UML et al, but part of me is starting to wonder if it's time for us to give it another serious go.
What is “valid” input? What is the failure scenario at the boundary for the consumers of your application? How are exceptions in the business handled? All of these are questions that might have a somewhat obvious answer, but if your goal as a business is to do something radically different compared to your competition, the “obvious” answer might be the wrong one.