Marcus Buffet: Managing my motivation

Full title is Managing My Motivation, as a Solo Dev, but this is great advice for any dev.

My favorite:

Leave tasks unfinished
I can’t overstate how much this one helps me. I try to leave a task 90% finished at the end of a working session. It feels slightly worse than closing out the work, but it makes starting the next day 10x easier. Having a quick win when I start coding is a massive boost, and it immediately gets me into the flow state. It can’t be too easy though, if all I have left is to run git commit, that’s not enough. Ideally it’s something where I know exactly what I need to do, that will take 5-10 minutes.

As I've written before: end the day with a failing test.

Go Is a Shop-built Jig

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.

Cat Hicks on Craft

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.

The grug brained developer

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

Clean code has room to breath

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.

Robin Rendle: 'Tech Last'

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.

Preemptive pluralization

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.

Granular interfaces

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

Self-deprecating comments

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.

The complexity that lives in the GUI

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.