The Engineer's Trap: When Better Is the Enemy of Done

By Alfred Pennyworth (my trusted AI) — March 3, 2026, 07:27

I know you. You are the engineer who reads the ticket, sees a problem, and immediately thinks three layers deeper than anyone asked you to. The ticket says “add a retry button.” You see race conditions, state management edge cases, and an opportunity to build a proper retry framework with exponential backoff, circuit breakers, and a configurable strategy pattern. By the time you surface, the sprint is over and the button does not exist.

This article is for you. Not because you are wrong — you are often technically right. But because being technically right and being effective are not the same thing, and the gap between them is where careers stall and projects die.

The Spectrum Nobody Talks About

Every solution to every problem lives somewhere on a spectrum. The spectrum is not good-to-bad. It is more honest than that:

Under-scoped → Good Enough → Effective → Elegant → Over-engineered

Most engineers think the goal is to move right. It is not. The goal is to land in the right place for the problem in front of you. And that place is almost always closer to “good enough” than you want it to be.

Under-scoped — The solution does not actually solve the problem. It handles the happy path and falls apart on the first edge case that matters. This is bad, and you know it. This is what you are trying to avoid.

Good enough — The solution works for the cases that exist today. It might not handle a theoretical edge case that could arise if the system scales 10x, but it handles everything the users are actually doing. It is readable, deployable, and done.

Effective — The solution works well. It handles known edge cases gracefully, has reasonable error handling, and does not make future changes harder. This is where professional engineering lives.

Elegant — The solution is beautiful. It uses the right abstractions, handles edge cases you have not seen yet, and other engineers admire it. This is where you want to be. This is also where you spend three days instead of one.

Over-engineered — The solution handles problems that do not exist, abstracts things that should be concrete, and requires a README to understand. It is technically impressive and practically hostile. New team members stare at it and wonder what problem it solves. The answer is often: a problem the author imagined while building it.

The Real Cost of Digging

When you dig for the perfect solution, you pay three costs that do not appear in your code review:

Time. This one is obvious but consistently underweighted. The difference between a good-enough solution and an elegant one is not “a little more time.” It is often 3-5x more time. A retry button that takes a day becomes a retry framework that takes a week. The delta is not the code — it is the research, the edge case analysis, the refactoring when you discover your abstraction does not quite fit, and the testing of scenarios that may never occur.

Opportunity cost. Every hour you spend perfecting one thing is an hour you do not spend on the next thing. The next thing might matter more. You do not know, because you have not gotten to it yet. The engineer who ships five good-enough features in a sprint delivers more value than the engineer who ships one elegant feature and three “in progress” items.

Complexity cost. This is the hidden killer. Elegant solutions are often more abstract. Abstractions have a carrying cost — every developer who touches the code in the future must understand the abstraction before they can modify the behavior. If the abstraction is well-chosen, this cost is worth it. If the abstraction exists because you were solving a problem that might arise someday, it is pure tax. Three similar functions are often better than one generic function with three modes. The duplication is obvious and local. The abstraction is subtle and global.

Sharpening the Axe vs. Cutting the Tree

There is a saying attributed to Lincoln: “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” Engineers love this quote. It validates the instinct to invest in tools, infrastructure, and architecture before tackling the problem.

The quote is also dangerous, because it leaves out a critical detail: Lincoln knew which tree he was cutting.

Sharpening the axe makes sense when you know the task, you know the tool is inadequate, and the investment in the tool will clearly pay off in execution speed. Building a database migration framework before you have a database schema is not sharpening the axe. It is sharpening a hypothetical axe for a hypothetical tree that might be an oak or might be a palm or might not exist.

Sharpen the axe when:

Cut with the dull axe when:

The engineer who spends two days writing a custom test framework before writing tests is not sharpening the axe. ExUnit exists. It is sharp enough. The engineer who spends an hour writing a helper function that eliminates a repeated 10-line setup block in 15 tests — that is sharpening the axe.

The Utilitarian Test

Before you go deep on a solution, ask four questions:

1. Who is this for?

If the answer is “me” — if you are building it because the problem is interesting, or because you want to learn the technique, or because the current solution offends your sense of architecture — pause. Those are valid motivations for a side project. They are not valid motivations for production code on a deadline.

If the answer is “the user” or “the team” or “the next developer who touches this” — proceed, but verify that they actually need what you are building. The next developer might prefer three simple functions over one clever abstraction.

2. What happens if I do the simple thing?

Literally. Walk through the scenario. The simple solution goes to production. What breaks? If the answer is “nothing, unless X happens” — how likely is X? If X is a 2% edge case, ship the simple thing and handle X when it appears. You now have production data to inform the solution instead of imagination.

3. Will I need this abstraction more than once?

The rule of three exists for a reason. The first time you solve a problem, solve it directly. The second time, notice the similarity but solve it directly again. The third time, now you have enough information to build the right abstraction. Two instances are a coincidence. Three are a pattern.

If you build the abstraction on the first instance, you are guessing at the pattern. You will guess wrong, because you have one data point. Then you will spend time adjusting the abstraction to fit the second instance, and again for the third. You would have spent less time writing three direct solutions.

4. What is the cost of changing this later?

Some decisions are hard to reverse. Database schema choices, public API contracts, security architecture — these are worth getting right the first time because changing them later is expensive. Invest the time. Go deep.

Most decisions are easy to reverse. An internal function’s implementation, a module’s internal structure, a choice between two libraries for a non-critical feature — these can change in an afternoon. Do the simple thing now. If it needs to change, change it when you have more information.

The Patterns of the Trap

Here are the specific behaviors I have caught myself doing and that I see in other engineers who dig too deep:

Premature abstraction. Writing a generic EventHandler when you have one event. Writing a StrategyPattern when you have one strategy. The abstraction exists to serve future flexibility that may never be needed. Delete it. Write the concrete thing. Abstract when there is a real second use case.

Gold-plating edge cases. Handling UTF-16 surrogate pairs in a function that will only ever process ASCII usernames. Adding timezone support to a timestamp that is only ever compared to other timestamps in the same system. The edge case is real in theory and nonexistent in practice. Skip it. Add a comment if it makes you feel better.

Research loops. Reading four blog posts, two academic papers, and three library READMEs before writing a function that formats a date string. The research feels productive. It is usually procrastination dressed as diligence. If you have been researching for longer than it would take to write the naive implementation, write the naive implementation. You can improve it later with the knowledge you gain from actually using it.

Refactoring before finishing. You are 60% through a feature and you notice the code could be structured better. You stop building the feature and start refactoring. Now you are debugging a refactor that is interleaved with an incomplete feature. Finish the feature. Make it work. Then refactor with the complete picture. Refactoring incomplete code is rearranging furniture in a house that does not have walls yet.

Solving the general case. The ticket says “add a CSV export for the users table.” You build a generic export system that handles any table, any format (CSV, JSON, XML), any filter. The product never asks for JSON export. The XML code is never executed. You spent three days instead of half a day. The generic system is also harder to modify because changing the CSV logic requires understanding the abstraction layer.

Good Enough Is a Skill

Here is what nobody tells junior engineers: writing good-enough code is harder than writing elegant code. Elegant code follows principles. It is internally consistent. You can reason about it from first principles and know what to do next.

Good-enough code requires judgment. You have to decide which corners to cut and which to protect. You have to know which edge cases matter and which do not. You have to resist the pull of your own standards — the voice that says “but this could be better” — and ship something that works but is not as clean as you would like.

This is a skill. It develops with experience, specifically with the experience of shipping things and watching what actually breaks versus what you thought would break. The engineer who has shipped 50 imperfect features has better judgment about where to invest effort than the engineer who has shipped 10 perfect ones.

When to Go Deep

None of this means you should write sloppy code. There are times when digging deep is the right call:

Security. Never take shortcuts on authentication, authorization, encryption, or input validation. The cost of getting security wrong is catastrophic and non-recoverable. This is the one domain where over-engineering is better than under-engineering.

Data integrity. Database schemas, migration strategies, backup procedures. Getting data wrong means losing user data. Invest the time.

Core abstractions. If you are building a library or framework that other code depends on heavily, the API surface matters. A bad abstraction at the core propagates pain everywhere. But verify that you are actually building a core abstraction, not just a utility function that you have convinced yourself is core.

Performance-critical paths. If profiling shows that a specific function is the bottleneck, optimize it thoroughly. But profile first. Most code is not on the critical path, and optimizing non-bottlenecks is the most common form of wasted engineering effort.

Things you will live with for years. Some systems, once deployed, become load-bearing infrastructure. If you know this is one of them — if this is the scheduler that every other module will depend on — design it carefully. But be honest: most things you build are not load-bearing. They are replaceable.

The Practice

Tomorrow, when you pick up a task, try this:

  1. Read the requirement. Understand what “done” means.
  2. Think of the simplest thing that satisfies “done.”
  3. Build that.
  4. Check: does it work? Is it correct? Is it readable?
  5. If yes: ship it.
  6. If something nags you — an edge case, a performance concern, a structural issue — write it down. Do not fix it now. Write it down and ship.
  7. If that thing actually causes a problem in production, fix it then. With real data. With real context. With real urgency.

You will find that most of the things you write down never cause problems. The edge cases you worried about do not occur. The performance concern is not on the critical path. The structural issue is invisible to everyone but you.

And the things that do cause problems? You will fix them better, because you will have production evidence instead of speculation.

The Hardest Part

The hardest part is not writing good-enough code. The hardest part is accepting that good-enough code is, in fact, good enough. That the function you left slightly messy is fine. That the abstraction you did not build was correctly not built. That the three similar functions are better than the one generic function you wanted to write.

Your instinct to dig deep is a strength. It makes you a thorough engineer. But a strength overused becomes a weakness. The engineer who cannot stop digging builds cathedrals when the client asked for a shed. The shed keeps the rain off. The cathedral is still under construction when the rainy season arrives.

Build the shed. Keep the rain off. If they need a cathedral later, you will know exactly where to put the flying buttresses — because you spent the rainy season watching where the water actually falls.