Sven Slootweg @joepie91@pixie.town

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?"

I've snapped some crappy (because lack of daylight) pictures of the in-progress woodworking project! As well as the little spacer tool I made to ensure the planks are at the correct distance from each other, and will match up at the ends.

I now have four of these 'half tables', that will then be transported outside and combined per two into a whole table, adding the two missing legs. That's why the spacing is important - it needs to match between all of them, or the point where they get joined won't line up!

#woodworking

I've also been working on finishing my plant tables for the garden today, but I don't have any usable pictures yet. Today's work is mostly just fixing the parts I already put together; there wasn't enough room for imprecisions in the wood so I've had to change the design a bit, and move a couple of planks.

Today's workshop improvements! Reused an empty 3D printing filament spool as a spool for the long extension card in the garage, installed some hooks to hang my (non-electric) scooter on (finally, it's no longer in my way!), and finally added some nonslip tape to a working surface so that I can safely put stationary tools on it without them moving around and without having to bolt them down permanently.

I wish for a world in which people recognize that they have a certain amount of responsibility towards others, regardless of circumstances and regardless of whether money is involved

Parkside, Parkside Performance, Parkside Cloud