The fact that it is both the end of coding as we know it and also just another tool is essentially the point of the post. It doesn’t quite come through in the title.
Author here - this kinda feels like a controversial take, because so much productivity advice seems to focus on blocking out distractions. I'm not sure that it is though? Every high-performer I've spoken to on our team and outside seems to work on similar principles. I think the key is balance - as with most things. Would love to hear your thoughts.
That’s how TS works too though - compilation just strips the types via babel etc, with type checking a separate process. You opt in file by file by switching .js to .ts
That sounds like a query planner… but it’s fundamentally not really what dynamodb is about. Query planners are amazing but the tradeoff is unpredictable performance - dependent on traffic, data size etc. Dynamodb offers “predictable performance at any scale” precisely because it doesn’t offer this sort of abstraction.
In New Zealand - most layoffs I’ve heard about have been US companies trimming offshore staff. At least one high profile local startup has laid people off though.
Speaking as a hiring manager it’s definitely been easier to find people since around mid 2022
The author isn’t claiming that micromanaging is good - it’s not. But I wholeheartedly agree that it’s better than being absent. Good leaders create great things by caring about the small details and taking responsibility for them. It’s a fine line between that and micromanagement, but I guess one mark of a great leader is that they’re able to tread it
We used to use pgtap extensively, but ended up removing it in favour of testing queries as part our regular nodejs application tests, via a db client - the ergomonics of the test tooling is far better, and I don't think we really lost anything.
Out of interest are you deploying exactly the same software to each instance? Or are there customisations?
My work deploys an instance per customer, and I haven’t encountered the same problem, but they number in the tens at this stage so not at the same scale yet.
Would love to hear any dos or don’ts you’ve picked up, being further ahead in terms of scale!
“Flexibility” isn’t why nosql patterns are useful - at least not in the sense of fewer constraints on your data.
Imagine you’re writing an editing interface of some sort with images, text blocks etc. Each is conceptually a “node” but have different attributes. A single node table with a column per attribute means redundant columns. A table per node type introduces other problems because you need to query all your nodes together. Basically however you model this you end up with tradeoffs and real apps can obviously get much more complex - next thing you have 50 tables and a complex query just to get the data out.
Contrast to the other extreme - storing the whole thing in a single hierarchical json document. There’s no restriction on the data shape, and you can just pass the whole thing around as json. Versioning becomes much simpler because you’re versioning a single document. Your export format is just the json.
There’s tradeoffs of course, and often a middle ground is the right approach - but json columns with validation definitely have their place.
They mentioned that most of the services are on-demand pricing, that’s why it’s cheap for a personal instance. Production presumably costs much more due to much higher usage.
fwiw plenty of overseas companies are hiring remotely in NZ these days, some explicitly eg atlassian, gitlab, but anecdotally, many others are willing to hire here even though their job ads say US only. This is pushing salaries up in a big way - not to parity, but a heck of a lot better than it used to be. Worth looking around if your salary hasn’t changed in a few years :)
IMO the best way to use this is as a way to determine what’s changed between your canonical dB schema (well organised and easily understood DDL) and migrations (which are what gets deployed, but don’t work well as a dB reference). So you edit the schema, then use migra to generate a candidate migration for the changes which you review before deploying.
Tusker (mentioned in other comment) does it this way; my company has used the technique very successfully for several years via some lightweight tooling built around migra.
I used to do this before I discovered renovate [1] - now we spend time working on major upgrades but minor are generally automatic (assuming they pass tests)