What you see is what you're worth
Every career leap I've made came from the same place: seeing something in a system that the people inside it couldn't see.
🧭 Career Navigation · For developers rethinking how they grow
This week’s challenge: pick one system you work with daily (a codebase, a team, a product) and write a one-page assessment of what it tells you about the business. Not the technical state. The business implications.
I’ve been evaluating other companies’ codebases recently. A client sends me a repository, and I produce an assessment: what’s the real state of this technology, what are the risks, and what does it mean for their business.
The interesting part isn’t the technical analysis. Any experienced developer can look at a codebase and spot missing tests, hardcoded credentials, or a monolith that grew beyond control. The part that creates value is translating those findings into language a business owner can act on. “Your deploy pipeline has no automated tests” means nothing to a CEO. “Every time your team ships a feature, they’re gambling that it won’t break something in production, and you have no way of knowing until a customer calls” means everything.
I didn’t build that skill by studying assessment methodologies. I built it by spending twenty years inside systems where the technical problems were always symptoms of business problems that nobody had named yet.
That ability to look at a technical system and see the business underneath it is the single most valuable skill I’ve developed in my career. And almost no developer I’ve met, at any level, deliberately practices it.
The invisible career ladder
Developer careers have a standard progression. Junior, mid, senior, staff, principal. Each rung is defined, implicitly or explicitly, by technical depth. You get promoted because you can handle harder technical problems, mentor other developers, make larger architectural decisions. Above senior, the expectation does shift: soft skills, stakeholder management, and business understanding gradually become part of the job description. The progression isn’t purely technical at every level, and anyone who’s reached staff or principal knows that.
But even where business understanding is expected, it’s treated as a complement to technical depth, not a skill in its own right. The career ladder still assumes technical execution as the foundation, and everything else as something you layer on top once you’ve proven yourself technically. That made sense when technical execution was the bottleneck. When writing the code was the hard part, the people who could write harder code were worth more. The career ladder tracked the scarcity.
That scarcity is dissolving. AI writes increasingly complex code. The technical execution gap between a mid-level developer and a senior developer shrinks every month. If your career growth depends entirely on being better at the thing AI is getting better at faster than you are, the math doesn’t work.
But there’s a parallel ladder that most developers never notice, because nobody names it and no job description lists it. I think of it as the perception ladder: what can you see that others can’t?
A junior developer looks at a codebase and sees files, functions, classes. Syntax. They’re reading the words.
A mid-level developer looks at the same codebase and sees patterns, architectural decisions, technical debt. They’re reading the sentences.
A senior developer looks at it and sees the team’s history: where they rushed, where they were careful, where they changed their minds. They’re reading the story.
The developer who builds a career that lasts looks at the same codebase and sees the business: where it’s headed, where it’s stuck, what the technology is enabling and what it’s preventing. They’re reading the implications.
Each level of perception changes what you can do, which changes what you’re worth. And the jump between them has almost nothing to do with writing better code.
Three systems you should learn to read
The codebase assessment work made me articulate something I’d been doing instinctively for years. Every career opportunity I’ve had came from reading a system (technical, human, or market) and seeing something that the people inside it had stopped noticing.
Reading codebases
When I evaluate a repository, I’m not looking for bugs. I’m looking for patterns of decision-making embedded in the code. A codebase with three different HTTP clients isn’t a technical problem. It’s a signal that the team has no technical leadership, or that leadership changed hands multiple times, or that nobody owns the standards. The real remediation starts with understanding why three coexist, which is a people question dressed up as a technical one.
Hardcoded credentials in a tracked file aren’t just a security issue. They tell you that the team is moving faster than their process can support, which means other corners are being cut too, which means the real risk isn’t the credentials; it’s everything else you haven’t found yet.
I look at test coverage and see hiring strategy. A codebase with zero tests tells me the team either has no one senior enough to enforce testing discipline, or they’re under pressure that makes anything beyond shipping feel like a luxury. Both of those are business problems that will compound.
The technical findings are inputs. The career skill is the interpretation.
Reading teams
The mentoring work I described in Edition #6 taught me the same lesson from the human side. Miguel wanted coding exercises. Alexandre wanted shortcuts. Both were telling me, through what they asked for, something important about where they were and what they needed. But what they asked for and what they needed were different things.
This happens in every team I’ve worked with. A developer who constantly asks for code reviews on trivial changes is usually looking for reassurance about their position on the team, not about the code itself. A team lead who micromanages pull requests has often been burned by a production incident they didn’t catch, and the control is their way of processing it.
Reading a team means looking past what people do and understanding why they do it. The developer who can do this becomes the person others trust, the person who gets called into rooms where decisions happen, the person whose influence extends beyond their technical scope. And none of that shows up on a GitHub profile.
Reading markets
In 2005, I could see that web development was shifting from server-rendered pages to richer client-side experiences. That wasn’t a prediction. The signs were visible to anyone paying attention: broadband adoption, browser capabilities improving, user expectations rising. I invested in learning JavaScript deeply at a time when most backend developers dismissed it as a toy language.
That bet shaped the next decade of my career. Reading the present clearly enough to see where the pressure was building turned out to be more useful than any prediction could have been.
The AI shift follows the same pattern. The developers who are positioning themselves well right now aren’t the ones making bold predictions about what AI will or won’t do. They’re the ones watching closely: which tasks are AI handling reliably today? Which ones require human judgment every time? Where is the boundary moving, and how fast? The answers to those questions change how you invest your learning time, which changes where you end up in two years.
Why this skill is invisible
Developer culture celebrates the visible: commits, contributions, conference talks, blog posts, open-source projects. Career advice for developers focuses almost entirely on building visible artifacts: ship more projects, write more posts, contribute to open source, make your GitHub green.
These things aren’t useless. But they optimize for a signal that’s becoming less scarce (the ability to produce output) while ignoring the one that’s becoming more valuable: the ability to understand context. The gap between those two things is where the real career leverage lives.
The developers I’ve seen grow fastest, the ones who jumped from mid-level to staff in three years instead of eight, had one thing in common: they could walk into a situation and see what was actually going on. The client who says they need a rewrite actually needs better deployment. The product manager who keeps changing requirements hasn’t figured out the business model. The team that’s “slow” isn’t lazy; their architecture forces them to coordinate on every change.
Seeing these things didn’t require exceptional technical talent. It required paying attention to the systems around the code, not just the code itself.
The reason this skill stays invisible is that it doesn’t look like a skill. It looks like intuition, or experience, or “just knowing.” But it’s a practice, and you can start building it deliberately.
How to practice
The perception ladder isn’t something you climb by accumulating years. You climb it by changing what you pay attention to.
Start with the system you know best: your own codebase. Tomorrow, before you write any code, spend fifteen minutes reading it as if you were an outsider. Not debugging, not implementing. Reading. What does the structure of this project tell you about the team that built it? What decisions were made under pressure? What patterns reveal a change in direction? Where is the complexity, and why is it there?
Then extend the same practice to the people around you. In your next meeting, instead of focusing on the content being discussed, watch the dynamics. Who speaks? Who defers? Who gets interrupted? Who gets silence after they talk, the kind of silence that means people are actually thinking about what was said? The answers to these questions tell you more about how decisions actually get made in your organization than any org chart.
Finally, apply it to the market. Every week, read one thing that isn’t about your technology stack. A company’s earnings call summary. A product teardown by someone outside engineering. An industry analysis. You’re not trying to become a business analyst. You’re training the muscle that connects technical reality to business context, which is the muscle that makes your technical judgment valuable beyond the codebase.
None of this will show up on your CV. All of it will show up in every conversation, every decision, every moment where someone needs a developer who understands the bigger picture. And those moments are the ones that move careers.
Try This
The previous editions built a growing library of artifacts: a delegation map, a judgment breakdown, a problem statement, a decision analysis, an evaluation document, a mentoring reflection, a creative project brief. Each one externalized a different kind of thinking.
This week’s artifact is a system reading. Pick one of the three systems from this edition (your codebase, your team, or your market) and write a one-page assessment.
If you choose the codebase: don’t list technical problems. Write down what the code tells you about the business. What does the test coverage suggest about the team’s priorities? What does the architecture reveal about the product’s growth trajectory? What would you tell the CEO if they asked you, honestly, what shape their technology is in?
If you choose the team: write down the three unspoken rules that govern how decisions actually get made. Not the official process. The real one. Who has influence? Where does information flow, and where does it get stuck? What does the team avoid talking about?
If you choose the market: write down what you see changing in the demand for your type of work. Not what the headlines say. What you’re observing firsthand: in job postings, in client conversations, in the projects you’re being asked to work on. Where is the pressure shifting?
One page. Observations, not solutions. The point isn’t to fix anything this week. The point is to practice seeing what’s there, clearly, before jumping to action. That practice, repeated consistently, is what builds the perception that separates developers who grow from developers who stall.
The Deeper Cut
The codebase assessments I’ve been doing revealed something I didn’t expect about my own career. When I look back at every significant move (the health tech company that grew to 80,000 users, the search engine that unlocked thousands of users overnight, the travel tech architecture that processed over a billion dollars) the pattern is the same. I walked into a technical environment and saw a business problem that hadn’t been named. The technical work followed from the naming, and the naming is what created the value.
I used to think this was just experience accumulating passively. What the assessment work showed me is that it can be practiced deliberately. Every codebase I evaluate now sharpens the same skill: translating between what the technology is doing and what the business needs it to do. That translation is the career skill with the highest ceiling and the lowest competition, because almost nobody thinks of it as a skill at all.
Paid subscribers get the system reading template: a structured format for producing the kind of assessment described in this edition, applicable to codebases, teams, or markets. It includes the specific questions I use in client assessments, adapted so you can practice the same analysis on your own work environment.