Wonder if the real value of LLMs/AI is similar to microservices in that it solves an organisational/culture problem.
In this case AI allowed the developer to make a change that the organisation would not have allowed. Regular rewrites don't let you signal to investors that you are AI ready/ascendant/agentic (whatever the latest AI hype term is) so would have been blocked. But, an AI rewrite.
That assumes they don't accelerate the accumulation of technical debt. For each item cleared how many new ones are added. LLMs accelerate your good engineers and your bad ones. So the slop likely increase faster than it can be cleared.
And it will affect good engineers and turn them into worse engineers too
AI benefits rely on these good engineers having 5, 10, 20 years of experience pre-AI designing (and fully, thoroughly understanding) these systems. What's going to happen to that engineering skill after 15 years of AI use?
It ought to only get better as it gets honed at an even faster pace than before, utilizing techniques and algorithms that would have been out of reach due to outside constraints.
> In that decade, this company was behind the curve
I like to think there is no curve only fashion. I've seen company's that were so behind that they managed to avoid adopting disasters like microservices etc. I've seen companies ahead of the curve go from monolith to microservices back to monolith.
Also funny that the ops team is now back just rebranded as the platform team.
Pretty much. Using "old" tech (assuming its maintained) is not "being behind" or "having technical debt". If stuff works and there is no meaningful gains from switching, you're doing engineering correctly.
It might be seen boring. Brakes in my bike are boring. I like them that way
Exactly! For instance, we had pull-based monitoring 20 years ago (Zabbix et al), but we abandoned it because it scaled poorly, favoring push-based agents (for InfluxDB, KairosDB etc). Now Prometheus is all the rage, yet we’re hitting the exact same scaling walls these systems had before. In a few years, we’ll rediscover push agents and call them the best thing since sliced bread.
Yup, same way people are starting to realise/remember having your compute next to your data is a good idea (maybe lambdas/serverless are not so hot because they get in the way of this).
Spacetimedb, convex, etc are basically the revenge of stored procedure.
If we’re trading war stories, one of my first software jobs was developing an electronic medical records system. We didn’t use VCS. At the end of the day/task, you send the director the file you’ve changed with a txt file of which lines were changed.
The director made sure things compiled, then we would drive down to the hospitals and copy the dlls into each PC one by one. And because hospitals can’t shut down their computers willy nilly, we could only deploy on weekends or public holidays. Not weekday nights because the directors have to be home for the kids.
That was in 2014. They’ve worked that way since the late 90s and ‘no point changing what works’.
If you read the article - or know anything about platform engineering - it should be clear that a platform team is certainly not just a rebranded ops team. The success criteria are entirely different, just for a start. Most ops teams don’t have the skillset to be a credible platform team.
That's a cute hot take, but it most likely comes from not having come across an environment where this is needed, so instead you may have seen people cosplaying as much bigger companies.
A true platform team is responsible for implementing and maintaining an internal platform for automated deployment and operation of a company's software. The platform is essentially a product, where the customers are developers and anyone else who has a stake in the deployment, maintenance, and operation of the company's software - including the ops team! I.e. strictly speaking, an ops team is a customer of the platform built by the platform team.
Done properly, this automates away a lot of what ops teams and "devops teams" do, because it allows fully automated self-service by developers. Developers should be able to create new environments and deploy new and existing services without opening tickets to some other team. Those environments and services are fully compliant out of the box with company policies and architectural decisions.
People sometimes think that this means that if you let devs submit PRs for terraform files and, say, k8s configs, that that's a "platform". But no, that's just shifting that kind of work to developers, it's not automating it. Under the hood, a platform might use those tools, but if deployment of environments and services requires interacting directly with generic tools that can be configured however a developer wants, that's not an internal platform.
Single writer will outperform MVCC as long as you do dynamic batching (doesn't prevent logical transactions) and all you have to do is manage that writer at the application level.
Concurrent writers just thrash your CPU cache. The difference between L1 and L3 can be 100x. So your single writer on a single core can outperform 10-100s of cores. Especially when you start considering contention.
Here's sqlite doing 100k TPS and I'm not even messing with core affinity and it's going over FFi in a dynamic language.
mmap is nice. But, I find sqlite is a better filesystem API [1]. If you are going to use mmap why not take it further and use LMDB? Both have bindings for most languages.
It's the opposite. The less competent the average developer the more valuable coding LLMs become (as the only way for those bad developers to generate ok code). Eliminate the good developers and even bad coding LLMs become valuable.
The docker desktop license requirement is a factor, though. You need a paid subscription if your company has something like 250 employees or $10 million in annual revenue
Since they bought bitcoin while their stock was worth ~2-4x what it is today, I’d say the “arbitrage paper certificates for digital 1s and 0s” play worked out pretty well overall.
Bought btc for $10k and $51k (about 60/40 respectively) and it’s trading for $65k 5 years later. Dunno what other buying/selling they may have done.
From Wikipedia:
> In October 2020, Square put approximately 1% of their total assets ($50 million) in Bitcoin (4,709 bitcoins), citing Bitcoin's "potential to be a more ubiquitous currency in the future" as their main reasoning.[52] The company purchased approximately 3,318 bitcoins in February 2021 for a cost of around $170 million, bringing Square's total holdings to around 8,027 bitcoins (equivalent to around US$500 million in 2021, around US$481 million as of July 2024).[53]
You have to compare it to what else they could have done with the money, such as investing in their own growth, or even giving it back to shareholders if they had no good ideas what to do with the money.
I did! If they invested it in themselves it would have been a 50-75% loss, same with doing a buyback (return the cash to stockholders) at a high stock price.
Dunno what better proxy I could
use for how it would have went other than their actual stock price. Unless we are to think their next best idea that they didn’t invest in would have done better than all the other things they did invest in. But that’s very speculative.
Instead they got a blended 300% gain on btc.
Should have sold the entire company for cash and bought bitcoin at the timelines they did.
Maybe if they'd invested in themselves they would have been able to expand (eg. they could have hired more sales people or spent more on advertising).
If they truly were unable to find a reliable investment then they should have given the money back to shareholders instead of speculating on a non-productive non-asset with awful negative externalities.
In this case AI allowed the developer to make a change that the organisation would not have allowed. Regular rewrites don't let you signal to investors that you are AI ready/ascendant/agentic (whatever the latest AI hype term is) so would have been blocked. But, an AI rewrite.
reply