JavaScript state machines and statecharts
I recently had a conversation about joining a startup with a really interesting, but complicated, product mostly actualized in a complex JavaScript spa (react).<p>They wanted a more senior engineer to join so as to help untangle some of the complications and lead the juniors (that built the thing already? Unclear) out of some kind of rats nest they&#x27;d been coded into. I never saw the code so I&#x27;m not exactly sure what this meant.<p>Anyway the founder asked me to look into this xstate platform before our call and asked a lot of questions about my understanding of state machines. The founder had this idea that if the team built out a bunch of state charts using this product and like, diagrammed their entire app, that was their ticket out of whatever sticky situation they were in.<p>I was pretty skeptical at the time and remain so now. This seems like an interesting analysis method, and implementing SPAs in a state machine way (each component being a state machine) is alright I guess, but, especially for a startup, building out these charts feels like a waste of time. To me it seems like fielding early customer feedback and driving features is more important.<p>My guess is that the engineers had a pretty good idea what was going on but were struggling to explain it in a way the founder understood, or maybe were slowing down on feature implementation, I don&#x27;t really know, but I&#x27;m always so skeptical of slapping more tools and plugins and diagrams onto the stack of things the engineering team has to worry about.<p>I&#x27;m curious if anyone has been on a team in a situation as I&#x27;ve vaguely described here and found state charts useful in getting them out of a hole?