fiat_lux

GNU+Linux user just wonders whether medical technology is bad for humanity’s long term survival because hereditary diseases can be survived and spread, but wouldn’t want anyone to misunderstand.

It’s nice to know we have looped back to the point in history where we casually consider which people should have agency over their reproductive rights. Oh wait, no it’s not nice at all, but somehow still totally acceptable and commonplace.

People have already mentioned testing and abstraction, but what about other developers and security?

Spaghetti code all you like in solo projects. But if someone else is coming along to debug a problem in their toppings, why would you make them remember anything about baking or the box when it’s completely irrelevant?

And why should the Box object be able to access anything about the Oven’s functionality or properties? Enjoy your oven fire and spam orders when someone works out they can trigger the bake function or access an Order’s payment details from a security hole in the Box object implementation.

It’s not just about readability as a narrative, even if that feels intuitive. It’s also about memory management, collaboration and security.

• When writing new code: make a good faith attempt to DRY (obviously not fucking with Liskov in the process). First draft is very WET - deleting things is easiet at this stage anyway and accidentally prematurely DRYing causes headaches. Repeat the mantra “don’t let perfect be the enemy of good” to prevent impulsive DRYing.
• When maintaining existing code I wrote: Refactor to DRY things up where it’s clear I’ve made a conceptual misjudgement or oversight. Priority goes to whatever irritates me most in the moment rather than what would be most efficient.
• When altering other people’s code: Assume they had a reason to WET (if you’re lucky, read the docs that discuss the decision) but be a little suspicious and consider DRYing things up if it seems like a misjudgement or oversight. Likely realise 50% of the way through that this is going to take much longer and be way more painful than you hoped because of some esoteric bullshit compatibility issue. Curse yourself for not letting sleeping dogs lie but still start engaging in sunk cost fallacy.
• When reviewing PRs: Attempt to politely influence the writer to DRY it up but don’t take too much offence to WET if it has a decentish reason in context. Throw in an inline one-liner to not make other maintainers question their sanity or competence when they realise they’re reading duplicate code. Also to more reliably establish git blame rather than blaming the next poor fool who comes along and make a minor reformatting revision across the file. Include a date so that someone can stumble across it in 10 years as an archaeological curiosity and their own personal esoteric bullshit compatibility issue.
• Long term maintenance: Live with your irritatingly damp mouldy code. There’s new code that needs to be written!

How will we be making WASM-based UI accessible for people using screen readers, screen zoom applications, text to speech and voice input users, etc.?

The Web is hostile enough to people with disabilities, despite its intent, and developers are already unfamiliar with how to make proper semantic and accessible websites which use JS. Throwing the baby out with the bathwater by replacing everything with WASM in its current form seems about as good an idea as Google’s Web Environment Integrity proposal.

What do you call the feeling when you’re nostalgic but it’s also slightly painful?