most engineers think their job is to write code. it is not.

the hard truth is: nobody pays for code. code has no value by itself. the only reason it has any value at all is that it solves a problem, either for a customer or for your company. until it does that, it is just lines of text.

think about it: if i spend two weeks writing the most elegant microservice in the world, but it does not get deployed, it is worthless. it does not matter how clean the architecture is, how proud i am of my abstractions, or how perfectly the tests are written. if it is not solving a problem in production, it is just an expensive hobby.

the code vs. the outcome

customers do not care whether your backend is written in php, rust, or python. they do not care if you used react or vue. what they care about is:

• can i check out my order faster?
• does the invoice system finally work without throwing errors?
• does this tool save me time instead of wasting it?

take authentication as an example. i could build my own oauth server from scratch and sink weeks into it. or i could wire something up fast with an existing library. the smart choice depends on context:

• if auth is not your core business, shipping faster with existing tooling makes sense.
• if auth is critical to your product’s value, like in fintech or healthcare, then blindly plugging in auth0 or supabase is just kicking the can. you have locked yourself into someone else’s roadmap and pricing model. that is not creating value, that is renting it until the bill comes due.

you do not score points for hand-rolled crypto or reinventing oauth, but you also do not create lasting value by chaining your product to a vendor you cannot escape from. the job is to balance time to value with long-term control.

merge requests: the real bottleneck

the slowest part of modern development is not writing the code anymore. i can go from “i want to generate pdf invoices with customer logos” to a working prototype in an afternoon.

the real slowdown is getting that code into production. merge requests become parking lots where ideas go to die. reviews pile up. people nitpick variable names while the customer is still stuck with the broken flow.

example: i once saw a bug fix for a billing system that would have stopped double-charging customers. the patch was 20 lines of code. it sat in review for two weeks while engineers debated whether the constant should be uppercase. during that time, the company refunded thousands of euros. the actual cost of those merge-request delays was orders of magnitude higher than the code itself.

pigeonholing developers

another way teams waste value is by pigeonholing developers into narrow boxes. “backend devs do not touch frontend.” “frontend devs do not touch the database.” “ops people do not touch business logic.” what happens then is endless ping pong across merge requests. one person implements half the solution, sends it for review, another person sends it back because it needs a change in a different layer, and the cycle repeats.

the problem is not skill, it is mindset. the more you box people in, the more handoffs you create, and every handoff is a delay.

a hypothetical example

a customer wanted a simple feature: display subscription status correctly on their dashboard. sounds easy.

• the frontend dev added the ui, but hardcoded the value because “the backend needs to add an api for it.”
• the backend dev created the api endpoint, but left the db query as a stub because “the dba needs to review the schema.”
• the dba updated the schema, but flagged the query for review because “ops needs to validate performance.”
• ops tested it, found it fine, but sent it back because “frontend still needs to wire it all up.”

this cycle took three weeks. the actual problem could have been solved by one engineer in one afternoon if they were willing to cross layers. instead, the customer waited nearly a month to see a subscription flag on a screen.

real value comes from engineers who are willing to cross boundaries. maybe you are stronger in frontend, but you still touch the backend change that unblocks the feature. maybe you are not an expert in sql, but you write the migration because it gets the job done. instead of throwing tickets over the wall, you ship.

it is better to deliver a complete solution that solves the customer’s problem than to protect your little slice of expertise.

so what does “creating value” actually look like?

• focus on the problem, not the tech. do not start with “i want to use kubernetes.” start with “our deployments fail too often, how do we make them boring?”
• ship small, ship fast. a 50 percent solution in production is infinitely more valuable than a 100 percent solution stuck in review.
• treat code as a tool. like a hammer. nobody gets paid for swinging a hammer, they get paid for building the house.
• challenge process bottlenecks. if your merge-review process takes weeks, fix that. no amount of “10x engineers” will save you otherwise.
• avoid pigeonholes. do not get stuck in “that is not my layer.” value comes from finishing solutions end-to-end, not defending turf.
• own what matters. use vendors where it makes sense, but do not lock your company’s future into someone else’s pricing model. control the parts that define your value.

the bottom line

you do not get paid to write code. you get paid to solve problems.

every time you sit down at the keyboard, ask yourself: is what i am doing right now creating value for the customer or the company? or am i just moving text around?

code is the medium, not the product. the product is the solution. and the highest value engineers are the ones who know when to move fast, when to take shortcuts, and when to own the core parts that make the business what it is.