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, horrible

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. Strong dependencies on half-assed internal data structures, stretch marks everywhere ("we did it like this because we had time pressure, and it was wrong, and now we cant get rid of it"), weird protocols ("we will just use a stringly-typed header for our high performance TCP communications, its easier to debug!"), lack of documentation ("no bro, the code is the documentation!"), and very little if any devops or testing (lol testing). Thats good that way, too, otherwise products would never be launched. Thats why a lot of engineers will not launch a product, ever - their standards are too high and theyre too hung up on doing it right, that their window of opportunity for their niche fades. The one thing I haven't seen a single startup or upcoming product struggle with is quickly churning out a lot of code that mostly/fully does the job and sells. Unless AI can replace engineers like me, half of who's job experience is cleaning up, streamlining and refactoring these "quick launch" codebases, in order to make the code last even if core engineers leave and to make onboarding easier, we are NOT going to see a massive revolution of AI programming tools.

BoorishBears 3y ago
Simply not true, and this post represents the biggest fallacy most technical founders struggle with. The most common problem is they never ship anything. Or they ship something no one needs. Or they ship something people need but don't know how distribution works so those people never find it. I'm someone who's spent enough time writing high quality code that my default thinking is in line with yours, but the truth is it's a privilege to get to a place where you can afford to hire people to clean up your "quick launch" codebase. Even if you look at it from a place of personal pride, there is more pride in proving your idea solves real problems for real people today, than there is in chasing an ideal codebase that scales better tomorrow when you don't even have proof anyone wants it.
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 ago
  I 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 ago
    I 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.

BoorishBears 3y ago

Simply not true, and this post represents the biggest fallacy most technical founders struggle with. The most common problem is they never ship anything. Or they ship something no one needs. Or they ship something people need but don't know how distribution works so those people never find it. I'm someone who's spent enough time writing high quality code that my default thinking is in line with yours, but the truth is it's a privilege to get to a place where you can afford to hire people to clean up your "quick launch" codebase. Even if you look at it from a place of personal pride, there is more pride in proving your idea solves real problems for real people today, than there is in chasing an ideal codebase that scales better tomorrow when you don't even have proof anyone wants it.

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 ago
I 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 ago
  I 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.