> You know from day one that your contribution is not valued
It doesn't mean the tech isn't valued, but that whether or not it's a marvel of elegance and cleanness is less important than whether or not it works and delivers sufficient value early on.
So you should go into a startup being prepared to do what it takes do meet business needs, and be less concerned about building something clean.
If you can do both, great. If your quest for technical elegance sacrifices functionality in the short term, in a startup that can often kill the business.
I've been part of discussions like that more often than I care, where e.g. some engineer wanted to go off and spend six months cleaning up a codebase that was ugly but functional, but where what mattered to the business was getting more functionality in place even if it meant having to spend 10x the amount to clean up the codebase a year later.
Sooner or later you pay the price, but paying the price later can often be far cheaper, because you may, e.g., be paying with ongoing revenue instead of paying with seed money or early stage VC funding, which has a very high cost.
This is different in a more established business, where cost of capital is less likely to decline as rapidly, which makes it more likely that you get into scenarios where deferring technical debt may actually be a net negative.
In a startup I'd value a developer that is sensitive to business needs and willing to take calculated shortcuts (as long as they also make the business aware when they do) over a technical perfectionist any day.
It doesn't mean the tech isn't valued, but that whether or not it's a marvel of elegance and cleanness is less important than whether or not it works and delivers sufficient value early on.
So you should go into a startup being prepared to do what it takes do meet business needs, and be less concerned about building something clean.
If you can do both, great. If your quest for technical elegance sacrifices functionality in the short term, in a startup that can often kill the business.
I've been part of discussions like that more often than I care, where e.g. some engineer wanted to go off and spend six months cleaning up a codebase that was ugly but functional, but where what mattered to the business was getting more functionality in place even if it meant having to spend 10x the amount to clean up the codebase a year later.
Sooner or later you pay the price, but paying the price later can often be far cheaper, because you may, e.g., be paying with ongoing revenue instead of paying with seed money or early stage VC funding, which has a very high cost.
This is different in a more established business, where cost of capital is less likely to decline as rapidly, which makes it more likely that you get into scenarios where deferring technical debt may actually be a net negative.
In a startup I'd value a developer that is sensitive to business needs and willing to take calculated shortcuts (as long as they also make the business aware when they do) over a technical perfectionist any day.