I love this warm color scheme from Steph Ango (kepano, CEO of Obsidian) based on printing inks and warm paper. It's my new default theme in Sublime Text—which is still my preferred editor when I'm not slogging through large PHP codebases.

I love this description of the Go programming language from Rob Napier:

Go feels under-engineered because it only solves real problems. If you've ever worked in a wood shop, you've probably made a jig at some point. They're little pieces of wood that help you hold plywood while you cut it, or spacers that tell you where to put the guide bar for a specific tool, or hold-downs that keep a board in place while you're working on it. They're not always pretty. They often solve hyper-specific problems and work only with your specific tools. And when you look at ones that have been used a lot, they sometimes seem a little weird. There might be a random cutout in the middle. Or some little piece that sticks off at an angle. Or the corner might be missing a piece. And when you compare them to “real” tools, “general” tools like you'd buy from a catalog, they're pretty homey or homely depending on how you're thinking about it.

But when you use one of them in your shop, you learn that the random cutout is because you store it against the wall and it would block the light switch otherwise. And if you put your hand on that little extra piece that sticks out, then the board won't fall at the end of the cut. And the corner… well the corner is where you messed up when you were first making it and it's kind of ugly, but it never actually matters when you use it. And that's Go.

A little Sketchplanation on "point positive".

Point positive is a rafting term for agreeing in advance to point towards the safe way out of danger rather than towards the dangers themselves.

When you're in trouble, don't dwell on the cause, look for a solution. Only when the waters are calm, take a step back, reassess, and learn the necessary lessons to avoid it in the future.

I lovely read on craft by Cat Hicks.

Grandpa loved craft. […] He fixed things often and silently. Grandpa just cared about things working. He had an instinct for not just broken things but soon to be broken things. He would point out risky work, bad decision making in the form of shoddy materials or shifting angles.

As software developers, we often consider our trade to be unique. But what we (should) have in common with others is the mindset of respecting our craft—of producing solid and lasting work.

I have read a lot of long spiels about craft that frequently end in something like, software work isn’t like other work, and we shouldn’t be judged the same way. We are entirely unique. We are the special ones. I find this both saddening and unconvincing. I think that all labor is skilled labor. I think about the factories and the fields and the ways that demands for speed instead of cadence can hurt people. I think we should seek to understand and value our skills and see effort. But I don’t think we are going to fix anything about how software work is valued by refusing to let it belong to the rest of the world.

A green test suite is a blank canvas, and a blank canvas is a paralyzing place to start.

A failing test is a pointer to the next step. When I end the day with a failing test, I know exactly where to begin when I get back. The perfect kickstart to get into flow.

If you want to become a better programmer, my number one advice is to learn another programming language. The further away from your comfort zone the better.

Read more

Standards are useful, but after a while they represent the beliefs of the past, not the needs of the future.

A good quote from Mathias Verraes on standards.

If you're going to read one thing today, make it this. So much good stuff in here I could quote just any paragraph.

complexity is spirit demon that enter codebase through well-meaning but ultimately very clubbable non grug-brain developers and project managers who not fear complexity spirit demon or even know about sometime […]

grug no able see complexity demon, but grug sense presence in code base

Timeless advice from Freek & Brent.

Just like reading text, grouping code in paragraphs can be helpful to improve its readability. We like to say we add some "breathing space" to our code.

$page = $this->pages()->where('slug', $url)->first();
if (! $page) {
    throw new Exception();
}

$page = $this->pages()->where('slug', $url)->first();
 
if (! $page) {
    throw new Exception();
}

Just one line of space can make the difference.

Crypto, AI, JavaScript frameworks,… are interesting tech, but that doesn't mean they need to be shoehorned into every product.

Set a direction, and choose the tools you'll need to get there. Don't choose a direction based on the tools in your disposal.

… by chasing trends we would never be the ones to set them.

This one's permanently stored in my Pinboard — a conversation I had this morning triggered a re-read.

"A user is only part of one team". Until we decide to add multi-team support, and the $user->team BelongsTo relation suddenly needs to be replaced in 50 places.

Golden advice from swyx:

It is a LOT easier to scale code from a cardinality of 2 to 3 than it is to refactor from a cardinality of 1 to 2.

A few weeks ago a spec change for an application we're working on forced us to refactor part of the codebase. It was food for thought about the flexibility granular interfaces provide, and choosing the right abstraction at the right time. This is a short writeup on the thought process we went through as we updated our logic to support a new feature now and allow more options in the future.

Read more

Henrik Nyh suggests to make comments more resilient to change with double-entry bookkeeping.

- $timeoutMs = 1000; // Equals 1 second
+ $timeoutMs = 1000; // 1000ms equals 1 second

Whether the discrepancy is caught immediately by the author, or in review, or by another developer far down the line, it will be explicitly clear that the comment was not intended for the current value.

This lowers the odds that a comment will get out of sync, especially useful in configuration files.

For more context head to Henrik's blog, The Pug Automatic.

RoyalSloth reviews the three most common patterns to model interconnected state in a user interface.

• Connect the boxes: create the user avatar component and pass its instance to the inventory table component
• Lift the state up: move the internal state of the user avatar component and the state of the inventory table into a separate box/class
• Introduce a message bus: connect the inventory table and the user avatar component to the shared pipe that is used for distributing events in the application

Connect the boxes and lift the state up seem to be the most common choices for React apps; respectively prop drilling and context or single state trees (like Redux).

There's no silver bullet to UI complexity, all methods have their caveats.

Read the full article on blog.royalsloth.eu.

There are two bike stalls near my apartment. One is right in front of the door, the other around the corner. The one in front of the door is closest, so when I can, I store my bike there. However, most of the time that stall is full, and I need to go around the corner instead.

That's fine. Until a next morning–when I'm still in a daze because I'm not a morning person–I take the walk around the corner, only to realise my bike was actually in front of the door. The day before was one of those lucky days I could store my bike in front of the door.

I quit using the front stall. The less choices I have to make, the more room I have for important things.

Read more