Merken

The Good Bad Bug: Learning to Embrace Mistakes

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
this thing and and and what here and here also pairs of all thank you all for coming out here today to spend your morning talking about failure which is like topic so I think DJ to sort of set you up in arms in like knock you down and as was mentioned I'm just write
and a fear that tweeting heian I that's my Twitter handle so there you go am the when I
was 26 years old I decided that I wanted to learn how to fight the fly a plane and my friends and family were very skeptical they had such words of wisdom as you don't even know how to drive a car you get motion sick you're afraid of heights and all this was 100 per cent true but I actually didn't see the relevance of you see no 1 was going to put my wings so now 6 1 thing and I was on final approach for runway to 1 in Santa Monica after a routine training flight I eased back on the throttle tilted the plane the nose of the plane of a tiny bit internal flair and floated gracefully war less down to the ground and suddenly the plane jump to the side and my instructor was like on the plane has a go you've got the plane and brought the plane to a stop on the runway and as our hearts come down down we got out and we looked at the damage it was a flat tire you newly
very finally was common and the plane safely stopped a flat tire really isn't a big deal you just have to tell it back to me is derived and change out the time the runway was then the blocked for less than 5 minutes so I was actually really surprisingly instructor said him in a drop the back of the classroom and I'll come back to fill up the FAA paperwork my heart rate jumped right back up please low it's just a flat tire no 1 got hurt why after the paperwork you see in addition to not being the biggest and paperwork is also really worried that I had just gotten my instructor in a lot of trouble but it turns out that the FAA collected details on all of its big or small even a tiny tire blow-out during a landing in my little four-seater plane they wanna get as much data as possible so that they can work out patterns that can help them implement safer systems they know that more data means that we the drop better conclusions but they also know that people really don't like paperwork or getting yelled at so to make sure the pilots are willing to fill out these reports they have a policy that if there were no injuries nothing he did was illegal and you fill out a report is not going to be any punishment nothing about a very
different approach that we have to automobile accidents when I was 12 years old I was riding home for the Saturn dealerships in a shiny brand new car it was the 1st brand new car that my parents had ever purchased were sitting in a stop light and suddenly we march forward we've been and my dad got out to check on the other driver an incredibly nervous 16 year old boy no the other I was fine everyone in our car was fine and the only damage was a small puncture on the bumper from the other cars license plate made and looked at over and he said well what I guess that the bumpers of the where he told the can to be careful and we all fell back into slightly less shiny car and drove home no paperwork was filed new data was gathered in fact there's not a single agency out there collecting data on QA issues it's usually handled by local agencies like the police and they do not like it if you call them up to let them know about something as trivial as a flat tire thank you can have an accident 2 cars actually bump into each other and as long as no one's injured and no 1 wants to make an insurance claim this will never end up in any records anywhere so these 2 different approaches have actually led to very different outcomes
a look at the most recent stats available which were for 2015 and for every 1 billion miles people the US travel by car 3 . 1 people died yeah the
and for every 1 million miles people US travel by plane the only point 0 5 deaths now if you're like me decimals especially when you're talking about a fraction of a person can be a bit hard to wrap your mind about it so this is a bit easier if you
hold the miles traveled steady 64 people died traveling in cars for every 1 person dies traveling in a plane now there is something very interesting going on here we have 2 different approaches that lead to 2 very different outcomes and the key difference is actually how each approach deals with failure you see it turns out that failure isn't something that you should avoid it the way to learn no
for we go much further it's probably a good time manager we're all on the same page when we talk about the failure so what is the area I think for some of us it might be that sinking feeling that you get in the pit of your stomach when something didn't go right and the person is yelling at you and having angry face new like when a bonding out then this morning and I can absolutely relate to that losers problem for this talk in looking at what different people said I found a lot of people are like of failure about 1 simple it's the absence of success was like seat what success so easy it's the absence of failure not really helpful to you but researches they actually have a very specific definition of failure failure to them is deviation from expected and desired results and that's not bad now I honestly think there's some truth in all 3 of these definitions but that last 1 deviation from expected and desired results that's something that you can actually test and measure so we just stick with that 1 for now now I can actually find any definitive data on this but I think as developers we have more results that deviate from our expectations in just about any other group of people so you think that programming would be the perfect place to learn from failure but 1 of the few places that I could actually find people routinely so most of the time capitalizing on failure was in video game development however my favorite examples
of this is that the game space invaders do you have sort of know the game space invaders so it's the old arcade game where you
control a small can at the bottom that's firing at a descending row of aliens and as feel more aliens they speed up making them harder to shoot right well that actually was not the game that's not what I was supposed to be the developer Tomohiro Nishikado the plan for the aliens to remain at a constant speed the entire time no matter how many aliens you destroyed there would not be a speed increase and tell the next level and he wrote the code to do exactly that there was just 1 problem he had designed the game for an ideal world and I don't know how
much in about 1978 but 1978 was far from ideal and he actually placed more characters on the screen and the processor could handle and as a result the aliens on and charmed along the 1st and only reach their intended speed once enough of them had been destroyed now Nishikado had a few ways of dealing with this he could show the project Intel processor speed too fast enough and that might seem silly but we can imagine that he was not compromise it also have modified the game designed put the where aliens on the screen so that it could run at a constant speed that you want but instead of being rigid and insisting on his original vision he decided have people tested out and they absolutely
did they got so excited has been spent up it actually project emotions on the aliens they're like 0 these guys are getting scared and taken out there trying to speed up because they know that I am about to kick their butts and was so popular that he kept that in the game and the family was actually responsible for creating an entirely new game mechanics the difficulty curve so before this games would always be the exact same difficulty for an entire level and it wasn't until you got to the next level that things would actually get more difficult after this all that's were things could get difficult at any point whenever the developer pleased the now I don't know if the developer here had read the studies but he was actually capitalizing on lessons that I see time and again in the research about the there is not something to hide from it's something to learn from in fact it turns out that feel you're actually presents a greater learning opportunities because there's more information encoded in the earlier than in success think about it but this
success usually look like the topic a
thumbs up the a smile from a
manager and what did you actually learn well there's research on this research actually shows that people and organizations that don't experience failure become rigid because the only the back that they get tells them just keep doing the exact same thing you're doing to make any changes because you're already winning body don't change anything then on the other hand it's
all up more like this OK look at this look how much information there is available in this error message if we really closely we can figure out exactly what went wrong we how much line in the code has an
issue and we have some experience with this particular error message would probably know what that issue most likely it's and even if never seen it
before we just a quick search away from pages and pages worth the information about this particular failure now that we had an experience with an approach that didn't work with a bit of effort we can actually figure out how to write something that does work now many of the
developments actually has a long and honored history of grounding all the mistakes and wrestling successes In fact the concept of exploiting their failures to make the program better is so important it actually has a name they call it the good bad bug not having space to learn from the
failures that actually came in very handy for a group of developers that we're working on the street racing game in the nineties so the concept game had players racing through city streets and are being chased by cop cars and if the police caught up with him pulled you over before he got to the finish line you lost there's just 1 problem the
develop 1st got the code for the algorithm just a tiny bit wrong and instead of law-abiding police officers trying pull you over you have these super aggressive cops China slammed right your car and they would do it at full speed no matter what you did the beta testers may actually have way more fun avoiding the cops need ever had with the racing game and as a
result the entire direction of the game was switched up and the Grand Theft Auto series was born to this like in
about that for a moment the core concept of the best-selling video game franchise of all time in history ever would have been lost if the developers had panicked and try to cover up the fact that they screwed up the algorithm state but instead of freaking out the so I let's see what happens and the attachment of now
there are actually some larger programs where hundreds if not thousands of hours of work have already been done by product leads and designers and business people before developer ever gets to write the 1st line of code and then development the work is encapsulated in a document called the game design document now the GTD is conservative considered a living document however it's actually a pretty big deal for changes to be made late in the game it means that tech requirement pages need to be redone art pages need to be redone really states have to be pushed back budgets might be off you get the picture it's no big
deal to change this but that was actually the unhappy reality that the Silent Hill developers were facing so they started out building the game to the GTD specs but there was 1 tiny problem topic I you see the
PlayStation's graphics card it cannot render all of the buildings in the textures in a scene so as you
walked toward buildings would suddenly popped into existence and blank walls would magically have a texture and as you can imagine that sort of
like 0 height trees suddenly
distracted people from the game anaphora game is very dependent on atmosphere that sort of pulls the player in the game's universe so this was kind of being breaking issue no living easy for every single
person involved to start pointing fingers that everyone else after all everyone had sort of played their part From the designers who put just 1 or 2 more buildings in the background to make it interesting to tech team that decided to make it for the PlayStation instead of the more powerful 3 to the business chain that determine the release date it was not a single individual anywhere along the line and made an obviously bad calls they're just a bunch of tiny issues that sort of snowballed into a big problem you see the entire system had failed but instead of running from the failure of the canal meeting sidestepped it they found a work around if
not the world with a very dense theory fog and it turns out that body is actually pretty light weight for a graphics card to render so now it
scares distant objects which means you can't really see buildings and touches on the horizon popping in anymore and has an amazing added
bonus is really really really creepy In fact it was so creepy that this bond became a staple of the Silent Hill Series 1 after graphics card to cut cut up and become powerful enough that popping wasn't an issue anymore the so that's another example of success being that from the doesn't defeat simply by embracing the failures now if these examples from the
programming world actually help to illustrate was happening at a more high stakes example in aviation automobile accidents you see the aviation system saves so many wives because accidents are treated like lessons we can learn from data is gathered and aggregated and patterns are identified if an accident was caused by pilot being tired they never just stop right there they look at pilot schedules and staff led levels and flight readiness checklist to determine what contributed to that exhaustion in contrast who do we usually blame for road accidents In the driver all she was reckless that dude he does not know how to drive in other words airplane accidents are always treated as failures of the system while car accidents are treated like failures of individuals all that judgment going around it's no wonder that people spend so much time trying to cover up their errors note by definitely stop there that's not sign that's the guy who went through it meaning they spend time covering it up rather than just acknowledging the failures and learning from them we now
not everyone in this room is a pilot but I actually think that we have a lot to learn from how aviation handle failures if we're willing to use a system to track and learn from our failures as we write code were actually to be much better off that's an basic question what should that system look like and broad strokes I
think that there are 3 very important pieces that the system would need on the first one is to avoid placing blame remaining to collect a lot of
data and then removed abstract patterns
so step 1 make sure that you understand that you are not a problem call that is much easier said than done right I mean when not to be yourself up over failure in the States is probably like the whole talk in and of itself or like a whole lifetime of self discovery in her the radiation failures like wanting to know is that they never just stop at the top level blank so there was
actually a case where the pilot made a critical error by dialing in the wrong destination the flight computer and cause direct so the cockpit recording the could clearly hear the pilot John and say and super excited to finally get a good night's sleep no I would have been very easy for the researchers to stop there and blame the pilot for being tired but then it was enough to know that he was tired they actually wanted to know why so the verified that he had a hotel during
his layover but that was enough so the
verified that he had checked and then they looked at the
records of every single time that door had opened and closed so they can establish the maximum amount of time that the pilot could possibly have slept and even then they didn't just say OK we've shown that the pilot could not possibly have more than 4 hours of sleep total tonight they looked at the three-letter flight computer readout and you're like wow you know now of were thinking about it that's an incredibly confusing interface if you're tired or distracted which a cockpit is a pretty distracting plates the now there are always willing to point out where
individuals have contributed to a failure but they also want to focus on what was wrong with the entire system so if you take away from failure in cold or anywhere else in life is anything like i'm dumb I just can't learn there's this probably this isn't my thing you are absolutely missing out on all the best parts of failure now I understand that everyone is going to be at the point where you can kind of quiet that inner critic but if you just since some time trying to ignore it and with the rest of the system given of time you're probably find that the voice in your head starts to contribute helpful insights rather than just criticism now step 2 document
everything even things that seem small Heck ideation document especially the things that seem small so my flat tire on the runway in Santa Monica was a very small error but just as we saw the Silent Hill example alone in those small errors and missteps can start to roll up into a major problem and catching problems early on in course correcting is going to help you avoid major meltdowns so how
should we document things and they can actually a paper documentation but as long as you have some sort of record that you can refer back to the form of documentation is really going to be up to you you should definitely include details about what you were trying to do the resources you're using this whether you were working alone or with other people how tired and hungry work and obviously what the outcome was get specific when you're recording the outcomes if you're trying to get data from your Railsback and either the old store India react components and it keeps telling you that you cannot dispatch in the middle of a dispatch don't just write down the actors so stupid and I can do all this is daiquiris away is my boss torturing me is that does not help trust me I check and now look at
the final step is to make use of all that data that you've been diligently gathering
imagine how powerful that data is as you go through it and start extracting patterns for when you do your best work and when you do your worst work instead of vaguely remembering that he struggled the last few times you try to learn how to manipulate hatches in Ruby you can actually see that you were only frustrated 2 out of those 3 sessions and the difference between the 1 where you felt good and the other 2 is that you were well rested out 1 or maybe you notice that you learn more when you pair was someone or when you have music playing or when you just use some amazing pineapple straight from cone white on the flip side you might discover that you don't learn well past 9 PM or that you're more likely to be frustrated when you're learning something new if you've not snuggled with the happy for at least 20 minutes prior to open your computer and that is in very good thing to know because it's a lot easier to identify the parts of the system that do don't work for you when you actually have a paper trail and you're not guessing
and you're also have a really nice log of all the concepts that you're struggling with which if anyone here has ever said 0 i'd love to write a blog post it is to have any idea what to write about this lot of all the things a struggling with that's a that's a blog post source right there you know let's say that you go back and you read this data and you see that you having your last edit coding session I was trying to wire up my form for my read raccoon now and it worked the sort of thing about where I was sending it but it kind of ended up in the URL which was a bit weird cool you actually have a very well defined problem to research and will be too long at all after reading some form documentation that you realize you were using to get action on that form and get request put the data the URL poster possible ones that keep hidden in the request body so now understand need 20 minutes a puppy travel time and you're ready to go fix that for now I'm focusing on
how individuals to learn from failure today and the thing is is this is also incredibly important proteins so in the research on failure there's actually a pretty famous study that looks at patient outcomes at demographically similar hospitals and they found very strange thing at the hospitals the head nurse managers that were focused on creating a learning oriented culture instead of blame oriented culture they were actually higher rates of error but they also had better patient outcomes near like that's weird here we have hospitals where people are encouraged to be open about mistakes and make more mistakes but patients are better for it and so they die again because that was not what they were expecting to find what they found was that it was just the people were more willing to report their mistakes which meant that the hospital's defined what was causing the mistakes and correct them which isn't that patients had their outcome at the blame oriented hospitals people were afraid of losing their jobs of really tiny mistakes and it's been a lot of time covering them up and maybe some of you have been on programming teams where that's a situation like if you break production everyone's getting value when you have to wear a stupid had the vote on it on a new and seasoned a lot of time like 0 crap just pushed a debugger up our admitted to hospital for anyone finds out and the underlying issues actually never get dealt with and if you show me adapt team that has a 0 tolerance policy from states all you dev team where engineers but a good portion of their time covering up the state rather than writing the code if you focus on blameless postmortems rewarding experimentation and just know not being addicted people because humans make mistakes you actually have very different outcomes and probably more longevity unless turnover on your teams now
look like everything else you try the process is the process that I'm proposing may not actually work perfectly for you the 1st time around think you you have to understand going a tiny bit to matter just figure out what about the process is it working for you and see how you can adjust it that's right you can learn from the failures that you're learning from y trying to learn from your failures and as you get more comfortable gleaning in both from failures your as signifying that every single bug is actually a feature as long as you can learn from it even if you end of the meeting every single line of code and starting over again you
few so that's a good question so it's how to communicate and that failure something to learn from from the engineering side to the business side of that might have a different perspective and that's absolutely going to be tough because if you are at a corporation that C is like a body of production as the into the world and you might lose your job because of it then that's going to be a problem and and it's been very hard for the engineers to be willing to fail publicly if they're gonna get punished even if it's not from their managers so part of that is you know it's up to everyone the China Light educate the other people on the team about like how this is part of the engineering process but that's obviously you know your work is building things and like fixing bugs and maybe not fixing people's so it's unfortunate say like if you're in management and working hard to try to light help business people understand that I is great if not been of buffering your team as much as you can from being punished for mistakes while allowing Member States immediate slide FIL internally be open about it happily was postmortems but put an nice veneer on top for the sea level people that need to think that everything's perfect and that's the best way to do things the shares so the question is about the difference between an early career developer making a mistake in the visible and a late career developer making a stake in being visible I so I actually had a similar question where some reside as a woman part of my career growth has ben I'm the looking like a no 10 times more than the next person that was applying for the job and being open about failures could take my career when you recommend and I was like I'm not an expert I recommend you like protector fucking career and let's I I would say that I think it's a great win like late career developers are open about failures because that gives room for early that by career developers to be open about their failures and I'm like I'm not embarrassed by not knowing something so when I've been in like cold readings or anything like that they're like no other any questions I'm always more than happy to raise my hand is a I didn't understand a thing because for me it's not embarrassing not to know something and so I kind of like and willing to take 1 for the team and afterwards people come up and say all like thank you so much for asking I thought I was the only 1 that didn't know and I think part of it is like if you're late in your career and your comfortable with where you are and you're willing to show that it's OK to fail and been take that 1 for the team if you feel secure and where you are in your career take that 1 for the team because all of us are going to be much better engineers by being willing to fail and learn from that and then we will be covering it up and so if you think that it might cost you your job cost your livelihood I have cost you the ability to go down the career path you want to like don't lose out on the value that you get from at least acknowledging internally mistakes to keep a private diary have you know what's gone wrong and how you learned from it you know have to publish it publicly but I would say later don't let other people keep you from being the engineer that you want to be and if the way that you get there is by trying stuff OWL writing the code breaking the code and going back and fixing the code and don't be afraid to do that like I absolutely don't let other people's weird ideas about everything needing to be perfect from like the 1st key press on the keyboard keep you from learning because ultimately in but you do you you the good engineers they don't be afraid as to the question is about had being so cool with a failure that people no longer worry about making mistakes and it's like whatever I mean so the money is I think that most programmers want to build stuff that works so mean it's going to be very rare that you find someone inside I don't care that it's not working for people whatever it's lunchtime and like most of us have a like my my baby is broken my code does it where guy like me put all that pressure on ourselves and in the research just it least in western culture is a can for other cultures the Western cultures like put such a stigma on failure that it's very rare that you would find that someone has gone too far the other way and it's much more likely that you're going to end up in a place where people are covering up mistakes and making things even worse because of that and I think if you do find yourself in a situation where we have so the term I think that tell if someone is getting a little too comfortable with mistakes is that they keep making the same 1 over and over again and that's not what this is about this isn't about being like of breaks whatever it's about saying like when stuff breaks what can I learn to do better next time and so if you've gone too far and like was affairs side of things we like each won't nothing is a problem and you know you just really bacterial I K I noticed that you've pushed the debugger to production
3 times in the last week you wanna late let's come up with the way that we can make sure that doesn't happen anymore and that's discourse correct there yeah I mean so the question is I have sort of fighting the balance between the extra time cost of documenting things worse is the value that you get when it works out well and you get some value from and I'm at the at the risk of bladder is being a cop-out I'd say you benefit experiment and find what works best for you and I don't know anyone in years had the experience of late learning something writing a blog posting don't forget alike writing some notes and 6 months later being very confused on a googling and finding your blog posts that you wrote 6 months ago when you have a problem and I mean what might be 1 of love letter that is to yourself where it's like past use like Jessica you're going to struggle with this 6 months from now I know how to explain it to you here you go out and silicon those moments that time you took to write a blog post you either learned it better and were able to do it more fluently next time or you have this great resource written by you for you for the next hundred confuse on anything in those instances people really see the value in like the documentation and the learning and certainly if you spend like a couple months you like are a lot of stuff down and nothing's getting better for me then yes steal it back in find the different thing that works better share so concrete steps that senior developers can take to help you new developers sort of document and learn from the failures who yeah I mean it's probably not very by individual and very by team I think certainly writing tasks is great like without getting too pedantic about it having at least some test coverage I forcing you to like think about especially as a junior the system that you're about to architect and forcing you to have a safety net for when you make a change later and don't realize that it's can break things and tests are amazing I am I am a big fan of having at junior developers and senior developers a light ray of blog posts and documentation from the has its at but we get so much and especially and in this room I think most of us are Ruby Rails developers probably working with other open source libraries and other things like maybe were not all at the point where we can sit down and write a jam or are a framework that's going to like help tens of thousands of were millions of people but we can write a blog post that like I struggled with this this is how I got around it this is what really made it clear to me and that helps the person that's learning that kind of solidify what they've learned and then is just like this beautiful gift to the rest of the community I'm I can't tell you how many times like people have been out so I work at a school reteach developers and live in playing times the students have to build an issue and has been resolved by a blog post about student like 2 3 4 semesters earlier row when they were going through that same issue and so it's both a great way for juniors to learn as well as like a great gift to the community and by people that can't necessarily give through like writing code that I mean that as a question is if I you've experienced a situation we thought covering up was and so was better than embedding and I mean all the freaking time because I don't like being you that I like to have certain rational fear of authority which has 0 to do with how many manager actually interacts with me but every time it's like you have a minute to talk in like 0 my god this is it could be fire and everything is the wires that is just like I wanted to tell you did a great on like so it is my last day and so I mean the thing is that some I am I'm never actually found a situation where it would be better for me to have hidden and I found situations where am I was really scared and the thing that I thought was going to be bad which is like a manager yelling at me actually did happen because I worked at a happy place without having cheated small mistakes like a typo in a report that the client had said we never look at that because there's just too much data in America and then my managers like he made a typo you care enough like that's not 18 hour workdays it's my level of terror in and so I think like that there are situations where it feels like the better option is to hide the state but never actually seen it where there's like long-term value from fighting the state and I mean I may be privileged and lucky in that that it's like never like killed my career and Shirley being seen as someone who makes typos a report certainly didn't help me at the ad agency but sigh laughter there and learn to code in my life is better so screwed those dead is if a anyone else Austin you guys have been fantastic in the summer thank the horse if the war
Menge
Quick-Sort
Ebene
Wechselsprung
Bit
Wellenpaket
Twitter <Softwareplattform>
Koroutine
Familie <Mathematik>
Wort <Informatik>
Computeranimation
Ebene
Addition
Datensatz
Druckertreiber
Mustersprache
Vererbungshierarchie
Physikalisches System
Bitrate
Tropfen
Faserbündel
Verkehrsinformation
Eins
Ebene
Bruchrechnung
Subtraktion
Bit
Punkt
Statistische Analyse
Computeranimation
Resultante
Umwandlungsenthalpie
Güte der Anpassung
Gruppenkeim
Quick-Sort
Raum-Zeit
Computeranimation
RFID
Homepage
Erwartungswert
Datenmanagement
Flächeninhalt
Spieltheorie
RFID
Softwareentwickler
Optimierung
Standardabweichung
Resultante
Automatische Handlungsplanung
Code
Computeranimation
Übergang
Datensatz
Spieltheorie
Minimum
Gamecontroller
Projektive Ebene
Coprozessor
Softwareentwickler
Maschinelles Sehen
Touchscreen
Beobachtungsstudie
Kraftfahrzeugmechatroniker
Punkt
Spieltheorie
Familie <Mathematik>
Projektive Ebene
Information
Kurvenanpassung
Softwareentwickler
Computeranimation
Übergang
Fehlermeldung
Datenmanagement
Thumbnail
Fuzzy-Logik
Selbst organisierendes System
Mathematisierung
Information
Sichtenkonzept
Gerade
Code
Computeranimation
Fehlermeldung
Fehlermeldung
Bit
Information
Softwareentwickler
Optimierung
Sichtenkonzept
Raum-Zeit
Computeranimation
Keller <Informatik>
Programmfehler
Homepage
Fehlermeldung
Softwaretest
Algorithmus
Spieltheorie
Vererbungshierarchie
Gruppenkeim
Softwareentwickler
Code
Gerade
Computeranimation
Office-Paket
Algorithmus
Computerspiel
Momentenproblem
Spieltheorie
Reihe
Speicherabzug
Softwareentwickler
Aggregatzustand
Richtung
Spieltheorie
Mathematisierung
Biprodukt
Softwareentwickler
Optimierung
Hill-Differentialgleichung
Code
Gerade
Homepage
Netzwerktopologie
Demoszene <Programmierung>
Textur-Mapping
Spieltheorie
Existenzsatz
Gebäude <Mathematik>
Volumenvisualisierung
Graphikkarte
Grundraum
Quick-Sort
Computeranimation
Gewicht <Mathematik>
Verkettung <Informatik>
Verbandstheorie
Mereologie
Gebäude <Mathematik>
Systemaufruf
Physikalisches System
Graphikkarte
Physikalische Theorie
Gerade
Quick-Sort
Dichte <Physik>
Objekt <Kategorie>
Maschinenschreiben
Gebäude <Mathematik>
Reihe
Horizontale
Graphikkarte
Hill-Differentialgleichung
Scheduling
Druckertreiber
Stab
Mustersprache
Wort <Informatik>
Physikalisches System
Kontrast <Statistik>
Optimierung
Code
Checkliste
Übergang
Fehlermeldung
Temperaturstrahlung
Rechter Winkel
Mustersprache
Systemaufruf
Physikalisches System
Computeranimation
Übergang
Physikalischer Effekt
Computer
Computeranimation
Fehlermeldung
Richtung
Datensatz
Total <Mathematik>
Extrempunkt
Computer
Computeranimation
Videospiel
Punkt
Hecke-Operator
Mereologie
Physikalisches System
Hill-Differentialgleichung
Computeranimation
Fehlermeldung
Schreib-Lese-Kopf
Bildschirmmaske
Datensatz
Benutzerschnittstellenverwaltungssystem
Zusammenhängender Graph
Speicher <Informatik>
Quick-Sort
Computeranimation
Subtraktion
Bit
Web log
Gruppenoperation
Quellcode
Physikalisches System
Computer
Quick-Sort
Eins
Weg <Topologie>
Bildschirmmaske
Gruppe <Mathematik>
Mereologie
Mustersprache
Lesen <Datenverarbeitung>
Beobachtungsstudie
Orientierung <Mathematik>
Bit
Abstimmung <Frequenz>
Prozess <Physik>
Anwendungsspezifischer Prozessor
Einfache Genauigkeit
Biprodukt
Bitrate
Fastring
Code
Programmfehler
Datenmanagement
Verbandstheorie
Prozess <Informatik>
Debugging
Optimierung
Figurierte Zahl
Gerade
Fehlermeldung
Aggregatzustand
Schreib-Lese-Kopf
Programmiergerät
Prozess <Physik>
Punkt
Web log
Momentenproblem
Gemeinsamer Speicher
t-Test
Übergang
Client
Perfekte Gruppe
Datenmanagement
Prozess <Informatik>
Zustand
Kontrollstruktur
Softwaretest
Schnelltaste
Topologische Einbettung
Biprodukt
Konfiguration <Informatik>
Rechenschieber
Druckverlauf
Grundsätze ordnungsmäßiger Datenverarbeitung
Aggregatzustand
Lesen <Datenverarbeitung>
Instantiierung
Blase
Subtraktion
Gewicht <Mathematik>
Mathematisierung
Besprechung/Interview
Term
Code
Framework <Informatik>
Task
Datensatz
Perspektive
Fächer <Mathematik>
Programmbibliothek
Softwareentwickler
Hilfesystem
Autorisierung
Expertensystem
Videospiel
Zehn
Open Source
Physikalisches System
Quick-Sort
Programmfehler
Summengleichung
Rationale Zahl
Debugging
Mereologie
Verkehrsinformation
Variationskoeffizient

Metadaten

Formale Metadaten

Titel The Good Bad Bug: Learning to Embrace Mistakes
Serientitel RailsConf 2017
Teil 20
Anzahl der Teile 86
Autor Rudder, Jessica
Lizenz CC-Namensnennung - 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/31292
Herausgeber Confreaks, LLC
Erscheinungsjahr 2017
Sprache Englisch

Inhaltliche Metadaten

Fachgebiet Informatik
Abstract The history of programming is filled with examples of bugs that actually turned out to be features and limitations that pushed developers to make an even more interesting product. We’ll journey through code that was so ‘bad’ it was actually good. Then we’ll learn to tame our inner perfectionists so our code will be even better than it is today.

Ähnliche Filme

Loading...