Ancient Slashdot reader Mark Round writes: Longtime reader here (since mid-1999 -- Hot Grits! Oog the Caveman! Beowulf clusters!), and I can still remember posting back on Slashdot's own 5th anniversary. Time's rolled on: my own blog just turned 25, and it's now roughly 40 years since I first sat down at a computer. So I went digging through archive.org, old backups, and a box of ZIP disks, and wrote up a long look back at four decades of computing through the one website that's been my online home along the way. It runs from my first 8-bit micro and a 1,200-baud modem through discovering the actual Internet at university (and burning far too many hours on Slashdot and sister sites like freshmeat.net), past gloriously pimped-out Enlightenment Linux desktops, all the way to the modern cloud-native world. Plenty of dodgy screenshots, terrible code, and fond memories of long-gone haunts like kuro5hin.org and Linux Coffee Talk along the way.
At CTO Craft Con, Dr. Catherine Hicks (founder of Catharsis Consulting and researcher on open-science work involving 15,000+ developers) argued that most engineering measurement failures aren’t really data problems.
No matter how much dashboards you vibe-code (we all do that nowadays, don’t we?), the problem is theoretical: understanding what causal model your metrics are actually testing.
Are you building spike lines?
Hicks opened with a historical detour that turned out to be her sharpest part of the argument. Probably a bit brutal from today’s point of view, but early electricity measurement looked straightforward: count the deaths, count the lumens, measure the hours of labor saved.
Why the number of deaths? Those numbers made sense relative to what came before. Gas infrastructure occasionally caused sidewalks to explode. Zero to ten electrocution deaths in a neighborhood looked different once you remembered that twenty people you knew had died from the sidewalk going up.
Measurement always encodes a comparison, and if you do not make that comparison explicit, your metric will mislead you.
The more cutting example was the spike line. In early U.S. rural electrification, large power companies would create something called a spike line. It’s a single wire that ran through a region, sometimes connected to nothing more useful than a light in a shed, in order to legally claim the territory and block rural co-ops from building real infrastructure. The federal government that was measuring electrification by the presence of a line wasn’t measuring access but the exact opposite.
CTO Craft Con
Hicks argued that engineering organizations are building spike lines right now, and mostly do not know it.
Measurement failures usually come back to theory failures.
The loudest thing (on Slack) might not be the most important
A change theory, in her framing, is a causal model: if I give engineers more ramp time on this language, they will engage differently with these processes, and that will produce a business outcome. Everyone operates inside such models, but most teams never make them explicit.
The result is that they default to measuring what is visible, what is fast to collect, or what is loudest on Slack. None of those is necessarily connected to the outcome they care about.
On AI specifically, she identified three recurring failure modes:
ed patterns within weeks. Third, measuring only at the individual level while ignoring the interaction between the tool, the team, the task, the project goals, and organizational culture – a system Hicks described as having too many interaction terms for any human to hold simultaneously.
Treating developers as interchangeable units producing identical work, when they’re actually using AI in highly individual contexts.
Reading early spikes in code volume as a stable signal, when research on open-source repositories shows those spikes often normalize into different patterns within weeks.
Measuring only at the individual level while ignoring the interaction between the tool, the team, the task, the project goals, and organizational culture – a system Hicks said has too many interaction terms for any person to hold at once.
Her response to that complexity was deliberate: stop trying to measure everything.
Your job is not to measure everything that’s happening. What you really need to do is think about what in your organization are the key signals to measure if they give you two things.
Those two things are levers, predictors of large behavioral patterns, or blockers you can actually remove, and shared outcomes you can hold the organization accountable to over time.
Correlation between learning culture and team effectiveness
Hicks drew on her own research to illustrate what a well-theorized lever looks like.
In a 2024 study of over 3,000 working developers, her team testedwhether learning culture could reduce the identity threat that developers report feeling from AI. Teams with strong learning cultures, defined as believing they have organizational support to learn, and rejecting fixed-mindset assumptions about what makes someone technically capable, cut their AI-related identity threat by 50% or more. She has since replicated the correlation between learning culture and team effectiveness across multiple engineering organizations, and found that reaching the highest effectiveness tier requires clearing a threshold of learning culture, not just improving incrementally.
The practical upshot for leaders: if you want to measure whether your AI investment is working, you probably should not start with token consumption or PR velocity. You should ask whether developers believe their organization treats learning as legitimate work.
What if your metrics are broken?
On the question of what to actually do when you realize your metrics are broken, Hicks was direct. Describe how you got there. Find the argument you lost, or the organizational story that made a bad measure feel safe to commit to. Then build a change theory first, and derive the measures from that, not the other way around.
She closed with a framing that captured her broader position: you are not trying to map every variable in a complex system. You are trying to create enough shared understanding that people will tell you what is actually happening.
You will become the person who can hear what is really happening. You will be the person who will start to hear: I think we’re measuring spike lines over here.
That, she argued, is more useful than any dashboard.
Microsoft is taking a new approach to fighting cybercrime, targeting the cyberattack supply chain, not just individual services. In a case unsealed today, we are simultaneously targeting two widely used cybercrime tools, Amadey and StealC, after AI-assisted analysis revealed they rely on the same infrastructure.
This action goes after the cybercrime “assembly line,” where coordinated tools drive ransomware, financial fraud, and disruptions to public services. Amadey and StealC are often used alongside each other: Amadey helps attackers gain access to devices, while StealC steals passwords and sensitive information. Together, they form a critical link in the chain. In the first two weeks of May alone, Amadey and StealC were linked to more than 140,000 infected computers globally, highlighting how widely they are used.
Working with Europol and industry partners, we targeted both tools at once. The goal: break the chain. Since the start of the operation, Microsoft has identified more than 18,000 victim computers, severed criminal control of those devices, and is working with telecommunications providers to help protect affected customers globally.
When multiple parts of an operation are disrupted together, attacks are harder to launch, scale, and recover from. The result: fewer disrupted services, fewer opportunities for cybercriminals to profit, and more friction when they try to rebuild. It’s no longer enough to go after threats one by one. We need to interrupt how the attacks are put together.
It’s no longer enough to go after threats one by one.We need to interrupt how the attacks are put together.
What’s new is how we’re combining AI analysis with an expanded use of that law.
Amadey and StealC were developed by separate cybercriminals, but they relied on the same infrastructure. To understand how they worked, investigators used AI, including Copilot, to quickly analyze the malware, asking questions in plain English instead of manually combing through complex code. That helped surface key details, uncover hidden data, and test findings in a fraction of the time, turning what would have taken hours or days into minutes and enabling the team to spot connections faster.
Those insights allowed the legal team to treat both malware families as part of a single conspiracy. Instead of going after each tool separately, as we have done in the past, we used RICO to charge multiple complicit enablers involved across the operation. In total, Microsoft’s Digital Crimes Unit disrupted over 200 command-and-control servers—the systems criminals use to control infected devices, steal data, and keep attacks running.
By targeting tools together, we can disrupt the cybercrime chain more efficiently and more effectively, in a way that better reflects how these networks actually operate today.
Cybercrime now runs like an assembly line
Cybercrime is no longer a series of isolated attacks—it’s a coordinated system.
Specialized tools handle each step: one gains access, another steals credentials, and others sell or exploit that access for fraud, ransomware, espionage, or other nefarious purposes. Different actors may be involved at each stage, but together they turn access into profit, quickly and at scale.
How cybercrime tools are built to be modular
That structure also creates a point of vulnerability. The people behind these cybercriminal tools may never interact directly, but their tools are designed to work together. If those connections can be identified, multiple stages of an attack can be disrupted at once.
How these attacks play out in the real world
Most people will never hear the names Amadey or StealC, but they feel the effects. A hospital locked out of critical systems. A city unable to deliver essential services. A small business losing access to accounts overnight. A retiree who lost their life savings.
These attacks don’t happen all at once. They unfold step by step: attackers get in, passwords are stolen, access is reused or sold, and sometimes repurposed for more targeted operations. For example, Microsoft has observed Russian-affiliated actor Secret Blizzard leveraging Amadey infections to deploy custom malware against targets in Ukraine.
By targeting multiple points in that chain at once, we reduce the chance that a single compromise turns into widespread harm. Put simply: fewer attacks succeed and fewer people feel the impact when they do.
No one organization can do this alone
Actions like this underscore a fundamental reality: we’re successful when we collaborate. No single organization, whether government or industry, has full visibility into how cyber threats operate across borders and sectors. What makes this effort effective is the combination of perspectives and data.
Bringing those efforts together expanded our collective datasets and made it possible to identify the connections between the two tools and act on them quickly. That shared understanding enabled a coordinated response that went further than any single organization could achieve alone.
This shows why partnerships matter. Industry shares technical insight, government brings visibility, and we need trusted ways to exchange that information. Only by working from the same picture can we stay ahead of attackers, disrupting not just individual tools but also the systems that make cybercrime possible.
Creating sustained pressure on cybercrime
This work doesn’t end with a single action. Cybercriminals adapt quickly, which is why we continue tracking how these operations evolve and working with partners to disrupt them.
Microsoft’s court-authorized disruption in this case is paired with ongoing efforts to track how cybercriminals rebuild, identify new infrastructure, and work with partners to disrupt the services they rely on to operate. It also includes incorporating the findings from this disruption into initiatives like Microsoft’s Statutory Automated Disruption program, which helps accelerate the removal of malicious domains and infrastructure.
The goal is not just to stop one operation but to slow the system itself—making attacks harder to launch, scale, and recover from. By combining AI-driven insight, legal action, and strong partnerships, we can continue to raise the cost of cybercrime and reduce its impact.
For more than a decade, Microsoft’s Digital Crimes Unit (DCU) has worked to disrupt cybercrime and nation-state threats, filing around 40 cases since 2008 and partnering with law enforcement to take down criminal networks. Learn more about the team’s efforts here.
We all know the benefits of TDD but we often find it time consuming and tedious to write. What if AI can do the driving and we can be the shrewd navigator?
It's easily said than done, but once we learn the right techniques the result can be rewarding. In this presentation we will take an example driven approach to test drive a piece of code and see how we can be that navigator that can steer us towards reaping the benefits of TDD.
In this episode of Battery Bargains: • a Volvo EX30 lessee looks to move up to mid-size • a gas car owner wants to go electric for under $20,000 • a family of four wants an EV for their secondary car
Our guests this week are Andrew Lambrecht from Ever Cars and Dave Conner from Out of Spec Dave on YouTube
John Joseph Adams, Sara Lynn Michener, and Rafael Jordan join us to discuss Season 5 of the alternate reality sci-fi show For All Mankind on Apple TV. Ad-free episodes are available to our paid supporters over at patreon.com/geeks.
Log in
