DEV Community: Micky C

Why Documentation Is a Leadership Act — Not a Chore

Micky C — Tue, 02 Jun 2026 09:00:07 +0000

The Documentation Reframe

Nobody wants to write documentation. It's tedious. It's never up to date. Nobody reads it anyway. So why do the best developers on every team seem to write so much of it?

Because documentation isn't a record. It's a leadership act.

What Documentation Actually Does

The purpose of documentation isn't to record what happened. It's to change what happens next. Good documentation:

Enables a new developer to be productive in half the time
Prevents the same mistake from being made twice by different people
Creates a shared understanding that makes conversations shorter
Builds the institutional memory that lets a team move faster as it grows

These are all leadership effects. Documentation isn't a record of decisions. It's the thing that makes future decisions faster.

The Developer Who Writes Documentation Is Leading

When a developer writes documentation, they're not just helping themselves. They're helping everyone who comes after. They're saying: "I've thought about this so you don't have to figure it out from scratch." That's leadership.

The senior developer who writes good documentation is the developer who is multiplicatively effective. They make everyone around them faster, not just themselves. A team with good documentation can onboard new engineers in weeks instead of months. A team without it stays dependent on the people who were there first.

This is why the best developers write documentation even when nobody asks them to. They understand that the ROI on good documentation is enormous, even if it doesn't show up in any sprint report.

Why AI Documentation Is Flat

AI can generate documentation. It can read your code and produce descriptions of what it does. This is technically documentation. It's also useless as anything except a starting point.

The documentation that makes teams faster isn't "what does this code do?" It's "what decisions were made here, and why?" It's "what should someone changing this code know before they touch it?" It's "what are the failure modes, and what should you do when they happen?"

AI doesn't know why decisions were made. It wasn't in the meeting. It doesn't know what the failure modes are. It hasn't watched a new developer make the mistake that someone carefully documented how to avoid.

The documentation that matters is institutional knowledge, written down. AI can generate facts. It cannot generate understanding of context.

The Leadership Multiplier

The developers who are most effective as they advance are the ones who multiply the effectiveness of everyone around them. Documentation is one of the highest-leverage ways to do that.

Writing documentation well is an act of empathy. It requires imagining the person who will read it, what they'll need to know, and what mistakes they'll be likely to make. That's not a technical skill. It's a human one.

The developer who writes good documentation is the developer who makes their entire team better, including the ones who haven't been hired yet. That's leadership. And it can't be automated.

Part of the AI-Proof Programmer series.

The Debugging Mindset: Why the Best Programmers Are Relentless Investigators

Micky C — Fri, 29 May 2026 09:03:27 +0000

The Debugging Mindset

There are two kinds of programmers in the world: those who when they hit a bug, immediately start changing code and hoping it goes away, and those who stop and ask "what is this bug trying to tell me?"

The second kind have the debugging mindset. It's the most valuable technical skill you can develop. And AI can't develop it for you.

What the Debugging Mindset Actually Is

The debugging mindset is a specific orientation toward problems. It says: this bug is not an inconvenience. It's information. The system is telling you something about itself that you didn't know. Your job is to find out what.

This orientation changes everything about how you approach a problem. Instead of frantically trying things until something works, you methodically eliminate hypotheses. Instead of assuming the bug is in the new code, you assume it's in your assumptions. Instead of fixing the symptom, you find the cause.

This is not a natural way to operate. It requires patience and humility. It requires being willing to say "I don't know" and mean it as the start of an investigation, not an admission of failure.

The Three Questions

Every debugger who operates at a senior level asks the same three questions:

What is the system actually doing? (not what I think it's doing, not what the documentation says it's doing, what it is actually doing right now)
What should it be doing? (how do I know this, can I verify it independently)
What's the gap between those two things, and what's the first step to closing it?

These questions sound simple. They are not simple. Most debugging sessions fail because the developer never correctly answered question 1. They assumed they knew what the system was doing, and the assumption was wrong.

Why AI Debugging Is Limited

AI can look at a stack trace and tell you what went wrong. It can suggest fixes based on patterns it has seen. This is useful. It is not debugging.

Real debugging is understanding why the code took the path it did, and what that reveals about the system. It's asking whether the documentation is wrong, or the test is wrong, or the code is wrong, or the assumption is wrong. It's knowing which of those to check first.

The best debuggers have a model of the system in their head that lets them make educated guesses about where the bug is likely to be. That model comes from having been burned before, from having seen similar systems fail in similar ways, from the accumulated experience of investigation.

AI doesn't have a model of your system. It has a model of systems in general. That model is useful for narrowing down the search space. It is not sufficient for the judgment call about where to look first.

The Skill That Compounds

Debugging is a skill that compounds faster than almost any other technical skill. Every bug you solve correctly teaches you something about the system you're working in. After a year of correct debugging, you know that system. After five years, you know systems like it.

This is the debugging dividend. The senior developer who debugs well isn't just solving today's problem. They're building a mental model that makes tomorrow's problems easier to solve.

The developer who relies on AI to debug for them gets the solution. They don't get the model. And without the model, they'll be dependent on AI for every problem, forever.

Part of the AI-Proof Programmer series.

The Judgment Tax: Why Senior Developers Are Worth More Than Their Code Output

Micky C — Tue, 26 May 2026 09:04:53 +0000

The Output Fallacy

We measure programmers by output. Lines of code. Features shipped. Tickets closed. This is the output fallacy, and it makes us hire for the wrong thing.

A senior developer doesn't write ten times as much code as a junior developer. They write code that is ten times less likely to cause problems, ten times more likely to be extended by the next person, and ten times more likely to be understood by the maintainer five years from now.

Code quality has a half-life. Junior code starts causing problems immediately. Senior code improves with time, because the decisions embedded in it were made with judgment.

What Judgment Actually Looks Like

Judgment is the ability to make good decisions with incomplete information. It shows up in small moments:

A junior developer implements a feature exactly as specified. A senior developer reads the specification and says "this won't work because..." — and they're right, even though they have no more information than anyone else. They just know where to look.

A junior developer hits a bug and tries to fix it with more code. A senior developer hits the same bug and asks "why does this bug exist?" — and the answer reveals a structural problem that would have caused five more bugs if left alone.

A junior developer finishes a task and moves on. A senior developer asks "what are we not seeing?" — and the answer changes the approach entirely.

This is judgment. It's not measurable in tickets closed. It's invaluable in code maintained.

The Judgment Tax

When you hire a senior developer, you're not paying for their code output. You're paying for their judgment on every decision that gets made while they're on the team.

This is the judgment tax. It's the premium you pay for the confidence that decisions are being made well. And it's almost entirely invisible until it's absent.

The teams without senior judgment are the teams where everything is an emergency. Where the codebase is a maze of special cases. Where every new feature requires three rewrites of the old ones. Where developers burn out because they can't keep up with the entropy they've inherited.

The teams with senior judgment are the ones where things are calm. Where features grow naturally. Where the code does what it says and the tests mostly pass and the deploys are boring.

That's not luck. That's judgment tax, paid well.

Why AI Can't Replace Judgment

AI can make decisions when the decision space is well-defined. It can optimize for a metric. It can learn from feedback. What it can't do is know what metric to optimize for.

This is the judgment gap. The senior developer's most valuable contribution isn't the decision itself — it's knowing which decision framework to apply, which constraints to relax, and which trade-off to make when all the options are bad.

Senior judgment is the accumulated experience of seeing systems fail. It's the gut feeling that something is wrong before the metrics show it. It's the ability to say "we're solving the wrong problem" and be right.

None of this can be learned from data. None of it can be replicated by a model trained on someone else's failures.

The Economic Argument

Here's the cold economic version: a senior developer who saves the team from one bad architectural decision has saved more time than a junior developer will produce in an entire year.

The math is simple. One bad decision can add weeks to a project. A senior developer's judgment, applied to five decisions that would have gone wrong, saves more time than they spend in a month.

This is why senior developers are worth more than their code output. The code is the output of their labor. The judgment is the output of their experience. And experience is not fungible.

Part of the AI-Proof Programmer series.

What AI Can't Understand About Your Users — And Why That Matters for Your Career

Micky C — Fri, 22 May 2026 09:03:15 +0000

The User Research Blind Spot

Your AI can write a login form. It can even write a beautiful, accessible, responsive login form with perfect validation and error messages.

What it cannot do is tell you why your users keep forgetting their password on the exact screen you designed.

This is the AI user research blind spot. It's not a gap in capability. It's a category error.

What AI Can and Can't Know About Users

AI learns from data. It can tell you what users did in the past. It cannot tell you why they did it, what they were thinking, or what they wanted but couldn't articulate.

When you watch a user try to complete a task and fail, you see the frustration, the hesitation, the moment they give up and close the tab. That moment is data. It's the most valuable data you can collect. AI wasn't in the room.

The senior developer who understands the user research process — the interviews, the usability tests, the "say out loud" protocol — has access to a category of insight that AI cannot generate.

This is not about the technique. It's about the specific humans you're building for, and what it takes to understand them.

Why User Research Is an AI-Resistant Skill

User research requires:

Being present with another person
Reading their emotional state
Following threads that seem tangential but turn out to be crucial
Recognizing when what someone says and what they mean are different things
Making judgment calls about which feedback to act on and which to contextualize

None of these can be automated. None of them can be delegated to an AI that wasn't in the room.

The developers who are most effective at building the right thing are the ones who have direct, ongoing relationships with the people who use what they build. They know the users. They've watched them struggle. They remember the moment of confusion.

AI can analyze a heatmap. It cannot tell you what that heatmap means in the context of your users' lives.

The Career Implication

The developers who will thrive in an AI-powered world are not the ones who can write more code, faster. They're the ones who can tell the difference between building the right thing and building the thing right.

Building the right thing requires understanding your users. Understanding your users requires being in the room with them.

That's not a technical skill. It's a human skill. And it's exactly what AI can't replicate.

The opportunity isn't to become a better coder. It's to become the person in the room who understands what to build.

Part of the AI-Proof Programmer series.

Stop Learning Frameworks, Start Learning Patterns That Transfer

Micky C — Tue, 19 May 2026 09:03:40 +0000

The Framework Trap

You learned React. Now you're learning Vue. Now Angular is making a comeback. You've spent the last three years learning framework after framework, and you keep ending up at the same place: confused about what actually matters.

This is the framework trap. And it's more dangerous than it looks.

What Frameworks Actually Do

A framework is a set of conventions that helps you build things within a specific set of constraints. React helps you build UIs. Django helps you build web apps. Kafka helps you build data pipelines.

The thing about conventions is that they're arbitrary. The specific way React handles state is not a law of nature. It's a choice made by a team of engineers at Meta, influenced by their specific needs and constraints.

When you learn React, you're learning those specific choices. When the next framework comes along, those choices become liabilities. The hours you spent learning component lifecycle methods? Gone. The time you spent understanding the virtual DOM? Transferred to nobody.

The Patterns Beneath the Frameworks

Real knowledge is framework-agnostic. It transfers. It compounds.

Here's an example: the observer pattern. Once you understand it deeply, React's useEffect dependency array makes immediate sense. Redux's store updates make sense. Vue's reactivity system makes sense. You didn't learn React — you learned a manifestation of a pattern that happens to be implemented in React.

The same is true for:

Dependency injection — understanding it makes Spring make sense, but also Hilt, and the service locator pattern in plain JavaScript
Event-driven architecture — understanding it makes Kafka clicks, but also RabbitMQ, and the Pub/Sub system your team built custom
Optimistic UI — understanding it makes React's pending state patterns make sense, but also the patterns in native mobile apps, and the ones your team rolls by hand
Event sourcing — understanding it makes Kafka the tool you reach for, not the tool you were taught to use

Frameworks come and go. Patterns are forever.

What Good Engineers Actually Know

Ask a senior engineer at a FAANG company how they'd build something, and notice what they reach for: not frameworks. Patterns.

"This is an event-driven problem. We could use a message queue, but honestly, for our scale, a simple in-memory pub/sub might be enough until we hit maybe ten thousand users a day."

"This looks like a CQRS situation. The read model and write model have different access patterns, so we should separate them."

"This is a classic distributed systems problem. We need eventual consistency here, strict consistency there. Let's draw the boundary."

This is not framework knowledge. This is pattern knowledge. And it transfers across every framework you'll ever work with.

How to Learn Patterns, Not Frameworks

The key to learning patterns is to always ask: "what problem does this solve, and is there a better way to solve it in my specific context?"

When you hit a problem that makes you reach for a framework feature, stop. Ask yourself:

What is this feature actually doing?
What pattern is it an implementation of?
Is there a simpler implementation of that pattern that doesn't require the framework?

When you learn a new framework, don't learn the features. Learn what problems each feature solves. Then look for the patterns. Once you see the pattern, the framework becomes a detail.

The developer who understands the observer pattern doesn't need to be taught Vue's reactivity system. They'll figure it out in an afternoon.

The developer who doesn't understand the observer pattern could spend years in Vue and still not understand why Vue behaves the way it does.

The Compound Interest of Pattern Knowledge

Pattern knowledge compounds. The more patterns you understand, the faster you learn new frameworks, because every new framework is just a different implementation of patterns you already know.

The trap of framework knowledge is that it doesn't compound. You learn React, then Vue, then Angular. Three separate piles of knowledge that don't connect to each other.

The senior engineers you admire aren't smarter than you. They've just been at this long enough that they've built a mental library of patterns. When something new comes along, they map it to what they already know. That's what makes them fast.

The investment you make in pattern knowledge today is the investment that pays dividends when the next framework drops and everyone scrambles to learn it. You'll already know the pattern. You'll learn the framework in an afternoon.

Part of the AI-Proof Programmer series.

The Five Conversations Every Programmer Should Master — And Why AI Can't Do Them

Micky C — Fri, 15 May 2026 15:50:14 +0000

Code is 20% of the Job

Most programmers spend about 20% of their time writing code. The other 80% is something else entirely:

Clarifying requirements in planning meetings
Explaining technical decisions to stakeholders
Negotiating scope and trade-offs with product managers
Giving feedback to colleagues

This is not a soft-skills pitch. This is about the conversations that actually determine whether your code ships, whether your features work, and whether your career advances.

AI can write code. It cannot negotiate a deadline.

Conversation 1: Requirements Clarification

The most expensive bug I've ever encountered wasn't a logic error. It was a feature that did exactly what the ticket said, but not what the stakeholder actually needed. It took three weeks to build, two more weeks to realize the mistake, and another week to fix.

The root cause was a requirements conversation that nobody had.

Requirements clarification is a skill. It involves asking questions that surface hidden assumptions, probing the "why" behind stated constraints, and getting specific about edge cases. Senior developers do this naturally. Junior developers often think requirements are just things written in tickets.

AI does not understand requirements. It does not know your company's context. It cannot ask the question that would have prevented three weeks of wasted work.

The developers who get things right the first time are the ones who had the right conversations before writing a line of code.

Conversation 2: Technical Trade-off Communication

Every architectural decision is a trade-off. You're choosing speed of development over flexibility, or simplicity over scalability. The developers who advance fastest are the ones who can articulate these trade-offs clearly — to managers, to other engineers, to stakeholders.

This matters because technical decisions often have business consequences that aren't immediately obvious. A "clean" architecture might take twice as long to build. A "quick" solution might create technical debt that slows down the team for months.

The conversation isn't just about the technical merits. It's about mapping technical reality to business constraints, and doing it in language that non-technical stakeholders can understand and act on.

AI can explain technical concepts. It cannot weigh trade-offs in the context of your specific business, team, and timeline.

Conversation 3: Scope Negotiation

"Why can't we have it all?"

Because scope is a negotiation. Features take time. Time has a cost. Resources are finite. Every "yes" to a feature is implicitly a "no" to something else — usually something implicit.

The developers who are trusted partners in product decisions are the ones who can have honest scope conversations without destroying relationships. They can say "yes, we can do that, but here's what it costs" and help find creative solutions that satisfy the underlying need without killing the timeline.

This is a conversation about priorities, about trust, about understanding what actually matters to the business. AI has no skin in the game.

Conversation 4: Feedback Delivery

The hardest feedback to give is honest feedback that might sting. The hardest feedback to receive is feedback that challenges your assumptions. The developers who get better fastest are the ones who can do both.

Giving feedback well requires reading the other person's emotional state, understanding their context, choosing the right moment, and framing the message so it lands rather than bounces off.

This is not a technical skill. It's not something you can learn from documentation. It's something you learn from actually doing it — and from getting it wrong, and trying again.

AI cannot give feedback that changes behavior. It can generate words that sound like feedback.

Conversation 5: Mentoring Handoffs

The most valuable developers don't just write code. They grow the team around them. This means mentoring junior developers through the moments that define how they think about software.

The handoff conversation is when you explain why a decision was made a certain way, what you considered and rejected, and what the junior developer should watch out for. Done well, this is worth more than any blog post or tutorial.

It's not about the code. It's about the judgment behind the code. And judgment transfer requires human connection.

Why AI Can't Do These

AI processes language. It can generate responses that sound like these conversations. It can even simulate the structure of a good negotiation.

What it cannot do is:

Understand the specific humans involved and what they care about
Read the room before deciding how to frame a difficult conversation
Make the judgment call about which battle to fight and which to let go
Build the trust that makes honest conversations possible

These conversations require you to be present. AI is never present.

Part of the AI-Proof Programmer series.

The AI-Resistant Programmer: Why Soft Skills Matter More Than Code

Micky C — Fri, 15 May 2026 15:44:37 +0000

The World Changed Quietly

In 2023, something strange started happening in programming communities. People who had spent years building their careers around technical excellence began noticing something unexpected: the developers getting promoted weren't always the ones who wrote the best code.

They were the ones who could explain that code to a product manager in plain English. The ones who knew which meetings to show up to and which to skip. The ones who could tell a junior developer why something was done a certain way — and make it click.

This isn't a story about AI replacing programmers. It's a story about what AI makes more valuable.

The Skills That Actually Matter

Ask any senior developer what separates great programmers from competent ones, and you'll rarely hear "writes cleaner code" as the first answer. You'll hear things like:

"They understand the business context"
"They know when to push back on requirements"
"They make everyone around them more effective"
"They can debug by talking to the system, not just staring at logs"

These are soft skills. And soft skills are exactly what AI can't replicate.

Why Soft Skills Are AI-Resistant

AI is trained on patterns. It excels at tasks with clear inputs and outputs, where the "right" answer is verifiable. Soft skills are the opposite — they're ambiguous by nature, context-dependent, and require reading people.

When an AI can reliably tell you that your product manager's actual concern behind that feature request is security theater, not user experience — come back and tell me about AI-resistant skills.

Soft skills matter more in an AI-powered world because:

Communication is coordination. Every hour a developer spends in meetings is an hour they're reducing coordination costs. High coordination costs destroy software organizations. Being the person who makes meetings productive is irreplaceable.

Judgment is scarce. AI can generate options. It can't tell you which option aligns with a three-year-old company's actual strategy when the CEO just changed direction last week. That judgment requires context, relationships, and trust.

Trust is non-negotiable. Senior developers get access to systems, data, and decisions that junior ones don't. Trust is built through relationships, not capability. You can't AI-generate trust.

The Quiet Revolution in What Companies Value

The developers who are thriving right now aren't necessarily the ones with the most LeetCode points or the deepest systems knowledge. They're the ones who can:

Translate between business language and technical constraints
Identify which technical debt actually matters (hint: not all of it)
Mentor juniors without making them feel stupid
Push back on deadlines without killing the relationship
Know when "good enough" is actually good enough

These skills were always important. But in a world where AI handles more and more of the technical work, the differentiator is everything AI can't do.

What This Means For Your Career

The programmers who should be worried aren't the ones who write good code. They're the ones whose only value is writing good code. If your entire value proposition is technical execution, you'll be fine — for now. But "for now" is a dangerous place to build a career.

The people who will thrive are the ones who use AI as a productivity multiplier for their soft skills. Imagine being 10x more effective at the things AI can't do. That's the opportunity.

The AI-Resistant Programmer isn't anti-AI. They're the developer who uses AI to handle everything except the part that actually matters.

Part of the AI-Proof Programmer series.

Test 1

Micky C — Mon, 11 May 2026 19:59:13 +0000

Body here