Jay Hoffmann

Tag: React

  • #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

  • #16: The build vs buy dilemma for personal decisions

    AKA The Tinkerer’s Dilemma

    As is probably true for people like me who work in code, and futz around in different note taking apps and personal blogs, I am what you might call something of a tinkerer. And so I often am faced with something like the build vs buy dilemma. But this internal tug-of-war does not revolve around organizational purchasing decisions. It’s more a battle of personal choices, of opting for one methodology over the other.

    By “build” I don’t mean crafting a full-blown application from the ground up. I’m talking about putting together a collection of some light coding and no code solutions. This gives me something more closely aligned with my own personal workflow at the expense of all of that technical, maintained overheead.

    On the other hand, “buy” doesn’t necessarily imply shelling out money for acquiring an off-the-shelf application (a lot of these apps are free). It’s more like buying in, embracing an existing approach and methodology. It’s about capitulating to a particular way of doing things, and trying to bend it to your will.

    My notetaking and general organization tasks have been served by Obsidian for the past few years. Its unique blend of features suits my needs perfectly, and I’ve managed to create a system that is good enough, and that I don’t mess with all that much.

    The other day, though, I got to thinking about something different. I had an urge to develop something similar to a second-brain app – akin to Obsidian or Roam, using my personal WordPress site. I immediately started mapping out all of the different blocks and plugins and little features that I would want to see in something like this.

    And then a night passed. And I thought about it. I began going over the realities of this new project. That initial flash to my brain was energizing, but time makes fools of us all. There were enough details to consider and challenges to overcome and time investments to spend to make the whole thing immensely daunting. Regardless, the very notion of this venture sparked a sense of intrigue and excitement that is, to my tinkerer’s mind, worth exploring. At the intersection of creativity and practicality, I found a new project that’s brimming with possibilities and potential learning experiences. Maybe one day I’ll give it a shot.

    Cassidy is kind of annoyed at React. She’s not the only one.

    Reading through one of Cory Doctrow’s recent posts about the open web, I like that he paused on a point that I find particularly important about the web.

    The web wasn’t inevitable – indeed, it was wildly improbable. Tim Berners Lee’s decision to make a new platform that was patent-free, open and transparent was a completely opposite approach to the strategy of the media companies of the day. They were building walled gardens and silos – the dialup equivalent to apps – organized as “branded communities.” The way I experienced it, the web succeeded because it was so antithetical to the dominant vision for the future of the internet that the big companies couldn’t even be bothered to try to kill it until it was too late.

    The web wasn’t inevitable. It was a gift at the intersection of a perfect circumstance. That’s why so many people have attempted to control it and centralize it and turn it into something that it’s not. Next time somebody tries to tell you that such and such platform embraces free speech, just remember that the web is open. It’s free by default.

    Notes

    Check Asana
    Clear out Reeder
    Check Inbox Note
    Read through emails
    Go through “To Sort” In Raindrop
    Set a weekly focus
    Publish Weeknote