"Perfectly implements" is doing a lot of work there. Enterprise software is very rarely perfect out of the box, and the issue with bad code is that it can make it extraordinarily hard to solve simple problems. I have personally seen tech-debt induced scenarios where "I want a new API to edit this field in an object" and "Let's do a dependency upgrade" respectively became multi-month projects.
> Perfectly implements" is doing a lot of work there. Enterprise software is very rarely perfect out of the box
Fair, by “perfectly implements” I meant to say that it correctly implemented the core invariant of a double entry ledger (debits = credits), not that it was 100% bug free
Since most won't actually deal with fintech (I don't know the stats on HN, but I'm talking devs as one industry), your first "a" example might actually be better than your first "b" example, depending on the complexity of the software. In lots (probably most) of industries, having a good codebase would mean architecture decisions were solid, but the domain/service layer is bad. Maybe my experiences don't match most of the HN crowd, but usually I get stuck with very detailed domain/service rules, but the architecture is a problem where too much memory or CPU is being used, just to abstract away the actual rules of the application (the purpose). Usually when I've been brought in to rebuild an application, the client is fine with the results, but they are upset over performance and/or cost to run the application. For anything of actual complexity, it's usually the supporting code that is the biggest failure, because complex apps usually have decent requirements. Now, if the requirements were bad, and the architecture was bad, AND the domain/service layer is bad, I don't know if there's anything to fix that.
I'm one of that 0.1%, since my yearly salary is more than about USD90k. And my attached wealth is the most typical kind, too: my wife and I bought a place to live, which we haven't sold in the 20+ years since moving in. It probably could be sold for a fair bit more than we paid: untaxed wealth.
I suspect that we won't pay 100% tax on whatever we earn when we sell, if we sell, but if we were taxed 100% I'm sure something nice could be done with that money.
I'm quite impressed by the rhetorical skill here. It's easy to overlook that what they're saying is "by taxing something/someone 100%, it would be possible to...", ie. "If pigs would fly, it would be possible to..." and making it easy to overlook that takes real skill.
Why build each new airplane with the care and precision of a Rolls-Royce? In the early 1970s, Kelly Johnson and I [Ben Rich] had dinner in Los Angeles with the great Soviet aerodynamicist Alexander Tupolev, designer of their backfire Bear bomber. 'You Americans build airplanes like a Rolex watch,' he told us. 'Knock it off the night table and it stops ticking. We build airplanes like a cheap alarm clock. But knock it off the table and still it wakes you up.'...The Soviets, he explained, built brute-force machines that could withstand awful weather and primitive landing fields. Everything was ruthlessly sacrificed to cut costs, including pilot safety.
We don't need to be ruthless to save costs, but why build the luxury model when the Chevy would do just as well? Build it right the first time, but don't build it to last forever. - Ben Rich in Skunk Works
That's an interesting story, but not a great analogy for software.
If a technology to build airplanes quickly and cheaply existed and was made available to everyone, even to people with no aeronautical engineering experience, flying would be a much scarier ordeal than it already is.
There are good reasons for the strict safety and maintenance standards of the aviation industry. We've seen what can happen if they're not followed.
The fact that the software industry doesn't have similar guardrails is not something to celebrate. Unleashing technology that allows anyone to create software without understanding or even caring about good development practices and conventions is fundamentally a bad idea.
Soviet engineering wasn't sloppy. It was designed for robustness, loose tolerances and simplicity. It was well thought out design. In the same way that as much thought went into the cheap alarm clock than went into the Rolex watch, maybe even more so, the engineers just had different requirements.
It takes a lot of work to make cheap, low precision parts work together reliably. The Rolex has it easy, all the parts are precisely built at a great cost and everything fits perfectly. With the cheap alarm clock, you don't know what you will get, so you have to account for every possible defect, because you won't get anything better with your budget and the clock still needs to give you an idea about what time it is.
The parallel in software would be defensive programming, fault tolerance, etc... Ironically, that's common practices in critical software, and it is the most expensive kind of software to develop, the opposite of slop.
There's a narrative that gets passed around in physics circles about how the Soviets were better at finding creative and analytical solutions than Americans, because of the relative scarcity of computing versus intellectual labour resources.
It would make sense to me that a parallel mechanism could apply to Soviet engineering. If material and technologically advanced capital are scarce, but engineers are abundant, you would naturally spend more time doing proper engineering, which means figuring out how to squeeze the most out of what you have available.
If you intend to hold to maturity then you should accrue the bond coupons over time, that’s the modal case
If part of your bond portfolio is available for sale, then you should use mark-to-market accounting, which prices in the present value of future coupons and the discount rate as well.
IIRC this was one of the issues with the failure of SVB, they were forced to sell their bonds
and realize a huge MtM loss
Most cloud providers have a similar offering to AWS Lambda, plus it is not that hard to convert your code from the event handling pattern impose by AWS Lambda to a long running container running in K8s or VMs like you are doing yourself
IMO the lock-in fear is overblown as the top cloud offerings (S3, Lambdas, K8s as a service etc) are already commoditized among the top providers, the exception being specialized databases like DynamoDB, Spanner, Cosmos …
Not saying there wouldn’t be some major work to switch your operations from eg AWS to GCP, but it is also not a hard lock-in
I hesitate to call Hetzner "cloud". Hetzner is an EC2+S3 competitor, not an AWS one. IMO the minimum for being a real cloud is you need hosted Postgres, hosted Kafka, hosted Kubernetes, and S3-compatible object storage. Without the first three Hetzner is just not in the same product category. Nobody sensible buys AWS for the comically overpriced EC2.
Another missed component is a real autoscaling load balancer. This often gets missed and taken for granted. Possibly due to if you haven't seen a good one (AWS) you might not realise what you're missing. Most aspiring "cloud" companies have fixed capacity single tennant load balancers which is not cloud in any definition.
It's far cheaper to do it yourself, but the entire point is that you outsource the management of the service. Lots of people don't want to deal with database failovers, or - god forbid - deal with Kubernetes control plane issues.
On the opposite, it is more expensive, and any large enough company should probably at least consider renting metal rather than services. For a small org, though, it lets you avoid a lot of infrastructure/ops work.
“Air conditioning. … It changed the nature of civilization by making development possible in the tropics.
Without air conditioning you can work only in the cool early-morning hours or at dusk. The first thing I did upon becoming prime minister was to install air conditioners in buildings where the civil service worked. This was key to public efficiency.”
I love this video, and similar by NightHawkInLight,[0] but (as they would agree) it's not a commercial product just yet.
For a while I've thought the first thing to coat with a fancy "Free AC" paint should be... the AC! For most sky-cooling rigs the main cost is pipes or panels on the roof to move heat from inside to outside, but AC is already moving heat. AC units operate at a higher temperature, so it should emit more IR radiation as T^4 (meaning a small increase makes a big difference). Most AC has a pretty good sky view, but maybe not as ideal as the roof.
It seems ironic to use "No AC" paint on your AC, but the physics and economics doesn't lie. Per square inch it's probably the most effective place!
As someone who grew up in a tropical country and has moved to a temperate one, this rings very true.
It is significantly easier to walk in 20C, 50% humidity than to walk the same distance in 28C, 100% humidity. You get lethargic really quickly in a hot humid area.
Every physical action just feels easier in a temperate climate than in a tropical one. Which is why air-conditioning is such a big deal - it lets you get temperate conditions in a tropical location.
(I'm not saying that those are a Mafia hallmark, but I do wonder whether the robes would make sense in Brazil. As far as I'm aware they are the gold standard of heat-adapted clothing. They probably don't do much about humidity.)
How do we square this with what happened when imperialist people went into areas with much hotter weather to establish colonies? Were the colonists less efficient back then when air conditioning didn't exist yet? Or could it be that these area weren't as hot in earlier centuries as they are today? Also, what are the implications for countries with imperialist pasts that are getting hotter due to climate change?
Thank you for sharing this article. I had never learned of this type of fan before, but I always wondered about how the people from Europe who weren't used to the heat would have coped with it, especially with how in recent times there has been news coverage about heat domes and infrastructure that might have been designed for a different climate.
These are, effectively, different use cases. You want to use (and pay for) Express One Zone in situations in which you need the same object reused from multiple instances repeatedly, while it looks like this on-disk or in-memory cache is for when you may want the same file repeatedly used from the same instance.
Is it the same instance ? Rising wave (and similar tools )are designed to run in production on a lot of distributed compute nodes for processing data , serving/streaming queries and running control panes .
Even for any single query it will likely run on multiple nodes with distributed workers gathering and processing data from storage layer, that is whole idea behind MapReduce after all.
It's true that formal wealth systems (like land, stock ownership and trademarks) require an elaborate legal and cultural infrastructure to maintain — but only at scale. The absence of such systems doesn't eliminate wealth inequality, it just changes how it's enforced.
In less formal or collapsed systems, wealth and resources are often controlled by a ruling oligarchy or individuals whose hard power acts as a de facto property right.
For example, many argue that Vladimir Putin is one of the wealthiest individuals in the world, despite lacking formal ownership on paper — his political and military power effectively grants him control over immense resources. Wealth inequality ultimately stems from control over resources, whether legitimized by law or enforced through power.
Power people have power because of power is more of a movie trope than the actual mechanics of the world you live in. Wealth is exclusively abstract legal constructs in the modern world. You might be surprised to know that even Putin's wealth is tied to legal ownership structures, (regardless if they're maintained by bogus shell companies, he has effective rights to the property). Whatever niche counter-example comes after doesn't influence how global inequality is administered or experienced by the majority of people.
"Moving on to the real world, I note that following a sea change in interest rates, non-investment grade public and private debt now offer prospective returns that are competitive to those historically seen on equities. I believe investors should consider shifting capital to this area if they are (a) attracted by returns of 7 to 10 per cent or so, (b) desirous of limiting uncertainty and volatility, and (c) willing to forgo upside potential beyond today’s yields to do so. For me, that should include a lot of investors, even if not everyone."
Howard Marks is one of the most respected investors in US with a stellar record. His newsletter (Buffet reads it) and books are widely read and respected. He doesn't need the marketing as some up and coming financial "influencer".
a) a pristine, good codebase that follows the best coding practices, but it is built on top of bad specs, wrong data/domain model
b) a bad codebase but it correctly models and nails the domain model for your business case
Real life example, a fintech with:
a) a great codebase but stuck with a single-entry ledger
b) a bad codebase that perfectly implements a double-entry ledger
reply