I may be misreading your message, but this approach seems to be an example of rational, good engineering. If a system is broken in a faraway place it is best to analyze it and develop a fix in a well equipped lab convenient for experts to work in. Once the solution is known, deploy and validate it, ideally remotely or by shipping components, not by sending your experts on site.

Sending an expert to a remote site or a ship to fix a problem is a last resort.

When N=10, and each one is a strategic asset, which, if found disabled, would cause every major head of state in the world to reassess their long-term global postures on technology, defense, and relations with the US, it doesn't take much to buy that plane ticket.

I worked as a mechanical engineer in the nuclear power industry for a couple years and this happened frequently even for normal power plants.

Like, one of the first projects I worked on was diagnosing a malfunctioning valve where most of the work was finite element analysis on computers, but we still had to send someone to take measurements and temperature readings since the company that made the valve no longer existed (and I'm not sure how you'd ship something like that since it was very large and used with contaminated water)

I agree that the cost of the plane ticket is minor but this IMO makes the proper procedure starting with lab replication even more important.

You usually get much better results when you work in a well equipped lab and have access to the right experts. For anything non-trivial "replicate, understand, fix, deploy" is a much better approach. Not always possible, and when it is not going to site may be the only option, but it should be fallback, not primary path. My 2c.

I think you are misreading; my reading of the parent post is that their last paragraph has the meaning "the push to lower military spending will remove the ability to afford the current process, which is bad, because the current process works great."

You appear to be thinking that problems can typically be replicated in a lab without sending an expert to the remote site. My supercomputing startup (PathScale) made specialized networks for supercomputers. While most problems could be solved with remote diagnostics, I still spent a lot of time flying to customer sites. Sure, you can call it "a last resort", but it's necessary if the problem can't be replicated in the lab.

Agree completely. Sometimes you cannot replicate things in the lab; then you go. But you do this only if you cannot replicate.

I spend part of my time developing large, real time, visible systems and when things do not go as planned there is always a lot of pressure to go on site now and "just fix it". I have taken my lumps to learn that the right approach is to say "no, we will start in our lab".

I can see how my statement was unclear. I'm going to go back and edit it for clarity.

If you can, take that job. You will not regret it. Consider this: that tech rep probably had a resume that a dozen companies would kill for, and he's still at Westinghouse. Flying across the planet, landing on aircraft carriers.

I have noticed that people who get hired there retire from there.

I'll continue to consider it in the future.

Assuming the Westinghouse bankruptcy does not relieve them of pension obligations, etc.

Take it. I worked in a job like that, the emergencies are few & far in-between. When there is one, there are probably multiple people on the team that can handle it.

My group used to have a list to sign up for going out on sea trials. I never got high enough on it to go. If you don't want to go, I doubt you would have to.