Links

Let me make it clear: without people at the top of their game sharing their experience and knowledge — regardless of whatever “game changing” technology is in place — we are pulling up the ladders and committing our industry to stagnation and death. We’ve already fucked it up over the last few years for junior developers by instead of investing in them, playing the slot machines (also known as LLMs) to — you guessed it — make the money number go up, but there’s still hope for recovery.

Excellent article by Brecht De Ruyte on Modern Web Guidance: specifically what it is, how it works and how he pairs it with his own skills.

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%.

Here’s the one-liner Chris Coyier uses:

<link
	rel="icon"
	href="data:image/svg+xml,<svg xmlns=%22http://www.w3.org/2000/svg%22 viewBox=%220 0 100 100%22><text y=%22.9em%22 font-size=%2290%22>🎯</text></svg>"
/>

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.

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.

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.

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.

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.

Tom Bedor, on forwarding AI output to a colleague:

If you are requesting human attention, demonstrate human effort.

This reminded me of a line from Don’t ask to ask, if you’re not willing to do the work to solve your problem, why should we?

Turns out, if you have a website and you think of the browser as a way to navigate documents — rather than a runtime to execute arbitrary code and fetch, compile, and present them — things can be a lot simpler than our tools often prime us to make them.

You can’t write a compelling narrative about the thing you didn’t build. Nobody gets promoted for the complexity they avoided.

Complexity looks smart. Not because it is, but because our systems are set up to reward it.

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.

A developer who builds accessible interfaces is more skilled. Say this out loud. Repeat it often. A developer who creates accessible interfaces isn’t doing extra work; they’re doing the work the right way.

No matter how rapidly technology changes, I am coalescing around some core beliefs:

1. Things that are worth doing are worth doing well.
2. Things that are done well require time and effort.
3. You make meaning through the doing.
4. Ideas are common; effort is not.
5. There are no shortcuts.

Harry Roberts on what CSS containment actually is, what each contain value does, and how to use it confidently on real projects without creating hard-to-debug side effects.

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.

Libraries are bits of other people’s code that I call from my code. Frameworks are other people’s code that call bits of my code.

Writing code has never been the sole activity of a software engineer. The craft has always been figuring out what code to write. Any given software problem has dozens of potential solutions, each with their own tradeoffs. Our job is to navigate those options and find the ones that are the best fit for our unique set of circumstances and requirements.

When you offload your thinking, you might be on-loading someone else’s you’d never agree to — personally or collectively.