Gotta love bench testing old hardware! It's always satisfying, but what caught my attention wasn’t the glowing tube, it was the packaging. IBM’s decision to wrap a tube together with its supporting circuitry into a standard module looks almost mundane today because we’ve internalised the idea of replaceable components. In 1948 it was a manufacturing decision with architectural consequences. With the article, Ken could make it easily become another nostalgia piece about warm valves and blinking lights, yet it keeps returning to production, maintenance and serviceability. Those are the reasons technologies survive outside laboratories. Sure, standardised modules create organisational knowledge as much as electronic systems, but once engineers learn to design, test, swap and manufacture repeatable building blocks, the same habits migrate into later machines. You can almost see the ancestry of plug-in cards, blade servers and even cloud infrastructure in that way of thinking. As we often celebrate the breakthrough component, whether it’s a GPU, accelerator or exotic memory technology, but yet the durable competitive advantage frequently comes from packaging, deployment and maintenance economics instead. Those are harder to photograph, but they’re what customers actually live with.

The gap between the diagnosis and the evidence is what I kept noticing; whilst the broad themes are familiar, women leave because progression stalls, culture disappoints and small biases accumulate into career-changing decisions. I don’t doubt those mechanisms. They match years of reporting and research. What I’d still want is stronger evidence about which interventions reliably change outcomes across different companies rather than isolated success stories. We know that retention is the central problem, and instead of assuming the answer is simply persuading more students to study computer science, there's a more useful framing, because every experienced engineer who leaves takes knowledge, mentoring capacity and organisational memory with them. There's also a management problem disguised as a diversity problem; where engineering organisations optimise relentlessly for deployment pipelines, uptime and developer productivity, yet often treat career progression and team health as soft variables. Those systems deserve the same discipline. Promotion criteria, project allocation, technical leadership opportunities and manager incentives all form part of the operating architecture. If those mechanisms consistently produce unequal outcomes, they’re engineering failures as much as HR failures. I’d also resist assuming every departure has the same cause. Labour markets, family decisions, changing interests and better opportunities all interact with workplace experience. Untangling those factors is difficult, which makes careful measurement more valuable than confident narratives.

RBF has always occupied an unusual place in engineering culture. Some people read him as a visionary, others as an inspired eccentric. This essay reminded me why both reactions persist. He has an extraordinary ability to connect ideas across physics, design, economics and human behaviour, and occasionally he leaps across the gaps without showing enough working. I do like his habit of stepping outside inherited assumptions, as engineers spend much of their careers improving existing systems. Fuller asks whether the system itself deserves to exist in its current form. That’s a productive question because it shifts attention from optimisation to redesign. The idea of accomplishing more with fewer resources still feels remarkably current in an era of constrained energy, semiconductor shortages and pressure to reduce environmental impact. The essay also leaves me wanting firmer evidence. Fuller often moves from observation to sweeping conclusions about civilisation with remarkable confidence. Some of those conclusions have aged well, others depend heavily on readers accepting his intuition. I’d rather see stronger links between principle, experiment and measurable outcome. But, Fuller repeatedly treats technology as part of a larger system whose interfaces matter more than its individual components. Modern computing, distributed infrastructure and sustainable engineering all reward that habit of thinking across boundaries rather than within disciplines. Yet, his greatest strength is encouraging engineers to ask bigger questions before building better answers.

Right, a remote tungsten mine sounds like a local business story until you realise it’s really about how wars reshape industrial geography... The mine matters because governments suddenly care where a dense grey metal comes from, who refines it and who controls the transport routes between them. That’s a very different conversation from the globalisation consensus of twenty years ago. The piece is strongest when it reminds readers that supply chains are strategic assets; commodities that barely registered in financial headlines now influence defence planning, diplomatic relationships and industrial subsidies, and Tungsten isn’t unique in that respect, but it’s an unusually clear example because there are few practical substitutes for many military applications. Digging ore out of the ground is only one stage of the value chain. China spent decades building refining capacity, technical expertise and commercial ecosystems around these minerals. Recreating that network in allied countries is a much larger undertaking than reopening individual mines. The real signal isn’t the mine itself. It’s that obscure materials have become leading indicators of geopolitical strategy. That’s a useful way to read the story.

Bingo! Margaret-Anne has put a name to something many engineering teams are already feeling; the surprising claim isn’t that AI creates more code. It’s that AI may quietly make technical debt less important than the knowledge gaps left behind. That’s a much more interesting proposition because it challenges twenty years of software engineering orthodoxy. Technical debt has always been visible because it’s encoded in repositories, issue trackers and architecture diagrams. Cognitive debt is harder to spot because it lives in conversations, confidence and mental models. Intent debt is harder still because it depends on whether anyone remembers why the system exists in the first place. AI compresses implementation effort so aggressively that those invisible forms of debt can accumulate before teams realise they’ve traded understanding for velocity. Right now I'm struggling to see evidence that these debts can be measured consistently across organisations, and Storey acknowledges this herself by proposing signals rather than established metrics. That’s the next research challenge! If you can’t observe the debt, it’s difficult to manage it systematically. But, the triple debt model is a genuinely useful way to think about software health in the AI era!