This was a super-interesting read, but I'm disappointed there isn't a description of what, exactly, was wrong about what he did, and what one should do instead. The only thing that comes to mind is the obvious one: you don't want more than the FDIC limit in a single bank account.
> you don't want more than the FDIC limit in a single bank account.
If the FDIC limit is a concern, you don't want to make the mistake of thinking it applies on a per account basis (it applies per depositor per institution per account class.)
Eh, depends. It's perfectly alright to put in more than the FDIC limit in a bank with consumer banking services. The amount of scrutiny and shit they have to put up with means that they can't really try SVB type shenanigans. You can bet your ass if Wells Fargo, UBS or Chase goes under, the Fed will bail them (you) out. The alternative would be having bigger problems in your plate than that.
Source: I'm a recent Credit Suisse business banking customer. Now UBS.
This is a very interesting, very well written post. The part that stands out the most is:
> if you needed venture capital to produce a viable small-scale business, you didn't really have a viable small-scale business to begin with. Triplebyte's break-even status was an illusion, predicated on funding that would probably never have existed if that scale were the founders' only ambition.
I wonder if there's a way to build a viable business out of a product like FastTrack that does not depend on venture capital to get going?
Arm being the one that's currently listed on the nasdaq exchange and otherwise owned by softbank isn't a totally compelling example of a European company
It is also not a US company. Where it's listed doesn't matter much. It matters where a) headquarters and other significant physical presences are located and b) where the majority shareholders reside. In that regard it is largely a European, and partially a Japanese company.
Good comment, and, basically, I fully agree, except, I really dislike your attempt to appropriate the words "programming" and "coding" here. Like, can you just explain what you mean without trying to redefine terms that have broadly accepted definitions distinct from how you're trying to use them here?
(Sorry, this probably sounds more critical than I'm intending...)
Programming requires creative thinking. Coding, historically, was a lower-paid, unskilled position.
You may think this is redefinition. It's not. This is how both terms originated. A "coder" did the unskilled gruntwork of implementation for business projects, while a programmer was holistic.
> I find it bizarre that people now use the term "coding" to mean programming. For decades, we used the word "coding" for the work of low-level staff in a business programming team. The designer would write a detailed flow chart, then the "coders" would write code to implement the flow chart. This is quite different from what we did and do in the hacker community -- with us, one person designs the program and writes its code as a single activity. When I developed GNU programs, that was programming, but it was definitely not coding.
> Since I don't think the recent fad for "coding" is an improvement, I have decided not to adopt it. I don't use the term "coding", unless I am talking about a business programming team which has coders.
In this case, it is you, and the wider cottage industry of business "coders" who are doing the appropriation. It's not your fault. The bootcamp or Super Cool Totally Serious College you likely learned from probably used the term "coder" alongside words like "rockstar!" You were given a bad definition, and never knew any better at all. ChuckMcM's comment, on the other hand, is correct. Using the word "literally" to mean "figuratively," while colloquial, is still less correct than figuratively.
The phrase "code monkey" is not a compliment, and didn't come from nowhere. It came directly from these pre-existing definitions.
Programming requires logic. If you are coding, the thinking's already been done for you. You are just doing unskilled labor akin to data entry to get the computer to actually follow the instructions.
Thing is that no one hires "coders" anymore, even if many people's jobs are in fact mostly coding instead of establishing the design. It's a weird stigma that translated to companies low key lying about what they really want out of an engineer.
It's a shame because there's a nice flow to coding once you got everything nailed down. Coders are no different from (human language) translators and like good localizers, a really good "coder" understands the subtleties of the language. If your application is concerned about scalability or performance or cross-compatibility, you aren't just googling an API and pasting in commands to get something working.
But I guess coding may not really be a thing in the next few decades if AI really does catch on.
No worries, got to use something as the holder of the definition. FWIW I read a similar essay that discussed cooks and chefs and came away seeing the many parallels with programming and coding.
I'm not sure what is meant by "data-oriented programming" (I know what "data-driven" means...) but, yes, "Data-Oriented Design" has a distinct (if somewhat nebulous) meaning which comes from game programmer culture. (And my guess is the difference between it and data-oriented programming is not slight.) Data-Oriented Design is, basically, the name given to the bag of techniques listed on the submitted webpage. I don't know if the term was coined by Mike Acton, but it was popularized by the talk he gave that is linked to on the submitted webpage. (It's an inspiring talk! You should watch it, if you have not, yet.)
As far as I can tell, Data-Oriented Design is a reaction to trauma experienced by game programmers trying to undo damage inflicted by the... inapt... application of OO techniques in game codebases by their (probably well-meaning, but ignorant) peers. (Hence the contrast in the names: OBJECT-Oriented Design -> DATA-Oriented Design.)
The keystone idea seems to be, instead of organizing your program's data as objects in an inheritance hierarchy, figure out which data will be accessed together in tight loops, and pack that data together in arrays. (I.e., prefer structs of arrays to arrays of objects.)
P.S., There's an interaction during the Q&A section of that presentation by Mike Acton which I love: one questioner asks, somewhat incredulously, (and I'm paraphrasing here) "If I were to follow the principles you have laid out in this talk, then, if I ever needed to alter the layout of my data--after having invested (perhaps significant) time already writing my program--I would subsequently be required to rewrite all the code which accesses that data." and Mike Action answers, basically, with a stone-cold "Yes."
No, it's just a really expensive game with a subscription model. What's the price to pay to get four copies of each card in every standard set? That's your quarterly subscription fee.
It would be pay-to-win if you could do stuff like, pay a fee to take a second card at once during a draft, or tutor a card from your collection during a game, etc...
Right, it's technically just expensive and that's the thing that may leave some players behind, but I bet that at competitive level, players are not missing any card they need.
Similarly with F1 after the cost caps. If you had 135M you could compete with no monetary disadvantage.
That would be a true description of any pay-to-win game — if you just buy everything available to be purchased, then you’re playing on a level-playing field.
But using this description, then the only truly pay-to-win game would be one where the win condition is literally an auction selling a “you win!” token.
I'd go around money advantage being way too significant and the money cap way too high or non-existent. Otherwise every game is kind of pay to win as getting your hands on one more chess book, or getting a better tennis racket gets you an advantage.
While mtg is not cheap, I would say that only older cards get crazy expensive and sometimes are straight out overpowered.
I think it's pay to win in the sense that there are multiple subscription tiers, and if you only pay for basic, you're not winning against the players paying for gold++.
That is exactly what "pay to win" means in the parlance of our times: the more you pay, the better chance you have to win. Tiers vs continuum doesn't matter here. The important part is that players with the same skill must decide how much money to pay the manufacturer to gain advantages over other players. If everyone had to buy the full set every quarter, then it would not be pay to win, it would just be a very expensive subscription game. There are things like sealed deck drafts where everyone agrees to buy in at the same price so that everyone can compete on skill. But there is a reason WotC doesn't allow proxy cards (just printing an unofficial copy of a card or a piece of paper with the name of the card), because they make a ton of money from the pay to win dynamic.
I agree that "tiers vs. continuum" has no bearing on the question of whether or not Magic: The Gathering is pay-to-win. I was merely pointing out that what tedunangst was describing was a continuum, not tiers.
Obviously, I'm not articulating my perspective very persuasively. Here's some additional flavor that might help (probably won't:)
1. In Magic: The Gathering, the most expensive deck is not always (or even ever, really) the best.
2. Is Golf pay-to-win? I can spend more on a set of clubs that have bigger sweet spots & will give me more distance with the same swing than my opponent's set.
3. The term "pay-to-win" comes from free-to-play MMOs.
I think most people that claim MTG is pay-to-win are just frustrated by how expensive it is. I agree. Don't play it!
1. I'd expect that in most pay-to-win video games, the top players are not also the top spenders. Depends on the amount of strategy and skill required.
2. No, because the people writing the rules of Golf aren't the ones that sell you clubs (as far as I know. Maybe there's some devious stuff going on behind the scenes).
3. Correct.
While I don't think "money is the only thing that determines the winner", Magic is absolutely is pay-to-win. It would not be pay-to-win if people could print their own cards (following a set of standards, of course), even though printing costs money.
The Wii is actually a perfect example of that philosophy. It was built using outdated, underpowered tech, but in spite of that, was a huge success because they did something unusual and innovative with it.
It's well known that long-dated treasuries are highly volatile. I think the lesson we've all learned here is that they didn't have a viable business. It seems like they were offering a product that was not profitable given their competition and reasonable risk management.
They're volatile if you trade them, right? But they're not volatile in the sense that there's uncertainty that they'll pay back. Do banks normally actively trade their long-dated bonds?
No, and that's the point. I understand that banks mark long-term bonds as hold-to-maturity (and only then can list them at par on their balance sheet). But they actually have to hold them. Otherwise, they have to mark them to market, and any sales of HTM bonds flip the entire tranche over to MTM.
So part of the problem is that SVB had a reasonable-looking balance sheet of HTM bonds, then had to sell some at market, which flipped their entire portfolio to MTM and destroyed their balance sheet.
E.g., a simple balance sheet:
Assets Qty. Par Market Total
-----
Mark To Market Bonds 10k $1k $0.8k $8Mn
Hold To Maturity Bonds 1M $1k $0.8k $1Bn
Total $1.08Bn
But then let's say I have $16M of withdrawals. I sell all of my short-term bonds for $8M, but have to cover another $8M, so I sell another 10k bonds at market price.
But, oh shit, now all my long-term bonds have to be marked to market, so now my balance sheet looks like this:
Assets Qty. Par Market Total
-----
Mark To Market Bonds 990k $1k $0.8k $792Mn
Total $792Mn
$16M of outflows have reduced the assets on my balance sheet by two hundred and sixteen million.
To allow the bond sale before they had a cash infusion basically flushed the business. I wonder if board of directors had an understanding of how it would detonate the balance sheet. After that, the regulators took the obvious necessary action.
Sure, though in all fairness, I understand it's standard GAAP accounting for all banks, and your balance sheet has to have a footnote explaining the market value as well. I.e., this particular play or accounting standard is extremely common.
It seems like SVB was perhaps a little more exposed to interest rate risk than others, and had a pool of depositors that were more likely to withdraw significant funds in lockstep.
