Hacker News Reader

Comment by yoz-y | Hacker News Reader

I've had kind of the opposite experience. At the startup we were really sluggish it was hard to learn anything because we were jumping into any possible business opportunity before even thinking about ROI because money was always tight. 80% of the time was wasted supporting clients and fixing bugs that were due to the fact that the product was shipped too early.

I think the biggest difference is money. A well funded startup might be a boon but a struggling one will be a bane.

View on HN

There are lots of startups that aren't doing it right. The best thing someone working at one of those startups can do is probably quit and go someplace else.

I think systemically one thing we need to do is help people make better decisions about where they spend their time. Especially for people who are good builders, they happen to also be the best people who can decide for themselves whether something is actually going to work.

The difference is whether you see learning to do meaningful things on a shoestring budget to be itself a useful skill.

Boeing won't care if you save the project $5k by spending a week of your time coming up with a clever workaround. The week was more important than the $5k. Same for a high level role generally. But not getting work done for a week because your boss won't approve a $500 purchase... that would be frustrating and get old fast.

> Boeing won't care if you save the project $5k by spending a week of your time coming up with a clever workaround.

I'm confused what you're getting at here. $5k/week is $260k/y (or a bit less counting vacations and holidays) and the fully-loaded cost of an engineer at a startup is typically more than that. Then consider how high opportunity costs typically are at startups, and I expect most startups would view your spending a week to avoid a one-time $5k expense to be a bad tradeoff.

Yes, but a week of delays costs the company like Boeing a lot more than just your salary, and they have deadlines to meet and other teams that need your project done.

I agree, most startups would view spending a week to avoid a one time $5k expense to be worth it for several years at least. That's why I'm saying the experiences are different.

If you're reading a judgment into my comment, there is none, I think doing super constrained engineering is super fun and an awesome skill to have. But I have also worked places that have the attitude of time being vastly more valuable than cash, and respect that both approaches are reasonable. Just different. But worst is when you're cash constrained to the point where even your clever workaround isn't possible to implement, even though it costs 10x less and is mission critical.

> I agree, most startups would view spending a week to avoid a one time $5k expense to be worth it for several years at least

Sorry, what I'm saying above is that I don't agree with that.

Ah, sorry, I misread you. Fair enough, raise to the level you feel is reasonable for your field. I just picked a number that I think is about right for people like me that don't code much.

I am also thinking more "angel+bootstrap+grant" funded startups rather than people already past a Series A; if there's 10 employees with a decent runway the calculation changes a lot versus 3 people getting something off the ground. I think the latter is more typical of a startup for the first several years.

I find that saving developer time or large amounts of money can be rewarded well in my position at a FAANG, you just need to save an amount commensurate to the opportunity cost.

"...save an amount commensurate to the opportunity cost."

Which can be a hell of a lot more than you expect. Like, don't bother spending two weeks to cut the CPU use of a service in half, if the service only uses 1k CPUs to begin with.

On the other hand, it seems like a savvy engineer could work that into a story to tell a Boeing interviewer about how they took the initiative to think outside the box and develop a solution that saved the day when the team was under a time constraint.

If they solved a time constraint by being clever and working hard then clearly Boeing would care about that, I agree.

Saving $$ per unit and saving $$ total are so different. If all you're doing is saving $500 total, I wouldn't even care in most cases... but if you managed to use clever techniques to save $0.30 off the manufacturing cost for a toy that gets sold in the millions...

I most strongly agree with the ethical part of the article, in any event. I'm sick of companies trying to take advantage of their employees, it's just sad and gross to see it done by startups that could be better than big companies in at least this one way. But instead they take it even further somehow because their finances are far more opaque. I don't think it should be up to noblesse oblige to determine whether distribution of profits and salaries are fair, it should be assumed to be the rule even if there may be exceptions.

It's a sad day when you look at employment agreements from Intel and a shiny startup and find that Intel is more up front and transparent about how things will work and what you'll get paid.

>noblesse oblige

I think the course of events in the USA in the decades since the 50s has essentially answered the question of what happens if you leave it up to the most fortunate to decide how to treat the least fortunate.

Sometimes the people who are best at "working stories up for interviewers" don't always feel the need for there to be any truth behind those stories...

Working for startups I usually hit the ceiling pretty fast. Not enough time for formal learning, because of fires or hundreds of menial tasks, and on-the-job learning is just not enough after a year or so.

Anyone stuck in this situation?

> were due to the fact that the product was shipped too early.

Can you explain more about this? The mantra is generally ship early and iterate fast.

How come the tech team was spending 80% in a bugs rat race?

The earlier statement of "80% of the time was wasted supporting clients" seems perfect? i.e. what else should you be doing other than supporting clients who are willing to pay with features and bug fixes?

Feel like I'm missing something.

Right, they ship a product with bugs, and than spend all of the time in fire drills instead of core functionality.

Nobody wants to pay for bug fixes.

Do more QA and avoid making your customers part of the QA team.

Initially the startup was a service company which later pivoted into customer medical product. Previous contracts were upheld, while new were piling on even after pivot. Note that this is in France, a lot of funding comes from 'collaboration' contracts between laboratories and companies, often including up to 5 different entities. All this means that you are stuck in a whirlpool of quarterly meetings. With a tiny team if your product needs even very little support for each client it piles up. On top of that this was a medical, connected, product, people have different expectations for devices with a stamp on them.

So now you have a team with about 2.5 collaboration projects per engineer, who are at the same time the tech support and SREs. With several new products in a pipeline. All of it wrapped in a bow of medical certification.

One think that startups should have in my opinion is focus. If you have enough funding to go for a moonshot drop everything else and go for it. Don't spend too much time hedging because you will never get to the goal. If it doesn't work out, too bad, but at least do everything you can to get there. Especially when cash strapped.

Could be a hardware product. Shipping hardware early is a nightmare.

> 80% of the time was wasted supporting clients and fixing bugs that were due to the fact that the product was shipped too early.

There are a lot of valuable lessons to be learnt here about product planning and dev process, but if you didn't make any attempts to fix the issues you mentioned, you probably didn't learn very much.

this has been my startup experience, too. Chasing any customer even if we had to make a lot of changes and try to support antiquated versions of things for our software to work for them. It rarely paid off. Actually, it never paid off.

Reply on news.ycombinator.com