[bryanrasmussen]

>No one thinks about moving the starting or ending point of the bridge midway through construction.

it is a common rhetorical device to phrase something as an absolute when the negation of it is only an edge case.

hence

>Hillel interviewed a civil engineer who said that they had to move a bridge! Of course, civil engineers don't move bridges as frequently as programmers deal with changes in software but,

[fluoridation]

Not to be that guy, but where can I read those interviews? I got as far as the blog (https://www.hillelwayne.com/) and looked around October of 2019 and can't seem to find anything. As it stands this isn't even anecdata, this is some guy saying some other guy said he talked to a few guys who say something happens from time to time.

[bryanrasmussen]

no idea but it stands to reason people will need to move bridges at times, we're in the middle of building a bridge, earthquake happens, stuff no longer like it was, gotta move that bridge is just the initial obvious situation that I can imagine from outside. Similar other natural disasters would also affect it, flash flooding etc.

[fluoridation]

I'll grant that, but that's not a "they don't do this as often as that, but", that's a "it's not unheard of". That was meant to be a response to a Tao of Programming-like post about why programming work has so much improvisation.

[godelski]

Well the reason you don't move a bridge is because it's really hard and really expensive. Just like you don't build an airplane while it's flying because it couldn't be flying if it wasn't built.

The analogies seem to just be missing the point. There's constraints, so what?

I've worked in hard science, engineering, and software. No one is omniscient, so the goals evolve and pivot during the project. That's pretty standard practice. You can't just plan and execute unless you're omniscient. Honestly, the big differences I see is that programmers spend less time at the drawing board and engineers and scientists spend much more time there because working in physical space is very costly and time consuming. But there's a lot of similarities. Programmers would be more effective if they spend more time at the drawing board and engineers would be more effective if they could hack on their tasks more cheaply (which is why sim has had such an impact for them)

[fluoridation]

>Programmers would be more effective if they spend more time at the drawing board

Would they, though? As you've correctly pointed out, design goals in software engineering get shifted by decision-makers because its cheaper than in civil engineering. The whole point of the ToP article is pointing out that software engineers have to account for possible future radical changes that in other branches of engineering are at most exceedingly rare. Any time you spend on initial planning beyond a bird's eye view may be time wasted.

[godelski]

Yeah. I find it weird to think not. Many problems are found during those planning stages. The process is iterative. Like I said, no one is omniscient. So that also means you can't just figure out everything during the planning stage. If that could be solved there then no one would ever pivot and frankly, that'd be a pretty strong case for planning in the first place lol.

But think about it this way, how do you plan a vacation? I'll tell you how I do it and you'll tell me if you're different, which is okay. There's no "right" or "wrong" way. I'm sure some things will be different and it's going to change every vacation, but bear with me here, since this is more of a communication aid than telling you how to vacation lol.

Prior to the vacation I plan out the major things, like how do I get there, how do I get back, the lodging, and so on. I'll have some key things planned out that I want to do. But I won't ever have everything planned out in detail. I actually do not like having each day scheduled unless that is more tentative and and acting as a stand in. Then after traveling my schedule changes, especially in the beginning. Things are different than I expected, so I'll learn that I'd have more fun doing X instead of Y. Or I find that I really like Z so I want to allocate more time to that. Maybe the weather changed and so I can't do P, and I instead do Q. I'll ask locals and hotel staff what their favorite places are to eat and go there. I'll likely have had a few more famous places to eat laid out, but definitely not every mean. Fuck, some days I'm just tired and would rather call the day early and do takeout. As the vacation closes, things become way more "stable". If I go to the same place in a second vacation I'll definitely lean on my experiences and do things very differently, usually with less flexibility (depending how much I was ale to discover what I like doing the first time around).

The point is that no matter what you're doing, there is exploration and exploration is coupled with the doing phase. It'd be pretty fucking exhausting to plan out the vacation at the airport. I mean people do do this and I'm sure you could still end up having a great time. But a little planning can really go a long way, right? That's the planning. Just like when you get back to your hotel at night and modify plans. That's a planning stage too. The logistics of a vacation almost force this kind of behavior on people. But in programming it is much easier to pivot, almost to the degree that you can be mid meal at a restaurant and decide you want to eat somewhere else. Being able to pivot like that is an incredibly powerful and useful feature, but this doesn't mean that planning still doesn't provide major benefits. Going in blind is crazy! If anything, it makes it more important. In both physical and software you still are time limited and unable to brute force all paths. In physical you can't jump mid meal and even if you pivot as soon as you get a good look, you're much more limited to what you can pivot to because you can't teleport across town. But in programming, you can. You can brute force sometimes, but that clock still ticks forward and you're still going to benefit from planning. The real difference is in physical I might be able to consider 2 dozen places to eat but in software I might be able to try a few hundred. Still need to plan if there's a few thousand, right?

You need to balance these things: the planning, exploration, and execution. Working in physical forces a dominating planning stage and more careful exploration stage, because execution is so costly. But in software execution is cheap. That doesn't mean we should throw out the planning stage, it means we can exploit it much more effectively!

[godelski]

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.