nawgszy

> >If it's already running in production you have to hope you don't accidentally corrupt production data

Or you write use a read replica to transform your data into a non-live DB and validate it before you put it into production, with backups of your final old schema available? Plus I really don't think a migration is that hard. Much harder than having a litany of shitty backends you have to glue together in your front-end app, trust me as someone who's done both.

I mean, I hear you, persisting data is hard, but that's not the database's fault, it's because you pick two of three on data: performance, persistence, and flexibility

> a database typically

But that's not the "worst performing" part of the stack, that's the highest latency part of the stack. Is there some specific reason you can not have co-located web & db servers? Also, is there a reason you still reference 2012 disk numbers when SSDs clearly have reduced all "disk" operations by an order of magnitude?

> just extending the data

What I mean by this is if you start with a minimal amount of columns in your database, and someone is like "we need new property x", it's easy to add X outside a migration - adding new columns or new tables does not require migrations if you don't modify existing columns

So this is my approach. Use as few bits as possible to persist your data, and then you can generally add new features migration-free

Well, this was maybe a bit entry level description.

Q: "databases are often the worst-performing part of the tech stack" - compared to what? nginx throughput? I find this to be a bit of a strange view, surely business logic is always the slowest part of the tech stack

Q: "What happens if that int should actually be a float?" - how often do you actually need to run migrations versus just extending the data? From my end, I have a small idempotent database schema-maintaining tool, and if I need a new column or a new table there's no need for a migration, and you know your whole stack will interact with the new schema or old schema identically assuming you set sane defaults etc. I've built a lot of medium-quality low-traffic apps so I'm yet to encounter a real-world case where a migration wasn't just bad planning

Could you say more about some of these times? I'm curious what it means in more concrete terms.

I only say this because I am a UI engineer who has been in some scrappy situations, so obviously I don't get to change the data model. What kind of structures do you find that "hit the database too hard" or otherwise invoke performance penalties?

Just what we all want on our production hosts.

A very agreeable comment. I think your edit surmises it pretty well actually. Take care!

That's exactly the distinction I was making. Do you call Ericsson a tech company? I certainly never hear them in that bundle.

Again, "tech" != "technology" in this domain in my view. It's the double-great-gp or so that says it, but "tech" in my view leans towards companies with humungous software outreach and data ownership, so clearly FAANG but also Microsoft, Palantir, data warehouses, that's the kind of thing I put in this "tech" bucket. It's a type of company that probably knows more than it should about a lot of things.

And again, this isn't the "Wikipedia" definition (which itself has context-based caveats...), but my opinion and experiences involve this being the sphere of companies one calls a tech company today. I apologize for my inflammatory tone in the other comment and hope I have explained my point, even if you hold a different experience

What kind of companies do you call "tech" companies then? I can't really understand the objection I'm facing, when people tell you their stock portfolio is heavy in tech do you really think companies other than the one I listed? I live in the Bay Area so maybe things are skewed to "local" companies but I held a similar opinion when I was still in Canada too...

EDIT: Just to hammer it home, search "is faang tech" and weep that "corporatefinanceinstitute.com" is on my side

I'm not sure if this is intentionally obtuse, but yes "tech" as a slang term doesn't mean "technology", it describes a type of company largely known for the prowess and scale of their user-facing software. This includes such entities as Facebook, Google, Apple, Microsoft, Netflix, and Amazon, but is not inclusive of course.

Tesla, on the other hand, clearly produces technological artifacts - quite impressive ones, at that - but they are not a "tech" company within the colloquial context you've stumbled into

I guess this might not strictly belong to "the package ecosystem", but I strongly disagree that you can compare the npm packaging story to the pip packaging story. Publishing to npm, hosting your own npm instance, configuring npm to look behind proxies for certain packages, an opinionated `package.json` with real functionality beyond dependencies, a unified entrypoint, wow it actually boggles my mind to hear Python people say pip is even in the same room as npm.

Definitely let's be clear - babel & webpack and the associated ecosystem are a pain, but those are mostly borne of necessity to transpile HTML/CSS/JS from frameworks, and not because node.js itself isn't a decent language.

Finally, I don't really follow all this business about the lack of standard library. Can you explain to me what you mean? What parts of the Python standard library are a part of your everyday toolkit? I've built a lot of web apps over the years and the only time I've ever used lodash is for throttle and debounce.

Fair enough, that's a good counterpoint, and I do agree seeing all the data from the source without our limited bucketing would be very interesting.

I agreed with you at first, but I recall the Bay Area having one of the earliest shutdowns in the US, and that started March 17. While some companies were definitely sounding the WFH alarm about a week prior to that, I think the March -> April jump would've been more incongruent with April -> May jump unless COVID wasn't the only driving factor behind the August -> March growth in the first place.

This article feels a bit "no shit", but there are a few interesting numbers in the table there.

* August 2019, 16.1million monthly users, 1.2billion revenue

* March 2020, 39.5million monthly users, 4billion revenue

* June 2020, 45.6million monthly, 7.2billion revenue

Not sure how best to format on here, but this is apparently a high growth thing both before and during covid.

Well, then you can just work out a deal to not monetize it.

Your objection is of course valid - extra workload on top of a normal job probably has its limits. But the fact one is willing to pay those who are willing to be paid for such an interview doesn't suddenly make it a strict requirement ha.

I must say though, I also view the interview standard I've faced - quick phone screen, 1h tech screen, 4-6h onsite (probably online now) - as adding up to a lot of time very quickly, especially as the "onsite" time is of course awkward when it means you take PTO to go to an interview. In this sense, I'd probably rather have an ~8-12h coding task than a 4-6h onsite. Maybe even a higher factor