jchigg ~ dev

The Work Looks Like Nothing

2026-06-01T00:00:00Z

The Work Looks Like Nothing

The top of the IC ladder is well traveled and still unmapped. Pattern recognition fails there. Even frontier models cannot reliably do it.

No two of these people have the same story. They are very often deeply technical. Many can break through political theater without raising their voice. Most can talk upward or downward depending on the audience. They can be innovators and creative geniuses while being your best defense against an irreversible mistake. Some are wired this way. Some learned to be. Both work.

They are hard to find, and the usual explanation is that the work is invisible - that judgment leaves no trace, that it cannot be measured, that you take it on faith and hope your interview was good enough to catch it. That overstates it. Plenty of the work shows up, and we are not paid badly for it. But roughly half of the judgment never reaches the balance sheet, and that unpriced half was never intrinsically unseeable. It was a property of how that half used to travel. That property has come apart, and once it does, the invisibility becomes optional. The strange part is who ends up holding the switch.

A Measurement Problem, Not a Psychology One

Start with the half that never gets a price.

Avoided waste is structurally invisible. A vendor trap that does not close. A migration that gets scoped down before it becomes a decade-long burden. A platform purchase the room walks back from before the check is written. None of these show up neatly in a retrospective. The decision that prevented them may have happened in a forty-minute meeting and produced no deliverable beyond a different direction.

The organization pays a fair salary for the seat, and the salary quietly covers two different things: the work that produced a commit, and the work that produced an absence. Only the first half has a SKU. The second does not always become a ticket. It does not always produce a dashboard. It is the absence itself - of rework, escalation, outage, remediation, regret - and an absence is easy to consume without ever pricing it.

To the person doing it, the work feels like noticing things. Pattern recognition does not feel like labor. That is the structural form of impostor syndrome. It is not only a psychology problem. It is a measurement problem that gets internalized. If no system records the work, eventually some part of me starts to wonder whether the work happened at all.

Why the Trail Disappeared

Judgment still cannot be measured. That part does not change, and I am not trying to change it. You cannot put a number on the decision not to build something. But measuring was never the only way to make the work real. The work could always have been seen. It just had nowhere to be seen.

Here is the mechanism. For most of a career at this level, the way to make judgment matter at scale is to stop typing and start influencing. Staying on the keyboard actually degrades your value, because the keyboard is a bottleneck. If you can influence other engineers, your worth compounds - through "do this" and "not this," through the mistake talked out of the room, through the design that quietly gets a second pass. It does not feel like working while you do it. The day you are most useful is often the day you typed the least, and some part of you files that as a day you got away with something. That feeling is not modesty. It is the absence of a record, felt from the inside.

But influence that travels through people is exactly what erased the trail. A human hears "not this," executes a drifting, lossy version of it, and ships something downstream. By the time the contribution lands it has been laundered - rephrased, re-attributed, softened, absorbed into someone else's commit. The judgment was real. The record of it was deniable. That is not a tragedy of recognition. It is a transmission artifact. The work was invisible because it propagated through a medium that does not preserve fingerprints.

The Mirror

The medium changed.

An executor that follows my instructions as well as I can define them and does not drift unless I cause the drift. The laundering step is gone. What comes out the other end is not a colleague's interpretation of my judgment. It is my judgment, run forward. The output is the mirror.

And the session that produced it is a record of how I reason, not just what I shipped. A git history shows the destination. The session shows the deliberation - what I checked before I touched anything, how I cut the problem apart, what I refused to do and why. That record of cognition did not exist in any work artifact before. It does now, as a byproduct of doing the work at all.

So I can say something that used to be unsayable. The log preserves judgment. I can look at a person's Claude Code logs and know exactly how they go about reasoning about a build. The work is visible. The judgment is visible.

I want to be precise about what I read for, because it is not what people assume. I read for reasoning, not output quality. The quality of the output is irrelevant in my frame - the two can go hand in hand, but they are not the same axis. The log is the truth. The score is a lens I lay over it afterward. A clean result built on lucky guesses reads differently in the trace than a rough result built on sound moves, and it is the moves I am after.

The Bookshelf

For me there is little mystery to where the moves come from. I read the kind of material that tunes pattern recognition toward systems under stress: Perrow on normal accidents. Langewiesche on aviation. Therac-25. Fire command. Mining disasters. When a system meets a force it was never designed to absorb, I want to know what failed first.

Different people in this band carry different substrates. Some come from operations, some from regulation, some from a decade inside a critical legacy system. The substrate is not the point. The point is that there is one - earned, hardened, and not interchangeable with any certification or recent hire's onboarding doc.

And the substrate is not a credential I have to vouch for separately. It is the shape of the reasoning itself. The books I have read let me see the shape of a problem and then build bottom up, safely and quickly, with almost no guardrails, because the guardrails are already in place between my ears. I have a bottom-up cognition, and it is completely visible in my logs. It shows up as the moves I make and the moves I never make. Chat history is downstream of the bookshelf.

Private Telemetry

The shape of the initial build is unflattering when stated plainly: a Python script that mines my own Claude Code session logs into a local SQLite database, runs weekly, and produces a markdown report of what I have actually been working on, how fast I did it, and what I picked up along the way. I did not build it to manufacture evidence. The record is a byproduct. The session is the artifact. The codebase becomes valuable residue.

That distinction matters more than it may seem. A record you sit down to produce on purpose - a design doc written to be pointed at later, a status update composed for an audience - is performance. I was never going to produce that, and not because I could not. Manufacturing the artifact for its own sake is the exact thing this kind of mind refuses, and until now refusing it carried a cost. It does not anymore. This is the opposite of performance. It is the exhaust of the work, captured because the work now leaves exhaust. The part of the job that used to evaporate is the part that now writes itself down.

The same tools that made the record possible also made more of the work possible. A prototype that used to look like nothing now looks close to complete. A weekend project that would not have happened becomes a public OSS repo. The argument made in a meeting still leaves no commit at all. The keyboard used to be the bottleneck. For me, it isn't anymore.

What the Market Cannot See

The market says it wants Principal ICs. What it typically means is that it wants people who can ship, lead without theater, detect failure modes before commitment, document accepted risk, define early warning signals, and keep building artifacts when the official record is too thin to hold the truth.

It pays for the half it can see and takes the other half for free, because that half had no SKU. The log is the SKU it never had. And it filters cleanly in a way a resume never could: performing does not help you in a session trace. You cannot present your way through a log. The trace rewards how you reason, not how you package it. The people who are worst at the performance - who will not craft a resume full of the right nouns, who go quiet in the part of the interview that rewards confidence over correctness - are often the ones whose logs are strongest. That is the match I am trying to make: employers to the engineers who will not destroy their systems and are invisible to the job market precisely because they refuse to perform.

These people are buried inside regulated industries - platform teams, compliance-heavy domains, infrastructure groups, health care, insurance, finance, government, manufacturing. The list goes on. They prevent six-figure remediations in environments where the cost of being right can become invisibility. They are not always easy employees, or easy candidates. They can be allergic to vague authority, performative process, and design choices that ask future humans to absorb present-tense ambiguity.

Which is the whole turn, and it is not irony. The profile most likely to read its own work as "just thinking carefully," most allergic to performing it, most certain it is not worth what it costs - that is the profile resemblance-screening was built to miss. It is also the profile that would rather encode the measurement than sit for the interview. So the instrument that ends the invisibility gets built by the one person the old regime was structured not to see. Not a coincidence. The same wiring does both.

Engineering applied one layer earlier. Done by people the record was never built to see.

They still doubt they are worth what the market would pay them. The doubt is running out of road. The moat does not evaporate on its own - it never has - but it does not hold against the person who builds the switch, and the switch is theirs now.

-- Justin Higgins. Software Engineer, Midwest. Two decades in regulated systems. Built the instrument that finally records what the work was.

Companion piece: The Principal IC Moat - the diagnosis this instrument was built against.

Reactions, disagreements, war stories: jchigg2000.dev@gmail.com

The Principal IC Moat

2026-05-19T00:00:00Z

The Principal IC Moat

The Goal

This started as a simple job search. One I didn't think should last long.

Twenty years as an engineer and architect in a highly regulated enterprise. Much of it as a full-stack developer in an industry allergic to them. Elevated for judgment, but constrained by lack of consistent formal authority. Useful, but underutilized in ways only those who have spent real time inside regulated industries can imagine.

What I didn't know going in: that longevity, that deep understanding of a complex domain, often gets read as disqualifying. Especially from the middle of Kansas.

The Unintended Moat

After a few hundred listings, a pattern emerged.

Companies write Principal IC job descriptions that blend stack requirements, aspirational leadership language, inherited organizational pain, and vague transformation goals until the actual work disappears. They attach titles that mean different things at every company. Then they screen by resume pattern-match against the very title and description they just made up. Dogfooding in reverse?

That isn't a filter for Principal-level judgment. It's a filter for resemblance to one snapshot in an ever-changing industry.

In 2026, a job description may say "Principal Engineer," but the content might look like any of the following:

A hands-on senior engineer who still ships features
A platform strategist expected to set direction
A technical executive without authority
A political consensus-builder
A vendor evaluator
A traveling salesman

What the hiring manager actually wants to buy is judgment. Judgment is hard to specify. So they reach for visible proxies: title, logos, years, stack, scope, artifacts, interview fluency.

That's the moat. Not malicious. Just a consequence of trying to write a spec for something that resists being specified.

The Diagnostic

I quickly realized that one's resume, a document that once needed a bit of polishing now and then, had become a living artifact. A precision instrument whose sole purpose is to evade a gauntlet of overworked humans, their software, their AI assistants, and the inboxes of hiring managers who get 50 more important emails per day.

What goes on a resume is no longer just the list of things you're best at, your expertise and biggest career achievements. Now it could also be anything you've been adjacent to that increases the odds of getting through that arbitrary gate. In the workplace, people attach their names to things they never intend to meaningfully participate in, just to internally rationalize inclusion of a resume bullet point. On the receiving end, this means interviewing people who lack the exact thing you're looking for — sound judgment, decision ownership, and respect among both developers and executives — earned for the right reasons.

Unfortunately, this audition feels like it violates a core belief for some of us. So we "cope" in a few ways. I decided to build a few things.

What I Built

I'm not going to walk through the full implementation. The relevant part is the shape of the problem.

Embeddings alone overweighted vocabulary — they'd rank "Principal Engineer who runs Jira" right next to "Principal Engineer who ships," because the words match. Claude alone could read through the vocabulary on any single listing, but reading isn't ranking. Score a field of candidates one at a time with no shared baseline and the scores drift. Neither approach, on its own, could hold a stable line between resemblance and seniority.

What worked was running them against each other. Three retrieval strategies, same corpus, and the disagreements became the signal.

Embeddings only. MiniLM, vector cosine, no LLM in the loop. Fast, free to run, scales to thousands of listings. Good at "find postings that read like this one." Blind to whether the role is actually senior or just uses senior-sounding words.

Full Claude batch. Every listing and every resume read by Claude with a structured rubric — autonomy, scope, decision authority, hands-on vs. coordinating. Title and seniority language stripped before the model sees it. Expensive. Slow. But it reads through the vocabulary in a way embeddings can't.

Hybrid. Embeddings on the listing side, Claude on the resume side. The asymmetry is the point. Listings are noisy and abundant — you don't need precision on every one, you need a fast filter. Resumes are few and precious. That's where the Claude budget pays off. It's also where the disagreement lives: when the embedding rank and the Claude score diverge on the same candidate against the same listing, the divergence is usually pointing at something real — vocabulary cosplay on one side, hidden judgment on the other.

Written in Go. Runs locally. Every pass versioned so I can rerun any mode against any snapshot.

The other move that mattered: forcing the role categories to emerge from the data instead of projecting them in. Strip seniority and focus language, cluster what's left, and see what the postings actually want.

Across 555 listings, 45 carried the title "Principal Engineer." The model split them: 31 landed in Staff / Principal SWE, 12 in Principal SA, Enterprise. Two didn't cluster at all. The title isn't doing the work. The cluster is.

The clusters that emerged:

Field CTO
Staff / Principal SWE
Staff ML
Staff DevRel
CTO / VP Engineering
Principal SA, Enterprise

Six shapes, hiding behind the same handful of titles. The moat made visible.

Closing

Early on, my own system told me I was a strong fit for Anthropic. Top of the ranked list, across every cut. I was immediately certain that wasn't success. I'd been learning about Claude, MCP, vectors, rerankers, and agents — for weeks. The embedding wasn't measuring fit. It was measuring basic overlap with what I'd recently been talking about.

That moment was more useful than any positive result. It told me what I was actually building: not a search system, a measurement instrument that had to be calibrated against its own biases before it could say anything true.

Of the 555 listings looked at so far, all but one embedded cleanly. The failure: "Member of Technical Staff, Field Eng" — 5,526 chars, over MiniLM's 512-token limit. The canonical IC role was too long to fit in the model.

The unintended consequence of legibility-based hiring is that the people most capable of doing Principal IC work are also among the most likely to detect the incoherence and opt out. They read the description — and all they see is another potential for impossible scope, unclear authority, mismatched title, and generic leadership language.

Some of them route around it, some of them turn their own job hunt into a Go codebase.

-- Justin Higgins. Software Engineer, Midwest. Spent six months job-hunting and built a search engine instead.

Reactions, disagreements, war stories: jchigg2000.dev@gmail.com