One of the most important lessons I try to impress on developers is also one that developers typically hate hearing:
Nobody cares about your code.
Your users don't care about your code. Your investors don't care about your code. Most of them will never see a single line of it.
They care that the product works. They care that it's fast. They care that it solves their problem. They care that you ship.
I've worked with some incredibly smart programmers who were not particularly good developers.
They could write beautiful code.
They knew every design pattern. They could debate architecture for hours. They'd happily spend three days refactoring something that already worked because the abstraction wasn't quite right.
But they were expensive. They were slow. They didn't ship.
And they spent way too much time worrying about things that provided very little value to the person actually using the software.
To be clear, this isn't an argument for terrible code.
Technical debt is real. Maintainability matters. Tests matter. Architecture matters.
But they're means to an end.
The code is not the product. Great developers understand the tradeoffs.
When should we build this properly for the next five years? When is "good enough" actually good enough? When should we take on technical debt intentionally? When should we pay it back?
What is the simplest thing we can build that solves the actual problem?
The best developers I've worked with aren't necessarily the ones who can write the cleverest code.
They're the ones who understand that their job isn't to write code.
Their job is to solve problems. Code just happens to be one of the tools they use to do it.