You're Not Paid to Write Code
One thing I noticed in my engineering organizations is that when people get the problem to work on, the first step is to open the editor, create a new branch, and start coding. I always felt this was the wrong direction.
What I've found over more than twenty years of building software across different domains is that engineers who delivered the most value to projects and companies weren’t the most productive coders. The ones that brought the most value were those that started first with thinking, asking questions, pushing back on requirements, analyzing, and making a plan. Sometimes, during this process, they found out that coding is not even necessary. And this was the best outcome.
This habit was valuable. This year, when AI can write code much faster than us, it’s become even more important to bring value to your company without only coding.
In particular, we’re going to talk about:
The identity trap. The common mistake is treating software engineering as code output. It shifts the focus to questions, intent, and what the work is meant to change.
Code is a liability, not an asset. Every line of code has to be maintained, understood, and changed later, so the real goal is not to write more, but to solve the problem with less.
What happens when you skip the thinking. It’s easy to fix the wrong problem when you jump straight into implementation. The difference is between moving fast in code and being right about the problem.
Why do we default to coding anyway. There is a reason why teams rush into code-first behavior. Incentives, praise, deadlines, and org structure all push it in the wrong direction.
AI amplifies this even further. What changes when code becomes cheap to produce? AI can speed up execution, but it also leads to poor framing, weak judgment, and unnecessary code scaling.
What thinking-first actually looks like. There is a simple way to clarify the problem before coding, using short notes, lightweight documents, feedback, and quick prototypes to test assumptions.
The engineer’s real job description. The focus moves from coding to judgment, trade-offs, architecture, validation, and deciding what should never be built in the first place.
Let’s discuss this deeper.
Unblocked: Context that saves you time and tokens (Sponsored)
Give Cursor, Claude, and Copilot the organizational knowledge they need to generate code that is ready for git push. Unblocked synthesizes your code, PR history, conversations, docs, and runtime signals to surface the right context for each task.
1. The identity trap
The idea that a software engineer is only as good as the code they write is just not true. People think that if you write a lot of code, you become a good software engineer. They look at things like how many lines of code you commit, how many pull requests you merge, and how many features you ship. If we use that way of thinking, then a computer program that can write code is already a software engineer, and most people are not, especially now in the AI age. That way of thinking is wrong.
A software engineer does not start by thinking about what tools or computer programs to use. They start by asking questions:
What problem are we trying to solve with this?
Who are we trying to help?
Why is it important to solve this problem?
What will happen if we do not do this and do something else?
Some people just focus on writing the code, which is what developers do. Software engineers think about the outcomes of their work.
When you write code, you want to make sure the code works properly. But software engineering is different. It is about making code that can handle problems when they happen. It should be easy to understand and fix, and other people should be able to work on it even if they did not write it. Software engineering also considers how it affects systems connected to it. It is like looking at the picture and thinking about how all the parts work together.
2. Code is a liability, not an asset
This is something we need to understand from the start. Even though our job is mainly focused on the code, we need to have it, not want it. The reason is that every line of code you write needs to be maintained, it needs to be understood by you in the future and your colleagues, and eventually changed when new requirements arrive. Nothing of this is free. Code is not valuable until what it does earns more than what it costs to keep it running.
The thing is that a lot of code never gets to this point. Code capabilities are assets, but code itself is a liability you incur to produce those capabilities. The goal is to implement the business capability with as little code as possible.
Jeff Atwood said the best code is no code at all. Code you do not write does not have bugs, does not need tests. Never needs to be cared for. If you can solve a problem by deleting code, changing the way you do things, or using a tool that already exists, then you have done your job well.
This is not about being against code, but about knowing when to use it. It's the code itself that we need to be careful with. We should think carefully about when to write it. Code is what we are trying to be disciplined about.
3. What happens when you skip the thinking
Let me walk through the example. I have seen this same thing happen many times. Let’s say we get a ticket which says: “Users are saying that the checkout is slow. We probably need to fix the problem with the performance.”
The engineer would look at the code, see how this functionality works, then identify a slow DB query and maybe add some indexes. Sometimes it would add tests too. The problem is fixed.
Then, three weeks later, the ticket gets reopened. It turns out that people are still leaving the checkout without paying. The slow database query was not the problem. People were leaving the payment form because it had many fields to fill out, not because it was slow. Nobody reviewed the data on how people use the website before they started working on the problem. So the engineer made the checkout faster. That was not what people were really having trouble with.
Now lets look at what happens when the engineer thinks about the problem.
Before they start coding, the engineer asks: What does “slow checkout” really mean to the website's users? They look at data on how people use the website, and they talk to two people who work in support. They read feedback from the last three months. They find out how many people are leaving the checkout at the payment form, and they write down something like this:
Users are leaving the checkout at the payment form. The data shows that people are having trouble with all the fields they have to fill out, not that it is slow. My idea is that if we make the form shorter, more people will finish checking out.
The engineer spent 2 hours thinking about the problem and came up with a correct solution. They made a form and tested it against the old one. It worked. 18% more people finished checking out, and the code change was 40 lines.
The first engineer was really fast at coding. The second engineer actually solved the checkout problem.
4. Why we default to coding anyway
Unfortunately, we often do coding first because that is how we measure and reward engineering work.
The way we measure things is how fast we complete our tasks, not by looking at problems to avoid. Promotions are given to someone based on the number of features they delivered, more than anything else. Nobody gets praise for removing code or making something simpler, even when it improves the system. Engineers are just smart people who follow the rules. This is a great example of Goodhart's Law.
This is a problem on the organizational level, not just with individuals. We see it when individual people make decisions. The goal is to show that we are making progress. Progress looks like we are writing code, because the clock is ticking from the moment we take the ticket. So, engineers write code before they really understand the problem, the organization rewards them, and we end up with something that’s not what we wanted, and then everyone is confused. This is only accelerated with AI (read more in the next section).
But, there is another way this can go. In teams where everyone can talk to each other and see how users are affected, we usually understand the problem naturally. The problem is worse in organizations where it takes a long time to see how a line of code affects the business, and it has to go through many teams and people.
5. AI amplifies this even further
AI coding tools have made it really easy to generate code. A lot of code. A good engineer with the tool can make a working draft in just a few minutes that would have taken hours before. This sounds like a good idea, but it really depends on what happened before they started using the tool.
Think of an AI tool like a person who builds something the way you tell them to. If you give them an idea of what you want, they will do a good job quickly. If you are not clear about what you want, they will still build something quickly, but it will be the wrong thing built. The tool cannot determine whether it is doing what it is supposed to. Only the engineer can do that.
In 2025, a METR study found that some experienced developers worked on their projects with and without AI tools. The developers thought they would be 24% faster with AI tools. After using the tools, they thought they were 20% faster. But the actual result shows that they were 19% slower. Researchers said this was mainly due to over-optimism about AI and lower AI reliability.
Also, folks from GitClear looked at 153 million lines of code. They found that when AI tools were used, there was four times more copied code and the code was changed more often. We are producing more and more code, but the question is what will really be needed.
Of course, AI models become better and better, but we still need to know what code is really needed and what isn’t.
When the engineer thinks carefully before using the AI tool, things are different. We can say that AI tools actually help good engineers do their job better. The better the engineer's plan is, the better the AI tools' results will be.
AI tools do not make everything equal. They make it so that engineers need to be even better at their job.
6. What thinking-first actually looks like
I want to be clear about this because saying “think before you code” can sound like a reason to have a lot of meetings and make documents that nobody actually reads. If we delegate problem-solving to AI, we skip the phase of understanding the problem. Bypass the “why” and jump into “how”. And this means if we don’t know how to assess architecture decisions, AI will just help us go faster in the wrong direction. And recent research from Anthropic confirms that.
What I found in all this hype about AI is that everyone is focused on execution, but no one is focused on thinking or decision-making. Defining products and problems will be more important than implementation in the future.
So, here is what I usually do: before I start writing code for something that’s not simple, I write one paragraph in a note. This paragraph answers:
What is the real problem?
Who does it affect?
How will I know when it is fixed?
Half the time, writing this paragraph helps me find a problem that I did not know was there (because writing is best thinking). This helps close the gap, or keep it flat, as an assumption before I start.
For larger projects, I use a short document that outlines the problem, the options, and enables the following:
Figuring out what the problem is. You have to know what you are trying to solve. Do not just listen to what the customer says they want. Look deeper into what they need.
Understand the business. When you make decisions about technology, you are making business decisions. If you come up with a solution that’s really cool from a technical standpoint but doesn't help the business, it is a waste of time.
Decompose. Find patterns and use abstraction to get rid of details that’re not important.
Planning. The goal is to think things through in a way before you start working on the solution. The outcome goes in the document.
Communicte. Get their feedback to make sure you are not missing anything. When you are working on a project, the requirements serve as a contract among the engineers, stakeholders, and users. If everyone is not on the page, the project can get out of hand, and you may miss your deadlines.
Prototype to test assumptions. And here comes AI. Make the simplest version possible to see if it works before you put a lot of time and money into it. This way you can make sure that your idea is a one before you invest too much in it.
We should note that Google and Amazon also both do this. Amazon has a process called Working Backwards that requires a press release and a list of asked questions to be written before any code is written, before any money is spent, and before any new employees are hired. The goal is to stop ideas before they use up engineering resources. Most proposals are not approved. That is okay, as most proposals should not be approved.
7. The engineer’s real job description
The job of a software engineer in 2026 is not about writing a lot of code quickly. It is about understanding the problem and figuring out what we really need. This means turning ideas into clear technical requirements and asking questions that others might not think of.
It is also about making decisions on what to build and what to buy. A software engineer has to know what to skip and remember that every new feature is a risk. The engineer must consider whether the feature's benefits justify the cost of maintaining it.
Then, about architectural judgement. Deciding how to build software, in which direction. If we make this mistake early, it will be costly to fix it later.
Software engineers also have to keep an eye on the code that AI generates (for now). They have to review this code just like they would review code written by a new team member. This means catching mistakes that the AI might make because it does not understand the context. So, we still need to validate its output.
Sometimes the best thing to do is to remove code. This can actually be a feature.
AI can generate large amounts of code, but it cannot decide what code to generated at the first place. It cannot figure out whether a feature is really needed or weigh the pros and cons of a business decision. These things require human judgment. They are the harder parts of the job.
Being good at coding is still important. What that means is changing. It shifted to knowing when code is necessary and whether the generated code is correct in terms of business value. A software engineer has to understand how all the parts of a system work together.
8. Conclusion
The expensive mistakes in software do not come from simple coding errors. They come from trying to fix the issue.
When we really understand a problem, we write code to solve it. The hard work is in thinking, asking questions, and defining the problem. That’s where the real engineering happens. Everything else is just implementing the solution.
When you get a task assigned to you, take a moment to write down two things before you start coding: what is actually not working and how you will know when it is working correctly. If you make this a habit, it will make a difference in what you build than any tool or technology will.
The best software engineers have always known this. The code is the last part of solving a problem.
The best code is no code. And if you must code, remember: every line is a promise you’re making to the future.
If you liked this post, consider subscribing to email updates about my new posts or sharing it on Hacker News.
More ways I can help you
📱 You Can Build A LinkedIn Audience 🆕. The system I used to grow from 0 to 260K+ followers in under two years, plus a 49K-subscriber newsletter. You’ll transform your profile into a page that converts, write posts that get saved and shared, and turn LinkedIn into a steady source of job offers, clients, and speaking invites. Includes 6-module video course (~2 hours), LinkedIn Content OS with 50 post ideas, swipe files, and a 30-page guide. Join 300+ people.
📚 The Ultimate .NET Bundle. 500+ pages distilled from 30 real projects show you how to own modern C#, ASP.NET Core, patterns, and the whole .NET ecosystem. You also get 200+ interview Q&As, a C# cheat sheet, and bonus guides on middleware and best practices to improve your career and land new .NET roles. Join 1,000+ engineers.
📦 Premium resume package. Built from over 300 interviews, this system enables you to quickly and efficiently craft a clear, job-ready resume. You get ATS-friendly templates (summary, project-based, and more), a cover letter, AI prompts, and bonus guides on writing resumes and prepping LinkedIn. Join 500+ people.
📄 Resume reality check. Get a CTO-level teardown of your CV and LinkedIn profile. I flag what stands out, fix what drags, and show you how hiring managers judge you in 30 seconds. Join 100+ people.
✨ Join My Patreon community and my shop. Unlock every book, template, and future drop, plus early access, behind-the-scenes notes, and priority requests. Your support enables me to continue writing in-depth articles at no cost. Join 2,000+ insiders.
🤝 1:1 Coaching. Book a focused session to crush your biggest engineering or leadership roadblock. I’ll map next steps, share battle-tested playbooks, and hold you accountable. Join 100+ coachees.
Want to advertise in Tech World With Milan? 📰
If your company is interested in reaching founders, executives, and decision-makers, you may want to consider advertising with us.
Love Tech World With Milan Newsletter? Tell your friends and get rewards.
Share it with your friends by using the button below to get benefits (my books and resources).