If I were to share some thoughts on making a meaningful impact at work, Ben Kuhn’s post would be it. His essay had me nodding yes, yes!, and YES! throughout, and it’s written more eloquently than I ever could.

Don’t rely too much on permission or encouragement. […] instead of asking people for approval to go do something, you can just tell them what you intend to do (implicitly giving them space to object or course-correct if they feel strongly).

You can just do things.

Make success inevitable. There’s a huge difference between the following two operating modes:

1. My goal is to ship this project by the end of the month, so I’m going to get people started working on it ASAP.
2. My goal is to ship this project by the end of the month, so I’m going to list out everything that needs to get done by then, draw up a schedule working backwards from the ship date, make sure the critical path is short enough, make sure we have enough staffing to do anything, figure out what we’ll cut if the schedule slips, be honest about how much slop we need, track progress against the schedule and surface any slippage as soon as I see it, pull in people from elsewhere if I need them…

The hard part is being honest with yourself. I’ve often fallen into trap (1) because I’m afraid my plan will surface failure.

On taste:

I’ve noticed a lot of people underestimate their own taste, because they expect having good taste to feel like being very smart or competent or good at things. […] For this reason, the prompt I suggest here is: what does it seem like everyone else is mysteriously bad at?

Taste isn’t about being the best at something. It’s about slowly lifting the whole by leaving small things in better shape than you found them.

Henrik Warne on the --dry-run flag:

Early in the development process, when testing the incomplete application, I remembered that Subversion (the version control system after CVS, before Git) had a –dry-run option. Other linux commands have this option too. If a command is run with the argument –dry-run, the output will print what will happen when the command is run, but no changes will be made. This lets the user see what will happen if the command is run without the –dry-run argument.

I’ve added a --dry-run flag on scary destructive stuff I’m planning to run on prod. But not as often as I’ve wanted.

The downside is that the dryRun-flag pollutes the code a bit. In all the major phases, I need to check if the flag is set, and only print the action that will be taken, but not actually doing it.

This is one of the things that has become less of a downside with AI writing more code for us. AI helps us write code faster, but what especially entices me is having more breathing room to add affordances like this.

RollerCoaster Tycoon, a classic game from 1999 is still worth dissecting for its performance to this day. First a quick primer on bit shifting (new to me—I’m used to high level languages!):

What the << operator does here [NewValue = OldValue << 2] is called bit shifting, meaning all the bits that store the value of the variable are shifted to the left, in this case by two positions, with the new digits being filled in with zeros. Since the number is stored in a binary system, every shift to the left means the number is doubled.

Since this is a lot faster than multiplication, Chris Sawyer decided to exploit this as much as possible:

The even more interesting point about those calculations, however, is how often the code is able to do this. Obviously, bit shifting can only be done for multiplications and divisions involving a power of two, like 2, 4, 8, 16, etc. The fact that it is done that often indicates that the in-game formulas were specifically designed to stick to those numbers wherever possible, which in most modern development workflows is basically an impossibility.

I do want to disagree with that last bit. Impossibility sounds too harsh. We can’t decide the requirements for stakeholders, but plenty of things aren’t as set in stone as they seem. It’s our job to nudge things in the right direction, so the result works with the grain of our programs.

I love digital tools that have some analog look or feel to them. (Speaking as an Excalidraw super user.) Going to have to find an excuse to use this beauty!

How to multiply your shipping cadence while using agents responsibly. Matthew Binshtok on the Vercel blog:

There is a fundamental difference between relying on AI and leveraging it.

• Relying means assuming that if the agent wrote it and the tests pass, it’s ready to ship. The author never builds a mental model of the change. The result is massive PRs full of hidden assumptions that are impossible to review because neither the author nor the reviewer has a clear picture of what the code actually does.
• Leveraging means using agents to iterate quickly while maintaining complete ownership of the output. You know exactly how the code behaves under load. You understand the associated risks. You’re comfortable owning them.

I’ve seen a lot of strong opinions about disclosing whether code in a PR was written by hand or generated by AI. I don’t really care. The author owns the code in the first place. The author and reviewer have a shared responsibility for what happens on production.

Putting your name on a pull request means “I have read this and I understand what it does.” If you have to re-read your own PR to explain how it might impact production, the engineering process has failed.

The litmus test is simple: would you be comfortable owning a production incident tied to this pull request?

Musings from Robin Sloan:

Most olive oil production at medium-or-greater scale depends on machines of this kind [over-the-row olive harvester]; they trundle over trees planted in long rows, almost like continuous hedges, and collect the fruit with vibrating fingers. Machine-harvested olives cost less to buy, and they arrive at the mill in better shape than olives harvested by hand.

The catch: most olives can’t be cultivated in this configuration; the trees don’t thrive so close together. Only a handful of varieties will tolerate it, so those handful have been planted in huge numbers, and the flavor of global olive oil has changed as a result.

AI enables us to do things faster, and sometimes better than we’ve been able to before. But it has its limits. And as we learn those limits, the work we do will shift to avoid them.

In a different section, the article dives into the limitations of the physical world.

The project cut across several different magic circles — Ruby code, quasi-governmental APIs, the rules and standards of the postal system — but/and it also broke out into the physical world of paper, printers, and post offices. The project required manipulations including but not limited to: folding, peeling, sticking … gnarly!!

It’s possible that an AI coding agent could have helped me with #1 above, and of course it could have advised me on the rest. But it’s impossible to imagine the AI agent handling #2-5 autonomously; it would require such a Rube Goldberg tangle of support that “autonomously” would no longer apply.

In our programming world, AI’s impact looks limitless. But once you drift outside the boundaries of software, it’s put into a different perspective.

If indeed AI automation does not flood fill the physical world, it will be because the humble paper jam stood in its way.

In a project management-themed Hackers Incorporated episode, Adam Wathan introduced derisking projects with save points. The entire episode is definitely worth your time, but that specific piece of advice has changed the way I work as a developer and make decisions as a project manager.

In practice, it has taught me to optimize for optionality, not efficiency.

Read more

For the past year, Obsidian has been my note-taking companion. I don’t care about fancy features like backlinks, canvas… I like Obsidian because it’s fast, minimal (up to you!), customizable, works with Markdown files, and has a good enough mobile app.

I’ve slowly grown towards a more consistent way of taking and organizing notes. While I’m using Obsidian, it’s a system that can easily be ported to any other tool as long as you have something that resembles a filesystem.

Read more

Next week we’re sending out the first issue of a new newsletter: href.email.

Content on the internet is at a tipping point. Social media actively discourages sharing links, while AI-generated content is gaining prominence. We want to double down on human-created and curated content. Authors and creators put a lot of effort into their work, which we want to bring to the surface with our own touch.

I’m looking forward to help curate write these the coming months! (And I’m stoked about the domain name, how was that not taken?) Expect a healthy mix of dev/design/product content. Head over to href.email if you want to subscribe.

I thought this image from Christoph Niemann in Sunday Sketching was worth sharing.

We can force ourselves to do good work. But for great work, we need a portion of luck.

PS: I highly recommend Christoph’s Abstract episode which you can watch for free on YouTube.

I’ve been writing more Blade + Tailwind the past few weeks. Coming from React + Tailwind I really missed tailwind-merge and clsx, but luckily came across this great package from Sandro Gehri.

{{-- components/button.blade.php --}}
<button
    {{ $attributes
        ->merge(['type' => 'submit'])
        ->twMerge('bg-green-500') }}
>
    {{ $slot }}
</button>

{{-- home/index.blade.php --}}
<x-button class="bg-red-500">
    A red button
</x-button>

Source code and installation instructions on GitHub.

From Escape the Algorithm. When we create a contract or a pattern, there are gains in familiarity, modularity, and composability, but it’s a lossy translation.

If I were to design a personal map of my neighborhood, it would include the potholes I swerve by on my bike rides, the neighbor’s sweet precocious 4 year old that is always on the front stoop and wants to tell me about her day, routes that have small patches of grass to the right of the sidewalk and end near a public trash can (suitable for walking my right-side-only peeing dog), the schedule and trajectory of shade during the summer, homes with potted flowers hanging off their railings, restaurants that closed ages ago, the playgrounds where we are most likely to run into parent friend crushes, and the street with the best view of the skyline at night.

It probably would not look like Google Maps.

Read more

In a New Yorker article titled The Art of Decision-Making, Joshua Rothman explores the paradox of how we can spend a lot of energy fretting over small decisions, while the big life decisions seem to come naturally.

We agonize over what to stream on Netflix, then let TV shows persuade us to move to New York

An interesting point he makes is how our aspirations can take a long time to come to fruition. How can we guide our actions if we don’t even know if we’ll still want the results by the time we get there?

To aspire […] is to judge one’s present-day self by the standards of a future self who doesn’t yet exist. But that can leave us like a spider plant putting down roots in the air, hoping for soil that may never arrive.

As the life we crave can change dramatically.

Before having children, you may enjoy clubbing, skydiving, and LSD; you might find fulfillment in careerism, travel, cooking, or CrossFit; you may simply relish your freedom to do what you want. Having children will deprive you of these joys. And yet, as a parent, you may not miss them. You may actually prefer changing diapers, wrangling onesies, and watching “Frozen.” These activities may sound like torture to the childless version of yourself, but the parental version may find them illuminated by love, and so redeemed. You may end up becoming a different person—a parent. The problem is that you can’t really know, in advance, what “being a parent” is like.

Last week, we released Laravel Error Share, a package to share local Laravel exceptions with a coworker or your debugging friend on the internet. We wrote all about the functionality of the package on the Flare blog. In this post, I’d like to look into some of the implementation details and considerations we made while building it.

Read more