Comment by cr0sh | Hacker News Reader

Comment by cr0sh | Hacker News Reader

Parent Full thread

I know nothing about ships, the Navy, or combat.

I do know that most or all of our Navy ships are highly computer controlled/integrated, so maybe the following would be moot today, but...

...wouldn't it be prudent for officers to have the skills to plot and do things on paper in the event that during combat or for other reasons the ship sustains such damage that limits or eliminates the ability to use the computer systems to do that same task?

Again - maybe it's one of those things where if the computer systems are down in such a way that you can't do the task, it is likely that you have bigger problems to worry about. Even so, I would think this would be a critical skill to have, if a "just-in-case, cover-yer-butt" scenario presents itself where it could mean the difference between life or death, survival, rescue, etc.

By that logic we'd never have single engine or single seat attack aircraft. In a lot of situations, you _have_ to rely on the technology in order to most efficiently spend your resources, even considering the potential failure modes. In many situations you're better off perfecting one mode of operation than in maintaining two redundant modes.

Seems the best reason to teach these things isn't because we expect them to be used to any substantial extent in combat, but because they're critical and necessary exercises for honing and maintaining the skills needed to wield the high-tech tools, much like in bballard's example. Learning and regularly applying the fundamentals is often critical to understanding the problem space. When you're commanding a naval ship I imagine the problem space is immensely complex, much more so than most other roles in the military, or anywhere else for that matter. If you can't foresee or recognize the problems quickly, you certainly won't be able to respond in a timely manner no matter how fancy the tools.

Yes, that was the reason we were told we had to do it on paper, in case the systems failed. Only we always did it on paper, not just for practice.

That's how our codebase evolves at a large internet company. A new shiny product is desired by sales, and to cheer us up into building it they promise we'll be allowed to delete the crappy old stuff when done. Rinse, repeat, 10 years later we have 10 legacy systems to support. Makes me think of "The Girl Who Sold Matches" whenever one of these comes up...

Reply on news.ycombinator.com