I've been working as a "web developer" since 2012.
I am a self-taught programmer who has worked on custom PHP frameworks, Wordpress, Drupal, Node.js apps, and Python microservices.
It wasn't until 2019, when I wrote my first state machine, that I felt like I wrote something as a programmer.
Writing a state machine for work using xstate and knowing that over a year later that code is still in production has given me a greater sense of self-worth.
What are state machines?
Before I get ahead of myself, for anyone who isn't aware, xstate is a Javascript library that implements finite state machines.
Finite state machines are a model of how to describe the world.
A machine exists in a state and transitions are created to show how the machine can move to different states or go back into the same state (a vending machine is a finite state machine).
These definitions at the start didn't do much for me, and they certainly didn't make me feel like a better programmer by "knowing" what they meant. I had to actually create something using these concepts in order to feel like I got it.
UI's have always been complicated
I work in healthcare. Healthcare apps are notorious for having complex UI's and forms that people need to fill out. At my job we use React and Redux.
There was a breaking point in 2019 when we needed to make a new UI flow for providers. My co-worker and I were writing out the following Redux object for the nth time:
{
didInvalidate: boolean;
isFetching: boolean;
hasError: boolean;
}
that we realized that there had to be a better way. This pattern wasn't working for us regardless of how many other posts endorsed it.
Youtube recommended this video on designing state machines for UX:
and I pitched it to my co-worker the day after. He examined the library and he didn't see any issues with it. We pitched the usage of this library to our engineering manager and he approved it as well.
It took us longer to build the feature since the xstate API was new to us; but the end result was a bug-free release.
It wasn't only that using xstate made the release of the feature bug-free, but everything around writing the code that convinced us that this was the way forward to developing UX.
I learned how to ask questions
Finite State Machine models force you as the programmer to clearly state what will happen with the thing you are building.
- How does a user get from A -> Z?
- Can the user end up in X for any reason?
- Are there any ways to catch the user if they are in a state we didn't account for?
I never asked myself these questions before coding. These were problems I addressed as I was writing the React components and using this.state or Redux to figure out. This is backwards.
We (as programmers for the web) should always be using state charts to answer these questions. I had to ask the designer multiple times about specific error states that weren't addressed. I had to direct message the product manager about the user types that weren't accounted for in the initial feature request. It was an ongoing conversation between all of us because we all wanted the feature to succeed.
How I felt like a programmer
We asked questions on what we were building. Once we were experts in the feature that we were about to build, did we then start to write out code.
As we finalized our machine objects and knew precisely what our feature was going to do, it was this confidence in the finite state machine model that made me feel like we "leveled up".
We became programmers because we knew how the thing that we built was going to work.
Top comments (0)