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
Well, the nice thing with Python types is that the _only_ difference to untyped Python is the type annotations. Last time I worked with TypeScript (two and a half years ago), it felt more like a different language _similar_ to JS. In my experience it was quite... viral. With MyPy I've genuinely seen just specific parts of a code base become typed and didn't notice any friction.
I wonder what would happen if that proposal for type comments in JS went through. Would TypeScript become just a type checker / optimizing compiler?
Closure team have also deprecated a lot of the old tooling. Closue was ahead of it's time for sure and as someone who heavily used the Closure Library and Closure compiler in advanced mode, it is sad that it did not catch on.
However using TSickle you can transpile Typescript into javascript which closure compiler uses for advanced optimisations.
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
Apart from one high profile NZ startup (possibly the same one) most companies seem to be okay. Lots of companies still hiring although not as aggressively as a year ago.
I know someone who lost their job at gitlab and various others working remote for US companies are worried. Most NZ It jobs are at companies serving local users or smallish NZ companies serving global markets. Relatively few work for a big global company that could easily move their job elsewhere.
It tends to release a lot of insurance money into the economy and a lot of work restoring things. Not good for inflation. A bunch of the mid/large (for NZ) tech sector companies tend to be a bit divorced from the NZ economy as many target a global audience, biggest factors tend to be the exchange rate/cost of living.
Boom times for anyone in road building and construction, probably.
It's been described as a billion dollar weather event on par with the Christchurch earthquake 10+ years ago.
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
A type of traditional story about leaders is how they showed up anonymously to check what was going on. Literally going back thousands of years.
I was just reading a story about how a king pretended to be a wandering drunken lout, and when his guards stopped him, he bribed some of them with gold, but others whipped and beat him and put him in a cell. Then he revealed who he was, and the guards who didn't lock him up and beat him, were whipped and banished.
That's a visionary with control/esteem issues and an inability to communicate. Micromanaging is a lack of trust in yourself as a leader and your team's ability to deliver. Good/great leaders never micro manage because they trust the vision was communicated and received and seek feedback to confirm this. When I can't connect or trust my team I've failed at leadership.
Failing at team leadership doesn't mean you can't be a detailed product manager with a strong vision for a successful product. But you shouldn't be managing the team, those responsibilities need to go to someone focused on the team and not the vision
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!
They're all exactly the same software, the only customization is configuration (more or less servers, getting data from this or that S3 bucket, etc.).
To be honest it comes down a lot to the tools you are using, you have to make sure they scale. For example we deploy one CloudFormation stack per customer (3-4 actually but it's not important), and those are deployed all as part of a single deployment pipeline (think AWS CodePipeline type of thing).
Well, turns out this pipeline thing does not like deploying to thousands of targets at once and only supports a few hundreds at most. We had to refactor the way we do that part because just loading the page with all the targets was taking 5 minutes. We also had to split our targets across 2 pipelines, and soon we'll have to go to 3, and it's a pain in the ass and a big engineering headache every time.
The main issue comes from operations, invest in automation ASAP, and make sure you make your customers accountable for their own mistakes. Half of our tickets are raised because a customer changed something on their side without thinking of changing the configuration in our system, which then breaks. If we alarmed them instead of ourselves it would be a lot easier.
Oh, interesting. I don't think it was that though. My understanding was that somehow the entire truck ended up flipping around 180 degrees (or more). And I didn't quite understand why that was a good thing - I think it was mostly about letting you do new kinds of tricks that weren't otherwise possible.
