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

As developers, we often talk about the importance of learning. Learning is so important to us, that it's worth persuing ways to improve the way we learn.

One way to become a better learner is to master the reverse: unlearning. Not the ability to completely forget, but the ability to set something aside for a brief moment.

When we learn a new language, framework, or tool, it's hard not to dismiss new ideas based on our existing opinions. It's the mental baggage we carry along all day.

What we've established as antipatterns in tool X's, might be shiny tool Y's bread & butter. That doesn't mean we should dismiss tool Y. Ideas on their own are rarely good or bad, they need to be evaluated in a certain context.

Read more

My colleague Brent wrote a food-for-thought post about two different kinds of programmers: builders & architects.

The first ones, the builders, are the programmers who get things done. […] On the other hand there are architects. They are concerned about sturdy and structurally sound code. […]

These two types of programmers seem like opposites. They themselves look at the other group and often think exactly that. They have a different way of handling the same problems. The other group's solutions are so different, they can't possibly be right, or so it seems.

Builders often find architects too rigid and conservative. They follow the rules for the sake of following them, without any practical benefit. Architects in turn, think of builders as careless, too focused on results, instead of thinking about long-term maintainability.

Different programmers aside, "build vs. architect" is the eternal internal conflict when I want to make decisions. Striking a balance between "getting things done" and "getting things right" is tough.

Read the entire, beautifully illustrated post on stitcher.io.