Swizec Teller - a geek with a hatswizec.com

Senior Mindset Book

Get promoted, earn a bigger salary, work for top companies

Senior Engineer Mindset cover
Learn more

    Avoid spooky action at a distance

    [name|Friend] unclear state dependencies are the biggest source of code that's difficult to detangle.

    So much so that Shared State Bad is a programming dogma described in books like Pragmatic Programmer and many others. But shared state is fine, even necessary, when done right. Let me explain.

    One of my earliest big projects was a text-based GUI for DOS. I was 12 and called it an operating system because I didn't know any better. That project taught me an important lesson about shared state.

    Example of what text-based GUIs in DOS used to look like, image from Wikipedia
    Example of what text-based GUIs in DOS used to look like, image from Wikipedia

    I wrote the project in Turbo Pascal before learning about functions, procedures, arrays, and objects. The whole codebase lived in 1 file, used nearly 200 global variables, and to give you a sense of scale: I ran into trouble because GOTO couldn't jump more than 4096 lines of code. Solved that with double jumps 🀘

    All talent no skill.

    Note: The GOTO statement lets you jump to pre-defined locations in the code. Once popular, the practice went away with the Structured Programming movement of the 60's and 70's and was replaced in most contexts with functions by the early 90's. You might still see GOTO in performance-critical low-level applications.

    The word "mess" doesn't even begin to describe my big project. I used global variables named a, b, .. aa, ab sort of like a programmer in the 1960's might use absolute memory addressing. I even re-used variables between features, which meant that a variable's exact meaning depended on how you got there.

    This caused many hard to fix bugs. Click through the UI in a new sequence of steps and everything gets jumbled up.

    How shared state causes problems

    The intermingled state made it so my code's exact behavior depended on how users (really just me) went through features. Here's a simplified example:

    var counter: integer
    
    counter := 0
    
    add:
    	counter := counter + 1
    	writeln(counter)
    
    sub:
    	counter := counter - 1
    	writeln(counter)
    	goto add
    
    fun_feature1:
    	counter := counter + 10
    	goto sub
    
    fun_feature2:
    	counter := 2
    	goto fun_feature1
    
    • add: the add block adds +1 and prints the value
    • sub: the sub block subs -1, prints the value, and jumps to add
    • fun_feature1: the fun_feature1 block adds +10 and jumps to sub
    • fun_feature2: the fun_feature2 block prints a message and jumps to fun_feature1

    Note: DOS was limited to 25 lines. Turbo Pascal used 4 lines for the UI. Meaning my code spanned at least 195 screens. With all 200+ variables defined in a big block at the top of the file. 12 year old Swiz must've been a genius.

    Unclear shared state happens quickly

    You don't need GOTO programming to run into unclear shared state. Here's a typical situation that happens in event-based code:

    let menuIsOpen = false;
    
    function toggleMenu() {
      menuIsOpen = !menuIsOpen;
      window.localStorage.setItem("savedMenuState", menuIsOpen);
    
      updateMenu();
    }
    
    function updateMenu() {
      if (menuIsOpen) {
        // display menu
      } else {
        // hide menu
      }
    }
    
    document.onload = () => {
      menuIsOpen = window.localStorage.getItem("savedMenuState");
      updateMenu();
    };
    

    Prefer pure functions

    The issue is that neither toggleMenu nor updateMenu are pure functions. You can't tell what they'll do unless you know the value of menuIsOpen.

    Note: A pure function is one that relies only on its arguments and has no side-effects. You know it's pure when calling the same function multiple times with unchanged arguments produces the same result.

    When shared state works great

    Shared state isn't all doom and gloom. It causes problems when you have asynchronous or threaded code and unclear access patterns.

    But your database is a repository of shared state and that works great. The cache in your networking layer is a type of shared state. Works fine. State management libraries popular in modern app development are all about sharing state and they can be fantastic.

    What gives?

    Explicitly declared state dependencies with strict guidelines around access patterns make all the difference. If a compiler or linter can enforce those patterns, even better.

    function SomeBeautifulData({ id }) {
    	const { data } = useQuery(
    		['beautiful-data', id],
    		...
    	)
    
    	return data.map( ... )
    }
    

    Thanks to explicit state dependencies, you can let framework machinery handle the details 😍

    Cheers,
    ~Swizec

    PS: databases achieve this with ACID – atomicity, consistency, isolation, durability. By ensuring every write completes before any read and that writes can't conflict, a database can ensure you always read the right data.

    Published on August 26th, 2023 in Software engineering, Architecture, Lessons

    Did you enjoy this article?

    Continue reading about Avoid spooky action at a distance

    Semantically similar articles hand-picked by GPT-4

    Senior Mindset Book

    Get promoted, earn a bigger salary, work for top companies

    Learn more

    Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.

    Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.

    Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help πŸ‘‰ swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.

    Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers πŸ‘‰ ServerlessHandbook.dev

    Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization

    Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections

    Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog

    Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com

    By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❀️

    Created by Swizec with ❀️