Comment by yobbo
1 day ago
Many startup business models have no chance of becoming profitable unless they reach a certain scale, but they might have less than 1% probability of reaching that scale. Making it scalable is easy work since it is deterministic, but growing customers is not.
Another perspective is that the defacto purpose of startups (and projects at random companies) may actually be work experience and rehearsal for the day the founders and friends get to interview at an actual FAANG.
I think the author's “dress for the job you want, not the job you have” nails it.
Unfortunately, you can't really get experience from solving hypothetical problems. The actual problems you'll encounter are different, and while you can get experience in a particular "scalable" stack, it won't be worth its maintenance cost for a company that doesn't need it.
I guess the work is deterministic, but it often (unintentionally) makes the systems being developed non-deterministic!
Ah yes. I once worked at a startup that insisted on Mongo despite not having anywhere near the data volume for it to make any sense at all. Like, we're talking 5 orders of magnitude off of what one would reasonably expect to need a Mongo deployment.
I was but a baby engineer then, and the leads would not countenance anything as pedestrian as MySQL/Postgres.
Anyway, fast forward a bit and we were tasked with building an in-house messaging service. And at that point Mongo's eventual consistency became a roaring problem. Users would get notifications that they had a new message, and then when they tried to read it it was... well... not yet consistent.
We ended up implementing all kinds of ugly UX hacks to work around this, but really we could've run the entire thing off of sqlite on a single box and users would've been able to read messages instantaneously, so...
I've seen similar with Firebase. Luckily I took over as tech lead at this company, so I was able to migrate us to Postgres. Amusingly, as well as being more reliable, the Postgres version (on a single small database instance) was also much faster than the previous Firebase-based version (due to it enabling JOINs in the database rather than in application code).
3 replies →
Dawg tinder was operating at 20M DAU with all its DB based on Dynamo. Probably still is.
And yeah there was ton of those issues but yolo
I watched a company you've probably heard of burn stupid amounts of money because one guy there was trying to build a personal brand as a Graph Database Expert, and another had fallen hard for Neo4j's marketing. Stability issues, stupid bugs, weak featureset, mediocre performance for most of the stuff they wanted to do (Neo4j, at least at this time, was tuned to perform some graph-related operations very fast, but it was extremely easy to find other graph-related operations that it's terrible at, and they're weren't exactly obscure things) all stretching out project development times to like 2x what they needed to be, with absolutely zero benefits for it. So fucking dumb.
Meanwhile all they needed was... frankly, probably SQLite, for their particular use case, having each client of theirs based around a single portable file actually would have been a big win for them. Their data for each client were tiny, like put-it-all-in-memory-on-an-RPi2 tiny. But no, "it's graphs so we need a graph database! Everything's graphs when you think about it, really! (So says Neo4j's marketing material, anyway)"
>“dress for the job you want, not the job you have”
I don't think I should dress down any further :>
> Making it scalable is easy work since it is deterministic
I don't think that necessarily follows. Especially the language choice is almost impossible to change - look at Facebook, Dropbox, etc. Facebook ended up creating an entirely new language that only they use, because it was impossible to rewrite in another language.
Language choice (and probably database choice too) are essentially locked in from the start, and they do affect scaling.
Growing customers is probably harder, but I don't buy "do everything in hacky Bash scripts because you can fix it later". Nor do I think having solid foundations means you need to be less agile. Would Dropbox have been less successful if they wrote their backend in Typescript? I doubt it.