gregplaysguitar

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.

> supports but ignores type annotations

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!

There’s a lot of value in keeping data in the same format everywhere. Why “munge” it into some other format if there’s no actual need?

“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.

Neither have a positive return as far as the gambler/insuree is concerned, if they do, they casino/insurer will not stay in business for long!

The difference is that one has a potential huge upside, the other prevents a potential huge downside