It's hard to infer what you're exactly saying here, but I've worked in physics (my undergrad), aerospace engineering (first job), and programming (my phd and onwards), so I think I can bridge whatever gap is being discussed here.

In programming, engineering, and hard science your goals evolve during development. There's always discovery during the doing process that necessitates pivots, and sometimes hard pivots. The main difference I've seen is just how much time goes into planning. Software has an advantage in that when working with physical things mistakes are incredibly costly both in money and time. You fuck up a tolerance and you might need you wait a few weeks for the part to be remade and you might have an expensive paperweight (hopefully you can use for some testing).

So what that leads to is more planning stages. That's not just make a plan and go, but make a plan, go, regroup, replan, go, repeat. It often means gathering people who are the owners of different parts of a project because you can't just duct tape things together and the most permanent solution is a temporary solution that works. This greatly affects how I go about programming and is something I notice I do differently from my peers. I spend a lot more time at the whiteboard while most people I know never visit one. I'm not spending all my time there, or even most, but I couldn't do my job without "pen and paper".

In programming the "laws of physics" aren't constantly changing and you're not "building a plane while flying it" (how would it even get off the ground lol), but your requirements are constantly changing. That's... normal engineering and normal in both experimental and even theoretical science. That's because we're not omniscient and you don't know the full answer from the get go lol.

This isn't to say in trad engineering and science we doing also "move fast and break things". Just like in programming you'll build toy models or scaled down versions. But I do think programmers could benefit a lot more and make a lot fewer mistakes (substantially reducing future workloads) would they spend a bit more time at the drawing board. It's great that in programming we can jump in and poke around and experiment so much faster than the physical world allows us, but it seems that this feature is overused instead of being used in addition to planning and designing. That's what actually made me come over to this side, was the ability to iterate faster. But sometimes you gotta take a step back and look at things. Sometimes you gotta move the bridge. Sometimes you gotta tear it down to build an entirely new one. The latter is actually much easier in programming and honestly I feel like it's used less frequently. But that's like being unwilling to throw away your first draft when writing a report (or anything). Why hold on? The first draft's job is to get the stuff out of your head and see it in a more physical form. It's so easy to rebuild, magnitudes easier than doing it the first time, but it always hangs on as if losing it is losing work.