Why Writing Better Code Stops Getting You Promoted
At some point in your developer career, writing better code stops getting you promoted.
Not because it is unimportant.
Because it is no longer the bottleneck.
There is a predictable inflection point where the system you are optimizing for changes, but nobody explicitly tells you. Up to that point, the path is straightforward:
Learn a language
Build things
Debug faster
Ship more
Effort maps cleanly to output. Output maps cleanly to recognition.
Then the curve bends.
You are writing better code than ever, but it matters less. Promotions slow down. Scope stalls. Feedback becomes vague.
You are not underperforming.
You are optimizing the wrong variable.
This is the career canyon.
Before the Canyon: Execution Compounds
Early in your career, execution is the dominant lever.
You are evaluated on:
Speed of implementation
Familiarity with tools
Reliability of delivery
The feedback loop is tight:
Write → test → fix → improve
Progress is visible and measurable. If you get better at execution, you move forward.
This is why early growth feels linear.
Execution scales early.
Real Example: John Carmack
Carmack’s early work at id Software was defined by execution excellence:
Writing highly optimized rendering engines
Pushing real time graphics forward
But his long term impact did not come from writing more code than everyone else. It came from choosing the right problems, like real time 3D rendering, and building primitives others could build on.
That is the beginning of leverage.
The Canyon: When Execution Stops Scaling
At some point, continuing to optimize execution yields diminishing returns.
So developers double down:
More frameworks
Cleaner abstractions
Micro optimizations
These are still good practices. They are just no longer decisive.
The constraint has moved.
From:
Can you build this?
To:
Should this exist, and does your solution create leverage beyond you?
The game changes from solving problems to choosing them.
Real Example: Dan Abramov
Abramov did not become influential by shipping more features than other engineers.
He:
Identified confusing mental models in frontend development
Helped shape how developers think about state and UI with Redux and React Hooks
Explained tradeoffs clearly through writing
His leverage came from clarifying problems and making decisions legible.
Why It Feels Broken: Signal Loss
Before the canyon, feedback is concrete:
Bugs fixed
PRs merged
Features shipped
After the canyon, feedback becomes abstract:
Shows ownership
Thinks strategically
Has impact
These are weak signals. They are hard to measure and harder to improve against.
So many developers respond the only way they know how:
Improve execution.
But the issue is not capability.
It is misaligned optimization.
You are still playing the early career game.
The Core Shift: From Output to Leverage
On the other side of the canyon, value is defined by decision quality and amplification.
From:
- Writing code
To:
- Making decisions that shape outcomes at scale
Concretely:
From solving tasks to defining problems
From implementing systems to deciding which systems should exist
From individual output to multiplied impact
Decision making scales. Output does not.
Real Example: Charity Majors
Majors did not just build another monitoring tool.
She reframed the problem:
Observability is not dashboards
It is the ability to explore unknown system states
That shift changed how teams debug production systems.
That is leverage. Changing how others think and act.
The Hidden Gap: Making Thinking Visible
As you grow, your work becomes less tangible:
Tradeoffs
Architecture decisions
Long term bets
These do not automatically get recognized.
If you cannot articulate them, they do not compound.
Real Example: Julia Evans
Evans built influence not by shipping more production systems, but by:
Explaining complex topics like Linux internals and networking
Turning tacit knowledge into clear, visual explanations
Her leverage comes from clarity.
If people cannot see how you think, they cannot trust you with bigger decisions.
Crossing the Canyon: Changing How You Operate
1. Start with problems, not solutions
Execution focused thinking asks:
How do I build this?
High leverage thinking asks:
Why does this problem exist?
What happens if we ignore it?
What is the simplest version that works?
Real Example: Sophie Alpert
Alpert focused on whether systems actually changed user behavior, not just whether they were implemented correctly.
That is problem first thinking.
2. Think in systems, not components
Local optimizations do not scale.
Zoom out:
Where are the real bottlenecks?
What breaks under growth?
What are the second order effects?
Real Example: Colm MacCárthaigh
MacCárthaigh’s work on AWS infrastructure focused on:
Reliability at scale
Tradeoffs between cost, latency, and resilience
That impact is system level, not component level.
3. Make your thinking legible
Your ideas do not scale if they stay in your head.
You need:
Design docs
Clear tradeoffs
Written reasoning
This is not a soft skill.
It is how decisions spread.
4. Rewrite your narrative
Most developers describe their work as tasks:
Built feature X using Y
Higher level evaluation looks for:
Problems identified
Decisions made
Tradeoffs accepted
Outcomes achieved
Example:
Implemented caching layer
Becomes:
Reduced API latency by 60 percent by introducing caching, accepting eventual consistency for non critical data
How you describe your work changes how it is valued.
A Different Growth Curve
Crossing the canyon does not feel like progress.
You might:
Write less code
Move slower
Feel less certain
That is expected.
You are trading speed of execution for scope of impact.
The developers who make it across:
Choose better problems
Make better decisions
Make those decisions understandable to others
Career Resources That Actually Help
If you want to cross the canyon faster, you do not need more effort.
You need better inputs and feedback loops around decision making.
Systems Thinking and Real Engineering
These help you understand how real systems behave and break.
Senior Level Thinking and Decision Making
These shift how you think about leverage and tradeoffs.
Making Your Work Legible
Most developers don’t struggle with impact.
They struggle with making that impact visible, understandable, and reusable.
This is where better tools can give you real leverage not because they are popular, but because they shape how you think and communicate.
Logseq
For networked thinking and decision logs that evolve over time. Its graph structure makes it easier to connect ideas, tradeoffs, and outcomes across projects instead of storing isolated notes.TaTanana
Built for structuring complex thinking. It lets you turn raw notes into structured systems, which is exactly what design decisions and architectural reasoning need.Mermaid
Lets you embed diagrams directly in docs and PRs using code. This keeps your system thinking versioned, reviewable, and close to the implementation.Linear
Not just for tasks. When used well, it becomes a place to document decisions, scope tradeoffs, and why something exists in the first place.
And one tool specifically for translating execution into impact: AI resume builder.
Used correctly, it forces you to:
Turn tasks into outcomes
Clarify tradeoffs
Express your work in terms of impact
That is the exact skill gap most developers have at this stage.
The Takeaway
The career canyon is not about becoming a better coder.
It is about becoming someone who:
Chooses the right problems
Makes high quality decisions
Makes those decisions visible and understandable
If you feel stuck right now, it might not be because you are not good enough.
It might be because you are still playing the early career game.
Once you see the shift, you stop optimizing for the wrong thing.
And that is when progress starts again.