Sven Slootweg @joepie91@pixie.town

You owe nothing to governments or companies, only towards your community

Like, I was getting kind of tired of most of the music mixes containing the same 100 tracks in a genre, but "every mix is 'new' AI slop that is different yet somehow the same as everything else" is actually *worse*

Add "music on Youtube" to the list of "shit ruined by AI", I guess

Basically I'm trying to fit everything efficiently in what one might call a one-car garage if one were generous. Efficiently enough that there's actually enough space to work on projects. While also storing gardening tools and a bunch of miscellaneous stuff in there.

Today's progress in Project Workshop Density: installed some overhead storage hooks for long things, so that they finally aren't in my way anymore; and installed an auto-retracting hose spool for my compressed air onto the ceiling.

Also worked on the plant tables a bit; cut and added all the ledges that the 'floor' planks will rest on. Assuming it's sufficiently dry tomorrow, I might assemble and install them outside tomorrow! Can't do that in the garage, because once fully assembled they won't fit through a doorway anymore.

#woodworking #workshop

There's a lot of lessons that can be learned from it, but I think that this one is perhaps the most important and also the most overlooked: to address a problem, you don't actually need to be able to solve it yet.

When talking about problems with accessibility, security, user safety, and so on, programmers have a tendency to dismiss these problems because they can't see an immediate solution, or for some reason they're unable or too difficult to implement it right now. So it's marked as 'not planned', and everybody moves on.

But let's consider the way traffic engineering has changed over the past decades in the Netherlands. It was originally just as much of an unsafe, car-infested sewer as many other cities; if you look at pictures from the 1960s or 1970s, it looks almost indistinguishable from anywhere else.

But then at some point, someone decided "we *want* to solve these problems". They couldn't actually fix anything yet; transportation infrastructure is expensive and hard to change or replace. But it didn't matter; they decided that solving these problems was now a *priority*. This is where the idea of Sustainable Safety started, which you may have heard mentioned before.

That decision changed the framing. Now, instead of automatically doing the same thing as before, every new decision and design was evaluated against the new design objectives, and improvements were made opportunistically where it was possible. If a road had to be renovated anyway, hey, why not replace it with something better?

There was never some grand cohesive plan of the exact changes to be made in every place, there was never some big total redesign of the road network. There wasn't even a concrete idea of when the process would be 'complete'; there was only a decision to prioritize safety going forward, and a decade-long process of asking "how can we get a little bit closer to that goal?" every time a design choice needed to be made.

And this is exactly what you can - and should! - do in software development, when dealing with the difficult, seemingly intractable problems, especially those that management will not set aside time or resources for.

All you need to do is accept the problem as one that needs solving, and ask yourself throughout the design process, whenever you make a design choice: "how can we get a little closer to this goal, is there low-hanging fruit here?"