497: Diagrams we love

0:00Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at Thapot about developing great software. I'm Joel Kenville. And I'm Audrey Slater. And together we're here to share a little bit of what we've learned along the way. So Audrey, what's new in your world? New in my world is I've starting work on a new talk. It's going to be at Haggis Ruby at the end of April. That is the Scottish Ruby Convention. I have to say that is a delightful name for a conference. I enjoy it as well. It's the tastiest Ruby conference. And the little Haggis mascot that is on the website is truly wonderful. I love it so much. And yeah, I don't know the detail, the fine lines of the shape of this talk just yet.

1:02It was a little bit talk about something that's on your mind and kind of fitting the theme of the conference. It's about building things for at least from my perspective, building things from that that kind of part of yourself that's like fed by creativity and like nurture by making and building and doing things for the sake of fulfilling that. I kind of think human need, but don't know the ins and outs of it too much. I think there's going to be a little bit of like my recent time exploring around with Dragon Ruby and what are the differences between game development and web development. But speaking only as like a hobbyist game developer, then yeah, there's something there, but I don't know exactly what it is just yet. Do you think you're making an argument for sort of side projects as creative outlet or is the idea to find a way to make your day job scratch that creative itch? Maybe a little both. I, yeah, I go back and forth because there are certainly times when I really buck against

2:09the trend of making your side project monetizable or like the thing that you get your creative itch taken care of with doesn't have to be your career, but also like your career should be rewarding and fulfilling and all these different things as well. Yeah, like I said, I haven't really kind of dialed in on it 100% of the way, but a little bit like we were talking about a little while ago I think is that kind of like playfulness and that enjoyment and kind of excitement and energy from those sort of purely creative or sort of purely exploratory parts of making and building and what we do. I think that's something that the Ruby community is really good at tapping into that sort of joy and almost like sort of creative weirdness and I think it's RubyConf this year that has a track for just fun weird things you've made with Ruby either the product itself or you use a technique that's very novel or things like that where you're not looking about to talk about productivity

3:15or efficiency or anything you're just sort of having fun and being creative with the language. Yeah, you think that creative weirdness I just reorganized my shelf that I've got behind me and I've got wise pointy and guide right behind my head here so yeah I think that really is baked into not only the history but like the philosophy of Ruby and it excites a lot of people in the community as well. How about yourself what's new in your world? So it is conference season we've talked a little bit about RubyConf having a track for fun and delightful Ruby you've talked about Haggis Ruby. I'm going to be speaking at Blue Ridge Ruby the spring I think it's April 30th through May 1st. Okay. So the title of the talk is state is the first decision you never made. It's built on the sort of challenging line the idea that we build as web developers, stateful experiences over a stateless protocol, HTTP and so that sort of makes

4:18everything we build a little bit of a paradox and this talk is all about resolving that. That's really interesting. I think that's funny a little bit too because often where I start and I know a lot of people start is like the data model and you think you're thinking about sort of state but that's not really application state in some ways. Yeah. So I think the part of the core of this here is that yes you can design state a state model like at the database layer or maybe you know if you're having to react app or type script you're building all your types and all of that but that's only one side of the equation because a full web application experience is built fundamentally on a client server model. So you've got two sides and the protocol that ties the two of them together is explicitly stateless. It's built to be stateless and in fact you're having a conversation between client and server and we often talk about them as if they're single things but servers can be sort of deployed in parallel to handle a bunch of incoming requests

5:25with a load balancer or something in front and so the server your client is talking to might be different every time you continue that conversation and yet from the client's perspective it has to feel like it is one continuous conversation and the server has to remember where it is in that context even though it has absolutely no idea. Yeah that's true. I never really think about that side of it until you're thinking about something kind of explicitly server side or like how do you handle these different requests and things like that when you're thinking about a single user or single clients experience you are always treating it as though it's a conversation back and forth between two entities but it's actually a lot more complicated than that. Even if you think of something as simple as authentication right if every request has to stand alone then you almost have to include username and password on every request otherwise the next request we've forgotten the servers forgotten who you are it might be a separate server that's handling it and of course

6:29that's not a good experience for people having to like force them to type in their username password all the time. There are mechanisms like basic auth that will sort of autosin that in the background we did a whole episode talking about basic auth and some of the downsides around it and so yeah there's a whole sort of menu of options that we have because the web platform offers us a lot of tools for managing state over the web but yeah this whole talk is about what are the tools we have available when we might want to choose one or the other one and so we're really digging into the foundational aspects of what it means to build for the web what it means to build stateful experiences and how oftentimes those decisions are not made consciously they're downstream of other things so you and your team argue about do we want to have more of a server rendered versus a client rendered approach and that decision will impact how you manage state and you might just

7:32sort of be stuck with a state management approach based off of that and you've never taken the time to think about wait how do I want to manage state right so it's a little bit of a going back to the fundamentals of what does it mean to build in a client server world and we should be conscious of those ideas as we architect our systems well it sounds great I can't wait to can't wait to hear about the progress and see the end project something that I think that the talk will lean on decent amount because we're talking about a lot of like conversation between different systems is there will probably be a lot of visuals and diagrams fourth talk that's something I find is very helpful for communicating to others about ideas but also just for myself as a form of like synthesis yeah sometimes I'll have like sort of sprawling set of ideas or you know a lot of code and then if I can reduce it down to a diagram then I probably understand it better is that an experience that

8:32you share as well absolutely I work with a notebook and a pen open in front of me kind of at all times and if there's ever something that is maybe too much to hold on to all at the same time in my head or like you're saying I haven't completely wrapped my mind around all of the different little corners I will sketch it out and sometimes it's through a recognizable form of a diagram like a a pattern or a certain type of diagram sometimes it's just like sketching little shapes until it can kind of coalesce a little bit in in my mind having started out in like illustration and art I think that is just sort of part of like baked into my like thinking process a little bit so absolutely absolutely part of the way that I work are there any types of diagrams you find yourself gravitating towards maybe some sort of classic or standardized diagrams or do you just sort of evolve your own like nomenclature as you as you go along yeah I think it depends on the situation

9:41but there are definitely a couple that I fall back to all the time I think the first one or like the most often that I reach for is just going to be your basic flow chart taking some sort of state of the world at the beginning and falling through decision branches right is this a or b does the user want x or y and tracing all of the different places where the control flow and the logic might branch into different directions based on that state that you kind of drop in at the top I always sort of think of it as remember that prices right game plenko not a possibility with that but explain it to me it's one of those pegboard games where you can drop a ping pong ball or a little disc or something like that into the top of a large board that has kind of offset pegs and it'll plink plink plink plink plink plink down the board as it goes to a

10:41final resting place and I always kind of try to set up the chart in a way that you have a single state at the top and that kind of relates to like where you drop in the ping pong ball or the disc and it can follow and flow through the pegs hitting the pegs going left or right or whichever direction which are kind of like your your branches in your logic and then it sort of rests at the end is the end state the end result of the you know the next action that kicks it off and not only does that help me know the sort of flow through the system but it also sets me up with the idea for my tests a lot of the time too like the state the starting position of your tests should be represented at the top of your flow chart and then every end state should have a sort of test related to it and so yeah flow charts they show up often in even my commit messages I'll use a

11:44little program to do ASCII art flow charts and put them into my comments they're so baked in and so fundamental to how I think about systems that we built so it's really interesting especially the idea of like those terminal states being different sort of things that should be tested I also have a big fan of flow charts and this is specifically control flow diagrams not necessarily data flow or data transformation diagrams right what's interesting to me is that control flow diagrams are effectively graphs mm-hmm because they can sort of loop back in on themselves yeah and I guess you know you could have sort of you know recursion or any sort of like thing like that where it loops back up to something and like you have a true loop in the control flow diagram most control flow diagrams I see are probably better described as directed acyclic graphs

12:49and something that I've started doing sometimes is taking that graph and then effectively denormalizing it so turning the graph into a tree oh okay such that every decision point that is sort of downstream of another decision point sort of forks the potential but then like it crossed different branches the same if it's possible for it to go down one branch and then like have the same choice that a different branch would have that choice gets repeated so the classic control flow diagram sort of has these sort of joining back in together as a form of almost like dry you only see the choice in one place and then all the things sort of if they hit that same choice they all branch in at the same place whereas my denormalization makes it into a tree but potentially repeats the the visualization of the choice right right what that does is it effectively

13:50maps all of the unique paths through the code mm-hmm and so now what you have is a tree and everything starts at the the root node the entry point of your program but all the leaf nodes are all the possible exit points or rather all the possible paths you could take with potential side effects choices that could lead you to exit points mm-hmm then you can look at that and say like you were saying earlier I needed tests for each of these because you almost certainly want a unit test that covers every single path and there might be more of them than you you think just looking at a classic control flow diagram you might also look at that and say oh I've got 20 different leaf nodes on this now control flow tree and I probably don't want that many I want to trim these paths yeah that is really interesting do you find that that will if you have sort of duplicated these these nodes

14:56at certain points have you ever found or do you often find that they are not the same decision they're not the same node at duplicated and you've actually kind of uncovered where there might have been an abstraction that wasn't quite working for you or do you most often see that those end up still being kind of the same conceptually so the duplication is not necessarily in the code it's purely in the graph sure yeah so commonly what I will see is a situation where somebody chains sort of multiple independent conditionals mm-hmm it's instead of saying if condition one du x else du y it'll just be if condition one du x keep going or if condition two du y keep going and now what you have is instead of a sort of clear branch of du one thing or do the other you can have any combination of those right you could do potentially both x and y you could do just one you could do the other or you could do neither and so in a classic control flow diagram

16:01what you would have is sort of you have your entry point at the top you have a decision diamond that says x or y or decision one yes or two and then it's going to merge back onto the main path and then you hit decision two mm-hmm and then you do that again whereas with this sort of tree approach that I'll do this denormalized version now we're effectively splitting two branches at decision point one and we're not merging back and so now both of those paths need to have that diamond for decision point two mm-hmm in the code it's the same conditional but in the diagram it now appears in two places because it's downstream of two different decisions mm-hmm and what that does is it visually shows you the combinatorial explosion that's happening in your code which maybe you thought you were being clever by just having a mate these might even be like inline return or not even inline returns but like inline conditionals in Ruby do x if condition one do y if condition two and you

17:05they're like terse one liners and it looks like your code is very simple and not doing a lot and you don't realize that what you have is actually code that has four potential paths through it and have you thought about the implications of how these things combine and is that what you actually intended because maybe what you intended is do one or the other yeah I think these sort of little tools that can very easily lay plain the amount of complexity are really useful because any time that you can you may have rolled something up into like you're saying an inline conditional that looks very simple that the text of your code looks very terse and very readable but the actual kind of the different states that you can reach the different paths and everything can be a lot more tangled and a lot more like you're saying that combinatorial which I can't say apparently the combinatorial explosion that you've had there can be more visual more palpable in a way and I

18:11think that's what a lot of these diagrams are able to do it gives you a different perspective you can look at the same thing from a different angle which will let you glean different insights from them I think for listeners who were interested in like through seeing how this approach works out in a more practical setting I'm going to link in the show notes I wrote an article a while back on refactoring multi-step forms and how some of that conditional logic oftentimes is a really complex and using this sort of analysis to try to simplify tangled multi-step form code multi-step forms sometimes lead to these of another diagram that I kind of like especially when there's a third actor in in the flow is a sequence diagrams being able to see those steps of communication between that client and that server like we were talking about and if something has to make that round

19:14trip several different times then looking explicitly at the communication with this sequence diagram can be super useful do you find yourself using those it's not in my like primary toolkit but when I do pull it out I find it really helpful and so like this is really useful for me if I'm trying to think through some sort of let's say an authentication flow that like you said it involves more than just your classic client server so you're you're doing a thing where you're like oh well my client talks to my server which then redirects to a third party auth servers which then redirects back to my server which renders the client but then the client talks to an OAuth provider and you've got three or four different parties involved and they like redirect or talk to each other and that can be really challenging and so that's a situations where I found that a sequence diagram is particularly helpful yeah I've even found sometimes when I've had to like we were saying before

20:16actually map this out in a diagram that I can find that I had just sort of glossed over some round trips between client and server and just sort of taken as sort of implicitly happening and not really thinking about them anymore when you have to actually diagram it out and it's like well wait how did the server know that that happened oh because it had to go back then the client had to give it a new piece of information based on that last response and things like that that diagram can really uncover a few sort of overlooked round trips between your users and your server in a sense it's a little bit taking the contents of the network tab in your browser and making that in a more visual format yeah network tab I think an underutilized tab in the dev tools for for a lot of folks anytime I'm working in like front-end code the network tab is almost permanently open on my browser it is I live in that tab 100 percent more than the console more than

21:19the inspect element network tabs where I live definitely for sure for sure since it's all about that it's that's where it all is it's all right there I think a diagram that I find myself leaning on more if I am doing more front-end type code is a state machine diagram okay because oftentimes front-end UI is very nicely modeled as a state machine it is yeah it doesn't have to necessarily be implemented as a state machine but if you're thinking about it conceptually thinking of the idea of okay this component is in a certain state and then there are so many actions that a user can take that will put them into this next state this can be useful as a sort of high level understanding tool it can be useful as an analysis and design tool as well if you're like oh okay if a user does this they can get into an error state and then you might have to ask yourself can they get out of that error state or is like a hard refresh or a new navigation or

22:21something like the only way they can get out of it usually don't want your error states to be terminal states and that's for just good design but it's a little bit more in your face when you're looking at a state machine yeah 100 percent and it can also sort of expose if there is somewhere that you need a user to be able to get but you haven't made all of the different connections or bridges but that arrive there you can you can see that in a state machine because if there are other states that aren't pointing to where you want them to get that should be then you can kind of rethink how you're conceptualizing or even just like what buttons are available or what links and things like that yeah that's another good one it's also really good because it helps you I think to thinking a little bit higher level but also thinking about edge cases so you say all right I have this component user clicks this button what are all the possible states this could transition me to and then maybe you think a little bit say well there is a

23:24network component to this we're loading some extra data what if they're like what about the error states there what if the it's not that user did something wrong it is there's a network problem or the server somebody on the server team made an error and now we're getting a 404 or a 500 back what do we do for the air and does that are there multiple different error states on this component based off the type of error that we can transition to is there just one or perhaps even you might say okay well I'm not just going from a server naive click the button new state loads for some extra information I've pulled from the server there's a time lag between the two maybe you actually transition from sort of initial state into a loading state right and then loading can go into all sorts of other states and so thinking about that I think allows you it kind of crosses that bridge between the development and design yeah I know to certain extent product as

24:26well right the like what should the user experience be yeah that's true that's true those in between states that a user is going to experience but someone who's thinking of like the happiest path or sort of the highest level isn't going to draft out to the nth degree maybe right from the beginning then when you start falling into those states as you're clicking through or you're working through something then needing to consider them becomes a lot more important I think one of my coolest state machine diagram experiences several years back I was sitting down with the thawbot developer or a thawbot designer and together we were building out this pretty complex UI widget that was type of head but that was like pulling data from the server and sort of dynamically generating the type of head and it had a bunch of pretty complex states to manage yeah and we'd started with something really naive and then I started implementing it in Elm and the types system immediately started telling me like what about this state what about this state all

25:28these things I hadn't considered and so I went back to the designer and together we sat down and like mapped out all the states and this was probably prefigmas so this may have been like a just a photoshop mock or something with just a bunch of different high level box of what the component might look like and it effectively turned into a state diagram where we say hey here's the sort of initial state and then we draw an arrow and like here's what the component might look like if this thing happens and then we want you to be able to return back to that initial state where you want you to be able to you know what happens if you blur then you go to this other state blur yeah right oh yeah and that was one of those conversations where we're like we start with a very simple set of things it's almost linear it's like oh yeah the happy path you type and then you are in a loading state and then you get results and then you select one and you're in the selected state and then one of us would be like oh but what if the user blurs and you know then we're like oh now we got to think about now all of a sudden we're drawing a lot more boxes and arrows

26:30and you know you spent a couple hours doing that and pretty soon we had a fairly complex set of sort of UI mocks with arrows connecting them and if you squinted just a little bit as a developer I could recognize that we'd effectively created a state machine but this was not with any like sort of formal nomenclature or diagramming rules or anything like that right this is just me and a designer sitting down and pretty creating canvas of mocks with arrows connecting them but we effectively created a state machine diagram did that exercise cause you to change your approach at all where did you collapse some of those did you or did it feel complete then because you had just mapped out all of the edge cases it felt much more complete I think it allowed us to discover a lot more edge cases that we hadn't considered and also gave me a lot of answers to all those like oh what about this how should I handle that that like maybe I would have forgotten about or maybe I would have been writing code and been like oh yeah I've got an empty

27:33state here how should I handle that because I was sitting with the designer going through that together it almost like forced those conversations and so it was a almost like a structured conversation tool it was a way to communicate between sort of development and design concerns yeah I love that as a sort of cross discipline tool yeah all of these different diagrams are really great for getting an idea more concretely into another brain yeah it's either it's it's another perspective or by having to be explicit because of the rules of whatever diagram then you can be more sure that you're on the same page together as you're as you're going along and I think that's a lot of the times why a little diagram will make it into a commit message or a PR just trying to describe a thing in prose can be so much fuzzier than you think it can be

28:34and then when you have to sort of formalize it into a diagram you can be much more confident that the other person is seeing the exactly what you're talking about it's also I feel like a diagram can often act as like a almost a summary something that's much easier to scan it's a bit of a map of the terrain and so if I'm like reading your prose like commit message and I'm like every sentence I'm having like person think about okay so this I'm trying to load your mental model into my my head yeah that might be challenging in a way that like a control flow diagram I just look at it and I can almost immediately be like oh okay I can see that we've got two or three branches that go off and sort of independently do things or maybe I'm like oh I see that there's one main trunk path a lot of things that merge back into it and then because it's a standardized diagram I can use my sort of human pattern matching skills to realize oh I've seen some of these shapes before not the like literal like diamonds and things like that but these like highly

29:35branching diagrams versus a trunk with things that merge back and I I have a sense of what that means in terms of a program right and what the like maybe edge cases or failure modes might be if it's a PR then maybe that tells me hmm I look at this diagram I know that I want to go and check this part of the code because I know that based off the shape of your diagram that's a place where there might be some bugs hiding right right I've seen this shape before and although the words in the diamonds might be different this sort of shape makes me wary of exactly this edge case yeah yeah that's fantastic I guess it's almost like you're moving some of this analysis that I'm doing out of the sort of language and prose world into like a spatial world yeah I both are good and I think we're both we're able to work very well in both worlds but there's something about spatial

30:37reasoning that humans are particularly good at it is yeah we are tool users right so that kinesthetic awareness can really sort of tap a little bit deeper I feel like than the sort of linguistic level we mentioned a couple of times now though why is the decision a diamond they're so hard to write in in an asky in just like the traditional kind of like flow chart why is it always a diamond yeah I need more space in there anyway that's a that's a complete diversion but if you could make that in shape you wanted what would it be I usually end up making it like a pointy rectangle so it's a box but then it keeps the diamond points on the end because very often it's two directions you could take right right it's almost like a kind of like lozenge yeah some sort of chevron or like a what is it it's a squished hexagon as we all know

31:38is the best of gone yes for all of the cgp gray fans out there do you have any other lightning round shout out favorite diagrams it's moving maybe a little bit away from straight up diagram but dependency graphs are a mental model and a form of drawing that I keep returning to they're a little bit more generic than something like a control flow but I use that to I throw dependency graphs at just all sorts of problems and they're really helpful if you were in the the thought pot slack it would be every other week there's a new comment or thought about a dependency graph from joelle and they're they're all really great insights so I know I know they are near and dear to your heart I think a like maybe variation on a dependency graph is a call graph and so sort of seeing a function and then what it calls and

32:38what its children call and sort of sew on down until you hit sort of leaf no and they just returns all the way up or you know does side effects we're not necessarily functional programmers here I will sometimes sort of trace that out for code or subsystems where I'm trying to modify things as a sort of high level map before I get into actual modification so I find that can be helpful ever now and then I'm a big fan of just your kind of standard DB diagram your entity relationship diagrams oh uh-huh I find being able to draw those little lines of associations between tables is super useful for me in understanding the ways that I'm going to be thinking about how different models interact and will really help me pair down or shape up I don't have any other verbs for left or right just down and up my data model so those are always fun for me to reach for as well how formal do you get with those diagrams are you just doing like boxes and

33:42arrows or are you doing like the crow's feet with the like one to many one to one zero to one sort of constraints on there I think as the complexity grows I will get more and more formal oil start out very simple and where there might be underlying more specific iconography to use it's it's easy to just sort of ignore that and keep it in my head but as soon as I need to completely switch my mind away to thinking about a different part of that diagram and then being able to come back having lost the context of it earlier having that little bit of extra information in there is super useful for me so rather than having to again like we're saying go back through in like parse and re-understand if it's just kind of there on the page yeah I'll start to throw that in once I'm leaving either a single part of the page or if it's if it's getting much larger do you ever use

34:45any automated tooling to generate some of those I think Rails ERD is the sort of classic gem for that I have implemented that plenty of times to be able to hand off to another team or you know someone that wants kind of a more complete picture of what the entire database is looking like not sure what they do with it but that is not usually something that I'll reach for it's often a sort of like planning and organizational technique for me and not something that is going to be I'm not going to be going back to it after things are kind of more solidified and in the code because then that's that's where I like to go back and look at things I feel like getting the like ERD for the whole database is often too much on any like non-trivial program I often almost want a like pick a model and then if you sort of think of like all the model other things that might connect to it via Rails associations go out and maybe just do like an immediate direct connections

35:48or maybe you sort of crawl the graph out from let's say the user model to adaptive two or three or whatever your end is and that's sort of what I want rather than the entire database yeah but if you don't want to print the entire database you're never going to get to use that plotter that's just sitting in the corner of the office because we all have a plotter at home now don't we yeah definitely yeah it's just it's off screen you can't see it right I've been playing around a little bit with using LLMs as diagram generators okay four things like hey give me an ERD starting from you know user and then going out to adaptive two or trace this function and all of its descendants down to adaptive three things like that man with an output as a mermaid diagram or something like that and I found that kind of thing pretty useful okay being able to just sort

36:51of get almost like lenses over your code at the press of a button it's the sort of thing that I kind of wish that the ideas had built in but then you often I'm sort of have to custom make it for every language and all these things and LLM is sort of a cheap way of saying like you sort of know how to do Ruby and you know like a pro the structure of a Rails app make me a diagram roughly in this way cheap in quotes but let's not get into that just now fair any other diagram shout-outs I feel like we've hit a lot of my greatest hits here I mean if we want to do shout-outs I'm going to go for technology and that is mermaid hmm 100% part of what's really fun about mermaid it is now embedded in a lot of different places and so you were talking earlier about get a PR's you can do a mermaid diagram if you put it in a fence mermaid block get a bull render it for you oh wow including like the ability to sort of pan and zoom and all this stuff if you have like a

37:56really complex diagram and mermaid supports classic just sort of boxes and arrows it supports ERDs it supports sequence diagrams it supports state machines basically everything we talked about today mermaid supports yeah and so you want to like really level up how maybe a colleague can understand a complex PR you've written mermaid diagram me a great way to do that now I feel like I want to write or find a mermaid renderer that will render into ASCII there's a project I saw that did something like that it was an alternate renderer for mermaid and it had sort of a what it thought was a nicer like SVG renderer but then it also had a like ASCII back end hmm I forget the name of that that project that if I find the link will add it in the show notes a lot of my note taking also might start off of a diagram because obsidian which is my note taking tool also embeds mermaid as a renderer so you can do a fence code block start writing mermaid and

39:02just sort of get a graph that works there nice I really love mermaid I have to look up the syntax all the time because like I said my diagrams always start with pen and paper and so whenever I need to transmit that to someone else or put it into like text only format then I have to go look it up but really really great docs for mermaid to just a shout out to the team that wrote the documentation for mermaid something that I like about tools like mermaid or even sort of older tools like graph is with its dots and tax is if you're doing a graph sort of boxes and arrows type diagram you don't need to know the whole thing ahead of time because the syntax just has you do pairs of nodes that are connected to each other and you don't even need to have the entire list of nodes up front you can just sort of start and say well I know A connects to B and then you're like oh actually there's also a connection between C and B and oh there's a connection

40:04between A and D and you just sort of each pair you can add one at a time order doesn't matter and just sort of build your graph out that way and then you you have a render and all of a sudden you see the big picture yeah and so that's the technique that I've used let's say I'm mapping out a really gnarly spec file that has a bunch of like let definitions but somehow not all of them are triggering and so the data that I'm expecting to be in the database is not there because you know regular let without the bang is lazy initialized right so what I'll do is I'll just go through all of the lets in a file and see what references what and it's sort of build out effectively a dependency graph yeah yeah and I don't need to sort of have the mental model of how it all fits together I'm just like manually going through the file finding everything that connects to one another just adding pairs of points and then all of a sudden I can see the whole picture and be like oh so there's this whole path here and if the top one doesn't fire then the entire chain doesn't

41:06and so the the ability of syntax is like mermaid or graph is to allow you to not have to have the whole picture just put pieces at a time I find is a really powerful thing yeah super useful you also don't run out of space in the paper to draw another arrow off of a bubble yeah yeah that's true that's that I think we might be running out of space on this podcast to talk about diagrams oh well done yeah well then I think maybe we should wrap it up let's wrap up