Links

  • Make It Work vs. Make It Good - Jim Nielsen’s Blog

    I love how Jim Nielsen articulates the difference between making it work and making it good. “Does it work?” is exactly the kind of signal an LLM can be trained against: the tests pass or they don’t. There’s no equivalent for “Is it good?”, is there?

    “Make it work” is the first 90% of the work. “Make it good” is the other 90%.

  • Accidental anonymity - macwright.com

    Tom MacWright on putting yourself out there and the fear of being found out for being imperfect:

    putting your art, writing, expression out to be judged by others is an act of bravery as much as talent, and a lot of people lack bravery. Sorry to say it but if you need your work to be polished and beyond reproach, that’s a determination and character problem, not a skill problem.

  • Don't be a meat proxy

    Niklas Gruhn, on relaying AI output verbatim:

    By all means, prompt AI. But don’t just relay the output. Read it, understand it, validate it, and then write a response in your own words (a decent certificate that you’ve done the prior steps). Making that effort is value you can add.

    This reminds me of Simon Willison’s rule, I will not publish anything that takes someone else longer to read than it took me to write.

    Among friends I’ll sometimes skip the rewrite and share a link with the prompt in it instead. As Dave Rupert mentioned, he wants the prompt because it shows the context you gave the machine and your understanding of the problem: I’d rather have the original prompt so I can just ask the machine myself. It’s the least bad way to relay, not an alternative to doing the work.

  • Should You Use AI for a Task? Here’s a Simple Way to Decide - Schneier on Security

    At work, if your job is to move a bunch of heavy things from one side of the room to another, you should use whatever assistive tech you have on hand: a wagon, a forklift… even an AI-powered robot. But at the gym, it makes no sense for that robot to lift weights for you. The point of weightlifting isn’t to move heavy things across the room; it’s to actually lift those heavy things.

    The same analysis holds for any task an AI can do for you. If it’s work—if the task has to be done and no one cares how—then it’s fine to use AI assistance. But if the task is more like the gym, and howthe task is done is at least as important, then it probably doesn’t make sense to use AI.

  • </> htmx ~ Vendoring

    Today I learned, that copying and pasting other people’s code in your project is called vendoring. Carson Gross goes on to explain how vendoring can get pretty difficult to deal with and how that is actually its strength:

    Because dealing with large numbers of dependencies is difficult, vendoring encourages a culture of independence.

    You get more of what you make easy, and if you make dependencies easy, you get more of them.

  • Our CSS isn't opinionated enough - craigabbott.co.uk

    I think the way we currently write CSS subtly shapes the way we think about components. By having the visual styles completely decoupled from the semantic meaning, accessibility is easy to forget, because we can’t physically see missing attributes. When the styling hook is anchored to semantics, you can’t get the visual styles without also getting the parts that make it accessible.

  • James Shore: You Need AI That Reduces Maintenance Costs

    Your AI coding agent, the one you use to write code, needs to reduce your maintenance costs. Not by a little bit, either. You write code twice as quick now? Better hope you’ve halved your maintenance costs. Three times as productive? One third the maintenance costs. Otherwise, you’re screwed. You’re trading a temporary speed boost for permanent indenture.

    […] The math only works if the LLM decreases your maintenance costs, and by exactly the inverse of the rate it adds code. If you double your output and your cost of maintaining that output, two times two means you’ve quadrupled your maintenance costs. If you double your output and hold your maintenance costs steady, two times one means you’ve still doubled your maintenance costs.

  • Writing code is cheap now - Agentic Engineering Patterns - Simon Willison's Weblog

    Simon Willison on what they mean by “good code”:

    • The code works. It does what it’s meant to do, without bugs.
    • We know the code works. We’ve taken steps to confirm to ourselves and to others that the code is fit for purpose.
    • It solves the right problem.
    • It handles error cases gracefully and predictably: it doesn’t just consider the happy path. Errors should provide enough information to help future maintainers understand what went wrong.
    • It’s simple and minimal - it does only what’s needed, in a way that both humans and machines can understand now and maintain in the future.
    • It’s protected by tests. The tests show that it works now and act as a regression suite to avoid it quietly breaking in the future.
    • It’s documented at an appropriate level, and that documentation reflects the current state of the system - if the code changes an existing behavior the existing documentation needs to be updated to match.
    • The design affords future changes. It’s important to maintain YAGNI - code with added complexity to anticipate future changes that may never come is often bad code - but it’s also important not to write code that makes future changes much harder than they should be.
    • All of the other relevant “ilities” - accessibility, testability, reliability, security, maintainability, observability, scalability, usability - the non-functional quality measures that are appropriate for the particular class of software being developed.