Jay Hoffmann

Tag: WordPress

  • #23: The React Rewrite

    I think about rewriting code a lot. If you’ve been at it for enough years, you’ll inevitably find yourself in many conversations about whether or not a team should be rewriting a codebase when faced with a project that is opaque, frustratingly slow and nonsensical. It can very quickly feel like a rewrite is the only option.

    Developers will often advocate for that solution, and I understand why. It can be liberating. It’s like clearing away an overgrown thicket to reveal a perfectly clear path ahead. If only the code was cleaner and more maintainable, the argument goes, we could deliver even more new features in half the time. We just need to refactor it first.

    But that is rooted in a flawed premise. Like anything, software tends to deteriorate over time and usually, it doesn’t necessitate drastic measures like a complete rewrite. Instead, what it often requires is simple, boring, regular old maintenance. I’d be willing to be that if you are considering a rewrite, it’s probably the wrong idea.

    A lot of the value that an agency like mine brings to a project is that perspective. When a client comes to us with an untenable codebase, we know how to maneuver through them, identify the most critical issues, and triage different parts for a more selective, focused refactoring that emphasizes incremental change. In other words, it’s our job to understand what we’re working with and identify the places where we can have the biggest impact.

    It’s a mark of a seasoned programmer to have the ability to do that and the willpower to resist the temptation of a rewrite.There’s a reason that Joel Splosky named it the single biggest strategic mistake you can make. The value that you add to a codebase is usually going to do little more than match the effort that’s already gone in. There are definitely cases when a rewrite is necessary, but they are very rare.

    And so we need to face the fact that the trajectory of the React project is at odds with what most experienced programmers can agree is a commonly accepted principle. Because React changes a lot. It’s very nature necessitates either pinning yourself to some obscure version, or being in a constant state of either preparing a code rewrite or just having completed one.

    It’s I think the most profound insight in Simon MacDonald’s removing React is just weakness leaving your codebase. React is not static but it doesn’t organically evolve. It unveils entirely new best practices and internal APIs every few years. And every time it does, we are forced to rewrite. And again, rewriting is typically a bad idea.

    By choosing React, we’ve signed up for a lot of unplanned work. Think of the value we could have produced for our users and company if we weren’t subject to the whims of whatever the cool kids were doing over in React.

    Stop signing up for breaking changes!

    Our code is filled with breaking changes. We don’t need our frameworks to add more.

    Bookmarks & Notes

    MacDonald also references the rule of least power, which I had never heard of.

    When designing computer systems, one is often faced with a choice between using a more or less powerful language for publishing information, for expressing constraints, or for solving some problem. This finding explores tradeoffs relating the choice of language to reusability of information. The “Rule of Least Power” suggests choosing the least powerful language suitable for a given purpose.

    W3C

    There is no moral imperative to be miserable, and nihilistic resignation is the most conservative affect of all.

    To be truly radical, James Greig suggests, you can try to take control of your own state of mind.

    Notes

    Maybe I could list out the focuses and the indiivdual tasks for a week and then do timeblocking / task management in the actual days? Something like that.

    Next week focus:

    • I’ve gotta finish taxes, call school
    • Post the changes to the sprint review meeting
    • Prep agenda for retreat
    • Spray for bugs
    • Clean nuggests
    • Put up cabinet
    Check Asana
    Clear out Reeder
    Check Inbox Note
    Read through emails
    Go through “To Sort” In Raindrop
    Review projects in Obsidian
    Add to collections in Obsidian
    Set a weekly focus
    Publish Weeknote

  • Being in Time

    It’s one of those chaotic weeks. Overscheduled. A lot going on. One thing goes wrong and it all goes down like dominoes.

    And yet it’s actually kind of fun. There is a lot of joy in activity and a quickened pace. It makes me wonder that my brain’s default setting always seems to try and seize on balance and routine. It’s easy to think of David Foster Wallace’s “this is water” parable in moments like these. But also, the way Oliver . Burkeman extended that story in Four Thousand Weeks (emphasis mine):

    Soon, your sense of self-worth gets completely bound up with how you’re using time. it stops being merely the water in which you swim and turns into something you feel you need to dominate or control, if you’re to avoid feeling guilty, panicked, or overwhelmed….

    Instead of simply living our lives as they unfold in time—instead of just being time, you might say—it becomes difficult not to value each moment primarily according to its usefulness for some future goal, or for some future oasis of relaxation you hope to reach once your tasks are finally “out of the way.”

    I’ll be thinking about that this week as I try to stay present. As I try to live my life and let it unfold.

    Reading

    A few articles I had some time to read.

    One was the original review of Infinite Jest in The Atlantic which offers a really fascinating perspective on the book that’s much fresher than what we have these days.

    Also, two articles that work well as a pair. Building an innovative agency (and why you might not need one) and what to do with your agency team about this whole AI thing people seem excited about. The key, it would seem, is one of those things that are painfully obvious once you see someone articulate it so clearly, as Nicholas does. You need to set up the preconditions for innovation to emerge so that when an opportunity presents itself, you are ready. Put another way, the worst time to innovate is at the exact time you want to be innovative. You should have already started.

    And I was really saddened by what Allie Nimmons had to say in her revealing and incredibly honest post about why she is leaving the WordPress community behind. It is a huge loss. Lots hit home, but especially this:

    There is a huge disconnect between the people making the “real” money with this software and the people who are trying to earn a fair living.

    Ursula K. Le Guin on what it means to write history:

    History is one way of telling stories, just like myth, fiction, or oral storytelling. But over the last hundred years, history has preempted the other forms of storytelling because of its claim to absolute, objective truth. Trying to be scientists, historians stood outside of history and told the story of how it was. All that has changed radically over the last twenty years. Historians now laugh at the pretense of objective truth. They agree that every age has its own history, and if there is any objective truth, we can’t reach it with words. History is not a science, it’s an art.

    Notes