Readcently: Semmel Roll

journal

Hot on the heels of yesterday’s inaugural journal, I’ve decided to revisit the handful of bookmarks I currently consider seminal: Pieces I often refer to in discussions, sometimes with myself.

Decision time

Good design requires thoughtfulness on many dimensions.

often a decision that delivers short-term gain may well end up delivering long-term pain

Resilient Web Design

Every web practitioner – whether developer, designer or otherwise – should read this concise book explaining the web’s fundamental principles, both philosophically and practically.

The lecture ( 📼 55 min.) on the same topic is also worth watching, particularly the process for identifying Just what is it that you want to do? (from 30 min.).

It seems obligatory to also point to the principle of least power in this context.

The Market For Lemons

A thorough analysis of “the front end’s lost decade”, explaining how a pervasive lack of engineering discipline made the web worse for both users and organizations.

There’s also an accompanying presentation ( 📼 25 min.).

From elsewhere:

In his seminal piece “The Market For Lemons”, renowned web crank Alex Russell lays out the myriad failings of our industry, focusing on the disastrous consequences for end users. This indignation is entirely appropriate according to the bylaws of our medium.

I’m afraid we can’t mention those bylaws without quoting adactio yet again:

given the choice between making something my problem, and making something the user’s problem, I’ll choose to make it my problem every time

Design Pressure

Design Pressure is the guidance or “pressure” that test-driven development places on your software design.

Design Pressure is the little voice in the back of your head made manifest by a crappy test with too much setup. It’s a force that says when your tests become hard to write, you need to refactor your code.

This is the reason I almost always end up regretting foregoing TDD, which still happens occasionally (though hopefully less so now).

It’s closely related to deletability in my head:

To optimize for deletability, we need to make sure we have a clean dependency graph. To build a clean dependency graph, we need modular code. Given that modular code is seen as a Good Thing™ in its own right, optimizing for deletability is used as a technique to achieve modular and more easily understood code.

… which in turn is effectively the same as replaceability.