It had a physically based sound engine I think?

Good managers will help you find your own motivation and set you up to follow it. Bad managers will kill it.

In this case, I would prefer an average manager that does not try to interfere with my motivations.

this makes sense, but can be at odds with the reason you're there. If your manager is not working to align your personal motivations with those of the organization they are failing. I don't believe it's a spectrum of good-bad management and "level of motivational interference". An "average manager" just does a weak job at the individual-organizational alignment.

Isn't it an interesting question? Wouldn't you like to know the answer? I don't think anyone is claiming anything more than an interesting thought experiment.

I don't have a direct comment to add, but after working on the fringes of streams a bit, they've worked as advertised, but the API surface area for them is full of cases where, as you say, you have to kind of internalize the full architecture to really understand what's going on. It can be a bit overwhelming.

It's a terminal, not a multiplexer. Different type of product.

Sometimes I think I understand computation, then I look at APL.

Oops. Earth's space connection to X just went down. We expect service to resume in about one martian lifetime.

Hard to draw super hard conclusions. Could also be that the bets made on Falcon turned out to be particularly good, vs a more methodical approach Blue Origin took. The highly iterative approach _may_ be faster, but I don't see any evidence yet that it will _always_ be faster. Just depends on how good your bets are and how much in-flight testing you happen to have to do based on a design.

Would be interesting to see more detailed information like specific engineering issues being resolved one way vs another.

Falcon beat New Glenn to the punch, but New Glenn is probably more capable overall, so it's not an apples to oranges comparison. Completion of Starship would really help the iterative approach case though (ignoring the junk it leaves scatter around the world when it goes boom)

People need to remember that New Glenn is completely artificial in market terms. Blue Origin had literally infinite money, and if not sponsored by the richest man on the planet it could never exists. And New Glenn even if its 'better' then Falcon 9 (yet to be demonstrated) will likely never make back its development cost.

I think people just don't understand what an absurd amount of cash burn Blue had for the last 10+ years.

So when it comes to iterative vs methodical, this is a perfectly clear case. SpaceX did it faster and for an amount of money that is so much less then Blue that its hard to even compare the numbers.

Go back and just look at how many people worked at Blue, and then do the math on what their cash burn rate was just for people.

Rocket Lab is also taking a more methodical and less iterative approach with Neutron, which should be ready some time next year. If they make that work well, that will be another point in favor of a methodical approach.

There should be an in depth academic study on their two approaches, it seems like it'd be valuable.

To me at least, given the (probably) positive affects iterative dev has (overall) had on software development, my personal feeling is it'd be useful for most other types of engineering. But (as someone else also pointed out) iterative is much more expensive in hardware fields, given the high cost of materials, and you need to have a lot more funds to build hardware this way.

Can you expand on

"We build non-dilutive growth engines for industrial and climate technology companies by creating high quality development pipelines for institutional capital."

Sure. Would contextualize by saying that infrastructure is a financial product: climate/industrial projects are sited in the physical world and have a hard upfront cost to produce a long term stream of cash flows, which, from a finance perspective, makes it look a lot like debt (e.g. I pay par value in order to achieve [x] cash flows with [y] risk).

When you drive past a solar project on the side of the road, you see the solar technology producing energy. But in order for a bank to fund $100M to construct the project, it has to be "developed" as if it were a long-term financial product across 15 or so major agreements (power offtake, lease agreement, property tax negotiations, etc). The fragmentation of tools and context among all the various counterparties involved to pull this sort of thing together into a creditworthy package for funding is enormously inefficient and as a result, processes which should be parallelize-able can't be parallelized, creating large amounts of risk into the project development process.

While all kinds of asset class-specific tools exist for solar or real estate or whatever, most of them are extremely limited in function because almost of those things abstract down into a narrative that you're communicating to a given party at any given time (including your own investment committee), and a vast swath of factual information represented by deterministic financial calculations and hundreds if not thousands of pages of legal documentation.

We build technology to centralize/coordinate/version control these workflows in order to unlock an order of magnitude more efficiency across that entire process in its totality. But instead of selling software, we sell those development + financing outcomes (which is where _all_ of the value is in this space), because we're actually able to scale that work far more effectively than anyone else right now.

Reminds me a lot of AngelList, which was initially nominally just a mailing list that connected angels and early stage startups, but eventually found that the restriction was in special purpose vehicles and automated the hard legal work of making many individual funding vehicles, and thus was behind the scenes actually a legal services company, if you squint.