I remember early morning becoming afternoons and early nights with the least amount of breaks for physiological needs.

My entire setup is still meant for and built around that meditative state, and keeps evolving upon these roots. (N)Vim, tmux, carefully tweaked keymaps and configurations, (recently introduced) split keyboard layers. Everything is in place for a specific reason: delegate as much as possible to the ancestral parts of my brain dedicated to muscle memory and coordination so I can focus on the singular thing I’m doing.

But something is dramatically changing, everywhere. And despite part of it is self-induced, most of it is more and more structural in how we work and socially evolving.

I remember how my work, and my free time, was flowing in that sense. I had waves of focus, creativity, chaos, concern, release; all of these emotional states work well together in a work session when they dynamically balance each other to produce an artifact, a thought, a brilliant new assumption you were previously ignoring, or whatever else. Truly mastering these emotions is also part of the ability of a skilled worker, in any field. Mastering fear and worry for a professional climber IS part of their skills. Mastering the stress coming from a Heisenbug isn’t different, the more mature you are as a software engineer, the more you know how to deal with your time, including breaks and, in general, the rest of your work and life to sustain it long-term.

I’ve recently started questioning if the way we’ve been working since the most powerful AI models came out is compatible with the standard working models. I’m not just talking about software engineering, it wouldn’t make much sense. Our profession, especially now, is getting closer and closer to other knowledge worker who solve problem at a higher level and their work is getting impacted in a similar fashion.

I have myself noticed with surprise how much of the low added-value work I got rid of. And I’m happy about it when it is really low-value; for the same reason I love vim macros: there’s no reason you should manually format in the same way one thousands lines of text if you can automate it.

What is happening here is different though, these are roughly the stages we’ve seen (so far). I’ll be using software but other fields can relate:

1. Write your code, AI is going to help you autocompleting a few things, boilerplating and suggesting additions or changes.

2. Write most of your code, take the critical parts of it and ask AI in the browser for suggestions, tests, validation and brainstorm with it. You can brainstorm with AI at any point of the flow, before, during, after.

3. Chat in your editor of choice with AI, it produce part/most of the code, depending on your trust and confidence. You (probably) review it and accept/discard the changes.

4. Spin an agent that does most of the work for you, you follow along (maybe), review and accept/discard/iterate over it.

5. Loop an agent over specifications of what you need, leave it more or less privileges to do anything it needs, depending on how much you segregated the environment or you trust humanity and their ability to prompt-inject you out of existence.

6. Orchestrate swarms of skilled agents to do the work you asked them to do, pretending you review the code. Ship it straight to production, your company is happy until they get hacked because of the many critical vulnerabilities “you” have introduced.

While all of this is happening in the background, you answer people on slack (or configure an agent to prepare and send you reports with summaries and answer for you to the less critical ones), skim-read a couple of important document you want to have an idea about, support a colleague with a critical bug on the pipelines, and do a back-and-forth on the Gemini and Claude browser sessions about the new project you’re leading for the next quarter.

“All and only the most high value-added work will remain for you” they said.

The problem is that the ups and (forced) downs I used to have were vital, especially the downs, the moment you relax some parts of the brain and focus yourself in creating your craft, in forming an idea, in shaping a diagram. They were vital for my brain to better process information, to give it space to clean up garbage and to be creative incidentally.

It wasn’t vital for my mental health for the sake of it: who cares? You should care for sure, but companies don’t usually work that way. Mental health is a concern for them if the byproducts and outcomes of a degrading worker’s creativity produces measurable damage, especially if the worker is hard or expensive to replace. Frameworks, procedures, anti-silos initiatives, bus-factor reducing policies are in place just for that.

Companies, in my opinion, should selfishly start thinking about this. When technology increases productivity through increasing the output it is beneficial for everyone IF AND ONLY IF the output is deterministically stable and its verification is either trivial or increases less than the output itself.

But this is not happening. The fundamentally, and by design, indeterministic nature of AI models is clearly what’s needed for them to be brilliant and able to do incredible things fast. But it’s also the condemn they gifted us along with it. We (still) don’t have the privilege to have huge output with minimal verification. Automated tests are not guardrails, if tests are all written by AI. LLM-as-a-Judge is not a guardrail as it brings with it non-determinism as a feature.

I think we’ll soon need to interrogate ourselves, as individuals first, and society later. What’s the trade-off we want to accept: low quality with high output or high quality, less output and more sustainability work?

You walk away muttering the same thing every technically correct person has muttered since the beginning of organized work: “They just don’t get it”.

They got it. They just weren’t moved.

Convincing vs Persuading

Perelman spent decades dismantling this blind spot. In his The new rhetoric: a treatise on argumentation, he drew a line that most of the intellectual tradition had been smudging since Descartes: the line between convincing and persuading.

Convincing is an operation on logic. You assemble premises, you chain them together with valid inferences, and you arrive at a conclusion that any rational agent should accept. The target is what he called the “universal audience”, an idealized audience of every reasonable mind that ever existed or could exist. If your argument is valid, it should work on all of them. A mathematical proof convinces. A benchmark convinces. A failing test suite convinces.

Persuading is a different animal entirely. Persuading targets a particular audience: these people, in this room, with these fears, these incentives, these memories of the last migration that went sideways. Persuading doesn’t ask “is this logically sound?”. It asks “will this move them to act?”.

Convincing addresses reason. Persuading addresses the full human. And the gap between the two is where most technical proposals go to die.

You can convince every person in the room that your microservices architecture is superior to the monolith. You can lay the evidence flat on the table like a surgeon displaying X-rays. And they will still vote for the monolith, because the last team that attempted a migration was disbanded, because the VP of Engineering ships their bonus on a Q3 deadline, because the tech lead built the monolith and his pride is load-bearing infrastructure.

Geometric vs Subtle Minds

Pascal used to distinguish between geometric and subtle minds (sensibilities). The geometric mind works through axioms and deductions, step by step, like a compiler. The subtle mind grasps a situation holistically, reading context, feeling the weight of unspoken constraints, sensing what a room will and won’t tolerate.

This is clearly a simplification, but engineers are usually trained almost exclusively in the geometric mind. The entire discipline is built on the assumption that correctness is sufficient, that if you can prove something works better, the proof carries its own momentum. Unfortunately in reality it doesn’t. Correctness is necessary but it is not sufficient. It should be the foundation, not the building.

This is why the best technical decision-makers I’ve ever worked with aren’t necessarily the smartest or most technically proficient people in the room. They’re the ones who learned, often painfully, that an argument aimed at “every rational person” lands on no one in particular. They stopped presenting to the universal audience and started reading the particular one.

Think about the last RFC/ADR/One-Pager you wrote.

You laid out the problem statement, described the current architecture and its failure modes, proposed a solution, backed by evidence. You anticipated objections and addressed them. In your opinion it was clean, thorough, well-reasoned.

Once presented you probably had some of the following people in your audience. The SRE guy who’s drowning in incidents and sees any architectural change as another surface area for things to break. The product manager who translates every engineering proposal into “how many sprints does this cost me”. The junior engineer who doesn’t understand the current system well enough to evaluate a replacement.

Probably your RFC even convinced them. But it didn’t persuade them. And you confused the two, so when the proposal stalled, you assumed the problem was comprehension. You added more diagrams. You wrote a longer appendix. You scheduled another meeting to walk through it again.

You were just polishing a handle of a door no one wanted to open.

Rhetoric is required

This terrain was mapped millennia ago. The three dimensions of rhetoric are since then well-known: the logical structure of the argument, the credibility and character of the speaker, and the emotional state of the audience.

Convincing lives almost entirely in the logical structure.
Persuading requires all three mixed together and calibrated to context.

In software engineering, we worship logic and treat the other two as contamination. We act as though caring about who is making the argument, or how the audience feels about it, is a form of intellectual corruption. It’s not. It’s the recognition that human beings are not compilers. They don’t parse your argument in isolation from everything else they’re carrying that day.

What drives decision-making has little to do with logical validity. Not because logic doesn’t matter, but because logic operates on a different layer of the stack. You need the logic underneath if you want to bring a solid proposal: that is your job.
But it’s not the interface. The interface is trust, timing, and the careful art of making someone feel that acting on your proposal serves what they already care about. This is not manipulation, which would require you not actually having the honest conviction underneath. The two must work together: you need a sound argument and the skill to land it.

Conviction without persuasion is impotence. Persuasion without conviction is fraud.

This doesn’t only cut one way. A VP of Engineering who decrees a change has the authority to make it happen. The org chart says so. The decision is made, communicated, documented.

Then nothing moves or results are way worse than expected.

Engineers complied without committing. They did the minimum the process demands and none of what the change actually requires.
Authority without credibility is just a mandate with no engine behind it. The VP convinced no one, they didn’t need to: they have the title. But they also didn’t persuade, because persuasion requires much more than the reporting line alone can provide.

Positional power gets compliance. Persuasion gets commitment. The gap between those two is where rewrites stall, migrations rot, and strategic initiatives quietly become shelfware.

Engineers and leaders who actually move things aren’t the ones who are right the most often. They’re the ones who learned that being right is the starting line, not the finish.

If you liked this post, consider subscribing to receive new posts, or sharing it on Hacker News.

Fred Brooks explained this in 1975 in his The Mythical Man-Month. I read it recently, and for a good part it’s clear he’s picturing a prehistoric world of software engineering. But at its core, many of those intuitions are more than relevant today.

Two golden ages of software engineering have passed since then, but the underlying concepts remain, one of which is the misconception of what a real product running in production actually is.

Programming Systems Product

Program

He draws a simple diagram with four quadrants. In the top-left corner sits the Program, a more or less complex application that “runs on one machine, for one person, solving one problem”. This is the part that, more than anything else, automatic programming has sped up a lot. Today I’d rewrite that sentence to give AI more credit: what you can possibly ship in a day (depending on the case) is much more than something a single user can run on their machine. In any case, that’s the thing you “build in a day”.

Programming Product

With a multiplication of the effort (he approximates it at 3x, clearly a simplification, and today the ratio is even different) you can transform your program into a Product through generalization, testing, documentation, and (a lot of) maintenance.
Regardless of the research you’ve done ahead of time, your users will need a feature you haven’t thought about, an SSO provider you haven’t implemented because of the additional complexity, they prefer CSV export instead of JSON, and so on.
The number of bugs and edge cases they’re able to find running your product in every possible absurd condition is incredible: old devices, niche browsers, network conditions, unexpected behaviors.
A note on documentation: who are the users of your product? You are required to document not only for your end users (including landing pages, wizards, hover text, external links, tutorials) but for yourself in the form of runbooks and today living documentation for coding agents. If the project also has an open-source nature, or you have colleagues, you’re better off documenting how to collaborate, what the architecture of the codebase is, and so on. If you’re building a B2B product, I can assure you that you need to document a lot of stuff that nobody will read, but often needed for some sort of compliance.

Programming System

Through another multiplication of the effort you can get to a Programming System. Especially when software lives inside a company, or you start getting serious with what you’re building, it rarely runs in isolation. It connects to other tools, services, and systems, and that web of connections changes everything dramatically.
The moment your program starts talking to other programs, complexity multiplies. Inputs and outputs need to be carefully managed, integration testing becomes essential, and things like monitoring and scaling turn into real challenges instead of afterthoughts.
This shift from a standalone program to a piece of a larger system carries a price tag similar to going from a script to a product. Plugging something properly into an ecosystem takes far more effort than building the thing itself.
If you start to have departments (it can just be yourself wearing multiple hats) you’ll discover the number of tools for all sorts of bureaucracy that you need to, in one way or another, integrate into your workflow just to keep the lights on.

Programming Systems Product

With all that said, finally, in the bottom-right corner sits the Programming Systems Product, which has the same core logic as your original product but generalized for strangers, tested until unbreakable, documented for people who will never meet you, and integrated into a living system of other components that all share resources and fail in creative ways.

The distance between the two corners is not incremental. It is a multiplier. “Three” times the effort to turn your script into something anyone can use. “Three” times again to make it coexist with everything else.

AI

Brooks’s multipliers assumed deterministic software. In 2026, some of the components you’re probably integrating are non-deterministic, and that changes the nature of the work at every level.

When your program enters a modern ecosystem, you aren’t just managing state. You are managing orchestration and observability across a distributed, often “black-box” network. Standard error logging doesn’t cut it anymore. If a logic error occurs somewhere in a chain of five different models or services, you need to trace it semantically, not just structurally. Worse, outputs can drift silently over time, breaking downstream services in ways that no traditional test suite would catch.

And when the software itself is built primarily by agents, the Product quadrant introduces a new kind of problem: volume. Automatic programming creates code faster than human engineers can review it line by line. The “source of truth” starts to drift between the developer’s intent, the prompt used to generate the logic, and the resulting code. Without deliberate effort to keep these aligned, the agent gradually loses its mental map of the project. New additions begin to break existing features in unpredictable ways. Call it context rot: a form of technical debt that doesn’t come from laziness or shortcuts, but from the sheer speed at which code is now produced.

This also means that in 2026, a Product isn’t just documented for humans. It is documented for coding agents. You need high-density context maps and runbooks that agents can consume to fix bugs or navigate the architecture autonomously. If your system isn’t “agent-readable”, it is already legacy.

Today tools are real. You can generate a working prototype faster than ever, and the gap between “I have an idea” and “I have a demo” has collapsed to hours. That part is genuine progress.

But the gap between “I have a demo” and “I have a product” hasn’t moved. If anything, it’s wider, because the demo now arrives so fast that people have even less patience for what comes after. The prototype feels like the finish line. It is the starting gun.

Especially because you’re not the only one to have gained that power.

Distribution

Something Brooks couldn’t even imagine at the time, but that we’re very aware of today, is Distribution.

Today, distribution is the final, invisible multiplier. The world is drowning in high(er)-quality noise. You are no longer competing against the difficulty of the syntax, you are competing against the infinite supply of “good enough” software generated by everyone else with a prompt.

Think about what that means concretely. Ten years ago, if you built a decent project management tool, your competition was the handful of teams with the engineering resources to do the same. Today your competition is anyone with an idea and a weekend. The barrier was syntax, now the barrier is attention. And attention doesn’t scale the way servers do. You can’t throw more compute at it. You can’t automate it away. Getting a stranger to care about your product long enough to try it, that is a problem that resists every shortcut the last two years have given us.

In this landscape, technical elegance matters zero (despite the fact I think it’s absolutely crucial) if you cannot bridge the gap to the user. Distribution is no longer a department that handles the “launch”. It is an architectural constraint. In an era of low-cost production, the only remaining scarcity is human attention, and solving for that is more complex, more expensive, and far more volatile than any legacy codebase.

The “built in a day” fallacy hasn’t disappeared. It has simply shifted its coordinates. AI has commoditized the first quadrant, turning the “Program” into a disposable artifact. But the remaining work of hardening, integrating, and distributing remains as resistant to shortcuts as it was in 1975.

The challenge of software engineering has evolved from “How do we build this?” to “How do we make this survive the noise?”.

If you liked this post, consider subscribing to receive new posts, or sharing it on Hacker News.

Telegraph operators in the 1860s could identify each other across hundreds of miles by the cadence of their tapping alone. They called it “the fist”. Military intelligence in World War II used the same principle to distinguish allied transmissions from enemy deceptions. No encryption. No codebook. Just the involuntary rhythm of a human hand.

Now think about what you do every single day. Emails. Slack messages. Login forms. Search bars. You hammer out thousands of keystrokes, and buried inside that noise is a biometric signature as unique as the way you walk or the way you sign your name.

The field is called keystroke dynamics.

The Anatomy of a Keyprint

When you type a word three things happen that you will never consciously notice. First, there’s a dwell time: how long your finger presses down on each key, measured in fractions of a millisecond. Second, there’s a flight time: the gap between releasing one key and striking the next. Third, there’s a latency: the full arc from first press to second release.

Stack these measurements across every pair of keys you type, every digraph, every trigraph, and you get a timing profile. A rhythm. A signature written not in ink, but in the micro-hesitations of your nervous system.

This is not something you can fake. You didn’t learn it or chose it. Your motor cortex and your muscle memory built it over years, and it runs underneath your conscious awareness like a second heartbeat.

Old Tools, New Forge

Early researchers in the 1980s (Gaines, Umphress, Williams) proved the concept with crude statistical models. Euclidean distance. Manhattan distance. Measure the gap between a stored profile and a live sample. If the numbers are close enough, you’re in.

The problem was the same problem that plagues every craft when it’s young: the tools were blunt. Statistical models couldn’t handle the chaos of free-form typing. They needed you to type the same password, the same way, over and over. Fixed text. Controlled conditions. A laboratory exercise pretending to be a real-world system.

Then machine learning arrived. SVMs (Support Vector Machines) delivered under 1% average error rate on 500 keystrokes of free text. Decision Trees pushed past 93% AUC (Area Under the Curve, a measure of classification performance) with just a few keystrokes. Traditional ML was solid, but ultimately limited by hand-crafted features and fixed-length inputs.

The real interesting stuff started with deep learning. Recurrent networks could finally model what typing actually is: a sequence, a temporal stream with dependencies stretching across dozens of keystrokes. CNN+RNN hybrids drove the Equal Error Rate (where false accepts equal false rejects) down to 2.67% on the Buffalo/Clarkson datasets using just 30 keystrokes. RNNs scaled to 168K subjects and still held 2.2% EER on desktop data. Then Transformers arrived and pushed it further, 3.25% EER on mobile with as few as 30 keystrokes across 60K users. Deep learning didn’t just improve keystroke biometrics; it made them viable at scale.

And then came the Transformers.

TypeFormer, a self-attention architecture built specifically for keystroke sequences, achieved an Equal Error Rate of 3.25% on the Aalto Mobile database using just 30-100 keystrokes. The previous Transformer-based result on the same dataset sat at 3.84% EER with a fixed 50-keystroke window. Meanwhile, the best RNN approach hit 9.2% EER, though on a different mix of datasets, so it's not a clean apples-to-apples comparison. Still, TypeFormer didn't just edge out the competition: it set a new bar for keystroke biometrics with fewer keystrokes and a flexible input range.

Authentication

There are three ways to deploy keystroke biometrics as a supporting authentication mechanism.

Fixed-text authentication asks you to type a known string (a password, a PIN etc). It’s easy to build, easy to profile, and easy to understand.

Free-text authentication watches you type anything like an email, a document, a chat message, and verifies your identity from the rhythm alone. Historically, it needed 500 or more characters to work. Modern deep learning does it in 40 to 60 keystrokes. About two sentences.

Continuous authentication is worth more attention than it gets. It runs quietly in the background, monitoring patterns like keystroke rhythm throughout a session. If the pattern shifts (say, someone else sits down at your keyboard) it triggers a security notification or simply locks the door, prompting for a second layer of authentication. The system already knows you left. It knew before you did. This aims to shift security at the intrinsic architecture level, like the difference between a lock on the front door and a house that knows who’s inside every room at every moment.

This is clearly at the research level and we know that every system has attack surfaces, this one is no different.

Injection attacks are real. Researchers have built rogue USB implants that sit inside a keyboard and replay a victim’s timing pattern with 93 to 96% accuracy on fixed-text systems. Humanoid robots have shown the ability to significantly degrade the performance of these detectors in white-box scenarios by imitating human gestures with high precision. Attackers can sample inter-keystroke intervals from empirical human distributions and forge passable imitations.

The defense? Liveness detection. Systems that look for micro-jitters: the tiny, involuntary tremors in human motor control that no replay attack or robotic actuator can perfectly replicate. Randomized challenge prompts. Multi-modal fusion, combining keystroke rhythm with mouse dynamics, device motion, even gait patterns, to create an identity surface so complex that forging one channel means nothing if the other three don’t match.

Anyway, every organization that relies on a single authentication factor is building on a foundation with exactly one crack needed to fail. Keystroke dynamics clearly doesn’t replace those layers alone.

Tracking

The marketing attribution landscape is shifting toward privacy-centric “cookieless” strategies that prioritize first-party data and server-side tracking.

Server-side tracking has emerged as a critical alternative, moving data processing from the user’s browser to a brand-controlled server to bypass ad blockers and browser-level restrictions like Apple’s Intelligent Tracking Prevention (ITP). Identity resolution solutions, such as Unified ID 2.0 (UID2), provide another durable path by using hashed and salted email or phone data to recognize users across different platforms.

It is important to note that while keystroke dynamics can technically “fingerprint” a user, it remains a biometric signal distinct from these commercial frameworks. Marketers are increasingly utilizing machine learning for behavioral and conversion modeling to fill data gaps, alongside Google’s Privacy Sandbox APIs, including the Topics API for interest-based targeting. However, current research does not link keystroke dynamics to the implementation of UID2 or the Privacy Sandbox, as these standards prioritize aggregated or deterministic data rather than individual behavioral biometrics. These frameworks often blend deterministic attribution, which relies on exact matches like login credentials, with probabilistic models that use statistical signals to estimate the impact of anonymous user journeys.

And more

Changes in typing speed, inter-key delay, and error frequency are emerging as passive digital biomarkers for Mild Cognitive Impairment. Your keyboard can detect neurological decline before you notice it yourself. Older users exhibit measurably slower, more variable typing patterns, and tracking those patterns over months or years creates a longitudinal health record that requires no clinic visit, no blood draw, no conscious effort from the patient. Your keyboard becomes a diagnostic instrument, not because someone engineered it to be one, but because the signal was always there. We just never measured it.

In education, platforms like Coursera use keystroke dynamics to verify that the student registered for a course is the one taking the exam. No webcam. No surveillance theater. Just rhythm.

In forensics, an anonymous account means nothing if the typing pattern behind it matches a known profile. Age, gender, linguistic background, all encoded in the timing between keys and how long you press them.

Privacy

Under GDPR and the UK Data Protection Act, biometric data used for identification is classified as special category data. You need explicit, informed consent. You need a Data Protection Impact Assessment. And you absolutely cannot store raw keystroke logs.

The correct approach is template conversion, transforming timing data into anonymized mathematical representations that cannot be reversed to reveal what was typed. Data minimization isn’t optional. It’s the law.

This is the razor’s edge. The same technology that can protect a user’s identity can, if mishandled, become the most invasive surveillance tool ever deployed on a consumer device. The difference is entirely in the architecture of the system, what you store, what you discard, and whether the human on the other end of the keyboard ever gave you permission.

You could be already broadcasting a biometric signal every time you type. Every email. Every search query. Every password. The rhythm is uniquely yours, shaped by your neurology, your muscle memory, your years of habit.

The question isn’t whether this signal exists. It does. It has since the telegraph.

The question is who’s listening. And whether the systems being built around it are designed as fortresses, or as traps.

BTW: I turned this rabbit hole into ShuffleKeys, a fully open-source keystroke dynamics obfuscator. If any of this got you thinking, contributions and beta testers are very welcome!

ShuffleKeys - OS Keystroke Dynamics Obfuscator on Github

If you liked this post, consider subscribing to receive new posts, or sharing it on Hacker News.

Refs

• A Survey of Keystroke Dynamics Biometrics - PMC

• Keystroke dynamics as a biometric for authentication - ResearchGate

• Efficient Convolutional Neural Network-Based Keystroke Dynamics for Boosting User Authentication - PMC

• Keystroke Biometric

• What’s Your Type? Keystroke Dynamics as Behavioral Biometrics

• Keystroke-based User Identification on Smart Phones - Genetic-Programming.org

• Privacy: Gone with the Typing! Identifying Web Users by Their Typing Patterns

• Keystroke Dynamics for User Authentication and Identification by using Typing Rhythm - IJCA

• Keystroke Dynamics - Biometrics Solutions

• The Improved Biometric Identification of Keystroke Dynamics Based ...

• Some Remarks on Keystroke Dynamics - Semantic Scholar

• Fast Free-text Authentication via Instance-based Keystroke Dynamics

• Authentication by Keystroke Dynamics: The Influence of Typing Language - MDPI

• A Comprehensive Review of Keystroke Dynamics and Human Gait Analysis in Biometric Authentication - IJCA

• TypingDNA on Mobile Phones: Best Practices for Browser and Native Integrations

• Using Keystroke Dynamics Behavioral Biometrics to Identify Users - OpenRiver

• A Survey of Biometric keystroke Dynamics: Approaches, Security and Challenges - arXiv

• Keystroke Dynamics: Concepts, Techniques, and Applications - arXiv

• A Deep-Learning-Based Approach to Keystroke-Injection Payload Generation - MDPI

• Keystroke Dynamics - Plurilock (Continuous Authentication)

• Keystroke Dynamics for Continuous Authentication - ResearchGate

• Authentication API - Keystroke Dynamics for Your App - TypingDNA

• Exploring Age-Related Patterns in Smartphone Keystroke Dynamics - JMIR

• Continuous Age Detection using Keystroke Dynamics - NTNU

• Exploring Age-Related Patterns in Smartphone Keystroke Dynamics - PMC

• Biometric Authentication in Exams: 6 Key Privacy Concerns & Solutions - Proctor360

• User attribution through keystroke dynamics-based author age estimation - Bournemouth University

• Age and Gender as Cyber Attribution Features in Keystroke Dynamic-Based User Classification - MDPI

• User Authentication Method Based on Keystroke Dynamics and Mouse Dynamics - PMC

I didn’t expect it to travel as far as it did, with nearly 600 comments on Hacker News. I want to genuinely thank everyone who, whether they agreed or not, discussed it, shared it, and reached out to me because they felt I raised a point worth engaging with.

Anyway, I knew it would sting, and some reactions1 confirmed not only what I thought, but also what I wrote: most people are still decorating the old house. Many are scared, in a denial phase that brings the discussion to a detrimental state for everyone.

I'll try here to cluster and answer the most common takes.

Framework Defenders

Of course frameworks have their place. The point was different: we're talking about blindly accepting design decisions without considering the trade-offs that always exist. We often do this from the start, when the solution space isn't clear yet. Starting to develop a simple web application with Next.js just because it's easy enough and deployable in a click on Vercel is a terrible idea if done by default, just because that's what YouTube influencer X told you.

“Frameworks provide correctness and battle-tested security”. Sure. Nobody is arguing against that when you really need it and it’s part of your design decisions. I’m arguing against defaulting to someone else’s blueprint when you now have the tools to draw your own, especially when the problem doesn’t warrant it.

The argument that AI performs better with frameworks because they provide "vocabulary" is telling. You're saying the machine needs the crutch too. That's not a defense of frameworks. That's an accusation of how we've trained ourselves (and now our tools) to think inside someone else's box, regardless of the context.

SQL injection protection is not an argument for adopting an entire web framework. It’s an argument for adopting a single, purpose-built sanitization layer. Not ten thousand lines of someone else’s opinions about how your application should breathe.

The middle path people get it. Build or buy what you need. Nothing more. Nothing less.

“But I love writing code”

So do I. In twenty years I have hand-built thousands of projects of any kind. This keeps being true even now, when the most powerful LLMs are available. Writing code is relaxing. It’s satisfying. It’s craft for the sake of craft, and I have never stopped doing it.

But that’s not what we’re talking about.

Loving to write code and questioning whether you should write every line by hand for every project are two completely different conversations. A carpenter can love hand-cut joinery and still use a table saw when building a deck. The love of the craft is not an argument against better tools. It’s an argument for knowing when the craft matters and when the deadline does.

Confusing what you enjoy with what a project demands is not passion. It’s lack of pragmatism. And pragmatism is not the enemy of craftsmanship. It’s what separates the craftsman from the hobbyist. The hobbyist would write code because it feels good. The craftsman writes code when it’s the right call, and lets the machine handle the rest so they can focus on the part that actually requires a human brain.

Nobody is asking you to stop writing code. Do, literally, what you want. I’m asking you to stop pretending that enjoying something makes it the right tool for every job.

Productivity Skeptics

The ones claiming “1.2x at best”: If your speed hasn’t changed, you’re using the forge to heat your coffee. I’ve recently heard university professors claiming they can’t find useful ways to use LLMs, and that most of the time the results are wrong. If you think buying a kitchen teaches you to cook, you'll be disappointed.

The 10x claim is also nonsense for most. Here’s the truth nobody wants to quantify honestly: the multiplier is not uniform. It’s asymmetric. The thinking time stays the same, if not more. It should. If your thinking time decreased, you’re not engineering, you’re gambling. What collapses is the translation time, the brutal, exhausting distance between a clear idea and working code. That distance used to be days. Now it’s hours. Sometimes minutes.

If you were already fast at typing and slow at thinking, yes, you’ll see 1.2x. The tool replaced your least valuable skill. If you were slow at typing and sharp at thinking, you just got some of your life back, or increased the value you can get.

“Rude Awakening” Prophets

You’re right. Partially.

Vibe coding will produce disasters. Companies are already shipping systems nobody understands. I see it. And when those systems break, not if, when, there will be no one in the building who can find the fracture. This is not a prediction. This is a certainty.

But this is not an argument against Automatic Programming (again, thanks to Antirez for coining the term). This is an argument against ignorance. The stochasticity argument is more interesting, and of course must have a place. Yes, a model is not a compiler. A compiler is a contract. A model is a collaborator. We don’t trust a collaborator blindly. We review. We test. We verify. If we’re not doing that, the problem is not the tool. The problem is us.

From Robert Martin’s Clean Code 2nd Edition:

On the other hand, I am the final arbiter of the code that gets produced.
It remains incumbent upon me to do the work to ensure that I can evaluate what it produces.
Doing that work will usually involve writing and cleaning the code that I ask it to improve so that I can properly judge the outcome. The trade-off is very similar to using an autopilot in an airplane. The autopilot can vastly reduce the workload. But under no circumstances should it be implicitly trusted. Rather, the pilot must continuously oversee its operation. By the same token, no pilot should ever fly without possessing the necessary flying skills that they continuously maintain and refine. So it is with us. We must stay in practice, and keep our skills high, because we must be able to competently oversee the automation that reduces our workload.

Career Worriers

There is fear, and uncertainty, I understand. The question isn’t whether the landscape is changing, it clearly is. The question is what we do with that knowledge.

The pilot model is the closest analogy I’ve seen.

The junior dev crisis is real and it’s already here. But the solution can’t be to slow down the tools. The solution is to fix how we teach. We don’t teach new pilots by making them build an engine from scratch. We teach them aerodynamics, systems thinking, failure modes. Then we put them in the seat with supervision.

The craft of understanding why code works is not going away. It’s becoming more important, not less. Because when the agent writes something wrong, and it will, the person in the seat needs to know why it’s wrong before the ground gets close.

We also have to consider the new skills that are forming, and will form, because of Automatic Programming. The ability to architect systems at a higher level of abstraction. The skill of ‘prompt engineering’ is, now more than ever, really just clear thinking made explicit. The judgment to know when to trust the machine and when to rewrite from scratch. These aren't lesser skills. They're different skills, and some of them require sharper thinking than what came before.

Skill polarization is not a bug. It’s how every tool revolution has worked since the first human picked up a sharper rock. The question is whether you’re sharpening your rock or admiring someone else’s.

The “Last 10%” Realists

Yes. The last ten percent is where the craft lives. It always has been. A prototype is not a product. A sketch is not a building. Anyone who ships a 90% AI-generated system and calls it done deserves the 3am phone call they’re going to get.

Here’s what you’re missing: that last ten percent used to come after months of the first ninety. Now it comes after days. You’re not saving ten percent of the effort. You’re reclaiming ninety percent of your time to spend on the part that actually matters. The hard part. The part that requires a human who has laid the bricks before and knows which ones crack under pressure.

But this is the 10% of the building part. If you've worked in this industry at all, you know where the biggest part of Software Engineering really lives. And it's not building.

If you liked this post, consider subscribing to receive new posts, or sharing it on Hacker News.

Year 2025, surrounded by AI models that can supposedly do anything.

Zuckerberg, Amodei, Siemiatkowski and many others are jumping on the near-future prediction bandwagon about AI replacing humans, with software creation especially included.

Redis, Postgres, Vercel, Supabase, Go, Zig, Ghostty, go find the software, tool, tech company you like - these are all remarkable creations that many of us use daily, directly or indirectly. Some we love, some we tolerate, but each represents not just code, but entire ecosystems built through human collaboration: communication, negotiation, documentation, and years of iteration and refinement.

Prototype

I've tested many of these low/no-code AI instruments (or used as such) like Lovable, Bolt and (somehow) Cursor across different disposable projects in recent months. To be clear: I'm not discussing the intentional use of AI as collaborative tools. These excel as programming partners for discussing ideas and pair programming, particularly in domains where I already have expertise (which helps avoid hallucinations), or for generating boilerplate code and templates.

The real problems emerge when we venture into what Andrej Karpathy has dubbed vibe-coding, whatever that actually means beyond surrendering control after a few iterations.

On LinkedIn I've witnessed product managers, hobbyists, and non-technical folks having a grand old time cranking out their fantastic MVPs, right until they notice their free credits have evaporated or their credit cards maxed out. Suddenly they're faced with mountains of generated garbage they're technically incapable of fixing themselves. And the machine can't fix it either.

They've reached what I call the AI Foot-Shooting Point. That special moment when the LLM has created so many stacked layers of absolutely useless, interdependent code that it's impossible for even the most advanced models to navigate the spaghettification of the digital mess they've created.

Don't get me wrong, it's fantastic that this new way of prototyping exists. I'm actually happy if software engineers at their jobs stop doing this themselves and getting stressed during that first phase of experimentation, leaving the fast iteration bootstrap process to someone else instead. But don’t forget that, especially at this stage, this stuff is absolute garbage under the hood, it is what it is: a prototype. That's why your iterations stop working at some point and you need to call in some experts to rewrite everything for you. Don't forget to pay them enough to clean up that mess.

Case Study

I’ve tested this myself in a few projects, I’ll describe here one as an example. I set out to build something deliberately simple: a fair-compensation salary matching SaaS service, using a very common stack (NextJS/Supabase/Vercel/Postgres/Stripe) - technologies with abundant resources and documentation online.

I used the most powerful models available. For the first 10-15 iterations, everything went remarkably smoothly with minimal interventions. Even here, though, I noticed the interventions I did make would have been exceptionally difficult, if not impossible, for a non-technical person without spending hours figuring out what to do. Tasks like migrating a database schema, managing data types and formats, and other "simple" problems that would baffle a novice.

Then things started breaking down on seemingly trivial tasks. For example, I wanted a form field to display only when the user role was "Company" and not "Candidate". The request was straightforward. In the simplest case, without touching any backend logic, it could have just hidden the textarea on the frontend based on the role stored in the session.

But no. The same AI capable of state-of-the-art complex Math struggled on such a simple task, and with each attempted fix, something else broke. Eventually, I gave up and investigated it myself. What I discovered was a development horror story: tons of dead code left for no apparent reason. Even the best models fine-tuned specifically for complex coding displayed a massive bias and competence toward addition rather than deletion, cleanup, and refactoring. Why?

Refactor Inability: Motorcycle Gloves for Playing Guitar

This additive bias likely stems from how code appears in training data. Most publicly available code represents the "state of the art" for that particular code snippet or repository, not the iterative process that led there. The models may occasionally train on diffs containing exemplar refactors, but they miss the context of why those refactors happened.

Real software development isn't linear. Sometimes you duplicate code to ship a feature, then apply DRY principles later. Sometimes you complicate things to meet a deadline, then apply KISS to simplify when you have breathing room. Sometimes it's August, everyone's on vacation, and you finally have time for that massive refactor where you apply all your knowledge, intentions, and creativity to sculpt the codebase like an artist.

AI simply can't do this (yet?), and it's painfully obvious. The models excel at leetcode-style problems and can provide fantastic snippets for bounded, well-defined tasks. In those moments, you can genuinely feel them channeling the best of human knowledge and creativity.

But as complexity grows, they deteriorate dramatically, caught in a positive feedback loop where they compound their own mistakes without recognition. They lack hesitation or shame in layering garbage solutions to appease you while you rush to build yet another IMDb & AI-powered Movies recommendation tool that nobody asked for (and that probably Netflix already does better as part of their paid service).

So What?

AI tools could excel at scaffolding projects and generating boilerplate, but struggle with production essentials like proper complexity management, error handling, security, and optimization when things are done at a slightly larger scale than MVP or single feature without human intervention. Despite making developers more productive, the gap between hype and reality remains stark.

The industry suggests AI will replace engineers imminently, but at the moment it can't reliably implement basic features without breaking others. Production software requires extensive testing, edge case handling, and architectural decisions that demand domain expertise AI lacks.

Until we see significant, infrastructurally stable software built primarily by AI, I remain skeptical of the most ambitious claims.

So here we are in 2025, surrounded by evangelists preaching the gospel of our imminent obsolescence while their billion-dollar companies still employ armies of human developers to build anything that actually works.

The revolution is perpetually one parameter update away, I'll keep watching the hype train barrel forward on VC fuel while the rest of us quietly fix the AI-generated spaghetti code left behind.

“Fatta la legge, trovato l'inganno”
Italian saying for “Made the law, found the loophole”

Let me tell you about the time a tech lead I know increased their deployment frequency by 300% in a single quarter. Management was thrilled. Investors were impressed. A promotion followed swiftly.

The secret? Needless to say: breaking every feature into microscopic pull requests, each deploying separately. One-line changes became heroic deployment statistics. The actual value delivered? Roughly the same, if not less, considering the overhead. But the metrics? Oh, the metrics looked beautiful.

If your organization has jumped on the "measure developer productivity" bandwagon blindly, congratulations! You've been handed a game to play.

PR Count & Commit Frequency

"Best/Senior engineers correlate with higher commit/PR counts" the prophet said.

Do they, though? The best engineers many of us have met spend most of their time:

• Mentoring and pairing with juniors and other colleagues through complex problems

• Researching solutions that won't explode in production

• Writing documentation no one reads until 2AM during an incident

• Reviewing PRs to prevent the next generation of tech debt

None of these activities generate the amount of PRs or commits your leadership want to see. But fine, if you want commits:

1. Never rebase-squash them

2. Make multiple small formatting changes

3. Break logical changes into separate commits

4. Commit every time you take a coffee break

5. Write unnecessary comments, then remove them in separate commits

Deployment Frequency

Want to look like a deployment hero?

1. Split features into nano-deployments

2. Deploy the same code with minor tweaks

3. Create a script that makes trivial changes and auto-deploys them

4. Plan to break monoliths into microservices, it’ll inflate deployment stats

PR Review Depth

I’ve seen this the first time on LinearB. Supposedly measuring how thoroughly reviews are conducted by tracking comments or time spent. Some organizations desperate to improve code quality have embraced this absurdity with open arms. So:

1. Add nitpicky comments about spacing and variable names

2. Ask unnecessary questions you already know the answers to

3. Break reviews into multiple sessions to inflate time-tracking stats

4. Schedule review meetings that could have been comments, then do both

5. The altruistic move: Write deliberately questionable code in your own PRs so colleagues have to leave more comments

Velocity Points

Meant to help with planning, it quickly devolves into the most gameable metric in agile development.

1. Gradually inflate point values for similar tasks quarter by quarter

2. Deliberately underestimate in the first few sprints, then "improve" dramatically

3. Hide complex work inside deceptively simple tickets

4. Split one 8-point ticket into eight 1-point subtasks (bonus: deployment frequency improves too!)

5. Negotiate aggressively during estimation meetings to lower points, then overdeliver

6. Master move: Create an "estimation recalibration" meeting every few months to reset baselines when your inflation becomes too obvious

MTTR (Mean Time To Restore/Recovery)

Having incidents? Time to play:

1. Declare incidents "resolved" the moment service is partially restored

2. Apply bandage fixes to stop the bleeding, mark as resolved, then reopen as a "new" incident when it inevitably breaks again

3. Redefine what constitutes an "incident" mid-quarter

4. Simply don't log minor incidents at all

(On a more serious note: Rethinking MTTR)

CFR (Change Failure Rate)

Management wants this number low, but actually improving it would require thoughtful processes and investment in infrastructure. Who has time for that?

1. Deploy trivial changes to inflate your total deployment count (denominator magic!) especially after a period with higher CFR

2. Roll multiple risky changes into one deployment – one failure for the price of five!

3. The senior play: Introduce a "pre-production validation" stage where failures happen but aren't tracked

The Deeper Problem

The fundamental flaw in developer metrics is context. Context is not just missing; it's actively avoided because it complicates the neat narrative of "numbers go up = good."

"But we need metrics to improve!"

Fair enough. If you're starting from a terrible place, measuring can help. The problem emerges when you reach a good state. What then?

Let's say your DORA metrics all reach "elite" status. What happens next? Do you keep optimizing deployment frequency until you're deploying every millisecond? Do you reduce MTTR to negative values, somehow fixing issues before they occur?

There's a natural ceiling to these metrics, and once you approach it, the only way to "improve" is to game them. And engineers, being the optimization-obsessed creatures we are, can't help but fixate on improving these numbers, especially when they're directly tied to promotions and performance reviews.

It's like using a speedometer as a target rather than a measurement. "I must drive faster each quarter to show improvement!" No, it is an operational indicator, not a goal in itself.

Alternatives have been proposed. The SPACE framework, DX Core 4™ (yes: ™, think about it for a second), and others attempt to address these issues by measuring the entire development chain with multiple factors like satisfaction and wellbeing. But if management remains obsessed with improvements on action metrics, those metrics will be incorporated too, and we've come full circle.

The Inevitable Innovation Slowdown

Here's another inconvenient truth: Sometimes improving requires getting worse first.

Implementing a new architecture? Expect every metric to tank temporarily. Refactoring a critical system? Your velocity will drop. Training the team on new practices? Productivity will suffer before it improves.

But if leadership is obsessively watching those metrics dashboards, they'll panic at the first sign of numbers trending down. Innovation requires patience that quarterly metric reviews don't allow.

I'm not suggesting we abandon any metrics entirely. I'm suggesting we recognize them for what they are: imperfect proxies that provide hints, not definitive judgments of value creation.

Some humble suggestions:

• Use metrics as conversation starters, not conversation enders

• Recognize that context matters more than absolute numbers

• Accept that experts value often shows up in other people's or business metrics indirectly

• Understand that not everything valuable can be measured

• Be suspicious when metrics improve too quickly

Or you could ignore all this and continue the metrics game. After all, you now have a playbook to win it.

If you liked this post, consider subscribing to receive new posts, or sharing it on Hacker News.

Salvatore Sanfilippo, creator of Redis, came out with a YouTube video called "I work alone", where, to use his own words, he talks about: "I'm a bad person and I experience software development as a solitary experience. But this approach has many advantages, which I defend in this video".

Most companies sell product software or services that are just spreadsheets on steroids. This is fine, as everyone seems to benefit from them: founders, executives, employees, customers, and the economy in general.

This is true in many other fields. There are millions of variants of biscuits; many staple foods are even produced by the same white-label companies and sold by different firms with different packaging and advertising as completely different products. We don't buy or use things just to satisfy basic needs - there's status, boredom, and many other reasons.

This dual nature of software, as both a commercial product and a form of creative expression, creates an inevitable tension, especially in talented people. While most business software is indeed a product for consumption, there exists another realm where code transcends mere utility.
This is where software becomes art, where each algorithm, function, design decision, architectural detail, brings the distinct signature of its creator.

But this pursuit of software craftsmanship often leads to a peculiar kind of loneliness. When you've tasted the freedom of creating something truly yours, something that reflects your unique vision and technical aesthetics, it becomes harder to find satisfaction in the conventional corporate approach to software development.

Take Redis, for example. While it's now a crucial piece of infrastructure used by countless companies, it began as Salvatore's personal vision of what his creation should be. Its elegance and simplicity weren't designed by committee - they emerged from one person's deep understanding and artistic sensibility.

This is the paradox many passionate software engineers face. The deep qualities that make us somehow good at our craft, our attention to detail, our desire for elegance, our need for creative control, can make us difficult teammates in traditional corporate environments. If you've ever considered yourself an artist of software, even once, you may have felt the struggle of working in an industry where code is merely a means to an end. Needless to say, AI (in its brainless copilot-version usage, more on this topic will come soon) accelerates this disconnection, where the <Tab> key has become the most pressed one on the keyboard. Fire and forget - even less of this production chain is yours, containing mostly your manual labor. Intellectual and artistic abilities are slowly shifting to other areas, where different skills and capabilities are needed - often politics, communication, stakeholder management, and the ability to navigate complex organizational dynamics take precedence over technical craftsmanship and creative vision.

The loneliness comes not from being alone - many of us work in teams - but from the emotional distance between how we see our craft and how it's typically practiced in industry. When you've experienced the joy of building something that's truly yours, something that reflects your technical taste and creative vision, it's hard to go back to building solely through the stifling mechanisms of corporate workplaces.

Yet, as Salvatore suggests, there could be a middle path. Even within corporate constraints, we can get some space for personal expression. We can take ownership of specific components or modules, infusing them with our creative vision while still serving the larger business goals. I remain quite cynical about this point, but I admit (as I found them in the past) there are places where this is possible, operating either outside of or even in compliance with market necessities.

Anyway, I personally think that the most innovative software projects start as personal endeavors, driven by individual vision rather than market research or committee decisions. Like any art form, the most compelling software often comes from a place of personal passion and singular vision, even if that makes the journey a bit lonelier. I keep telling people who are passionate about software to cultivate their personal projects, where they can truly express their creative instincts without constraints. You'll probably never get rich or famous, and these projects might not even be particularly useful to others. But they serve as your playground and sanctuary for true mastery and experimentation, where the purity of software craftsmanship still exists.

As expressed by Salvatore in his closure:

I encourage you, even in a corporate environment, to sometimes take on a project that's completely your own.

Tell your boss, tell your colleagues: “Don't worry about this stuff, I'll handle it, I'll take care of it. Get the fuck out, and let me do things how I want to do them. I'll do them better than if we had ten people deciding because I'll be in love with that project. It will mean something to me because it's an expression of my project-oriented, engineering, creative, and inspirational spirit”.

Give it a try, it's beautiful to work this way. But be careful, because if you get carried away with this approach, it will be difficult to return to the absurd, boring, illogical normalcy of projects done by committee while everyone yawns and nobody really cares.

I also want to include here the original, verbatim, version for my Italian audience.

Vi invito a volte anche in ambito aziendale a fare un progetto che sia completamente vostro.

Ditelo al vostro capo, ditelo ai vostri colleghi: “Non vi preoccupate di sta roba qua, ci penso io, me la vedo io. Toglietevi dai coglioni e faccio le cose come voglio fare io. Le farò meglio di come le avrei fatte se decidiamo in dieci perché sarò innamorato di quel progetto. Conterà qualcosa per me perché è un'emanazione del mio spirito progettuale, ingegneristico, creativo, di ispirazione”.

Provateci, è bello fare così. Poi però attenzione che se vi fate prendere la mano da questo sistema sarà difficile ritornare nella normalità assurda, noiosa, illogica del progetto fatto a tavolino mentre tutti sbadigliano e non gliene frega niente a nessuno.

If you liked this post, consider subscribing to receive new posts, or sharing it on Hacker News.

I've spent the last few years working with various metrics, including DORA, and particularly with MTTR. Here stands a first layer of confusion as it can be meant as Mean Time To Recovery/Restore/Resolve, and sometimes even Respond, but we'll stick to the widely accepted one: Recovery, meaning: impacted users are, in one way or another, interacting with the system again successfully.

While these metrics are usually adopted as business KPIs, I believe we need to reconsider their role and keep them as operational metrics only.

Here's my thought.

A Statistical Significance Problem

MTTR's statistical significance is remarkably low. When we look at incident data, we often see a non-normal distribution of recovery times. Some incidents take minutes to resolve, while others might take days, independently of their impact and severity. Moreover, most companies, especially small and medium-sized businesses, don't experience enough incidents to achieve statistical significance in their measurements. And if they do have a high volume of incidents, that itself should be their primary concern rather than optimizing their MTTR.

Also, not all incidents are created equal. Usually, MTTR treats all incidents the same way: a one-day minor incident affecting a single user carries the same weight as a one-hour major outage affecting millions of users. This leads to misleading metrics that don't reflect the real impact on our services.

This wide variance and apple-to-oranges comparison makes it difficult to draw meaningful conclusions from the mean value alone.

The Real-World Disconnection

As mentioned, MTTR isn’t usually implemented in companies considering incident severity and impact. A quick recovery from a minor issue improves your MTTR more than a well-handled major incident that naturally takes longer to resolve. This creates perverse incentives where teams might be tempted to categorize incidents as multiple smaller issues rather than one larger one.

Also, the quality of the remediation isn’t taken into consideration. Recovery, intended as Mitigation so that users journey are completed again on the systems, is just part of the equation. It could be considered acceptable to mitigate the availability sacrificing latency, but is it for days? Or weeks? The benefit of proper recovery, or better, the fixing the root cause is not included in the MTTR.

The Actionability Problem

Here's a crucial question: If your MTTR goes up, what specific actions should you take? There's no clear answer beyond "investigate the context". Similarly, if MTTR goes down, does it necessarily mean your service is more reliable? Not really. This lack of clear actionability makes it problematic as a target metric.

Consider a scenario where your team has gotten remarkably good at applying quick fixes to recurring issues. Your MTTR looks stellar on paper – dropping from hours to minutes – but you're masking a more insidious problem: architectural flaws that keep causing the same failures. You're optimizing for speed of repair rather than addressing root causes, essentially rewarding firefighting over fire prevention.

The metric can also create perverse incentives. Teams might rush through fixes to maintain a low MTTR, potentially introducing new vulnerabilities or technical debt in the process. Or worse, they might start classifying incidents differently. Breaking up what should be one large incident into several smaller ones, or prematurely marking issues as resolved only to see them resurface hours later. The metric becomes a game to be played rather than a true measure of service reliability.

Even more troubling is how MTTR obscures the customer impact dimension. A five-minute outage affecting your entire user base could be far more damaging than a two-hour incident affecting a small subset of users, yet MTTR treats them identically. This disconnect between metric and business value makes it dangerous to use MTTR as a primary indicator of operational excellence or team performance.

The Google Paradox

Allow me to use this silly but simple paradox: Google, who invented the SRE concept, has been working on incident management for years. If MTTR were a consistently improvable metric (and this is what business usually looks for), Google's MTTR should be near zero by now. But it isn't, because new features, systems, and complexity constantly introduce new types of incidents, as is normal, so why put pressure on the entire engineering department for something that is non-gaussian distributed, non-continuously improvable by nature, and that is not actionable?

If we still want to keep these metrics, just leave them as just another indicator for the authorized personnel.

The Business Metrics Trap (and a proposal)

I won't go deep into this large and widely discussed topic around why using DORA metrics as business indicators on the quality of Engineering creates problematic incentives, but it's clear that when promotions or OKRs depend, for example, on MTTR, teams might: split larger incidents into smaller ones, rush recoveries without proper root cause analysis, manipulate incident definitions to improve metrics, and so on.

Instead of fixating on MTTR, we should focus on:

• Service Level Objectives (SLOs) that directly measure User Experience and especially User Journeys. Spoiler: It's more difficult, requires more time and shared effort beyond Engineering to negotiate what's important.

• Reliability metrics that matter to specific services, prioritized by the Pareto principle.

• Service availability measurements and engineers’ perceived stability (more on this soon).

These metrics provide more actionable insights and better align with business goals.

Measuring Success in a different way

We can better measure reliability improvements using different approaches, such as frameworks that are already adopted by business like the Kirkpatrick model.

We could, for example, every quarter or semester:

• Survey incident managers and on-call people about perceived reliability trends.

• Gather detailed feedback about specific services and pain points.

• Convert qualitative feedback into quantifiable metrics to track trends across categories that align with our systems and needs.

• Track these metrics over time to demonstrate improvements and take targeted actions in context.

To conclude, while MTTR and other DORA metrics (may) have their merits as operational indicators, their elevation to business KPIs deserves reconsideration. The non-normal distribution of recovery times, the lack of severity weighting, and the potential for creating misaligned incentives suggest we need a more nuanced approach.

Instead, organizations would benefit from focusing on comprehensive SLOs that genuinely reflect user journeys, developing context-specific reliability metrics, and implementing qualitative feedback systems like quarterly surveys of incident responders.

By shifting our focus from abstract, potentially gameable metrics to meaningful measurements that capture real service reliability and user impact, we can foster genuine improvements in our systems. The path forward lies in understanding that reliability isn't just about recovery speed, it's about building resilient systems, making informed decisions based on service-specific needs, and maintaining a holistic view of system health that considers both quantitative and qualitative indicators.

Resources:

• Kent Beck on developer productivity

  • …and the answer of Abi Noda

• Reddit discussion

• Interesting discussion on MTTR, CFR and SLOs

In these cases, you can't just wing it. There are a few concepts to reconsider in a new light and a dedicated playbook to follow step-by-step.

1. Values are Trends

One of the most pervasive myths in the corporate world is the notion of company values. Don’t be scared, these are supposed to be guiding principles, but the reality is they are just superficial declarations to fill the "Who We Are" page of your company's website and every job description published on LinkedIn.

They're shaped according to current trends rather than genuine convictions, as with anything else, it’s the market that demands it. A few companies in the industry try to adopt unique or authentic values, but honestly, that is a waste of time and doesn’t pay you back. Why bother striving for originality when conformity seems to be the path for survival?

Consider the evolution of workplace values over the decades:

1970s/80s: Casual dress codes and lip service to women's rights, though women were predominantly relegated to lower-tier positions within companies. The rise of open-plan offices symbolized a supposed commitment to collaboration.

1990s: In times of economic uncertainty, corporate communication emphasized job security, loyalty, and the illusion of upward mobility within the organization.

2000s/2010s: The emergence of the startup culture brought incredible perks such as ping-pong tables, on-site massages, gourmet meals, and trendy office spaces, all in the name of fostering collaboration and open communication.

2020s: The pandemic prompted a collective reckoning with personal wellbeing and a sort of social awakening. Concepts like remote and hybrid work arrangements gained prominence, alongside a newfound emphasis on diversity, equity, and inclusion. There's no need to really commit; just need to green/pink/whatever-washing.

These are mere marketing tactics, and you have to start adopting them. It's all about going through the motions. Hold a token DEI session during the quarterly All-Hands meeting. Toss in a work-from-home day to show off your "hybrid" work model. And of course, don't forget to swap out the company logo for a rainbow version every June. You know the drill, it's part of the playbook.

2. Bother them

This might seem quite vague, but the concept is actually very simple. Workers should never feel calm and safe at work. You always need to give them small daily shocks, disturbances, and unpleasant inputs. You have to set a higher bar for stress and anxiety in the workplace.

Let me give you a few examples to help you understand what I am talking about:

• Invite employees to a mostly pointless face-to-face meeting, giving them one or two weeks' notice. Needless to say, the shorter the notice and the longer the journey (e.g. another country or continent), the better. Occasionally, it's necessary to disrupt their personal lives for a few days, causing issues for their families. This is an ideal way to filter out individualists and keep as many workaholics as possible. Over time, they will increasingly focus on the only thing left in their lives: their job.

• Every decision must be prepared with an anxiety hype. There is no need to simply announce to people what you have decided. It’s much better to follow what every AAA game studio and film company has been doing during the last few years, for example:

  • Announce in a public channel or by email that something important is going to change.

  • Schedule a meeting titled with “IMPORTANT” with no further details in the description, or just something allusive but also ambiguous.

  • Don’t answer any questions about what’s happening, and don’t give any details to the lower levels. They have a closer relationship with workers, and there is the risk they might reveal something.

• Waste some of their time. Create dedicated daily/weekly meetings for each core service, project, process, even better if managed by a TPM/PM/APM who controls and leads every single decision, implementing a proper micromanagement.

• Set strategic and recurring meetings at annoying hours. These are very important to eliminate any sense of flexibility they might have. A standup at 8:30-9 AM to disrupt the school run of a parent, or preventing commuters from getting a slightly later train to avoid peak hours. Scheduling a recurring retrospective meeting at lunchtime or 5:30 PM are also great ideas.

• The default setting for the company calendar should be kept as private. Employees should not be aware in advance of what management is discussing, or even that a meeting is taking place and who is participating. As a bonus, occasionally invite an employee to an ongoing meeting, with a vaguely plausible reason.

• Only discuss planning and important matters at the highest level possible. At most, you should reach out to their team lead, staff engineer, or engineering manager, depending on your organizational structure.

3. Transparency

Speaking of values, transparency has never been a thing so far. Unfortunately, as we said, the current trend puts some emphasis on it. Your role is to provide some sort of transparency on business facts and demand the same from employees. Of course, you just need to pretend on your side. The purpose is to preserve in your staff the bare minimum sense of trust, especially when you can’t completely control them in an office as it was before.

A few concrete actions:

• Hold sporadic town hall meetings where superficial issues are discussed, but real concerns are brushed aside or ignored. The most important thing is to give them the impression that decisions have been made between the last and the current session, after gaining their feedback.

• Share only convenient news (positive or negative, depending on the period) or partial information while concealing critical details on current developments.

• Organize events where executives make brief appearances or give scripted speeches without engaging in meaningful dialogue or addressing employee questions. Be sure that if there is a Q&A session, to open the Slido/Dory/Mentimeter as close as possible to the meeting and not leave it open during the meeting itself, so there is enough time to prepare the blowing smoke answers. Needless to say, disable the possibility for anonymous questions. If too many complaints arise (it will happen), just make sure to have VPs/Directors conduct similar sub-org meetings where Q&A is live, allowing them to show a smaller audience the humanity of the company. Divide et impera is key to handling uprising.

• Establish ethics hotlines for reporting misconduct, mobbing, overtime work, and harassment, put HR in front of employees, and let them play with the brick wall. Sometimes this is also required by local laws, so you have to do it anyway.

4. Engineering

This topic needs a separate chapter. Software engineers tend to be anarchic, often individualistic, and it’s difficult to impose nonsense and incoherence on them. You hired them precisely for that reason.

Your engineering culture has also been shaped by the ingress filter you established in your selection process. There is a clear trade-off: the smartest engineers are often the most problematic when it comes to making hard decisions, while the more accommodating ones aren’t as performant during stable periods. Even though not always possible, to achieve the best results, you are better off implementing the following measures using the boiling frog technique, letting them adapt to small changes over time.

Reorg: Keep doing reorgs. Something doesn’t work? Reorg. Lack of strategy? Reorg. Don't let engineers get too close to their teammates or too comfortable in their roles and areas of expertise, as they could become bottlenecks or be hard to replace later on. In general, reorganizations offer executives so many benefits that they would need a whole book to cover the subject.

Feedback illusion: Occasionally, make them feel like their feedback is valued by pretending to listen to their ideas. Carry out engineering surveys now and then, and hold unproductive skip-level meetings every six months to maintain the illusion.

Ownership: Shared ownership could be a headache for management. From your perspective, it might work for some low-maintenance tasks, but for new developments and cutting-edge projects, ownership should lie with the aforementioned *PM. It's much better to have control over a small group of puppets, rather than empowering your teams and allowing them to plan and design their own projects. Engineers often complain about quality, but that's not really something we should prioritize. The business must be profitable, and engineering just needs to serve its purpose being standardized enough so that we can replace workers if needed. As a side note, Java/.NET/React, and any industry-standard language or framework, perfectly serve this exact objective.

Gradually shift back to a blameful culture: Blameless culture stepped in a few years ago. It was so easy to identify a specific person for an incident. Now things have gotten more complicated. There must be a process that identifies a root cause, and then there are some actions to take. Engineers love that. But at the higher levels, you don’t.
People need to assign human responsibility. For many law systems, fault is individual, and even when an automatic process is involved, down the line one or more physical individuals have to pay in some form or another. We can’t accept that an algorithm or an AI model killed a person driving a car, and the same is here.
There is no need to remove their beloved blameless processes, just attach the final ownership of a product or service to a single person so that they will have full responsibility, whatever happens.

Embrace Silos: In recent years, "silo" has almost become a swearword, along with "technical debt." The reality is that silos can be beneficial from a management perspective. They allow for better identification of who is working on what, and reduce the possibility of leaks of corporate secrets. Segregation is key. IT team is your best ally here, just go and request separate and granular access for repositories, services, and contributions. Communication channels in Slack/Discord/Teams should be kept private, there's no need for people to pry into others' conversations. Knowledge sharing is something engineers love to talk about, but they simply want to stick their noses into others’ affairs in the name of collaboration.

Entropy is the natural direction of the universe, and sabotaging culture is certainly easier than creating it, but a proper work still requires some dedication.

Culture eats strategy for breakfast.

“Decisions went from being made for the benefit of users, to the benefit of the company, to the benefit of whoever was making the decision.”

If you liked this post, consider subscribing to receive new posts, or sharing it on Hacker News.

A crucial factor in this process is complexity management, and we understand that it is not always feasible to eliminate it entirely. Sometimes, it is inherent in the domain we operate in, or it arises from real-world scenarios. Additionally, in many 'fast-paced' work environments, those who contribute (directly or indirectly) to the design of a system are often rewarded for short-term choices rather than for long-term sustainability.

Unavoidable complexity

Eliminating any other source of avoidable (although with some associated cost and trade-off) complexity, let's assume you find yourself confronted with an inherently complex scenario, and you are tasked with deciding how to address it. A common situation arises when developing a library or module responsible for sending requests over the network. Due to its intrinsic nature, instability may occur, necessitating the implementation of a retry logic.

In poorly written software, this is often managed by either incorporating the logic into the module but exposing certain non-optional configuration parameters (such as timeout seconds, the number of retries, backoff strategy...) to handle it, or in the worst-case scenario, it is entirely delegated to the module's users.

As we mentioned, the primary objective is to consistently simplify the experience for users (i.e., other developers, end-users, sysadmins) when constructing modules. When developing, the focus is on maintaining a straightforward interface for common scenarios, ensuring that users can solve their problems without delving into intricate technical details. While it may be tempting for module developers to address easy issues and pass on the tougher ones — perhaps by throwing exceptions, introducing numerous configuration parameters, or overloading the API to shift responsibility of the software's runtime behavior — the core principle remains centered on user-friendly functionality.

What is important to understand is that the short-term approach is even detrimental for us since changing our interface (through exceptions or function/API/config parameters) ties our hands if we want to improve things in the future, forcing us to introduce breaking changes that we could have avoided. This is an additional cost, as we often need to support many versions simultaneously. This cost was hidden at the time of our poor decision, and now it’s coming back to hit us in the face.

Pulling complexity up or down?

With all of this in mind, it is pretty clear that it is often better to pull complexity downward, but it should always be framed in the wider realm of minimizing the overall system complexity. As Ousterhout points out in the book, pulling complexity down is most valuable when:

• The complexity being pulled down is closely related to the class’ existing functionality (e.g. retry-timeout loops in a client hiding API calls).

• Pulling the complexity down will result in simplifications elsewhere in the application (the retry-loop is handled in a single place and reused everywhere in the module).

• Pulling the complexity down simplifies the class’ interface (for the most cases, if not all, there’s no need to expose our users to the network instability management details).

Reasonable defaults

In conclusion, if there is something to take with you, it’s the question: "Will your users (or any upper-level module) be able to determine a better value than we can determine here?" Often the answer is no, and providing reasonable defaults or, better yet, a self-discovering mechanism to set these parameters (think about TCP congestion control) is the way to go to keep things simple (for them) at our cost for sure, but for long-term sustainability.

This represents the signatures of the five basic I/O UNIX system calls:

And this was the old/classic way in Java to open a file and read it into serialized objects:

You don't have to be a C expert or a Java expert. Obviously, we are not even comparing the same thing, but are you able to notice something in terms of abstraction?

On one hand, we have the simplicity (some would say the beauty) of the UNIX interface, concealing incredibly complicated abstractions and underlying behaviors. Just think about the many different scenarios this interface allows to be used in. On the other hand, we can see a somewhat cumbersome surfacing of lower-level details. In Java, a FileInputStream lacks buffered I/O and serialization support, requiring explicit use of BufferedInputStream and ObjectInputStream to address these limitations. This explicit need is dictated by the unfortunately chosen default behavior, not well-balanced in this interface design.

Software design is a complex process, and managing this complexity is crucial for creating maintainable and scalable systems. In his book "A Philosophy of Software Design," John Ousterhout explores the concept of deep vs shallow modules, shedding light on a fundamental principle in software design.

Modular Design

The cornerstone of Ousterhout's philosophy is modular design, where a software system is decomposed into modules, each serving a specific function. These modules, whether classes, subsystems, or services, aim to be relatively independent. While the ideal of complete independence is unattainable due to necessary interactions between modules, the goal is to minimize dependencies, allowing for easier maintenance and modification.

To manage dependencies effectively, we have to understand the role of interfaces, including formal and informal elements. Formal elements, explicitly specified in the code, include method signatures and class attributes, as obvious. Informal elements, usually described through comments or documentation in general, encompass high-level behaviors and usage constraints. A well-defined interface helps developers understand what is essential for utilizing a module, mitigating the "unknown unknowns" problem.

Abstractions play a key role in modular programming, providing simplified views of entities by omitting unimportant details. In the context of modules, the interface serves as an abstraction, presenting a streamlined perspective of the module's functionality while hiding implementation intricacies. Ousterhout emphasizes the need to discern what details are truly important to avoid both unnecessary complexity and obscurity.

Deep vs Shallow Modules

Deep Modules: “Less is better and hide complexity”

The concept of deep modules encapsulates the idea that the best modules offer powerful functionality with simple interfaces. Visualizing modules as rectangles, the area represents functionality, and the top edge signifies interface complexity. Deep modules provide substantial benefits with minimal costs, as their interfaces hide internal complexities. Examples such as the Unix I/O interface or garbage collectors (where the interface is mostly zero) showcase the effectiveness of deep modules in providing powerful abstractions.

Shallow Modules: “More is better and expose complexity”

Conversely, shallow modules have relatively complex interfaces compared to the functionality they provide.
Sometimes, we end up with shallow modules due to laziness in the design process, simply accepting requests for new features and adding them on top of what we have, instead of thinking ahead (see Tactical vs Strategic Developer) about how to prepare our software to accept changes. When the time arrives, we should pause and consider the best way to incorporate these changes. You may even discover that the best course of action is to not add them at all, or that the initial thought you had was merely a shortcut rather than a wise design decision.
Sometimes, the system is already designed in such a way that keeping the abstraction simple becomes too complicated or expensive. Once again, we may have overlooked something in the design process so far, and in the worst-case scenario, we should at least try to mitigate the problem instead of relying on the fact that anyway we are already working on something broken.
In general, while occasionally unavoidable, shallow modules contribute less to managing complexity and lead us into a vicious cycle that incrementally worsens the quality of our system and interfaces.

Classitis

Many of us have heard something like, “A class should be at most X lines of code” or “A method/function longer than Y lines of code must be split into multiple methods/functions”. This is sometimes blindly taken to the extreme without considering the specific case or, even worse, without considering the damage brought at the interface level. Think about jumping around in a codebase, navigating from a small function to a small function, only called from one or two points in the code and exposing an obscure subset of parameters, clearly part of a higher business logic. You clearly feel lost. Does this sound familiar?

Ousterhout refers to this phenomenon as “classitis”, the tendency to promote numerous small classes, overlooking the risks of verbose code, escalating complexity, and shallow interfaces.

Conclusion

In conclusion, when designing a module, a system, an API, a service, a library, or a function, don’t just rely on principles that sound cool on paper. Ask yourself what the real outcome of your decision and design is. It could be something small, like adding a parameter to a function or exposing a seemingly insignificant implementation detail to the user of your interface. Designing deep classes and dividing your module interface from its implementation hides complexity, allowing users to interact with a simplified abstraction that prioritizes common use cases.

The Divide

Tactical Developers

Tactical developers are often focused on the immediate tasks at hand. They are adept at solving specific problems quickly and efficiently (often in terms of their time). These developers excels or just focus in coding and implementing features, demonstrating proficiency in the tactical aspects of software development. Their skills lie in writing code, fixing bugs, and ensuring that the software functions as intended at a first glance.

However, the drawback of a purely tactical approach is the potential for shortsightedness. Tactical developers may prioritize quick fixes over long-term sustainability, leading to a codebase that becomes increasingly complex and difficult to maintain over time.

Strategic Developers

On the other hand, strategic developers take a more holistic view of software design. They are concerned not only with the current problem but also with how their solutions fit into the broader context of the entire system. Strategic developers focus on creating a maintainable, scalable, and adaptable architecture.

Ousterhout emphasizes the importance of strategic thinking in software design. Strategic developers invest time in designing abstractions, creating modular and reusable components, and considering the long-term implications of their decisions. While this approach may take more time upfront, it pays off in terms of the system's ability to evolve and adapt to changing requirements.

The flaws of the “modern approach”

In the evolution of modern software development practices, the emphasis on metrics such as velocity, inspired by frameworks like DORA, has been both a bless and a pitfall for companies.

While the intention behind adopting these metrics is often to streamline processes, reduce friction, and enhance overall efficiency, a common trap arises when organizations prioritize numerical outcomes over the qualitative experiences of their engineering teams.

In an environment driven by a relentless pursuit of faster pull request production and higher velocity, there is a risk of inadvertently fostering a culture that incentivizes individualistic behaviors and shortcuts. This can result in a focus on meeting numerical targets at the expense of thoughtful and sustainable software development practices. Striking a balance between quantitative metrics and a qualitative understanding of engineers' experiences is crucial to nurturing a healthy and sustainable software development culture. Companies should recognize the importance of creating an environment that values collaboration, innovation, and the long-term well-being of their development teams, rather than solely fixating on numerical indicators.

This focus on fast feature delivery and hitting numerical targets (un)intentionally allows a build-up of unavoidable (and accepted) technical debt, shortcutting on hasty decisions making the codebase harder to maintain.

Instead of addressing the root problem, some companies accept this as a normal part of the process. They try to manage the consequences without realizing that their development principles might be flawed. A classical example of this is Facebook/Meta, which shifted from "Move fast and break things" to "Move fast with stable infrastructure" recognizing at some point that their initial approach, while promoting innovation, was increasingly causing problems and accumulating technical debt brought to unmaintainable and unstable systems.

To break this cycle, probably companies need to rethink their fundamental principles and create a more sustainable and resilient software development culture, accepting that engineers are not working in an assembly line and that software creation is still art and craft.

In conclusion

Optimizing investment in software design is crucial for long-term success. Emphasizing the drawbacks of a large upfront investment (think about the old waterfall method), the suggestion of Ousterhout is to favor a continuous, smaller investment approach, dedicating approximately 10'-20% of total development time. While this may slightly extend project timelines initially, the resulting enhancements in software design become evident within a few months, ultimately accelerating development speed as a consequence and not as a requirement.
Investing in good design is a continual effort that pays off in the long run. Small, consistent investments prevent minor issues from snowballing into major problems. It's essential to adopt a strategic approach consistently and view investment as a present-day necessity, not a future task. Postponing cleanups during a crunch is tempting but risky, as it often leads to a perpetual cycle of delays and a shift toward tactical approaches. The longer design problems linger, the more challenging they become to address.

Tradeoffs

Sometimes I see a dogmatic approach that some people take towards code review, which can be time-consuming and resource-intensive. I think we need to adopt a pragmatic approach that recognises the tradeoffs every company must consider, especially smaller ones, deeply involved in scaling themselves and working iteratively towards their main goals, survive and grow.

By being more flexible in the way code review is conducted, companies can achieve a more efficient and effective process that is tailored to their specific needs and resources. This approach can help to strike a balance between maintaining code quality and productivity, which is critical for companies seeking to grow and succeed in today's competitive market.

In this blog post, we will explore some pragmatic approaches to conducting code reviews and highlight some key takeaways. You can apply just some of them, depending on the repository, system component, pull request, and seniority or code-specific knowledge of the engineer(s) involved.

Ease your life beforehand

Having pre-work done, such as setting up a CI/CD pipeline for testing, linting, formatting, measuring performances is critical in ensuring code quality, reliability, and maintainability. Also, it can be handy to leverage git hooks, where possible, to address a subset of these.

These tools help to automate and streamline the development process by detecting and fixing minor issues, improving code consistency, and reducing the reviewer effort, especially onboarding new engineers in the team that are not familiar with code style and best practices.

A well-designed CI/CD pipeline can catch issues early in the development cycle, enabling developers to address them quickly before they cause significant problems. By using these tools, developers can focus on writing high-quality code that meets business requirements, and reviewers can focus on the important stuff.

The role of submitter

The submitter of the pull request plays a critical role in ensuring the smooth and efficient code review process. To help facilitate this process, teams should provide clear onboarding instructions on what to do before submitting a pull request for peer review.
This can include expectations such as:

• Sounds obvious but, documenting code with inline comments in the trickiest parts, as well as documenting changes in the pull request description (use templates!).

• If there is no process in place for assigning a reviewer, the submitter can reach out to their team lead for guidance. Github can be configured to automatically assign them for you based on the repository.

• Additionally, if the change is significant, it can be helpful to include a diagram. If you are developing or modifying a workflow or a non-trivial algorithm, a flowchart provides an immediate overview to the reviewers. As a side note, it’s a best practice to do this before the change, don’t need to say why.

By following these guidelines, submitters can ensure that their code changes are clearly documented, and reviewers can quickly understand the proposed changes, leading to a more efficient and effective code review process.

Reading, Understanding, and Running Locally

One of the most fundamental aspects of code review is to read and understand the code changes thoroughly. This involves analysing the proposed changes to ensure they align with the project's objectives, adhere to best practices and standards, and are well-documented.

Running the code changes locally can be essential sometimes, as it enables the reviewer to test the functionality and identify any potential issues that may not be immediately evident from a code review. Additionally, it helps to ensure that the code integrates seamlessly with the existing codebase and spotting issues in the development setup such as dependency problems or versions mismatching.

Level of Depth

Code reviews can vary in-depth, depending on the size and impact of the changes. For minor changes (e.g. renaming a local variable in a statically typed language), a brief review may be sufficient, while larger changes may require a more detailed review.

In general, and considering the assumptions above, code reviews should focus on the most critical aspects of the code changes, such as the logic, functionality, and performance. More on this later on.

Reviewers should also ensure that the changes are consistent with the project's style and guidelines whereas they can’t be addressed by a linter. In many languages exist dozens of ways to do the same thing, these is fun for sure, but can (and it does) reduce the overall readability of your codebase. I do really recommend, despite being technical and vertical on Go, the Golang FAQ to have a grasp of what I mean.

Number and “role” of Reviewers

The number of reviewers involved in a code review can vary depending on the project's size, complexity, and team structure. However, having at least two reviewers can provide a balanced approach.
They can play the same role, doing a both generic review, but from time to time I’ve found another approach working better, splitting their focus/time (which are limited) in technical aspects (language gotcha, readability, dev tools etc.) and business logic, especially where it is impacted by the change.

Having a subject matter expert on the project or repository can be particularly helpful in ensuring that the proposed changes align with the project's objectives and are consistent with the existing codebase. In some companies, for the same reason, a language-specific review (conducted by a more expert engineer) is required to achieve a good quality code and at the same time growing the language expertise of the submitter, which will not require this level of review later on.

Conclusion

In conclusion, conducting code reviews is an essential part of our engineering life, and of software development, it needs to be conducted with a pragmatic approach and considering the tradeoffs and specificity of our pull request, codebase, team and company objectives.

Teams should automated as much as possible from the beginning, in order to alleviate the burden of long and consequently weak reviews. Therefore, by prioritising the core logic, reviewers can work towards improving the overall team in both general aspects such as language, code style, and skills, as well as specific aspects such as the codebase, business logic, and team knowledge.