The CEO just needs to do more CNBC appearances and they're good.

Why does years of work matter? Serious question.

I think this is down to how investors think about how to value a piece of a company. I think about it almost the same way as I think about sports gambling.

There's a value proposition in which direction the stock is going to go and how long it's going to take to get there. It only makes sense to be invested in a stock if you think it's going to be worth more later than it is now and the amount of time your money is tied up in this stock is commensurate with the profit you may get as a result.

Investors work on limited information about companies, and having a track record can influence a buying decision one way or another. It may matter to some investors and not to others. For many, it's weighed against the price of the stock. Would you bet $100 on a company with a short track record? What about $10,000, $100,000, or more? Generally there's a point where people drop out of buying more of a stock and say that they can't justify the risk given the information they have. That's the expected value that Anthropic will receive from that investor.

Anthropic needs to worry about what that number is for a huge amount of individual investors and how to maximize the amount of money put into the cost of their stocks, and there's very little chance that they can attract the biggest pool of investor money without some of those people considering their longevity vs a more established company like Meta. It may not matter to all investors, but the fact that it will matter to some makes it a factor in the total valuation.

Possibly speaks to its moat being weak, if a dedicated team from scratch can duplicate their efforts and get to where they are today in 2 years (but not where they will be).

It's not work, but the Lindy effect makes Anthropic's outlook in 2032 very uncertain.

Because building a stable revenue base takes time. We've had many flash-in-a-pan type product but things which still make money 10 years later are rare.

Aren't they all like that?

No, most of the products today like Claude Code / Chat allow you to opt-out of training without also disabling important features like chat history.

> A CS degree was never going to provide you with all of the tools that you need for a successful career. It provided you with the basics to get your foot in the door.

+1

Aside from teaching me the _basics_ of programming and discrete mathematics, it did not help my career. I, in-fact (due to poor GPA), did not even have a SWE role out of school and had to find my own way here into a successful career. (I struggled even with LeetCode easys coming out of college) I attribute it to creating opportunities for luck (networking) and an appetite for life-long learning (which came well after college).

Exactly. Also it's incredible how many working professionals (as evidenced by this "movement") don't understand why companies pay for software to these SaaS companies.

Ironically attaching your company to a movement like this will deter people from using it.

In my opinion, most tech-like professionals miss the point of delegating liabilities.

The whole reason to pay for software is to offload the liability to a 3rd-party. In simpler words: "As a company, I have this need and I don't want to solve it myself. Also, if I pay someone, I can sue them on contract breach just in case."

The legal part of the liability offload is key in the decision, because it requires ownership.

FOSS doesn't fulfill that requirement, therefore, adopting FOSS means the user owns the liability of using the software. Companies don't need or want more liability than they currently have to, less is better.

> The whole reason to pay for software is to offload the liability to a 3rd-party... FOSS doesn't fulfill that requirement, therefore, adopting FOSS means the user owns the liability of using the software.

Let me introduce you to Red Hat.

> The whole reason to pay for software is to offload the liability to a 3rd-party. In simpler words: "As a company, I have this need and I don't want to solve it myself. Also, if I pay someone, I can sue them on contract breach just in case."

Ah management-style cover-your-ass engineering. Which doesn't work even with things like IBM contracts, never mind with anyone smaller. The problem is what they actually guarantee.

When you actually investigate the question (because you were a Google SRE and you move to a smaller company, and obviously disaster preparation starts with knowing what happens when disaster strikes): "Say, really smart manager, what does the contract actually say happens when you need the cover-your-ass provisions? Let's say AWS fails to give us machines. Let's say this software doesn't deliver. Let's say the bank connection we're paying for breaks". First observation: the managers (at a very big European telco) don't actually know the answer to this question. Or they pretend not to (I'm pretty sure they just lied to me, didn't care about anything but the checkmark, and did in fact know they did not have any option for disaster recovery because their developers had told them many times).

Answers: AWS doesn't give you a cent back, under any circumstances, does NOT get your servers back online but MAY give you 20% reduction on your future bill (and for customers in the UAE with the Iran war, they didn't)

Software doesn't deliver, then we don't have to pay the last milestone payment (10% of the cost), and the supplier does nothing anymore.

If the bank connection breaks, nothing happens. You are forced to keep paying anyway. Although, I guess you get the transaction cost for free because there won't bee any transactions. I do hear there's a small problem with that.

So, obviously, no, this does not cover the company's ass at all. It's about a manager being able to say they very cheaply did something. What will happen to the company in case of actual problems? It'll immediately cease to function, and none of these cover-your-ass provisions will matter at all. Which is, of course, what happened about 4 months later and the company's new SREs were expected to fix the shit ASAP, without ANY help from the "service" part of these platforms. We had to buy new services to get it fixed, once the service was down senior management literally got involved and approved the purchase orders, yelled at a bunch of infrastructure teams to make changes they never would and the company never got the money back from the "guaranteed" platforms. It cost about 15x, for that year, what it would have cost to have 2 providers for the service, and I'm sure that more than covered a development team for the software. And thank god we at least hosted our own source and made sure local builds worked.

By the way: they just switched to the newly ordered much more expensive platform. About 3 weeks later, focus was moved away, by management, from repairing stuff and so the ability to switch back was ... just dropped.

Let's be realistic. Most of the videos on hackertube.org wouldn't exist if it weren't for the enormous sums of money YouTube pays their creators because of...ads.

I would also be more impressed with it if they created their own video processing and serving stack.

This is verifiably not true. The majority of the value I get from youtube aren't even by monetized videos.

This is just outright wrong.

The vast majority of all yt content makers do NOT pay the bills with ad rev but sponsors.

These platforms are sucking every penny they can from everyone at every step because number must go up. That is what they are suppose to do being public.

A private company like steam with a sub pay model where creators still can do sponsorship videos throwing out the attention algos would be a better product and still be plenty profitable.

Not all companies should be public and often the best are not.

> when I say things like OpenAI and Anthropic are gonna crater

But how do you know that? (And no I'm not shocked by this statement, it's just odd to say it with conviction.)

Two companies valued at 3 trillion dollars who sell a product anyone can make that falls in cost by 50% every single quarter.

I don't understand how anyone could argue that doesn't crater with any conviction.

I know Google SREs who do feature development on the infrastructure support they support alongside their devs.

There's nothing unique about junior SREs. They're replaceable with almost any "vanilla Dev". You don't really build a unique experience or expertise until Senior+.

The difference between a junior SRE and a dev is that during an outage the dev will take responsibility for their own code only[1]

While the SRE will follow the problem to the next layer or component and try understand what is going wrong there even though they never heard of the system 10 minutes ago.

[1] "I know I'm on call for this team but the guy who sits next to me wrote that code" is something I've heard way too many times.

Fair.

That's where my analogy breaks as all of them do.

My point is that @pluc comments suggests too specific and I wanted that his examples break down in different levels of expertise.

Nothing I mentioned deals with disposability of engineers.

At 40 YoE, it seems like your heart was probably never in it. I really miss coding at my day job. I still code plenty for my personal projects.

Let's not rush to such judgment - our desires change as we age, the field has changed (including what nose-to-the-grindstone coding looks like) and burnout affects many.

Plus, some people enjoy the rigors of solving in-the-weeds code problems and others enjoy building systems-level designs. This was always true.

Exactly, thank you. I'm much more interested in how systems interact gracefully, addressing failure modes and building for resiliency/scale.

Do you need good quality code to do that? Sure, but that's just another line-item on the laundry list of things to make it happen.

You guys act like the React component nonsense from the past 10 years is the same as the code I was learning at age 16. It's by far and away completely different. And none of it has been audited by Daybreak.

I'm very happy to let the robot handle any incidental React or other extraneous tools that end up adjacent to the core work I'm doing. It avoids getting blocked without interrupting teammates or spending time and cognitive capacity on stuff that has no lasting value in my work.

That's precisely my point when I say the field has changed even for "true code writing."