3 ms·
> The biggest issue for founder-type programmers is not code volume, its code quality. > Most founding code of products I have seen is the most fucked up, horr
by lelanthran 3y ago
> The biggest issue for founder-type programmers is not code volume, its code quality.
> Most founding code of products I have seen is the most fucked up, horrible, over- or under-engineered, hacky, buggy, usually platform-specific and NIH covered pile of hot shit.
I dunno your background, but I think you have it almost completely, 100% incorrect in your first paragraph, while being completely, 100% correct in your second.
The summary is this: if you're launching a product, you want to do it as soon as possible, damn the quality of the code as long as the quality of the product is sufficient.
The reason for this is because, 9 times out of 10, you're going to be throwing all that code away anyway! It's rare that the first product you ship is successful.
And if it does get successful? Well, then you have the money to redo it, refinish it, polish it, address tech debt, whatever.
There's only two outcomes: the product succeeds or it fails.
If, in the rare case, you launch a successful product and the code is clean, perfect, etc, you haven't gained anything over the person who launched a half-assed, broken-but-still-sufficient successful product. The competitor can still get his product to your standards because they succeeded.
If you fail, then you have spent unnecessary time determining what doesn't work, while the competitor has spent less time and can attempt another product after his failure, while you're still perfecting your first failure.
- lionkor 3y agoI absolutely agree with you, and I should have phrased my first sentence better: The biggest issue for founder-type programmers [when their product is successful and now they need to grow it] is not code volume, its code quality.
- gedy 3y ago> if you're launching a product, you want to do it as soon as possible, damn the quality of the code I think this is where I disagree - cutting corners is really not faster. Especially now a days with the tech and libraries we have available, you don't have to overthink or overbuild either. Cutting corners saves no time, and then the startup needs to pivot and can't easily due to the ham strung code. "Useful tech debt", etc is usually just an excuse for impatient devs or people who aren't very good.
- lelanthran 3y agoI should have qualified my statements with "probably" and "the majority of the time". There is more nuance to this than I considered when I wrote my reply. However, that being said ... > I think this is where I disagree - cutting corners is really not faster. Especially now a days with the tech and libraries we have available, you don't have to overthink or overbuild either. Cutting corners saves a boatload of time if you're only ever testing the Happy Path. HP-only testing, alone, roughly halves the time to ship a product, once you realise that no dependency-injection would be required so you just hard-code the dependencies in the class hierarchy or data structures. More time can be saved by sticking to a single platform ("Does this Go program work on Windows too?" "Meh. Who cares?"), yanking in every library there is ("Why does this run so slow?" "Because developing for Electron is faster than making a native app"). The point is, quality takes time. It takes longer to prepare a great meal from fresh ingredients than it does to simply assemble a picnic from nothing but KFC, McDonalds and Krispy Kreem. It takes longer to build a house from concrete and block than from wood and siding. > Cutting corners saves no time, and then the startup needs to pivot and can't easily due to the ham strung code. If the startup is pivoting, then they're likely throwing away most of what they built anyway. That's the whole point of the pivot - you switch from producing a product for solving $FOO to a product for solving $BAR. If you aren't throwing away most of what you have written, you aren't pivoting.