Chad Fowler:

Why are humans allowed to edit the output at all? If you care about provenance—about being able to trace every line of code back to a decision—then manual edits are a problem. They break the chain. They introduce code that has no record, no explanation, no origin you can inspect. So you end up in an uncomfortable place: You don’t just prefer that agents write the code. You require it. Not because agents are better programmers. But because they are the only way to guarantee that every change passes through a process that can be captured, inspected, and replayed. Humans don’t stop participating. They just move up a level. They define intent. They shape constraints. They review outcomes. But they don’t write the code directly anymore. Because the moment they do, the system forgets how it got there.

↬ ∙ Tagged in AI, Software Engineering.

Kore Nordmann:

This shape matters because the single biggest cost of the SPA model is that it duplicates the server. State lives twice, once in the database and once in the client store. Rendering logic lives twice, as templates on the server and components on the client. And between the two halves you must now build and version an API which exists only to feed your own frontend. For an application which is genuinely client-state-heavy, like a collaborative editor or a design tool, this duplication buys responsiveness you cannot get any other way, and it is worth every line. For a catalog with a search box it is pure overhead.

↬ ∙ Tagged in Software Engineering.

David Poblador i Garcia:

Which is to say, after two decades and forty-four meters of build tools and bundlers and hydration schemes, the industry sprinted in a giant circle and arrived, slightly out of breath, back at something that looks an awful lot like the file you uploaded over FTP. The instinct didn’t expire. The ground moved, for real reasons, and then it moved back.

A journey in and out of the heart of darkness.

↬ ∙ Tagged in Software Engineering.

Luke Plant:

The “pile of technical debt” is essentially a pile of knowledge – everything we now think is bad about the code represents what we’ve learned about how to do software better. The gap between what it is and what it should be is the gap between what we used to know and what we now know.

↬ ∙ Tagged in Software Engineering.

Sean Goedecke:

This is why tiny software companies are often much better than large software companies at delivering software: it doesn’t matter that the large company is throwing ten times the number of engineers at the problem if the small company is twenty times more efficient.

Why don’t large companies react to this by doing away with all of their processes? Are they stupid? No. The processes that slow engineers down are the same processes that make their work legible to the rest of the company. And that legibility (in dollar terms) is more valuable than being able to produce software more efficiently.

↬ ∙ Tagged in Software Engineering, Work Culture.

Vojtěch Rylko and Werner Jainek:

Our legacy Things Cloud service was built on Python 2 and Google App Engine. While it was stable, it suffered from a growing list of limitations. In particular, slow response times impacted the user experience, high memory usage drove up infrastructure costs, and Python’s lack of static typing made every change risky. For our push notification system to be fast, we even had to develop a custom C-based service. As these issues accumulated and several deprecations loomed, we realized we needed a change.

They chose to rewrite using Swift on the server.

↬ ∙ Tagged in Software Engineering.

Some nice tips in this.

↬ ∙ Tagged in Software Engineering, Tools.

Jeremy Morrell:

Adopting Wide Event-style instrumentation has been one of the highest-leverage changes I’ve made in my engineering career. The feedback loop on all my changes tightened and debugging systems became so much easier. Systems that were scary to work on suddenly seemed a lot more manageable.

↬ ∙ Tagged in Software Engineering.

Fascinating deep dive into hitting and overcoming the scaling issues affecting the sync engine Linear built.

↬ ∙ Tagged in Software Design, Software Engineering.

Tony Stubblebine:

Many things at Twitter were broken to the point that they could bring the entire site to a halt. Greg’s strategy, now distorted through multiple retellings and my own foggy memory, was to focus on short-term triage rather than long-term fixes.

Essentially, he realized that a collection of temporary, duct-taped fixes was the only thing that would give the Twitter team the breathing room to start working on longer-term fixes.

I think of this in school grade terms. Greg went looking for all the Fs and then turned them into Ds. Then he turned all the Ds into Cs and then all the Cs into Bs, etc.

↬ ∙ Tagged in Processes, Productivity, Software Engineering.

Skills that lead to good code stewardship.

↬ ∙ Tagged in Management, Software Engineering.

Miriam Posner:

You could say, then, that by the late 1960s, software development was facing three crises: a crying need for more programmers; an imperative to wrangle development into something more predictable; and, as businesses saw it, a managerial necessity to get developers to stop acting so weird.

↬ ∙ Tagged in Software Engineering.

Dan North:

The five CUPID properties are:

• Composable: plays well with others
• Unix philosophy: does one thing well
• Predictable: does what you expect
• Idiomatic: feels natural
• Domain-based: the solution domain models the problem domain in language and structure

Also this belter from Martin Fowler.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

↬ ∙ Tagged in Software Engineering.

Dan North:

The purpose of testing is to increase confidence for stakeholders through evidence.

…

You are testing if and only if you are increasing confidence for stakeholders through evidence.

↬ ∙ Tagged in Software Engineering.

A look at how Etsy tailored their search results to individual customers.

↬ ∙ Tagged in Software Engineering.