Hands, heads and hearts: from coding to caring

"Ship it"

Imagine Nadia, a few months into her first job, and Marek, who reviews her pull requests.

The codebase is C#. A pragmatic, mid-sized system that calculates discounts for orders.

Nadia was asked to add a new rule - a seasonal discount that stacks with loyalty points, but only under certain conditions.

She wrote it. Tested it. It worked.

public static decimal ApplySeasonalDiscount(decimal total, int loyaltyPoints, bool isSeasonActive)
{
    if (!isSeasonActive) return total;

    var discount = loyaltyPoints > 100 ? 0.15m : 0.10m;

    return total - (total * discount);
}

Nadia shipped it.

The code was clean, the tests were meaningful, the rounding was correct to the cent.

By any craft standard, this was good work.

She even noticed the duplication with the other discount methods - a genuinely good catch.

But she asked, got waved off, and moved on to the next ticket.

"Why does it work this way?"

Two years later.

Nadia is no longer new. She has shipped dozens of features, fixed her share of production incidents, and by now she has opinions.

A new request lands - a fifth discount type, this time combinable with two others under specific business rules that nobody wrote down anywhere.

Notice what changed.

Nadia was no longer asking "does this compile, do the tests pass" - she was asking "is this the right shape for the problem, and what will it cost us later if it isn't".

She doubted the given approach.

She proposed an alternative, defended it, and accepted that it needed a conversation before any code got written.

She was reasoning about structure, not just output.

Notice what she did not ask.

She did not ask whether a fifth discount type made business sense, or whether pricing should be this configurable in the first place.

She trusted that someone above her had already answered that, and stayed entirely inside the solution space - given that this needs to be built, what is the right way to build it.

That boundary matters. She was designing. She was not yet questioning why there was anything to design at all.

"Would you bet your money on this?"

Another few years pass.

Same title. Same desk, more or less. Nadia is still an engineer on the same team, and Marek is still the lead who reviews her work.

Nobody promoted her into caring about what happens next. A new initiative arrives from above - a loyalty tier system with five levels, gamified badges, and a leaderboard.

Nadia had no more authority in this room than she had in the first scene. (well, she probably earned something through that time - do you know what it is, dear Reader?)

Nobody made her responsible for the roadmap. Nobody had to.

She questioned whether the request was the right one anyway, brought evidence anyway, and committed to building whatever got decided anyway - properly, without sulking about being overruled.

She cared whether the company's money and the customer's time were spent well - not just whether her part of the system was elegant, and not because a title told her to.

She cared about understanding Marek's point of view and his words - his mental model.

Hand(s), Head(s), Heart(s)

Three scenes.

Same person.

Different capability each time.

The first scene - a clean, well-tested discount rule, a good catch on duplication that got waved off - was Hand(s).

The second - doubting the given approach, proposing a real model instead of a sixth near-identical method - was Head(s).

The third - questioning whether the leaderboard deserved the quarter at all, and putting her name on that answer - was Heart(s).

You probably suspected as much while reading them.

That's the point - the labels were never the interesting part. What Nadia actually communicated was.

How could we explain each lens, in slightly reductionist terms?

Notice something about those three definitions, dear Reader.

You can point at Hand(s) - it's the diff. You can point at Head(s) - it's the sketch on the board, the alternative that got argued for in the meeting nobody wanted to sit through.

Heart(s) leaves no artifact of its own. It never shows up in the pull request, and no reviewer can approve it into existence.

It's the one ingredient in this whole potion that never makes it onto the label - and the only one that decides whether what you built was worth drinking.

Together, they're the lenses you compose, one on top of another: Hand(s), Head(s), Heart(s).

Unlike TEA, this is not a spectrum you move across depending on the situation.

It's a set of lenses, composed together - not swapped one for another.

Marek could not have asked Nadia for a design opinion in her first week, because she had nothing yet to doubt with.

She had to first know what "correct" looked like, with her hands, before she could sense that something was structurally wrong.

And she had to be trusted with structure, with Head(s), before her opinion on "should we build this at all" carried any weight in the room - no title required either time, just enough demonstrated judgment for people to want to hear it.

Hand(s) are necessary, not sufficient

Let's be fair to Hand(s), dear Reader.

Nobody gets to skip it.

A designer who cannot write the C# that expresses their own idea is not designing - they're speculating, and someone else pays for the gap between the speculation and reality.

A person with a strong opinion about ownership who cannot ship a working feature is not exercising Heart(s) - they're just having opinions, which is a much cheaper thing to do.

Nadia's clean rounding logic, her fifteen test scenarios, her instinct to notice duplication - none of that stopped mattering once she reached Head(s) and Heart(s).

It became the foundation everything else stands on.

The hidden cost of staying at Hand(s)

Here is what should worry you, dear Reader, if you have ever taken pride in shipping fast, and stopped there.

For a while, it works. It works remarkably well, even.

Tickets close. Velocity charts go up and to the right. Someone calls you "reliable".

Nobody tells us that reliability, at the Hand(s) level, is measured by how faithfully you execute someone else's understanding of the problem - not by whether that understanding was any good.

You are not asked "should we build this" because you have not yet earned the standing to be asked, and you have not yet practiced having an opinion worth defending.

Nadia noticed the duplication in her first scene and got told "not today".

That's not a failure of hers - that's simply what Hand(s) sounds like from the outside.

Competent, correct, and not yet invited into the room where the shape of the problem gets decided.

The codebase does not punish you for staying at Hand(s) immediately.

It punishes whoever is still there in three years, still confident that well-written code and passing tests were the whole job.

That's the dark side of staying at Hand(s) too long, dear Reader - not incompetence, but a comfortable kind of invisibility. You get very good at not being asked, and eventually you stop noticing that you've stopped being asked.

Head(s) without Heart(s)

The second failure mode is a bit more subtle, and in some ways more comfortable, which makes it more dangerous.

You've grown into Head(s). You doubt, you architect, you see the abstraction three moves ahead. People bring you problems because you're good at reshaping them.

And somewhere along the way, it stops mattering to you whether the thing gets built at all, or whether it was worth building.

You optimize the design of features you don't believe in.

You elegantly implement a leaderboard nobody asked for, because the elegance itself became the reward, detached from whether the customer's actual problem

This is the architect who can defend any decision technically and cannot tell you why the business or consumers should care.

Nadia in her second scene was already close to this - a genuinely better design, argued well, for a ticket she had not yet questioned the existence of.

It took another round or rounds, and a willingness to say "I don't think this deserves our quarter", to close that gap.

That's the dark side of staying at Head(s) too long - skill without meaning.

The trade-offs get sharper. The diagrams get cleaner.

Nobody asks anymore whether any of it was worth doing - least of all the person best equipped to ask.

Heart(s) - investment or cost?

The third scene cost Nadia something the first two did not.

The comfort of just doing what was asked. The safety of being able to say later "I only built what I was told to, it's not my call".

She traded that comfort for visible disagreement - for going on record against a decision that had already been made above her, with no title obligating her to try and no guarantee anyone would listen.

This is why so few people arrive at Heart(s) (and why organizations often prefer they don't?).

A room full of Hand(s) and Head(s) executes predictably.

Probably with the decent quality (whatever it means to you, dear Reader).

A room with Heart(s) in it argues, questions the premise, sometimes says no - and is, over any long enough horizon, the only kind of room that reliably builds things worth having built.

They argue, because they care.

Care about what?

About other people - whether they are customers or their colleagues.

Because nothing great (and valuable) was built when all agreed.

Extreme Programming was never a set of technical rituals adopted for their own sake - pairing, collective ownership, sustainable pace, whole-team responsibility for the outcome are what Heart(s), practiced daily, actually looks like from the outside.

You cannot mandate caring with a policy document.

Heart(s) requires mutual trust, and mutual is the part organizations skip in favor of procedures, control and governance.

What came first, dear Reader - the governance, or the lack of trust it was quietly built to compensate for?

Nadia had to trust that "I'd rather we spend the quarter on checkout" wouldn't cost her the next uncomfortable conversation she needed to have. Marek had to trust that her pushback was an honest read of the data, not insubordination wearing a lanyard. Remove either half of that trust and the exact same words curdle into either silence or noise.

You can only build the conditions where people who've already grown through Hand(s) and Head(s) are trusted enough to start caring out loud - and where that trust is returned, not just extended.

Quite too idealistic, isn't it?

Maybe.

Heart(s) has a dark side too, and it shows up when someone stays there without ever going back down to do the work.

Caring out loud is cheap once it stops costing you anything.

Opinions about every decision. Delivered from the sidelines. By someone who hasn't shipped a feature or sketched a design in years.

That still sounds like Heart(s).

It's trust, spent on volume, long after it stopped being earned.

Everyone in the room can tell the difference. Nobody says it out loud.

Where does the LLM fit in this?

I bet, you knew this question was coming, dear Reader.

Here is the uncomfortable part: an LLM is remarkably good at Hand(s).

Give it a clear specification (by the way, dear Reader, what is a "clear specification"? How do you know it's "clear" - clear to whom, and clear until which surprise arrives?), a language, a test - and it will produce something that compiles, sometimes something well-designed, occasionally something you'd have written yourself given enough coffee.

As explored in LLMs, 3D printers and amplifiers - it works as an amplifier of whoever is directing it, not as a replacement for the judgment doing the directing.

An amplifier has no opinion about whether the song is worth playing.

It plays whatever signal it is fed, louder.

There's a reason the fit is this good, and it isn't flattering to how the profession has treated Hand(s).

Stripped of Head(s) and Heart(s), Hand(s) was always a mercenary way of working.

Grunt labor, however well-crafted.

Take the specification. Produce the artifact. Move to the next ticket.

No opinion required. Frequently none welcome.

It was already transactional - and transactional work is exactly what a model trained on transactions reproduces well.

Head(s) asks for something it cannot manufacture on demand.

Reasoning about optionality. About the structure - elements, interactions and purpose - an architecture should have. About which trade-off costs less in eighteen months.

It can list you three options when asked.

It cannot sit with the discomfort of not yet knowing which one is right.

It has no stake in being wrong about it.

Heart(s) sits further out still.

It isn't really a technical faculty to begin with - it's a humane, social one.

Whether a leaderboard deserves a quarter of a real team's time is not a question about code.

It's a question about people - what a company owes the customer in front of it, versus what it owes its own comfort.

And people doesn't stop at the customer. It includes the teammate who inherits whatever gets decided here.

"What do you have in mind?"

"What does it mean to you?"

"What is it important to you?"

Ask them of a customer. Ask them of a colleague. The question doesn't change - only who's answering it does.

It's by, with, and for people, all the way down.

A model has no colleagues to let down. No customer to fail. No finite quarter of its own working life to spend on the wrong bet.

It cannot care, in any sense worth the word.

Caring requires something to lose.

Which means the era in which "I write well-crafted code quickly" was, on its own, a durable professional identity is quietly closing - not because writing it well stopped mattering, but because the scarce part of that sentence was never the typing.

But Heart(s) does not get to skip looking at what Hand(s) produced.

Someone still has to read the diff.

It makes no difference whether the Hand(s) that typed it were biological or virtual - a person's, or a model's, prompted by that same person.

If Hand(s), purely as execution speed, is now something you can rent by the token, then the only thing left that was ever actually yours is the Head(s) that decided what to build, and the Heart(s) that decided whether it deserved to exist (and how you are communicating with other human beings).

That should not read as a threat, dear Reader, though I understand if it does.

"Typing was never the bottleneck", some might boldly say so.

Even if it was not the bottleneck, building understanding through fast feedback loops was.

Learning is a real bottleneck.

Knowledge acquisition is a real bottleneck too.

Insights and conceptual framing are bottlenecks as well.

Typing might and often helps with that.

Why?

Typing is thinking.

It was simply the most visible part of the job, and the easiest one to reward.

We tricked ourselves, stakeholders included, into thinking that coding, Hand(s), was the entirety of the work.

There's more to it than that, we just need to escape the matrix.

Composing, not switching

In TEA, where you consciously move between Telling, Explaining and Aligning depending on what a given conversation needs, Hand(s), Head(s) and Heart(s) don't offer you that choice in the same way.

You do not wake up and decide to "do some Heart(s) today" the way you might decide to explain something more carefully.

You add a lens, and mostly, you don't remove the ones beneath it - you keep looking through every lens you've already installed, every day, for the rest of your career.

Nadia at the Heart(s) level still writes C# on a Tuesday when the team needs her to - through the Hand(s) lens, same as always.

She still doubts a design on a Wednesday - through Head(s).

The difference is that she no longer sees through either lens alone. Heart(s) sits on top now, and everything below it gets seen through it too.

"What are you doing?"

You've heard some version of this one already, dear Reader.

Three stonemasons, same building site, same question put to each of them: "What are you doing?"

The first says: "I'm laying bricks."

The second says: "I'm building a wall."

The third says: "I'm building a cathedral."

Same bricks. Same mortar. Same hands.

Really same?

"The level is in the eyes of the beholder."

The first looks through Hand(s) - one brick set correctly after another, according to the pattern he was handed. (sometimes without care and understanding, unfortunately)

The second looks through Head(s) - the brick matters because of the wall, the load it carries, the plan it has to satisfy. (sometimes without seeing the bigger picture, unfortunately)

The third looks through Heart(s) - the wall matters because of the cathedral, and the cathedral matters because of who will stand inside it, long after his own name is forgotten.

None of the three is lying.

None of them is wrong, exactly.

Same as with this well-known motivational tale about stonemasons,Hand(s), Head(s) and Heart(s) are here to communicate something more profound over a simple metaphor.

Metaphors are imperfect, but they can help us see the world in new ways.

Looking for logical holes and inconsistencies in metaphors can be a useful exercise, but it's not the primary goal.

Be free with your interpretations.

Be free with your tempo.

Be free.

Play with that.

Let yourself flow with the uncharted sensations that are true vessels of understanding.

Understanding of thyself.

Understanding of the world around you.

Starting small

You don't need a promotion to start installing the next lens.

It starts with a single question the next time you're handed a ticket.

Or more general, questioning.

The gap between Hand(s) and the lenses stacked above it is not talent, dear Reader.

It is curiosity.

It is hard work.

It is slowing down.

It is saying "I don't know".

It is mostly the accumulated habit of not being asked, and therefore never practicing the answer.