Link tags: product

Coding Is When We’re Least Productive – Codemanship’s Blog

I’ve seen so many times how 10 lines of code can end up being worth £millions, and 10,000 ends up being worthless.

Backseat Software – Mike Swanson’s Blog

People use “enshittification” to describe platform decay. What I’m describing here is one of the mechanisms that makes that decay feel personal. It’s the constant conversion of your attention into a KPI.

cubic blog: The real problem with AI coding

Can you ship AI-generated code without creating a maintenance nightmare six months from now? Can you debug it when it breaks? Can you modify it when requirements change? Can you onboard new engineers to a codebase they didn’t write and the AI barely explained?

Most teams haven’t realized this shift yet. They’re optimizing for code generation speed while comprehension debt silently accumulates in their repos.

One team I talked to spent 3 days fixing what should have been a 2-hour problem. They had “saved” time by having AI generate the initial implementation. But when it broke, they lost 70 hours trying to understand code they had never built themselves.

That’s comprehension debt compounding. The time you save upfront gets charged back with interest later.

The AI Gold Rush Is Cover for a Class War

Under the guise of technological inevitability, companies are using the AI boom to rewrite the social contract — laying off employees, rehiring them at lower wages, intensifying workloads, and normalizing precarity. In short, these are political choices masquerading as technical necessities, AI is not the cause of the layoffs but their justification.

Where’s the AI design renaissance?

I’ve had some incredibly productive moments with AI design tools. But I’ve had at least as many slogs, where I can’t get it to do some basic thing I should’ve done myself 45 minutes ago.

My hunch: vibe coding is a lot like stock-picking – everyone’s always blabbing about their big wins. Ask what their annual rate of return is above the S&P, and it’s a quieter conversation 🤫

This, in my opinion, is how we end up with a firehose of AI hype, and yet zero signs of a software renaissance. As Mike Judge points out, the following graphs are flat: (a) new app store releases, (b) new domain names registered, (c) new Github repositories.

Why doesn’t anything work anymore? | Jason Rodriguez

I’ve worked in the tech industry for close to two decades at this point. I’ve seen how difficult it is to build quality products, but I’ve also seen that it can be done. It just feels like no one gives a shit anymore, beyond a handful of independent devs and small shops. It’s wild.

Decentralizing quality || Matt Ström-Awn, designer-leader

I’ve personally struggled to implement a decentralized approach to quality in many of my teams. I believe in it from an academic standpoint, but in practice it works against the grain of every traditional management structure. Managers want ‘one neck to wring’ when things go wrong. Decentralized quality makes that impossible. So I’ve compromised, centralized, become the bottleneck I know slows things down. It’s easier to defend in meetings. But when I’ve managed to decentralize quality — most memorably when I was running a small agency and could write the org chart myself — I’ve been able to do some of the best work of my career.

Addicted to Every Possibility by Nathan Beck

Find freedom not in infinite choice, but in working a single seam until you strike gold: conducting dozens, even hundreds, of iterations within a tight parameter space—not in search of more, but in search of better.

The Imperfectionist: Seventy per cent

If you’re roughly 70% happy with a piece of writing you’ve produced, you should publish it.

Works for me!

You’re also expanding your ability to act in the presence of feelings of displeasure, worry and uncertainty, so that you can take more actions, and more ambitious actions, later on.

Crucially, you’ll also be creating a body of evidence to prove to yourself that when you move forward at 70%, the sky stubbornly fails to fall in. People don’t heap scorn on you or punish you.

Durable products | Brad Frost

Wherein Brad says some kind words about The Session. And slippers.

Slippers are cool.

Prescriptive and Descriptive Information Architectures | Jorge Arango

Interesting—this is exactly the same framing I used to talk about design systems a few years ago.

Hixie’s Natural Log: When complaints are a good sign

This is a very smart way to handle feedback about a product.

Trains are offices | hidde.blog

This tracks (ahem) with my experience of coding on trains.

Hidde lists the potentially flaky connectivity as a downside, but for many kinds of deep work I’d say it’s very much a feature, not a bug.

Generative AI Is Not Going To Build Your Engineering Team For You - Stack Overflow

People act like writing code is the hard part of software. It is not. It never has been, it never will be. Writing code is the easiest part of software engineering, and it’s getting easier by the day. The hard parts are what you do with that code—operating it, understanding it, extending it, and governing it over its entire lifecycle.

The present wave of generative AI tools has done a lot to help us generate lots of code, very fast. The easy parts are becoming even easier, at a truly remarkable pace. But it has not done a thing to aid in the work of managing, understanding, or operating that code. If anything, it has only made the hard jobs harder.

AI-free products

Develop a simple, focused app that does what it says on the tin — not one where the tin talks back at you.

Prototypes, production & fidelity layers | Trys Mudford

I’ve always maintained that prototyping and production require different mindsets. Trys suggests it’s not as simple as that.

I agree with much of what he says about back-end decisions (make it manual ‘till it hurts—avoid premature optimisation), but as soon as you’re delivering HTML, CSS, and JavaScript to real people, I think you need to meet certain standards when it comes to accessibility, performance, etc.

Pluralistic: The (open) web is good, actually (13 Nov 2023) – Pluralistic: Daily links from Cory Doctorow

The web wasn’t inevitable – indeed, it was wildly improbable. Tim Berners Lee’s decision to make a new platform that was patent-free, open and transparent was a complete opposite approach to the strategy of the media companies of the day. They were building walled gardens and silos – the dialup equivalent to apps – organized as “branded communities.” The way I experienced it, the web succeeded because it was so antithetical to the dominant vision for the future of the internet that the big companies couldn’t even be bothered to try to kill it until it was too late.

Companies have been trying to correct that mistake ever since.

A great round-up from Cory, featuring heavy dollops of Anil and Aaron.

No Taste | Scratching the Surface

Designers can’t help but participate in these displays and debates of taste. It’s part of the job. There’s an irony in the predominantly liberal and inclusive political leanings of most creatives that often become unbending and exclusionary in their work and everyday lives. Comic Sans, Thomas Kinkade, New Urbanism, clutter—there are too many heretical acts to count. Natalia Ilyin writes in Chasing the Perfect, “For people who want their straight lines to be straight, life itself is the problem. The modern urge is the urge to get away from organic existence in general.” No wonder most movie villains live in spartan homes of concrete, glass, and steel. The often humor-free designer is not so different, if not in evildoing, then at least in temperament.

How do build tools break backwards compatibility? | Go Make Things

If you have a project that uses just plain HTML, CSS, and JavaScript, you can just open up the files and start working on them at any time. A project from 20 years ago will still work just fine, and can be easily modified.

Projects that use build tools? Well… to work with them, you need your build tools to actually build. And that’s not always guaranteed.

Also, it me:

One of my least favorite things as a developer is wanting to do a quick patch fix on an older project—I’m talking a simple one-line of CSS kind of fix—but first having to spend 30 minutes patching my build tools to get them running again.

Ship Faster by Building Design Systems Slower | Big Medium

Josh mashes up design systems and pace layers, like Mark did a few years back. With this mindset, if your product interface are in sync, that’s not good—either your product is moving too slow or your design system is moving too fast.

The job of the design system team is not to innovate, but to curate. The system should provide answers only for settled solutions: the components and patterns that don’t require innovation because they’ve been solved and now standardized. Answers go into the design system when the questions are no longer interesting—proven out in product. The most exciting design systems are boring.