Hacker News Reader

Comment by _urzu | Hacker News Reader

In 6 years of being in a startup environment, being fast never gave me any advantage.

In fact, being too short sighted and always reaching for the easy wins gave me a lot of fragile products. The value is in well-engineered stuff. But I used to prioritize product over everything. I'm a recovering product-first engineer.

My take now is different: I'm very well aware of product and code quality. But I'm resisting my compulsions to actively control myself. I just do.

I work on whatever problems I feel are important at the day. I usually end up having product cycles and code cycles automatically.

I'm happy with this strategy. A semi-technical boss that constantly whispers micro management commands in my ears is my worst nightmare now. I'm grateful, I don't have one anymore.

Also: Wat, you don't unit test? Well then have fun developing "fast" by having to manually test your app's IO.

View on HN

I think the takeaway from you experience and the article should actually be recognize what your personal priorities are, the team's priorities, and make decisions with that in mind.

> The value is in well-engineered stuff

A start-ups needs to survive long enough to find a business model and profitability, and that becomes much harder when you're not a technology company and put technology first.

For every Google that succeeded, there a dozen Facebook and Twitter's that took a "good enough" approach. No shortage of well-engineered products in the graveyard.

Also keep in mind that if a company makes it long enough and you continue to grow, you're engineering team output will be many multiples of what it was when you made some earlier mistakes. Much easier for a few hundred engineers to fix problems created by a dozen.

Bad business models kill software much, much more than bad software kills businesses.

Fair enough, and I guess we have to differentiate between VC-funded and others.

E.g. your comment might be true for VC-funded. But it may not be true for other types, e.g. bootstrapping.

But then additionally, I'm super surprised how a well-engineered product can transfer trust to potential customers. Consider, now that we've all been on the Internet for 20 years, we have well-trained bullshit sensors. So I'd say there are shades of grey in all of this.

I think you could make a venn diagram out of 'building the right thing' and 'building it right' and the intersection of the two is the sweet spot where a successful and sustainable product might land. Or, more likely, it's where one might gravitate to over time as the business matures.

Even within that spot there's room to shift focus - sometimes you'll want to work on technical excellence, shoring up bugs, paying off tech debt. Other times it'll be a case of taking on a bit more debt in order to innovate. The proportions of building it right and building it the right way will shift but never so far as to abandon one of those principles.

Reply on news.ycombinator.com