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

51–60 of 92 posts

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

#51

Post by jacquesm »

medler wrote: post #47
SoftTalker wrote: post #25

Earlier quoted context omitted.

I like the term "defect" it's more accurate than "bug."

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

An error has by now become something else, I like the 'defect' term a lot better.

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

#52

Post by jacquesm »

bulte-rs wrote: post #18
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…

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

And the value of good documentation, and actually reading that documentation as well as making sure the documentation is indexed and quick to peruse in a situation where you don't have time to waste.

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

#53

Post by jacquesm »

eschneider wrote: post #2

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.

And risks digest.

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

#54

Post by sklargh »

eschneider wrote: post #2

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.

Agree with the above, fabulous learning tool. A theme that often dominates is small mistakes deep paid for with blood and treasure at usurious interest rates.

I also recommend Admiral Cloudberg. https://admiralcloudberg.medium.com/drama-in-the-snow-the-cr...

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

#56

Post by jacquesm »

SoftTalker wrote: post #24

Makes sense if your software is responsible for keeping people alive. Most of us don't need to work to such a standard (thankfully).

You don't always know if your software is going to be responsible for keeping people alive. Operating systems, system components, firmware in devices and so on are all potentially software that can be responsible for keeping people alive.

Let me give you a simple and easy to understand example: an MP3 decoder performs the boring task of transforming one bunch of numbers into another bunch of numbers. This second bunch of numbers is then fed into a DAC which in turn feeds into an amplifier. If your software malfunctions it could cause an ear splitting sound to appear with zero warning while the vehicle that your MP3 decoder has been integrated into is navigating a complex situation. The reaction of the driver can range from complete calm all that way to a panic including involuntary movements. This in turn can cause loss or damage of property, injury and ultimately death.

Farfetched? Maybe. But it almost happened to me, all on account of a stupid bug in an MP3 player. Fortunately nothing serious happened but it easily could have.

So most of us should try harder to make good software, because (1) there should be some pride in creating good stuff and (2) you never really know how your software will be used once it leaves your hands so better safe than sorry.

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

#57

Post by michaelrpeskin »

deathanatos wrote: post #49

It's a lot of good advice, but IME the next step is "but how do I actually do this?" A lot of the difficultly boils down to an inverse NIH syndrome: we outsource monitoring and alerting … and the systems out there are quite frankly pretty terrible. We struggle with alert routing, because alert routing should really take a function that takes alert data in and figures out what to do with it … but Pagerduty doesn't sup…

I use “E, as in Eminem” in my malicious alphabet.

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

#58

Post by unmole »

medler wrote: post #47
SoftTalker wrote: post #25

Earlier quoted context omitted.

I like the term "defect" it's more accurate than "bug."

“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.

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

#59

Post by gpm »

treve wrote: post #26
SoftTalker wrote: post #25

Earlier quoted context omitted.

I like the term "defect" it's more accurate than "bug."

Is it? I think the definition of Bug is literally defect. Maybe it carries a different 'weight' for some people?

I think they're actually subtly different.

A bug is a computer program behaving unexpectedly. It can be caused by a defect. It can be caused by a bug crawling into the wiring and making the hardware malfunction. It can be caused by a cosmic ray flipping a bit.

A defect in a computer program is a place where the computer program that does not instruct the hardware to perform in a way so as to do what the program is intended to do.

Given the current (poor) state of our software, most bugs are defects, but not all. Sometimes it really is a bug shorting out a path on the motherboard causing the computer to not do what it was told to do.

Whether or not most defects are bugs is very case specific. Sometimes they're bugs. Sometimes they're just features that haven't been implemented yet, causing the computer program to not do what it is intended to do in an expected, rather than an unexpected, fashion.

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

#60

Post by the__alchemist »

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…

Another good one: Warnings, cautions, rules etc are often written in blood.
Post reply on HN