RCJ
The Scholar
I understand it before I touch it.
Who you are
You'd rather understand a system than add to it. Before you change a line, you trace how the whole thing fits: across files, across services, across the people who built it. Other engineers come to you when they need to know how something actually works, because you're the one who took the time to find out.
Where you shine
System thinking. Agents see the context window; you see the whole board. You catch the failure that hides between two services because you carry the map in your head, and the map took years to build. When everyone else is guessing, you're the one who already read the code and knows.
Your blind spot
You can study past the moment you needed to act. Kernighan's Law says debugging is twice as hard as writing, and you've internalised it so deeply you sometimes refuse to move until the picture is perfect. But the picture is never perfect, and the ship leaves while you're still reading. Understanding is a tool, not a destination.
In the AI age
You're sitting on the scarce skill. When agents write the code, the value moves to whoever can make sense of what got built, and that's reading, the thing you love. The trap is going deeper when you should go wider: the agent will happily generate ten systems for you to understand, and you can't read them all at the same depth. Pick where your understanding actually has to be perfect.
Your move
Time-box the reading. Decide up front how deep you need to go, then act before the picture is complete. Aim your understanding at the critical path; let the agent run where a rough mental model is enough.
How you're wired
Affinity. You love reading code.
Autonomy. You move slow and on purpose.
Trust. You trust your own mind.
Plays well with
Clashes with
Your shadow
The type wired opposite to yours — every instinct flipped.
The Sprinter WAB compare →“Cheaper code means more code — and I keep it on the rails.”
Developers who share your type
- Brian Kernighan Wrote the book on writing it clearly — and on understanding it before you change it.
- Fred Brooks Held all of OS/360 in his head, then warned you about the parts you can't see.
Debugging is twice as hard as writing the code in the first place.
Your ideal AI workflow
Point the agent at a slice you've already mapped, and read its output the way you'd read a colleague's PR: for intent, not syntax. Let it draft the parts you understand well enough to judge fast, and reserve your deep reading for the one path where being wrong is expensive. Your review is the loop — make it the fast part, not the bottleneck.
Who to pair with
Pair with a builder who'll act on the map you draw — an RCB or SCB turns your understanding into shipped code while you keep the picture honest. You'll grind against the WAJ and SAJ who move before they've read; the fix isn't to slow them down, it's to be the one who tells them which corner of the system actually warrants the caution.
Where you'll struggle on a team
Because you trust your own read over the team's tests, you can become the bottleneck nobody routes around. Work waits on your understanding even when a rough answer would've shipped fine. The team feels it as 'ask RCJ and wait.' Name the calls that genuinely need you, and hand the rest a default of 'good enough.'
What to stop doing
- Reading the whole system when you only needed to understand one path.
- Refusing to act until the picture is perfect — it never is.
- Treating an agent's output as something to fully re-derive instead of review.
Wear it
Put your type in your GitHub README:
[](https://whatkindof.dev/type/rcj)