[HN Gopher] Trying to become a better developer by learning more...
___________________________________________________________________
Trying to become a better developer by learning more about aviation
Author : fcmam5
Score : 74 points
Date : 2023-07-30 12:03 UTC (1 days ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| gbacon wrote:
| Fun to consider as both a computer scientist and a CFI.
|
| Instrument training in FAA-land requires learners to understand
| the five hazardous attitudes: anti-authority ("the rules don't
| apply to me"), impulsivity ("gotta do something _now!_ ),
| invulnerability ("I can get away with it"), macho ("watch
| this!"), and resignation ("I can't do anything to stop the
| inevitable"). Although the stakes are different, they have
| applicability to software development. Before a situation gets
| out of hand, the pilot has to recognize and label a particular
| thought and then think of the antidote, _e.g._ , "the rules are
| there to keep me safe" for anti-authority.
|
| Part 121 or scheduled airline travel owes its safety record to
| many layers of redundancy. Two highly trained and experienced
| pilots are in the cockpit talking to a dispatcher on the ground,
| for example. They're looking outside and also have Air Traffic
| Control watching out for them. The author mentioned automation.
| This is an area where DevSecOps pipelines can add lots of
| redundancy in a way that leaves machines doing tedious tasks that
| machines are good at. As in the cockpit, it's important to
| understand and _manage_ the automation rather than following the
| magenta line right into cumulogranite.
| ryandrake wrote:
| Great observation. You can easily and routinely see all five
| hazardous attitudes in software development, especially in
| small companies and startups where there is sometimes no formal
| process in place. I wonder if you could measurably improve your
| software by focusing on those attitudes during interviews...?
| bulte-rs wrote:
| Former airline pilot checking in!
|
| Remember the importance of checklists in the "grand scheme of
| things". It helps maintain proper "authority" during operation
| and makes sure you don't forget things. If you don't write it
| down and check it, someone, at a certain moment will forget
| something.
|
| Also, the "Aviate, navigate, communicate" axiom (as mentioned
| by author) is really helpful if you're trying to setup
| incident/crisis response structures. You basically get your
| guiding principles for free from an industry that has 100+
| years of experience in dealing with crisises. It's something I
| teach during every incident/crisis response workshop.
|
| edit: Although it's not aviation specific, and a little light
| on the science, "The Checklist Manifesto" by A. Gawande is a
| nice introduction into using (and making) checklists.
| paulddraper wrote:
| IIRC the five hazardous attitudes are required material for all
| pilots not just IFR.
| warner25 wrote:
| It seems like there are almost daily HN front page items about
| aviation, and a lot of pilots in the comments. I've wondered
| about the reasons for such an overlap in interests among people
| here.
|
| I fit this myself: I grew up playing flight simulators, studied
| computer science as an undergrad, was a military helicopter pilot
| for a while, and then went to grad school for computer science.
| Along the way, I've personally met at least half a dozen other
| academic computer scientists with a pilot's license or military
| aviation background. Is it just selective attention / frequency
| illusion for me, or is there more to this?
| JohnFen wrote:
| > I've wondered about the reasons for such an overlap in
| interests among people here.
|
| I bet that a large part of why is that people here tend to have
| reasonably high incomes, and flying is an expensive hobby. I'm
| sure that flying would be an incredibly popular hobby across
| all demographics if it were affordable.
| zeroc8 wrote:
| I became a pilot at age 20, got all my ratings up to a frozen
| ATPL, worked as a flight instructor, gave up my airline
| ambitions due to deteriorating eyesight, became a software
| developer, worked on other stuff for 20 years, rekindled my
| interest using Xplane, got a job working on a new flight
| planning system for a major airline...
| josefrichter wrote:
| I studied Air Traffic Management = basically managing and
| evolving ATC systems. I work now as a product designer, which
| for the most part involves conceptual design, dealing with
| complex flows and optimising them, dealing with imperfect
| humans using those systems, "solving problems" that go far
| beyond design. I often say it's the exact same job, just in
| slightly different domain.
| hcarvalhoalves wrote:
| > Build for resiliency and designed to fail safely
|
| This is important, but I'm not sure everybody necessarily agrees
| on what "fail safely" means.
|
| Fail safely can mean one of:
|
| - It doesn't fail silently
|
| - It doesn't cause cascading failures
|
| - It doesn't cause infinite failure loops
|
| - It doesn't fail in ways that corrupt data
|
| - It doesn't fail in ways you lose money
|
| - You can safely retry
|
| - You can safely retry anytime (not just today, or just this
| month)
| akhayam wrote:
| I have taken so much inspiration aviation industry when designing
| and operating software system. In addition to the inspirations
| mentioned in this blog, I find the idea of "antifragility" in
| aviation quite fascinating, where every near miss is studied,
| documented and checklisted across the entire aviation industry.
| This means that every near miss improves the resilience of the
| entire industry. We need to build similar means of learning from
| others' mistakes in complex software systems as well.
| WalterBright wrote:
| Control reversal, when the surfaces move opposite from the
| command, have happened. They nearly always result in a crash. How
| does Boeing prevent controls from being hooked up backwards?
|
| The hydraulic actuators (rams) have an input and an output port.
| Connecting the hydraulic lines to the wrong port results in
| control reversal. To defend against that:
|
| 1. One port has left handed threads, the other right handed
| threads
|
| 2. The ports are different sizes
|
| 3. The ports are color coded
|
| 4. The lines cannot be bent to reach the wrong port
|
| 5. Any work on it has to be checked, tested, and signed off by
| another mechanic
|
| And finally:
|
| 5. Part of the preflight checklist is to verify that the control
| surfaces move the right way
|
| I haven't heard of a control reversal on airliners built this
| way, but I have heard of it happening in older aircraft after an
| overhaul.
| SoftTalker wrote:
| Makes sense if your software is responsible for keeping people
| alive. Most of us don't need to work to such a standard
| (thankfully).
| rad_gruchalski wrote:
| That does not mean there are no valuable lessons in there.
| syndicatedjelly wrote:
| There's a certain level of arrogance that comes from the people
| who don't work on safety critical stuff, that we could all do
| without
| maccard wrote:
| Eh.
|
| I make video games. _Everything_ in games is a trade-off.
| There are areas of my code that are bulletproof, well tested,
| fuzzex and rock solid. There are parts of it (running in
| games people play, a lot) that will whiff if you squint too
| hard at it. Deciding when to employ the second technique is a
| very powerful skill, and knowing what corners to cut can
| result in software or experiences that handle the golden path
| case so much better, you decide it's worth the trade off of
| cutting said corner.
|
| I'll let you know when I find the right balance.
| ryandrake wrote:
| I always thought "well, nobody's gonna die" is a crappy
| attitude for any professional developer. We should care about
| quality and getting it right, regardless of the stakes.
|
| QA: "Look, if that integer overflows here, your software is
| going to fail." Dev: "Well, it's a cooking recipe app.
| Nobody's gonna die!" How low of an opinion you must have of
| your own profession if you're going to excuse yourself this
| way!
| KolmogorovComp wrote:
| > NATO Phonetic alphabet (Alpha, Bravo, Charlie...).
|
| NIT, A is written as Alfa in the NATO alphabet [0] as it is
| easier to understand its pronunciation. For the same reason J is
| written as Juliett (two t), because in some languages t can be
| silent.
|
| [0] https://en.wikipedia.org/wiki/NATO_phonetic_alphabet
| gbacon wrote:
| Don't forget their cousins "tree" and "fife" -- or the
| overpronunciation of Papa as /papa/.
| josefrichter wrote:
| I once heard a recording of a conversation between ATC and an
| aircraft with a registration OK-PPP. Every communication from
| either side starts with Oskar Kilo Papapapapapa :-)
| KolmogorovComp wrote:
| As well as "niner", but I didn't want to delve into all the
| subtleties.
| Animats wrote:
| Minor lessons from time at an aerospace company:
|
| - When your device is in use in the field, the user will be too
| hot, too cold, too windy, too dark, too tired, too wet, too
| rushed, or under fire. Mistakes will be made. Design for that
| environment. Simplify controls. Make layouts very clear. Military
| equipment uses connectors which cannot be plugged in wrong, even
| if you try to force them. That's why. (Former USMC officer.)
|
| - Make it easy to determine what's broken. Self-test features are
| essential. (USAF officer.)
|
| - If A and B won't interoperate, check the interface
| specification. Whoever isn't compliant with the spec is wrong.
| They have to fix their side. If you can't decide who's wrong, the
| spec is wrong. This reduces interoperability from an O(N^2)
| problem to an O(N) problem. (DARPA program manager.)
|
| - If the thing doesn't meet spec, have Q/A put a red REJECTED tag
| on it. The thing goes back, it doesn't get paid for, the supplier
| gets pounded on by Purchasing and Quality Control, and they get
| less future business. It's not your job to fix their problem.
| (This was from an era when DoD customers had more clout with
| suppliers.)
|
| - There are not "bugs". There are "defects". (HP exec.)
|
| - Let the fighter pilot drive. Just sit back and enjoy the world
| zooming by. (Navy aviator.)
|
| Aerospace is a world with many hard-ass types, many of whom have
| been shot at and shot back, have landed a plane in bad weather,
| or both.
| SoftTalker wrote:
| I like the term "defect" it's more accurate than "bug."
| treve wrote:
| Is it? I think the definition of Bug is literally defect.
| Maybe it carries a different 'weight' for some people?
| tdubhro1 wrote:
| I think for many people "Bug" can imply something that
| crawled in from outside and messed up the system, "defect"
| implies that there was an avoidable deficiency in the
| specification or the implementation. The engineering
| mindset might prefer "defect" since it implies that we can
| fix the process and improve the quality of future products,
| whereas "bug" implies these things are just a fact of life
| and you can't expect to eliminate them
| ryandrake wrote:
| I've started using "defect" instead of bug for these
| reasons. The "bug" euphemism implies the software was
| once correct, but then problems crawled in from somewhere
| external to infest the otherwise good software.
|
| That's really not how 99% of software problems happen.
| They are defects because the software was defective from
| the moment it was conceptualized or typed in.
|
| "Bug" tries to soften/downplay the developer's role in
| producing a defective program.
| kimburgess wrote:
| A "bug" is specific to computer systems. It traces back to
| a literal bug (moth) trapped in a relay and is an external
| factor with no responsibility attributed.
|
| A "defect" is a declaration that something is evidently
| faulty with a clear onus on the vendor to fix.
| maxbond wrote:
| I had a similar experience, and found "aviate, navigate,
| communicate" to be an excellent model for responding to
| production incidents.
| LorenPechtel wrote:
| I very much believe in swiss cheese safety systems. There *will*
| be errors, you try to avoid them becoming catastrophes.
|
| And I hate systems that don't let you say "ignore *this* warning"
| without turning off all warnings. I have some Tile trackers with
| dead batteries--but there's no way I can tell the app to ignore
| *that* dead battery yet tell me about any new ones that are
| growing weak. (We haven't been using our luggage, why should I
| replace the batteries until such day as the bags are going to
| leave the house again?)
| WalterBright wrote:
| As a former Boeing flight controls engineer, I wrote a couple
| articles about lessons that transfer to software:
|
| Safe Systems from Unreliable Parts
| https://www.digitalmars.com/articles/b39.html
|
| Designing Safe Software Systems Part 2
| https://www.digitalmars.com/articles/b40.html
| eschneider wrote:
| If you want to become a better developer through aviation, I
| can't recommend anything more highly than reading through NTSB
| accident reports. Learn from others the many, many ways small
| problems and misjudgements become accidents. It'll change the way
| you build things.
| evil-olive wrote:
| for approachable summaries of those accident reports, I'd
| recommend Admiral Cloudberg's "Plane Crash Series" on Medium
| [0] and Reddit [1], as well as YouTube videos from Mentour
| Pilot [2].
|
| the latter's videos tend to have clickbait-y titles to make the
| YouTube algorithm happy, but the content is excellent.
|
| 0: https://admiralcloudberg.medium.com/
|
| 1:
| https://www.reddit.com/r/AdmiralCloudberg/comments/e6n80m/pl...
|
| 2: https://www.youtube.com/@MentourPilot
| Animats wrote:
| It takes two major failures or errors today to cause the crash
| of a commercial transport aircraft. All the single points of
| failure have been fixed. You'll see this repeatedly in NTSB
| reports. Failure or event A happened, and then failure or event
| B happened. Single-event crashes of airliners are very, very
| rare.
| JohnFen wrote:
| > All the single points of failure have been fixed.
|
| Now you've jinxed it!
| civilitty wrote:
| There's also a lot to learn about the differences in solo work
| vs teamwork. The swiss cheese model plays out differently when
| it's GA vs airliners.
|
| NTSB reports for general aviation tend to focus on individual
| mistakes since that's most often solo pilots with no ground
| crew, but for commercial flights it's generally a more complex
| series of mistakes made in a team.
| jimkleiber wrote:
| I'm really glad I stumbled on your comment. I train people in
| conflict resolution and emotional leadership and I've been
| looking for places to learn more about conflicts and causes and
| I think these NTSB reports could provide me a lot of examples
| from which to learn. They remind me of how at college I had a
| class on business communication and we discussed the
| communication issues that led to the Space Shuttle Challenger
| disaster.
|
| Thank you for recommending the NTSB reports :-)
| eschneider wrote:
| The cliff note version: More people die because they're in a
| hurry/feel pressured and push a marginal situation when they
| should have known better than you could possibly believe.
| tialaramex wrote:
| This is one of the sadder reasons why scheduled aviation is
| so safe. When flying planes is your job, why would you ever
| push your luck? I feel so tired, that storm looks pretty
| nasty, or the maintenance guy seemed like he had no idea
| why it's doing that - fuck it, we're not going, get the
| airline to put you on another plane if there is one,
| otherwise get them to pay for your hotel, I'm not flying
| anywhere today.
|
| One safeguard that is needed, and I believe is provided
| even in the US - is a strong union to ensure that "Because
| I'll get fired unless we go" isn't the answer. People in
| safety critical roles must be protected so that "No" is
| always an option for them.
|
| For private pilots, reasons to push your luck sneak over
| from real life. To get home before the twins are asleep. To
| be back in time for work tomorrow. So that I don't miss
| Trisha's wedding. Because the replacement was very
| expensive and I can't afford it right now. The fuel prices
| are lower back home, we'll fill up there.
| bombcar wrote:
| My CFI said "graveyards are full of people the world
| couldn't do without, it can wait a day" - important to
| remember for many things, if you start pushing your luck
| it'll eventually push back.
| evil-olive wrote:
| the umbrella term for this in the aviation world is "crew
| resource management" [0] or CRM.
|
| a major focus has been on encouraging less-experienced
| members of the flight crew to speak up if they notice
| something wrong, and ensuring that the more-experienced
| pilots are open to receiving that feedback instead of
| adopting an "I'm more senior, I know what I'm doing, don't
| question it" attitude.
|
| 0: https://en.wikipedia.org/wiki/Crew_resource_management
| imoverclocked wrote:
| The Swiss-Cheese Model of Aviation Safety is useful to know
| before reading NTSB reports. It's a good lens to help in
| understand the context around the reports.
| heelix wrote:
| The other way swish cheese is also referred to is 'breaking
| the chain'. Not uncommon for a bunch of individually minor
| things to become something major. The beauty of these
| reports is they help identify links that if removed,
| prevent the small things from becoming a serious event.
| _dain_ wrote:
| A lot of this wisdom is summarized in the book _The Field Guide
| to Understanding "Human Error"_ by Sidney Dekker. I learned of
| it from this talk about Three Mile Island:
| https://www.youtube.com/watch?v=hMk6rF4Tzsg
| jasonpeacock wrote:
| Similarly, Accidents in North American Mountaineering[1] covers
| failures and their factors and is good reading.
|
| [1]
| https://publications.americanalpineclub.org/about_the_accide...
| thenobsta wrote:
| I took a self-rescue course and a list at the end of their
| handout had such good engineering tips that I shared it with
| my eng team. Lots to be learned about engineering from
| climbing/mountaineering. The list was something like the
| following:
|
| A few pro-tips:
|
| - Slow is smooth. Smooth is fast.
|
| - Simplicity/speed/efficiency is good.
|
| - Strong is good. Redundancy is good/better.
|
| - Equalization and Extension are a trade off.
|
| - Not everything is a nail so NOT every tool is a hammer.
|
| - Tools that have multiple uses are good.
| rad_gruchalski wrote:
| This article isn't complete without mentioning DO-178C: Design
| guidance for aviation software development.
___________________________________________________________________
(page generated 2023-07-31 23:01 UTC)