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

Oh, I think they are. You just haven't seen them (yet?) and you probably never will, because their creators are slaving over perfection, somehow expecting the randomverse to spot it.

The winners are the ones who accepted imperfection, who were brave enough to show the incomplete, who were prepared to make the effort to do more than just write code.

VHS over betamax, Windows 95 over OS/2, Apple 2/mac over amiga. Our history is littered with marketing over product.

For every success there are 10 guys with a story about how their effort was better, how the winner was rubbish. But the winner always won the marketing game.

Too many coders are playing the perfect game of checkers, in a world where everyone else is playing an average game of chess.

Somewhat weird mindset. It is natural that when a new market gap is discovered, the first iteration of products are crappy and do the job just barely. Applies to software, cell phones, forestry machines, water toilets. Having a mindset where everything should be perfect from the start will get you nowhere.

Oh, man. I think you hit the head of the nail. One succinct phrase that describes the entire problem.

In my experience this leads to mediocre results. You need to throw out prototypes often, otherwise you'll end up with shitty solutions.

It's an unfortunate fact that as soon as you see a prototype, everyones instict is to fix the most glaring issues and call it done.

But to get to a truly great solution, you often have to throw out the prototype, and start all over.

Unfortunately very few people have the patience for that. Usually the prototype already took so much time, that everyone is already totally stressed, and starting over is out of the question.

If throwing the prototype away isn't possible, it's not really a prototype anymore.

Great point. The long-term survival of a business distills down to being able to bring in more money than it costs you to produce a product. It's such a simple concept, but it's easy to forget when you're swept up in the excitement of coding and engineering an idea you're excited about.

Ironically, it's the most ambitious engineers who tend to make the mistake of doing too much engineering work before trying to validate the product. I can't count how many times I've signed up to follow ambitious engineers' startup ventures that turn into years of highly-detailed marketing updates for products that never seem to get any closer to materializing. These are the startups that fizzle out 2-3 years later with blog posts blaming the industry, the timing, the economy, or other external factors for their failure.

In reality, most of them could have determined their market fit, or lack thereof, much faster by launching a smaller version early and iterating with customer feedback.

> The only people that really want them to move and change things are investors, not customers.

I'm glad the Notion works for you, but I think we have a long way to go to reach perfection. To pick an example from the post, even indentation needs work. There's also always more work to do to make the product faster and easier to use.

This is important, at least for me. Some people can be confident without backing or just fake confidence, some people can't. It is a natural process to take a long time building the right abstractions and just then get into marketing mode, when you have a solid platform to back your confidence.

>Why? Because your friend actually did something with their idea. They created something. It may be terrible, but at least it exists. They’re now informed about how to proceed based on something real, something tangible.

I recall an article (or maybe it was a comment) posted on HN about someone who was very engineering focused about their start up. They focused heavily on code quality and product quality. Their product was said to be rock solid.

They had a good thing going in a space they believed would be huge.

Then over a few months a competitor showed up with a janky / flaky product and took all their customers. This new competitor output new features left and right, they often didn't work well, but they existed (unlike the startup in question).

It janky product, it was Salesforce.

Finding that 'executed well' in this case was getting features out the door.

"Executed well" could just be a matter of recognizing "right now we need to get these features out the door". How / when ... who knows how you figure that out.

No, we aren't. We know how to do that, and can do it when we want to. In software dev we rarely want to, because (loaded use of the qualifier “questionable” aside) product teams tend to perceive (not entirely inaccurately, though sometimes the particulars are in error) market demand for additional features. (Also, what physical products are very often optimizing is unit production cost for equivalent products, not quality. But software already has an essentially zero unit cost, so there's essentially no gains to be had optimizing that.)

So a new product won't but in time maybe it actually can be? Within some scope. Like is a 10 point gymnastic routine really perfect? Can you actually claim it isn't perfect because there's variables you could measure that could have been more optimal? I would say not. For humans there is human-attainable perfection, and for products there is product-attainable perfection. Through iteration, of course, but not only iteration, also by really thinking about the problem, working it out, having good taste, trying out all the possibilities in some restricted way.

This is something only 4x+ perfectionist types of engineers can do naturally.

They cost double the price tag, they need freedom and respect, you don’t attract them by leetcode interviews or arrogant managers but its the only way to get high quality product in reasonable time.

Otherwise you have no alternative but do it like everybody else — spend time and money on training, layers of management, elaborate system of acceptance tests, feedback loops etc.

Including training your users to live with your mediocre product and hope for the best.

Yes, yes, YES! I'm doing this now, and just figuring out the "business" side of the product code is so much more work than the core idea (which is simple to code).

And getting the actual sales/marketing/accounting/admin/etc stuff is going to be 10x worse, I am sure.

Unfortunately, it goes against the startup ethos. That's why I avoid using startup products whenever I can. With regular companies, the problem is less pronounced, though it exists nonetheless.

It's sad people have to keep fucking up things they first made work, only because they're looking for more profit.

The odds that someone else iterates on your idea aren’t zero, but they’re very close to zero. In practice, usually nobody else cares about your new thing enough to use it, let alone copy or improve upon it.

OTOH, the odds that you need to iterate a few times before you have something that people want are greater than 50%.

So, you don’t need to convince yourself that a competitive product isn’t a risk, nor that you’ll be able to handle a competitor if one emerges. Merely accept that the risk of making something that doesn’t serve a market is way higher - probably by 10x or more. Going from 50% chance of making something useless to 25% - by seeing how users react to your product - is worth increasing the chances of a copycat from, say, 1% to 2% (or even from 2% to 10%, though I don’t think 10% is likely).

I don't think it's necessarily bad by default. Any single customer (large or not) is going to be clearer with their requirements, than trying to distill something that can fit several other customers' problems. It tends to put firmer constraints on your design, brings more clarity to your direction. It also depends on what you're comfortable with - personally I prefer to focus on solving the technical challenges, so I find that constraints on product direction leave me with more brain cycles to tackle the tiny details. Once I have a well-engineered solution, it tends to generalise more easily.

I think what you need is not best practices. You need principles.

If you take performance as a matter of principle from the get go, you will never ever ship a slow product.

Most startups nowadays seem to value design more than performance. They even value the design of their landing page more than they value the design of the actual product.

Another thing they seem to value is _perceived_ ease of development, at the expense of performance.

I say perceived because, in my experience, what you may perceive initially as a productivity boost ends up becoming a productivity burden as the code size grows.

I hear this pretty often, typically from very talented developers who have never shipped traditional commercial software as a product (which is definitely a dying breed). I don't care how good you are, you shipped a PoC in a week, not a product. It's great that your self reflection has identified what you're both good at and want to do, but a lot happens outside of writing code to create a product and this can take a long time. I've built a few in my career where I had involvement in the entire process, and typically the difference between when we're "done coding" to when the product is completed is 4x. I'm slow so maybe you can get this down to 3x, but I'm not convinced.

If I had one dream for software development the field and craft it's that we would build less, better.

Exactly this.

Not only that, but when it works the way you're describing, it's often a 2-way conversation. The developer strives to understand the goals, then starts making suggestions to determine if the business is ok with shortcomings that would make it a lot cheaper and faster, but would fulfill those goals. They'll also dig into what the business wants in the future so when the implementation starts they can take that into account.

Instead we get product who wants to own all of that and then throw things up into a jira ticket and have it magically be great. There's no value add there.