Bestand wählen
Merken

Fighting the controls: tragedy and madness for programmers and pilots

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
I let's meet annually prejudice and that's what I look like on television and I worked for a company called deal and we it's a Swiss company boundary like to work for them and we do and cloud hosting
for Django in Python developers who don't want to be system administrators so something I wish I had a long time ago and and we we do everything of course also on and genuine Python if you want to talk about the Django Python deployment afterwards please come to me very happy to talk to about that makes and I'm also heavily involved in the Django community and co-developer of the gender project I am and a board member of the Django Software Foundation discovered by the Vice President of the judges of the nation but it's not actually as glamorous as it sounds and and current about trying to and my contact details of their on looking any danger saying anything interesting on Twitter that he won't follow it by means of e-mail me or just come and talk to me like talking to people and the but that's enough about me
what I want to talk about the tragedy and madness in states and because these are subjects of programmers need to talk about and you should know this picture and this is the Peterborough the elder and landscape with the fall of across and you know the story of the myth of aggressors falling from the sky and is over there in the corner of the picture was falling into the sea unnoticed when the wax on his wings melted and the whole world is going by so you can imagine the fall of the grass and at time of the year and agony and and terror his father watching helplessly and you might think well this is a a senseless tragedy a pointless mean less lost and this problem right and how wrong it's a ceaseless meaningless but a tragedy if we understand that in the the original meaning of the word it's an ancient Greek dramatic form and a drama is a story and stories are never meaning stories are always meaningful because they they tell us something and in fact a story helps us to find sense in some senseless lost so that that's what tragedy is that it helps us tell a story to make sense of something that doesn't make sense so what may have happened because my hand no meaning itself a story we tell ourselves and each other about it over and over again does have the meaning and you know this meaning might be and it's really important to take your father's advice or not to be too powerful or something like that and no what happened they don't all to because that was his time and is gone and he's gone but we still have the story to work with and so that was the time but we have the story of the time and in this talk I'm talking about the story of the time as opposed to the time that I'm interested in what we can learn from the story of the time for the record of the time so and what's madness will make you and you familiar with this famous quote from from Einstein that madness the definition of insanity is doing the same thing over and over again and expecting different results of Einstein actually it wasn't I'm signed it was the writer Rita Mae Brown said that and the fact that it was it was much way apparently so that uh and um imagination Chinese proverb and actually nobody knows who who said that a lot if you're a
programmer that probably sounds a little bit familiar this experience in doing something over and over again and expecting a different result because that's what we do we sit in front our keyboards run the same thing again and was surprised not ranged when the same error happens again unless something slightly mad about its this experience in its experience that programmers are familiar with so what is going on what happens to programmers when they're linked to by this madness when it's sitting there from the computer in front of a machinery do you think the again because the results were and what they wanted or expected and they do it again and then look in disbelief at the crash and then despite the evidence of their eyes all they can say is than it is copy happening but
the on the 31st of May 2009 Air France flight 7 was flying from Rio de Janeiro to Paris and about 3 hours after takeoff it encountered icing conditions and ice crystals began to accumulate in 1 of the plateau tubes these little forward-facing facing tubes that measure air pressure and therefore St the and if this cause them to give inconsistent readings which in turn cause the autopilot to disengage and warning sound went in the pocket and they were in some time conditions so the pipelined appears everyone and uh had to and just the planes attitude and as well as adjusting for role he pulled back on the stick causing the plane of the to get causing the aircraft apply and used as the and within about 60 seconds the ising event was over and the instruments were reporting correctly but the plane and climbs to its maximum altitude and lost their and lived and it was in an excessive numbers of position and began to stall when it's also been sort supporting the stole alarm sounded in the cockpit and the across started to fall because it wasn't flying any longer and the pilots fought the controls down toward the Atlantic Ocean and we were trying to make sense of what was happening to them and all the wild man kept pulling back on the stick trying to climb to recover altitude and not realizing that what he was doing was keeping the plane in a star the captain what do what was a respirator was called back into the cockpit and he sat behind the 2 pilots and on the cockpit recording you hear the stall warning going off about 80 times and finally just a few thousand feet above the water the 1st officer and the captain's finally realized what 1 and had been doing it and the courtly put the nose down so the plane could pick up speed and recover and it was too late and the plane crashed into the ocean and everyone onboard and 228 people and died so the story of um that Air France 4 4 7 has the same kind of whole on people's imagination of the story of vigorous it has the status of a mate uh in aviation in which people think they going to or hope they're going to find some kind of deeper truth or the revelation significant mystery maybe like a story of the titanic people also keep telling each other over and over again and find some meaning and how do we explain how an Airbus 330 1 of the safest most reliable planes ever built FIL out of the scope there was no reason for it to crash the crew were not incapacitated the engines were working normally the plane respond to the controls there was nothing wrong with it apart from from a brief sense error and it functions normally all way down to the ocean and they can send a chill down the spine to think about it just for many reasons and 1 of the things that's chatting about it is that when we think about what happened in the cockpit it's like a glimpse into madness for rationality and that's something that we find hot to look into and this is Gloria Anderson added it anybody and those variants of all this these things that she's a musician performance and have piece from the air is kind of story of an in-flight emergency starts with the kind of calm authority that we expect from negation and then then it descends into dimension confusion and if you ability to listen to it not before you get onto an airplane necessarily that which makes the point that in x there 2 times the time and this the record of the time this is time that we live human something's happening and then there's the re-creation of that time off we still tell the story of what happened with the time that belongs to the world now maybe of flesh-and-blood fear and so on and there's the other time that belongs to a world of technology and numbers and data and this the thing the time when things happen and the time when we we create the story so our time now that we live right in now is contradictory is confused it's counted out in the remaining years or in some cases maybe minutes and seconds but there's the times could be pieced back together afterwards by the data recorders and and the as white captured by the data recorders and put back together by the researchers and investigators who are trying to work out what happened so this is the time and this is the record of the time and I yeah our time goes in 1 direction it unfolds inexorably and it comes to an end but the rest of the time can be played backwards so it can be played over and over again backwards and forwards we can slow it down we compose it so in their time in France for 4 7 is gone the yeah but in the record of the time we can suspend the plane in its fall and In the record the time the passengers still there unaware the pilots still fighting the controls the passengers and don't know that madness is taken over in the cockpit and that case centered 1 and is doing the same thing over and over again and expecting a different result so we've been talking about madness and people talk about pilot error is a really bad terms that simultaneously judgemental and unrevealing and aviation has a much better way of yeah talking about what happens in a call-center loss of situational awareness 1 and from there and was lost situational awareness and is what happens when a pilot loses the true picture on what's happening to them when you use situational awareness although Hughes includes you need might be staring you in the face but because of a contradiction with your expectations you will fail to understand what they are telling you in aviation needless to say loss of situational awareness awareness is absolutely deadly it's a kind of cognitive breakdown and has a number of notable characteristics of which will talk about later very briefly and blind spots faulty mental models misjudgments about cause and effect and decision making so the question I want to explore is does the same kind of madness the same kind of cognitive breakdown and afflicts programmers and pilots when they make apparently a rational judgments and decisions and turned out
to be more closely at programming out to see whether we can find some deeper understanding of what programming it's so some people think that programming is science um they're all wrong and don't get confused by the idea of computer science it's sort of programming so the computation programming is much more like engineering of flying a plane because of the engineering is a science and their own also programming engineering and flying a plane off crafts all skills or what in Ancient Greece again would be called technique uh listening skills and actually if you replace 1 of examples is always using all of skill is piloting a ship take of course is the root of our word technology and we can find various interesting parallels between programming and piloting so for example and if any of you done pair programming but has its counterpart in the 2 pilot cockpit with this that uh the pilot flying is operating the controls the pilots not flying pilot monitoring who is telling them what to do and handling communications and overall uh flight operations I'm interested in finding out some parallels that happen when things go wrong now in nearly all crops you'll find 2 phases or activities a primary and a secondary activity and and the corresponding programming to program itself and debugging and the creative phase on 1 hand and the troubleshooting phase on the other so in the primary activity it's synthetic we put things together in the 2nd activity its analytic we break things apart so we've got assembly and disassembly In the creative phase we moving forward and in the 2nd rate activity the debugging part we're moving backwards and in the 1st we have imaginative and goal operated to thinking gold so goal oriented thinking and in the secondary activity it's logical and problem oriented In 1 signer OS questions like how can we get there from here and in the other people had we get here for the sake let's make something happen at all how did this happen no why did why often why isn't it so this is that's the section between programming problem and debugging and this happens in all crafts but for program is quite unusual how much time we spend on this half of the cycle this really dominates a lot of about work we look at how much time you spend programming most of it will be in that side rather than and decided that's quite unusual and and that's the part I'm interested in on this part because then we talk about this a lot in as this we've got methodologies and models and frameworks and paradigms and a great deal of uh has been said about the practice of programming and have teams work and how what we planned and managed executed and delivered in reviewed about debugging we say very little and that's all because we spend so much time doing that I think there are a few reasons why this is the case so that 1 is that programming is a creative craft like cooking and well sorry like like writing a book and in creative craft it's acceptable acceptable for us to get things wrong many times until we get it right unlike crafts like surgery for example yeah when you go to a surgeon you want to be sure that the surgeon has not only done this operation many times before that is going to be conducted in exactly the same way with the same result same thing when somebody makes meal that's not the time when you want to hit somebody's doing something groundbreaking and experimental on other hand when you write a novel or uh composing a jazz masterpiece experimentation is fine in programming failure is on arguable you don't get to argue about whether what not because your stereo trace back and it means that we don't have time now to stop and think with that really work if you're not satisfied with your piece of writing or your painting you can sleep on and think well maybe it does welcome or maybe maybe the critics haven't caught up yet and maybe feel John Coltrane insane know it works you know 1 needs to to to uh catch up with me in programming you can't do that it's it has failed the it programming try again is instantaneous all the instantaneous and cost-free and that means we're tempted to do the same thing again immediately ways if you're an engineer building a bridge or an airplane that temptation is it is much less because it's expensive to try again at in programming feedback is nearly instantaneous and cost-free so means we're tempted to try things just to see if they will work you tend not to do that with the aircraft of bridges and that's and finally in this is a very important 1 debugging is a mostly private affair is the programmer and the code and the error and they're living in a miserable manager plot and it's misery that we deal with in private like being sick it's not we want to do it on our own and so debugging stays in our heads programmers love talking about programming but you will never get a conversation out a programmer is in the middle of the debugging afterwards us a way out there was fantastic bargains know I did this happen in old happily tell you will story but the only thing they want to do when they're in the middle of debugging is look at the screen and so the fight without code so all these things come together and what they do is they take the programmer more quickly into debugging and keep the programmer there there's vicious cycle which forms a tighter and tighter spiral with no um inclination to step back reconsider is a closed cycle in which we don't want to talk to other people uh about it and get away from the code so there we are programmers debugging funny ourselves doing the same thing over and over again as if we expected a different result fighting our controls and my argument is that the nature of the debugging leads us towards cognitive breakdown that debugging itself provokes loss of situational awareness in programmers I'm arguing that the activity of debugging is responsible for producing the same kind of mental conditions cognitive conditions that tall flight 4 4 7 out of the sky it I you're aware the this is your Web Application Developer and you're trying to restart an application that crashed and you check Logs you flush the cache is you we started the application you the web server now logged in directly In the terminal inserting print functions into the code desperate for any clue
the it's called and links and you know you are in the grip of madness doing things that would never dream of doing like changing production code on the fly or trying to reconfigure the web application gateway and finally you discover what is happening you've been doing all those desperate and futile things to recover from the crash on the wrong server you were typing the commands into the wrong the terminal window you would desperate for clues and all the clues were right there in your face and you couldn't see them and you didn't see them because you lost situational awareness and you were fighting the controls or your debugger complex algorithm that was working until yesterday when you made some minor and insignificant changes and it is our algorithm is out because you mean living inside of for a month and somehow it's logic is collapsing all around you and you take apart piece by tiny piece and your checking and rechecking positively no comp possibly have anything to do with a problem changing it so much that you own mental model of of it starts to break down and down at this copy happening and finally you realize that in 1 of the changes what happened is that the algorithm is now receiving a different data set you died in deep into a rabbit hole chasing after completely irrelevant solution to your problem there was nothing wrong with your algorithm was just receiving different data and you lost situational awareness because you were too busy fighting the controls and then you fly a plane into the sea telling yourself that this can't be happening it there's remarks last words on the cockpit voice recorder from the flight so loss situational awareness is a common enemy of the pilot and the programmer what can we do about it what happens to programmers it makes us look and feel foolish what happens the pilots they die so unsurprisingly aviation developed very good strategies for dealing with it 2 strategies to mitigate it and they target the kinds of cognitive breakdown that characterize it so remember these I mentioned uh than earlier so your eyes were a blind spot if you the right distance because when I you will be able to see the other doctor because you'll be no blind spot where the optic nerves BVI their deadly spots um you can't even tell when you have a blind spot the only thing you can do is get another perspective which is why we have 2 eyes or maybe invite another person look at it or change your own perspective but we need mental models of the world as a kind of short hand for navigating the world the more complex the world's all the possible world more complex mental model when they break down we need to rebuild them and we need to rebuild them from something objective that's not inside us um Germans a very useful language it has sir multiple words for thing so 1 is being as in things and another is gaining stands which means the tree something like stand against and that's what an object is it something that we can stand against it's on the outside of the OS and the we need something that we can stand to gain something that's outside of cells in order to rebuild a mental model it we don't have access to causality in the world we can simply observe the world and make observations and judgments and make judgments about cause and effect we don't see cause and effect themselves in complex this is difficult enough the best of times in complex stressful situations is much harder and so the flight computers a little born and to the problem and but when he pulled back on the stick and the attitude of plane increased even further the storm warnings stopped because the flight computers were receiving such anomalous information that they couldn't even process it and when he let the nose recover which is what he should've done the stall warnings went off again because now the plane could detect what was happening so he was trapped in this for the feedback loop in which his actions and cause and effect work 180 degrees out of phase with each other so we need to find ways of rescuing out judgments about cause and effect putting them out of these complex and tight stressful loops and finally and our decision making processes need to be exposed and made explicit had born on X said of what he was doing it wouldn't his reasoning would have been clearly and immediately obviously faulty and ask panic set in his actions became more and more rational and and the 2 decisions he took the way his thinking went unchallenged because it stayed inside his head the and the rest of the crew made poor decisions to that were revealed in actions or implicit in remarks but they would never brought out into the light until the final moments so aviation spent over a century learning how to deal with these problems and it's lessons on woven into every pilots training uh in aviation cognitive breakdown is dealt with through the employment of various simple practical strategies and procedures and it means a pilots have supernatural competency supernormal competencies they are ordinary people doing ordinary simple things and those simple things are what make them safe they use checklists when your is about how many times you done this a procedure even if you've done it several times that day the you do it from a checklist so here's a checklist for
aid 7 4 7 normal procedures manual this will be on a card in the cockpit this is for the primary activity or flying you know that the programming part of flying that the foregoing part I covers everything and they'll have
checklists for emergency procedures for the bonding the secondary activity offline their checklist for absolutely everything the big manuals on has 1 down by the side and in the cockpit in the few moments off the autopilot disengaged born and should have have been all axioms prevention of had the check on his lap working with 1 and I'm going through the checklist with and instead 1 and thought his controls relying on his own memory his skill and and his and um experience a checklist so all those characteristics of comes to break down a checklist serves so as an alternative perspective to an alternative perspective it serves as an alternative perspective to avoid blind spots it helps rebuild a mental model it gives us to something to stand against the kind of objectivity it helps guard against support decision making we use checklists often system administration sometimes in programming I've never seen a checklist used in debugging communication in aviation it's always explicit and verified so say you have the controls I have the controls descendants flight level 315 descend fight level 350 again it brings in other perspective reveals a mental model it helps reconnect cause and effect and exposes our thinking processes this is what happened in 5 4 4 7 and you can read this and weak because 1 and been pulling back from that stick trying to climb and other pilots did not know because he hasn't told them and bear on the left hand side of the uh cockpit had been pushing forward and trying to lower than those the system was in dual input mode where it sums the commands and Rivera had made his decisions or actions explicit either and nobody in the cockpit knew what was happening until it was too late we still this all the time in debugging and a and struggle with something for hours and hours ago us IOC finally described the problem and the answer pops into my head because i've made it explicit and need a co-pilot or I seen to stick to wall often be actin description will turn out to be 90 % of the work towards the solution stress panic drive us tight into our of bad decision making 1 thing that aircraft like to do and do really well is fly an airliner wants nothing more than to flight level and in a straight line and and let go of the controls when the water pilots engaged or almost any point in the next few minutes they would've been ok he could have done nothing and they would have all lived in the this a good advice and so simply doing nothing not only allows an aircraft to recover allows pilots to recover now a pilot can't go on doing nothing indefinitely especially when for example in engines on fire but they can differ longer than you think even in an unexpected emergency but programmers weekend leave the code alone almost indefinitely if go on holiday and come back to related that code will be waiting patiently for you to come back and tackle again from where you left off if you walk away and come back and that's fine because there is no pressing need for you to do anything so often the best thing um that we can do is get away from the code because when there's no pressing need to do anything then we should do nothing and I solve more problems falling asleep or writing my bicycle doing the dishes but I have fighting with the controls and I've certainly cause less damage which is so we could learn to do these things and we can adopt chance checklists how hard would it be for us to develop a systematic checklists for debugging and programming we can improve the way we communicate so that we do nothing and think nothing without communicating without exposing its another person as we do for example in pair programming will be ready to head debugging and urgent getting we need to learn it is to stop fighting the controls so these are all ways of getting away from a failed or failing perspective always of stepping outside yourself and finding something else in the universe to get a grip on to help you they ways to reset your thinking and prevent bad judgments and decisions and they can work in programming and they work in aviation but we're talking about a flight 4 4 7 not because it's something that happens is because it's something that never happens only once in a lifetime anomaly final an airliner I can assure you is the safest way to travel In the meantime other disciplines like nursing and surgery in the nuclear industry also learning in adopting these strategies and programmers not to think and talk about programming and about their practicing methodology and theory but they don't interfere about theorized about debugging and as it might be an embarrassing private misery and I think that needs to change so as I said in an air pressure that is the time and as the record of the time and record all the time is scrutinized and replayed endlessly in order to force it to yield up its secrets so that we can learn from them and make things better and we don't do that in programming but as soon as we've seen at the last thing you want to do when you've had a horrific debugging session is look back at it you just wanna get on with your life and work but we need to learn to do well on our failures and confront them the way aviation dose because we so often caught up in the time and we want to look at the record the time the by the way these techniques also work for other things no other crises and emergencies like him the malfunctioning malfunctioning washing machine or relationship in trends but the truth it's these things work in aviation because they built into it at every single level not because somebody heard about them in a conference talk edition is safe because they're defining part of its culture and processes the truth is as individuals will only get so far and they work for aviation because there a systematic approach adopted throughout the industry until now debugging mistakes routinely kill us our colleagues and our customers I think probably our habits as programmers will change very much our industry would change and and this is an industry this is just deep in the culture of the industry aviation paid for its lessons with people's lives people died to make it safe in every time in aviation every time you break a rule have a simple however the now every time you decide you don't need to follow a checklist every time you do something the way you happen to feel like doing at that moment you literally dis honoring the dead in programming it the it's not the change thank you very much be and
fit and we've got a few minutes for questions and and uh uh yeah let's have some some questions maybe at once want to make some commentators have questions 1st so it's on the front and you know generation on the mean it seems like your conclusion is unnecessarily pessimistic but it seems like your conclusion is a necessary pessimistic as of example you changed my opinion that perhaps I should use checklists them and like that seems kind of like a good idea out so all may you by talking more about the actually can hedges and progress in ministry for their thinking it the more we might you know I I think that some I yes I am pessimistic and and and cynical yeah patterns that is he talking about and that the extracted hi andrew is very interesting um to think there is a role for a professional bodies of programming a similar to you how doctors pilots and other uh but a professional pressures have yet there are in the body which regulates their behavior their actions and enforces penalties within that there are in industry the conceivably yes and I think there is a kind of movement for this starting for example in academic and research software think there have been want to talk about this already at this conference and um the keynote uh captains keynote yes about ethics in programming also touches on that but I mean look at us you know how we kind of people who are going to all our industry does it look like a very regulated will industry and I think when the it'd be really reinforced at this stake 1 thing that can be really interesting you know look at the companies of building self-driving cars Apple and Google here when you when you see how apples it uh programming works on something like I I cloud synchronization think OK you would be making self-driving cars that's interesting all grew up you maybe the regulations will come in not from the programming side from the engineering side and an and the real world effects but you know I can crush my programs 10 times a day and their evenness so in the thank you yet I am aware that a checklists are actually used in programming on interestingly in aviation software so you find the things like has the variable being initialized exactly once and this is
because of regulations so I I would like to re asked the question are you where where US auras anyone aware of checklists being used in Python and thank you it's interesting you say that and we sometimes use checklists in programming but never in the body part yeah in in that secondary activities at distance to know a workshop on on my data powder workshop and I was thinking when is URL called not working and um I was visually typing into the uh mosquito pi uh files typing adding new elements in the wrong file and finally I you less my checklist has to make sure that what you are is you mentioned that you spent several hours trying to develop something and as soon as you heard it down you discover what the problem was but a few years ago I don't know if you're wearing Akamai engineer wrote the 15 minute rule I Ingatestone as ever heard it basically says try dividing for 15 minutes if you can't solve it write it down and ask someone else I think it's great advice to live fire and you know at least annually was 15 minutes I had that could you a wrote that but it's a marker my engineer at my this city and company IID just below the 50 rule you'll find a blog post by him about it to really carried that because you have a 15 minute rule the above 15 minutes and then tell someone else may it's 1 of the problem of and thank and so thank you very much for your talk I think uh when I saw you putting up analysis and synthesis that's maybe that fits very well to a highly iterative process these and I think all these programming mood things they were using like Fail fast Fail often that should lead us to doing more iterations more quickly and maybe your proposal to could help us working quicker on iterations and kind of like acknowledging debugging steps is kind of like in in a very serious step of the activity that were doing and I'd like kind of like you failed you have to debug but more like OK you have to do debugging now and to common some are not engineer of working for most of those so Conrad some very good so story that you told him very accurate and uh you should try making this into a keynote of my opinion thank you but I think that every time I get a trace back for whatever thanks the Holly every single time you know we really need and so this this this is the kind of mentality we dealing with you know I had already the program and I am still surprised that that that really has to change the work had been made me do my has just a bit I should buy my head harness the idea somehow gets in that there's a real block there about the expectation of failure we've never expect to do with the best thing that because as we come in pink is automated testing but the story that was dividing the 1st of all thank you were much for a talk I think we a programmers in them as a programming role but also the most stellar a let's say a record off off you know dividing things by methodologies because I was actually reading a blog by a guy who started and such reliability engineer and some are small like online casino something that became 1 of the largest 1 could use in the world and he became head of such Libya's change nearing group and I think we have a lot to learn from site reliability engineers because the curve of a lot of methodologies uh how to debug right because they don't about called the debug infrastructure the books services and while the in this block so every word to it with search would be to fuse when this is so that he spent a year uh going through all the teachers that were created it like since the birth of the company writes that something fails something much wrong and social ability right and she classified everything that went wrong right and he created a huge pretty much like a miniature lecture case with the flow chart of things that can go wrong and like any junior sulfur levels junior him basic just go through to saying it yeah we don't have the best CA but uh they're achieve people right but the pool growth way stronger more robust methodologies and yeah why think we can definitely learn from our site reliability engineer colleagues because they know they can't just do nothing as easily as we can as programmers um it I um I think I'm also a convert to the debugging that and this excellent Aladdin ask about the overhead of constructing uh checklist I think we're industry that sheet it had no known that I know of has died from 1 of my Retrospect's um but is is the overhead to always using a checklist given the given how easily and cheaply we can fill a I don't know as the same my debugging check this so far as got 1 item on and it me 20 seconds to right and I'm since I started using it I've always looking to use it so maybe if you know that it's just noise in also say non-majors it's not enough training I have no idea what the overhead might be and probably less than the time we spent futilely debugging things do you have a now another question so remember air Camara duration because your theory what is the rate success so if your talk you just success
Arithmetisches Mittel
Randwert
Twitter <Softwareplattform>
Geschlecht <Mathematik>
Widget
Systemverwaltung
Projektive Ebene
Softwareentwickler
E-Mail
Whiteboard
Computeranimation
Resultante
Schnelltaste
Subtraktion
Programmiergerät
Bit
Systemzusammenbruch
Computer
Computeranimation
Arithmetisches Mittel
Bildschirmmaske
Datensatz
Rechter Winkel
Wort <Informatik>
GRASS <Programm>
Benutzerführung
Fehlermeldung
Aggregatzustand
Resultante
Umsetzung <Informatik>
Einfügungsdämpfung
Programmiergerät
Röhrenfläche
Extrempunkt
Natürliche Zahl
Web-Applikation
Hochdruck
Bridge <Kommunikationstechnik>
Kartesische Koordinaten
Euler-Winkel
Login
Computeranimation
Richtung
Negative Zahl
Datenmanagement
Programmierparadigma
Radikal <Mathematik>
Wurzel <Mathematik>
Parallele Schnittstelle
Phasenumwandlung
Metropolitan area network
Parametersystem
Nichtlinearer Operator
Lineares Funktional
Datenlogger
Physikalischer Effekt
Plot <Graphische Darstellung>
Programmierung
Bitrate
Kontextbezogenes System
Optimierung
Ereignishorizont
Entscheidungstheorie
Teilmenge
Arithmetisches Mittel
Informationsverarbeitung
Konditionszahl
Server
Garbentheorie
Charakteristisches Polynom
Ising-Modell
Lesen <Datenverarbeitung>
Fehlermeldung
Ebene
Rückkopplung
Server
Maschinencode
Existenzaussage
Ortsoperator
Hausdorff-Dimension
Wasserdampftafel
Programmierung
Toter Winkel
Zahlenbereich
Mathematische Logik
Term
Framework <Informatik>
Benutzerbeteiligung
Datensatz
Informationsmodellierung
Erwartungswert
Spirale
Endogene Variable
Softwareentwickler
Plateau-Problem
Optimierung
Informatik
Schreib-Lese-Kopf
Autorisierung
Soundverarbeitung
Zwei
Abundante Zahl
Quick-Sort
Office-Paket
Chirurgie <Mathematik>
Caching
Rationale Zahl
Mereologie
Dreiecksfreier Graph
Gamecontroller
Wort <Informatik>
Wiederherstellung <Informatik>
Geneigte Ebene
Benutzerführung
Einfügungsdämpfung
Programmiergerät
Prozess <Physik>
Momentenproblem
Web-Applikation
Formale Sprache
Computerunterstütztes Verfahren
Euler-Winkel
Komplex <Algebra>
Computeranimation
Netzwerktopologie
Algorithmus
Bildschirmfenster
Radikal <Mathematik>
Kontrollstruktur
Physikalischer Effekt
Sampler <Musikinstrument>
Kontextbezogenes System
Algorithmische Programmiersprache
Checkliste
Mögliche-Welten-Semantik
Entscheidungstheorie
Informationsverarbeitung
Menge
Server
Strategisches Spiel
Information
Ordnung <Mathematik>
Normalspannung
Ebene
Rückkopplung
Server
Subtraktion
Wellenpaket
Mathematisierung
Gruppenoperation
Systemzusammenbruch
Toter Winkel
Zellularer Automat
Mathematische Logik
Informationsmodellierung
Multiplikation
Perspektive
Gateway
Luenberger-Beobachter
Abstand
Schreib-Lese-Kopf
Soundverarbeitung
Universal product code
Binder <Informatik>
Objekt <Kategorie>
Minimalgrad
Debugging
Gamecontroller
Wort <Informatik>
Programmiergerät
Punkt
Momentenproblem
Computeranimation
Übergang
Deskriptive Statistik
Digital Object Identifier
Flächeninhalt
ATM
Physikalischer Effekt
Übergang
Ein-Ausgabe
Checkliste
Algorithmische Programmiersprache
Entscheidungstheorie
Twitter <Softwareplattform>
Funktion <Mathematik>
Festspeicher
Strategisches Spiel
Dualitätstheorie
Charakteristisches Polynom
Ordnung <Mathematik>
Normalspannung
Telekommunikation
Maschinencode
Wasserdampftafel
Mathematisierung
Gruppenoperation
Toter Winkel
Physikalische Theorie
RFID
Virtuelle Maschine
Informationsmodellierung
Datensatz
Perspektive
Widget
Optimierung
Grundraum
Soundverarbeitung
Videospiel
Systemverwaltung
Schlussregel
Physikalisches System
Chipkarte
Objekt <Kategorie>
Chirurgie <Mathematik>
SALEM <Programm>
Mereologie
Gamecontroller
Normalvektor
Axiom
Term
Maschinenschreiben
Bit
Web Site
Programmiergerät
Prozess <Physik>
Wellenpaket
Web log
Gruppenoperation
Besprechung/Interview
Gruppenkeim
Iteration
Geräusch
Element <Mathematik>
Physikalische Theorie
Synchronisierung
Übergang
Erwartungswert
Arithmetische Folge
Software
Reelle Zahl
Mustersprache
Abstand
Kurvenanpassung
Optimierung
Regulator <Mathematik>
Schreib-Lese-Kopf
Analysis
Softwaretest
Soundverarbeitung
Logiksynthese
Programmablaufplan
Zwei
Schlussregel
Programmierung
p-Block
Kontextbezogenes System
Elektronische Publikation
Bitrate
Checkliste
Arithmetisches Mittel
Druckverlauf
Generator <Informatik>
Dienst <Informatik>
Rechter Winkel
Wort <Informatik>
Overhead <Kommunikationstechnik>

Metadaten

Formale Metadaten

Titel Fighting the controls: tragedy and madness for programmers and pilots
Serientitel EuroPython 2017
Autor Procida, Daniele
Lizenz CC-Namensnennung - keine kommerzielle Nutzung - Weitergabe unter gleichen Bedingungen 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben
DOI 10.5446/33696
Herausgeber EuroPython
Erscheinungsjahr 2017
Sprache Englisch

Inhaltliche Metadaten

Fachgebiet Informatik
Abstract Fighting the controls: tragedy and madness for programmers and pilots [EuroPython 2017 - Talk - 2017-07-13 - PyCharm Room] [Rimini, Italy] Damn it, this can’t be happening! As programmers, we find ourselves time and again spiralling down into tighter loops of desperate troubleshooting, fighting the controls of our machinery and descending into what feels like a kind of madness. Later, when it’s all over, we realise that the clues we needed to recover the situation were staring us in the face all along, but we somehow couldn’t even see them. There’s a reason for this: the nature of debugging for programmers means that it quickly tips us into these states, and then very effectively keeps us there. In programming we have worked hard to improve some aspects of programmers’ work, creating methodologies, development frameworks, paradigms, practices and thinking deeply about how to solve the problems of producing good code. We have done very little work to improve the way we debug our code, The good news is that although programmers have not developed very adequate strategies or techniques for mitigating the risks that debugging draws us into, other industries, and in particular aviation, have. We can learn from their lessons without paying their price

Ähnliche Filme

Loading...
Feedback