>"Does "crunch mode" exist in other complex engineering professions? Civil engineering, aircraft design, nuclear plant design, and so on?"
In my experience, not really, not nearly to the same crazy degree that everyone in technology is familiar with.
I've worked close to some large construction projects (hundreds of millions USD) and smaller build-outs of physical infrastructure (ISP stuff).
Off the top of my head, I imagine some of the reasons these projects aren't subject to "crunch mode".
* There's a huge supply chain of permits, materials, equipment, labor, inspections and more that has to be scheduled well in advance and is difficult if not impossible to rush.
When you have some relatively self-contained pile of code it's easy to think a successful redesign is always within reach.
* There are few if any sudden epiphanies or clever "hacks" to be discovered and even if there were, the consequences for using one with some hidden side effect can be literally deadly.
* In construction, labor is backed by the confidence and support of powerful, effective unions. Good luck telling a bunch of steel workers that they're going to have to put in an extra 30 minutes, much less a 48-hour marathon and not get paid.
* Professional engineer is a licensed profession as opposed to technology where it's often an entry-level title that doesn't necessarily mean anything.
I haven't met a professional engineer who didn't have some respect for and ability around process, planning and documentation. All of which are things which go a long way toward setting expectations and building / maintaining realistic schedules and fixing problems as they arise.
Meanwhile. we've all met software, network or systems "engineers" and had to support the code/infrastructure of people who were happy to just "make it work" and move on.
(Yes, yes, this is certainly arguable - I used to argue it against the professional engineers I supported all the time.)
* Software development tends wander much closer to the bleeding the edge than do other forms of engineering. I expect a construction project is far less likely to try and use some novel load-bearing material than a software project is to make a bet on some new framework.
I've worked at various points in a startup, banking and aircraft design/manufacture. My wife is a civil engineer. I've seen Crunch Mode in some form in all of them but the rationale will differ.
For example, my wife did both offshore and tunnel engineering and would work very long shifts plus be on call between them. The main difference with the sort of thing I've done in software is pay: she received overtime even as a professional engineer and this was the main draw, particularly offshore.
In aircraft design, there was never any crunch on the actual design because it was pointless; the review and audit processes went on for years. However, we'd work extended hours for trade shows etc but it was much less common than in banking or the startup.
In my experience, not really, not nearly to the same crazy degree that everyone in technology is familiar with.
I've worked close to some large construction projects (hundreds of millions USD) and smaller build-outs of physical infrastructure (ISP stuff).
Off the top of my head, I imagine some of the reasons these projects aren't subject to "crunch mode".
* There's a huge supply chain of permits, materials, equipment, labor, inspections and more that has to be scheduled well in advance and is difficult if not impossible to rush.
When you have some relatively self-contained pile of code it's easy to think a successful redesign is always within reach.
* There are few if any sudden epiphanies or clever "hacks" to be discovered and even if there were, the consequences for using one with some hidden side effect can be literally deadly.
* In construction, labor is backed by the confidence and support of powerful, effective unions. Good luck telling a bunch of steel workers that they're going to have to put in an extra 30 minutes, much less a 48-hour marathon and not get paid.
* Professional engineer is a licensed profession as opposed to technology where it's often an entry-level title that doesn't necessarily mean anything.
I haven't met a professional engineer who didn't have some respect for and ability around process, planning and documentation. All of which are things which go a long way toward setting expectations and building / maintaining realistic schedules and fixing problems as they arise.
Meanwhile. we've all met software, network or systems "engineers" and had to support the code/infrastructure of people who were happy to just "make it work" and move on.
(Yes, yes, this is certainly arguable - I used to argue it against the professional engineers I supported all the time.)
* Software development tends wander much closer to the bleeding the edge than do other forms of engineering. I expect a construction project is far less likely to try and use some novel load-bearing material than a software project is to make a bet on some new framework.