I think your reply and the op are actually saying the same thing. The is almost 0 chance for a game to be 100% handmade. Even I would want to, I would still use llm to generate tests.
I think the nuance is always there. The disagreement seems to be the semantics.
Cannot just transplant one company's situation to another. Market tolerated Musk because its Musk. Musk has several unique qualities:
- He has track record of making bets in the past and payoff.
- He is way better at working in hardware space than software. His ai data center built out is very fast.
- He is similar to Zuck that he would pivot fast towards whatever is making money. The llm bet might not pan out as good as he thought, but he quickly transitioned into a compute seller
- He is very good at financial engineering. This is an often overlooked quality of musk. His spacex ipoed at the best time and beat both anthropic/openai to the market. Now the other 2 are trapped in the current financial situation.
There is a conspiracy theory that the tokenmaxxing period was anthropic/openai ipo play. They do the tokenmaxxing to revenuemaxxing first, then time the ipo window to show they had the the huge growth to justify their price tag.
However Elon was able to ipo before them which took a lot liquidity of the market. Their financials are exposed. The market condition and sentiment now is in the gutter. It would be very interesting to see how these would pan out
That's my theory, which I've seen being echoed here a few times. Encourage increased usage, suddenly raise prices, capture the photo-finish in the short lapse between prices going up and usages adjusting, and present that goldilock point-in-time to the investors as the new normal.
Requirements engineering still applies to senior engineers. You are given a problem and you need to work out the requirements and the path to completion.
But for staff engineers, they need to to discover the scope themselves. That's where "inventing" coming from. Not saying inventing is a good word here, but requirement alone is not enough for staff level's work
"Requirements Engineering", "Writing Code", "Writing Documentation" are all areas of work that are independent of seniority in my point of view.
I might send a junior to a well-meaning customer that already knows exactly what their requirements are to just document them and learn the process. Or I might require a principal engineer for the requirements engineering of: We need a new programming language. Let's figure out the requirements for it and what abstraction level is actually feasible for the target hardware platform.
Same for writing code: A junior might write code, a staff engineer might write code. Just likely on very different levels.
If an engineer comes to a manager and asks for budget for work they invented, I'd expect the answer to be something along the lines: "That is nice, but can we please focus on the stuff we are required to do?" That alone would be reason enough for be not to put ideas that way, but to come up with a requirement why it makes sense to do the work.
You are not talking about the expectations in terms of the corporate levels. Staff and senior have clear definitions in tech companies. A staff(l6) is the team lead who is required to find the scope for himself and team. That's in his job description. If he can't do that he would get pipped or fired.
A senior(l5) is the tech lead on the project level. He is not in charge of handling the team's scope. As long as he handled his own projects well, he would usually pass the review cycle. The difference is crucial. At staff and above, the engineer's responsibility is vastly larger than a senior's.
I am not saying a senior can't do a staff's job - that's how he get promoted once he demonstrated that he is operating at a staff level, i.e "inventing" scope for his team. But a senior's scope is much smaller than a staff's.
This applies to almost all US medium to large tech companies
There is also insane amount of debt from ai related investment. China's free model is crushing the ai margins while these companies need to pay their debt and obligations. The debt bomb clock is ticking.
> and it does not require anything close to that to maintain their network.
If it's so easy to disrupt visa/mastercard payment network, they wouldn't be able to charge this much. Payment is a highly competitive business. We witnessed so many payment companies went under or were bought out, but these two stay for years and are still profitable.
The truth is their moat is considered very durable and hard to build. A global n banks to n banks payment network is not as simple as how people thought.
Visa and Mastercard do not own the internet cables or the wavelengths. Anybody is free to compete, and that's why they have many competitors. It is very common for businesses to accept a variety of unrelated payment methods. There is no monopoly here.
In my experience it's kinda different. The serious issue that raised by higher up usually means more scope, visibility, bonuses and potential bonuses. Teams usually fights to get the important issues(whichever the higher thinks that's important) as their team's work. The drawback is that it's very possible that multiple teams are fighting for the same pie and resulting in duplicated work.
In the end if there are enough incentives(usually money) people would work on those.
reply