Dustin Boston

Hi, I’m Dustin Boston, a creative and curious Sr. Frontend Engineer at True Anomaly, in Los Angeles, California. I specialize in frontend web development with JavaScript, React, and Node.js. You can also find me on GitHub and LinkedIn.

  • Read One Book Per Week

    How to Read One Book Per Week

    There are some great tips for reading more in this post. My favorites are:

    • Always have a book. Keep a book in every room and on every device.
    • Read all three types of books, paper, audio, and e-books.
    • Don’t finish every book. I have a textbook that I only need to read half of.

  • Software Engineering Topics Worth Writing About

    Is it worth writing about?

    Some topics I think are always worth writing about and sharing:

    • Your process, failures and successes, to figuring something out
    • How to hack on some major open source project
    • In-depth comparison of projects or approaches, down to source code, benchmarks, and architecture when relevant
    • Building minimal versions of some production system
    • How some major systems works under the hood, down to the code
    • Mistakes you made in structuring organizations, or production architecture, or testing, etc.
    • How to get the dang configuration right for testing Electron apps in Github Actions

  • What I Care About as a Lead Engineer

    I care about different things now that I have grown into a lead engineer. There are some things that I have started to care more about, and some things that I have started to care less about.

    What a lead cares less about

    1. Personal Commit Volume
      • Junior/Senior View: “I need to ship a lot of code to prove my value.”
      • Lead View: “I need to unblock others so they can ship code.”
        • As a lead, you spend time on code reviews, design, answering questions, and clearing the path. As a result, the number of commits you make decreases.
    2. The Latest and Greatest Software
      • Junior/Senior View: “Let’s use this new beta framework; it’s faster, cooler, and more modern.”
      • Lead View: “Can we hire for this? Is it stable? Does it have good documentation?”
        • Leads focus on long-term maintainability and hiring over cutting-edge trends. As a lead, I shy away from big rewrites if they are not critical.
    3. Micro-Optimization & “Perfect” Code
      • Junior/Senior View: “This function can be 5 ms faster if I rewrite it three times.”
      • Lead View: “Is it good enough to ship today?”
        • Seniors often chase architectural purity. Leads are more open to taking on technical debt if it gives a business edge, like meeting a deadline. They need a plan to pay it off later.
    4. How the Team Solves the Problem (Implementation Details)
      • Junior/Senior View: “This is exactly how I would write this class.”
      • Lead View: “Does the interface match the spec? Does it pass tests? Then do it your way.”
        • Leads learn to delegate ownership. Nitpicking every line of a Senior’s code to match their style creates a bottleneck. It also demoralizes the team. They care about the contract (inputs/outputs), not the implementation.
    5. Being the “Smartest in the Room”
      • Junior/Senior View: “I need to have the answer to every technical question to show authority.”
      • Lead View: “I need to find the person who has the answer.”
        • A Lead’s value comes from synthesis and decision-making, not encyclopedic knowledge. They feel at ease saying, “I don’t know, let’s ask the database expert.” This change means they now route knowledge instead of sharing it.
    6. Rigidity in Process
      • Junior/Senior View: “The ticket had incorrect formatting, so I won’t do it.”
      • Lead View: “This is urgent; I’ll fix the ticket later.”
        • While Leads usually enforce process, they also know when to break it. They focus less on sticking to strict rules, like needing 100% test coverage for a prototype. Instead, they focus on the practical needs of the business.

    What a lead cares more about

    Lead engineers change their focus from output, like writing code, to outcomes. This includes system reliability, team speed, and business value. Their focus is on the big picture. They focus on the product’s technical success. Their concerns are strategic, not tactical.

    1. The “Bus Factor” (Risk Mitigation)
      • The Concern: “If we lose someone tomorrow, does the project die?”
      • The Action: Leads obsess over knowledge silos. They push for rotating key tasks. They need documentation for complex systems. They also avoid obscure technologies that are hard to hire for.
    2. Force Multiplication (Developer Experience)
      • The Concern: “Why does it take 45 minutes to deploy a one-line change?”
      • The Action: Leads care about the feedback loop. They invest time in CI/CD pipelines, local dev environments, and linting tools. If they save 5 minutes for 10 developers, that’s 50 minutes of extra productivity per build.
    3. Observability & Average Recovery Time
      • The Concern: “How do we know it’s broken before the customers tweet about it?”
      • The Action: Seniors care that the code passes tests; Leads care that the code emits logs. They focus on metrics, dashboards, and alerting. This way, when issues arise, they can find the root cause in minutes, not days.
    4. Technical Debt as a Financial Instrument
      • The Concern: “Are we paying too much ‘interest’ on this legacy code?”
      • The Action: Leads don’t aim for zero technical debt; they aim for managed debt. They talk with product managers to “buy” time for refactoring. They explain the cost of inaction. For example, they say, “If we don’t fix this now, feature X will take twice as long to build next month.”
    5. Alignment with Business Goals
      • The Concern: “We are building a Ferrari, but the business needs a moving van.”
      • The Action: Leads are the filter between “cool tech” and “profitable tech.” They prevent over-engineering. If a basic CRUD app can solve the business problem, they will block the team from building a complex microservices architecture. Even if the team wants to do so.
    6. Consensus and “Disagree and Commit”
      • The Concern: “Is the team paralyzed by debate?”
      • The Action: Leads care about decision velocity. They lead technical talks and make sure everyone’s voice gets heard. They also finalize decisions to resolve ties, helping the team move forward.

    The transition from Senior to Lead is fundamentally about trading personal output for team output. It requires letting go of the immediate satisfaction of closing tickets to focus on the often invisible work that keeps the system healthy and the team moving. By prioritizing business alignment, risk mitigation, and developer experience over technical perfection and personal commit counts, a Lead Engineer ensures that the team doesn’t just ship code, but delivers sustainable value.

  • Anti-AI Hype

    Simon Willison’s response to Don’t fall into the anti-AI hype

    I’m glad someone was brave enough to say this. There is a lot of anti-AI sentiment in the software development community these days. Much of it is justified, but if you let people convince you that AI isn’t genuinely useful for software developers or that this whole thing will blow over soon it’s becoming clear that you’re taking on a very real risk to your future career.

    Don’t fall into the anti-AI hype

    Whatever you believe about what the Right Thing should be, you can’t control it by refusing what is happening right now. Skipping AI is not going to help you or your career.

  • Technical Blogging Lessons Learned

    Lots of good advice about blogging in this post, like writing with a time limit:

    Setting time limits. I started… with the idea of using 60min every Sunday to write. Whatever gets written in those 60min gets published.

    Or this one from Jeff Atwood about making writing a habit:

    Just write. Make a habit of writing. It’s like exercise. It’s like anything else…mental health. What are the fundamentals of mental health? Are you eating? Are you sleeping? Are you exercising? Are you having sane interactions with friends and family? These are the fundamentals. And I would add another fundamental to that: Are you writing?

  • Reframing AI “Slop”

    Instead of saying “AI writing is slop,” we should explain how to make it better. What you may see as “AI slop” might be legitimate, but poor writing. Not everyone has an MFA.

    Also, as AI writing becomes more prevalent people will start to sound more like AI. So rather than say “that sounds like AI,” we teach people how to use their own voice.

  • Web Frameworks and LLMs

    Dead Framework Theory makes some good points about React and LLMs:

    1. React has become the default framework of the web
    2. React’s dominance is perpetuated by LLMs via existing sites and tooling
    3. New frameworks and platform features must compete against via LLMs
    4. Framework innovation stagnates and frameworks become irrelevant

  • Functional Programming in React

    Level Up React: Functional programming in React

    React uses a functional paradigm, so we should use functional principles when using it. This article shows the basics of functional programming with React. I’m interested to see how far this can be taken. For example, could we use combinators as HOC’s to compose pages?

  • Working From Home Improves Mental Health

    The effects of commuting and working from home arrangements on mental health

    Working from home improves mental health as compared to commuting, especially among women and those with poor mental health.

  • More Ways CSS and HTML Can Replace JavaScript

    You No Longer Need JavaScript by Lyra Rebane

    Modern CSS and HTML can replace JavaScript for more use cases than most developers realize. The web is evolving away from JS-heavy frameworks and toward progressive enhancement.

    This article has examples of centering things, nested CSS, web components, dark mode, CSS variables, accordions, and form field validation.