Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Trying to become a better developer by learning more about aviation

medium.com

Post reply on HN
Print view View original

71–80 of 92 posts

Re: Trying to become a better developer by learning more about aviation

#71

Post by resonious »

jacquesm wrote: post #66
resonious wrote: post #61

Earlier quoted context omitted.

What's the difference? I'm not sure how this renaming would change my behavior.

The difference is that a bug implies that it is an outside influence, a defect is something that has to do with making the thing in the first place. A bug you can see as happenstance, a defect implies liability. Huge difference.

I guess I've over-corrected in the other direction. All of the "bugs" I've ever dealt with were caused by engineers, so perhaps the original meaning (similar to "glitch"?) was lost on me.

Re: Trying to become a better developer by learning more about aviation

#72

Post by jacquesm »

resonious wrote: post #71
jacquesm wrote: post #66

Earlier quoted context omitted.

The difference is that a bug implies that it is an outside influence, a defect is something that has to do with making the thing in the first place. A bug you can see as happenstance, a defect implies liability. Huge difference.

I guess I've over-corrected in the other direction. All of the "bugs" I've ever dealt with were caused by engineers, so perhaps the original meaning (similar to "glitch"?) was lost on me.

The word comes from an insect that got caught in the wiring of one of the earliest vacuum tube computers. This caused the thing to malfunction and removing the insect became 'debugging'... the rest is history. I think it's a fun term but defect is far better for the man made software issues.

Re: Trying to become a better developer by learning more about aviation

#73

Post by jacquesm »

SoftTalker wrote: post #65
ryandrake wrote: post #43

Earlier quoted context omitted.

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!

Have you ever written avionics-grade software? If all software had to be written to that standard, we'd have a lot less of it. That might be a good thing I guess, but recipe apps probably wouldn't make the cut.

> Have you ever written avionics-grade software?

I've written software that estimated fuel loads for freight carrying 747s.

> If all software had to be written to that standard, we'd have a lot less of it.

I'm not so sure about that but if that were the consequence then maybe that would be ok. It would mean that we've finally become an engineering discipline with as a result more predictable and reliable output.

> That might be a good thing I guess, but recipe apps probably wouldn't make the cut.

A recipe app can result in injury, disease or death with ease depending on how much a recipe can be corrupted. Just one lost sanitation step for some choice ingredient and you're off to the ER with food poisoning.

Re: Trying to become a better developer by learning more about aviation

#74

Post by soultrees »

unmole wrote: post #58
medler wrote: post #47

Earlier quoted context omitted.

“We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz. with the programmer who made the error. The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's…

Chinese companies typically say defect instead of bug . Naturally, the bug tracker is called the Defect Tracking System. I think the impact of linguistic choices is vastly overstated.

On the contrary I think the impact of linguistic choices is everything. Even subtle changes can have huge downward effects.

Re: Trying to become a better developer by learning more about aviation

#75

Post by perilunar »

gbacon wrote: post #13

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 appli…

> anti-authority ("the rules don't apply to me")

Of course in Aviation the 'authorities' are usually rational and fair. In many other areas of life they are neither, and are incompetent to boot. Being anti-authority is justified in such cases. i.e. there is a moral responsibility to disobey unjust laws.

Re: Trying to become a better developer by learning more about aviation

#76

Post by mips_r4300i »

evil-olive wrote: post #34
jimkleiber wrote: post #4

Earlier quoted context omitted.

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 Challen…

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/…

CRM is also being adopted by emergency responders (EMTs) and so on. I've started to use it whenever possible in important or high stress situations dealing with people. Stuff like repeating peoples questions to them so they hear your interpretation of what they said. Always responding to questions, even if the answer is "I don't know yet" or "I'm still working on it".

It's like taking a protocol like TCPIP and mapping it onto human interactions to provide a lot more robustness and remove many sources of mistakes.

There are more elements to CRM, but finding good breakdowns of examples seems to be tied up in paid or industry training and harder to dig up as a layman.

Re: Trying to become a better developer by learning more about aviation

#77

Post by unmole »

soultrees wrote: post #74
unmole wrote: post #58

Earlier quoted context omitted.

Chinese companies typically say defect instead of bug . Naturally, the bug tracker is called the Defect Tracking System. I think the impact of linguistic choices is vastly overstated.

On the contrary I think the impact of linguistic choices is everything. Even subtle changes can have huge downward effects.

"That's just like, your opinion, man"

Everything? Really? Not to be flippant but I've heard a lot of people say something similar but I am yet to see a single convincing example.

Re: Trying to become a better developer by learning more about aviation

#78

Post by mips_r4300i »

WalterBright wrote: post #44

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

Good points. Embedded systems deal with many of those. It made me think of a funny story that causes me to pay closer attention to things like this:

Some time ago I shipped a product running an RTOS which unfortunately had a subtle scheduler bug where it would randomly crash periodically. The bug was pretty rare (I thought), only affecting part of the system, and reproducing the bug took several days each time.

In my infinite genius, rather than waste weeks of valuable time up to release, I set up the watchdog timer on the processor to write a crash dump and silently reboot. A user would maybe see a few seconds of delayed input and everything would come back up shortly.

Unfortunately, I had accidentally set the watchdog clock divider the wrong way, resulting in the watchdog not activating for over 17 hours after a hang!

The bug became much more widely noticeable after the product was released, and only by sheer luck, many people never noticed it.

I eventually fixed the scheduler bug in an update, but the useless watchdog configuration was set in stone and not fixable. Taught me to never assume a rare bug would stay rare when many tens of thousands of people use something in the field.

Re: Trying to become a better developer by learning more about aviation

#79

Post by ArnoVW »

warner25 wrote: post #22

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 m…

I'll add a datapoint. Not a pilot, just like to know how complicated stuff works. And, like the article, I do think there are lessons to learn from aviation.

Re: Trying to become a better developer by learning more about aviation

#80

Post by samtho »

perilunar wrote: post #75
gbacon wrote: post #13

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 appli…

> anti-authority ("the rules don't apply to me") Of course in Aviation the 'authorities' are usually rational and fair. In many other areas of life they are neither, and are incompetent to boot. Being anti-authority is justified in such cases. i.e. there is a moral responsibility to disobey unjust laws.

Authority is relative and is more nuanced. Only in recent human history have we seen a deliberate separation of church and state, for example. Prior to this, they were intertwined to a degree that would be incomprehensible to us now.

As a new pilot myself, I can say with confidence that the FAA has some major flaws and the US congress has been able to get their dirty hands in aviation policy to enact separate rules that did not originate from the recommendations by the NTSB.

Post reply on HN