Keynote - Kent Beck

oh my gosh good morrow friends here we are it is oh my gosh it's already 11 central we are into the last day we're in the closing third of this marathon known as the ruby comp okay here we are well it is my pleasure to welcome you in to day three um as you are all very well aware the community on slack has been super super vibrant and i hope you've had the opportunity to really participate in as much of that as possible i have heard rumors mostly seen pictures that folks did do the karaoke last night upon nine zoom which must have been so smooth i would imagine or not who knows but regardless i am seeing so much fun fun fun stuff that's going on so uh massive applause to all of you for keeping this community alive and vibrant i really appreciate it personally and i know that all of us that are first-timers here appreciate it too so thank you all all right so let's kick this day off i want to bring to the stage marty one of the organizers here ruby central one of the directors to introduce our keynote for the day howdy marty hello good morning how are y'all doing ruby conf doing all right normally i'd be able to hear you all shout back from the audience but we're virtual so that's not going to happen um i do though sorely miss you in person i am a director by the way at ruby central and you've often seen me on stage before but so far with this conference i've been behind the scenes doing stuff in crowdcast but this morning i get to introduce our next keynote speaker now for some of you um he needs no introduction you're familiar with his work um but i suspect there are a good number in our audience who are not familiar with kim beck though i suspect you have encountered some of the ideas he's championed over the years personally kent's works uh have had a major impact on how i approach and write software i remember very distinctly back in 2004 when i uh joined a small software team that was uh going to practice xp or stream programming that i uh then had to uh was introduce these books and it changed everything um so the uh some of these ideas you're probably familiar with like test driven development unit testing refactoring thinking in patterns uh pair programming and other agile practices uh which is wild to think that back then um we it was fairly rare that this was done on teams and i remember having to advocate that we would do some of these practices on some of my software teams but now uh it's fairly commonplace uh so kent is no stranger to our conferences he's spoken here before the last time was in 2015 in atlanta for railsconf um but he's come back to share his insights with us today so without further ado please welcome kent beck to our virtual stage [Applause] [Music] so [Music] bye [Music] so one of the lessons of uh covet and isolation and lots and lots and lots of video is that every meeting is better if it starts with banjo so there you go that's uh that's my talk thank you all so much for coming um sears i i told this story uh just now in the green room and i'll tell it again i've always had a lot of uh imposter syndrome around music i've been playing for 50 years and i always like oh if i only i was better so i figured if i just forced myself to practice i would get better and then i'd be good enough and so i would force myself to practice for a while and i'd get better but i was never good enough and then i'd get discouraged and the cycle continues and when isolation started i just made a habit of starting every zoom meeting two minutes early uh can i say zoom on on crowdcast am i going to be anyway we'll we'll see what happens if i get cut off immediately you'll know so uh i would start at every zoom meeting with a couple minutes of music banjo guitar um and uh but i'd show up early and then i noticed that people other people started showing up early just to catch some music and they loved it and they gave me so much positive feedback that i wanted to practice because i wanted to be better because i wanted more of that stuff so your second lesson is uh it's not about the ironclad willpower it's about human connection i hate when that happens but there you go um okay so i do have other messages uh than that uh that would probably be plenty but i do have a message and what it is is a general principle reversibility as applied to software development and i'll make a another meta comment if you haven't seen me talk and by the way this is my first railsconf ruby conf talk ever so i'm that first timer that that adam mentioned unwind uh meta comment ah is that uh if you want to come up with ideas come up with combinations of ideas it's really hard to think up a new idea idea from scratch but relative to that it's easy to take two ideas that nobody just nobody ever put together before put them together and something interesting comes out of that so lots of stuff i write you'll see that as a as a theme and here it is reversibility is general principle as applied to team software development so we're going to take those two things together and see what comes out the the other side now i have had some questions about my presentation software so this is a canson xl 160 gram for any of you pen heads out there i have a lot of pens and a lot of paper this is beautiful paper i highly recommend and then and then these uh winsor newton brush markers again highly recommended so that's the that's the software that i'll be using today presentation maybe we'll have a giveaway if any of these slides turn out cool that would be fun okay so first idea is reversibility and what are we talking about here i recently debuted a a workshop with the jesse tron jessica kerr called invitation to systems thinking and as the wheel turns as it always does we we went from a a very reductionist approach to software development to a very holistic one and now we're back to kind of reductionist like oh what are the numbers and we're going to make the numbers go up and then everything will be better and whenever the wheel turns that direction the antidote is systems thinking so this is the idea that uh uh jessica's uh uh motto is uh relationality over rationality is the idea that in any complicated system uh you don't have control but you're not helpless it's there's a bunch of pieces in your system and it's their relationships that really um make it challenging i mean it's both the power of the system is that you get more than the sum of the parts and that's also what prevents you from having control over what the system does um so uh you can go look at systemsthinking.dev for uh information if you're interested in this workshop it's a lot of fun we just did the first one a couple weeks ago we're going to do another one in january and of commercial plug um in 2000 and one two maybe at an early early extreme programming conference we had a presentation by uh professor zaninoto who was the dean of the school of economics at the university of trento and he said this extreme programming stuff now remember this is a point at which extreme programming was wild and crazy and this could never possibly work and he said from an economist perspective extreme programming makes perfect sense and here's how it makes sense and he gave this fantastic presentation some of the clearest thinking that i've ever heard and it still took me about 15 years to figure out what he was talking about so here in a nutshell is it you guys will pick up on this quicker than i did thank goodness for that um what makes if you have some big complicated system there's no clear relationship between inputs and outputs you change the inputs and then what happens next who knows so if you have a giant factory and one little thing seemingly little thing can go wrong and the whole factory shuts down or you can take away an element in the factory and all of a sudden everything works more smoothly so what is this this is the over rationality part you can't figure out by looking at all the pieces in the system what's going on and what the professor said was there's a reason for that and it's because large complicated systems have first they just have many many states so i'm going to be sad that i wrote that large but there you go they have lots and lots of states so you might think oh the system is in this state so if i do this thing the same thing's going to happen the last time it was in that state well duh there are too too many states to be able to say the system is in this state i remember the the first time i ever pushed code at facebook the message that came back was uh your code was successfully pushed to 6300 out of 6400 servers and i panicked i'm like oh no what's on those other servers people said i who knows it's not causing problems don't worry about it well each one of those servers was in some kind of state and it wasn't even possible to understand what the states were much less understand what would happen if i changed the inputs how are the outputs going to change so uh another uh problem here is interconnection and this is the idea that the the pieces in the system don't stand alone any piece could alter any other piece so for example at gusto my my employer where we do small business payroll and benefits if you look at gusto itself as a system and how we deliver service to people you can say well this many customers call in with this kind of problem and this many customers call in with this kind of problem in it it takes a person this many hours to resolve it so uh retroactive address changes costs us uh 14 per customer per year something like that we can take all the costs of serving our customers and we can we can break it down and we say well here's the benefits ones and here's the payroll ones and of the payroll ones then this and then that up up above and down here we got we have 14 cents per customer per year whatever it is and and that accounts for all the costs all the historical costs but those aren't leaves in a tree all of those seeming leaves are potentially connected to all of the other ones so i can reduce over here i can reduce this 10 cents to zero by making some change and accidentally cause this other one to increase from 40 cents to two dollars and if i'm not looking very carefully at what i'm doing those interconnections are gonna make it impossible for me to go and control this this system i i eliminate 14 cents here and 14 cents gets eliminated from the top nah sometimes i eliminate 14 cents here and two dollars goes away from the top and sometimes two dollars it gets increased in the top so that's this sense of interconnection we're not dealing with leaves in a tree we're dealing with items that are all potentially connected to each other and in software development we talk about coupling as a measure of that that interconnection between the elements in a software design uh a third source of difficulty is the variation so the reason we can't control this system is because things change um the external world will change even the internal world will change something like a wear in a mechanical system will cause small differences and sometimes small differences make no difference in the end sometimes small differences though make very large differences in the end and we can't account for all of this variation and the the last uh element that makes systems impossible to control is reverse is irreversibility which is once we make a decision we can't unmake it and uh irreversibility is all around us i recently decided to downsize my stuff um and so i thought well i've got all these boxes of books uh that i've collected for decades and next eight decades it's like 50 boxes of books and uh they're stored away but i'd like to just get rid of them but i feel kind of funny about getting rid of them because i have a lot of attachment to these books if i just discarded the books that would be an irreversible decision i couldn't get them back i couldn't even remember what they all were because it's thousands literally thousands of books so i thought ah what i'm going to do is i'm going to scan all of my books into goodreads and then if i want to read them again if i want to remember what i've read and if i want to read them again kindle is there i can go get a copy get an electronic copy and i can reread anything that i've ever read in the last years so that's a that's an example of an irreversible decision turning into a reversible decision uh an another part of my downsizing is my journals so one of my practices every morning is i'll just free associate for two pages worth i'll just write write whatever comes into my head and sometimes it's trivial stuff and sometimes it's my plans for the day and sometimes it's deep thoughts and so on but i have a shelf full of these journals and i thought well maybe i should get rid of those too because it feels good like 550 boxes is just gone that's like three-fourths of my physical stuff is gone and that felt good maybe i should get rid of my journals too but getting rid of the journals is an irreversible decision i was able to make the the getting rid of the books a reversible decision because of the magic of kindle and so on but getting rid of the journals is irreversible now i could make it into a reversible decision by carefully scanning each page blah blah blah but that is definitely more trouble than i want to go to so there we have these decisions uh uh which can be reversible or irreversible if you're in a complicated system and you make an irreversible decision you can't take it back if you if you uh if you accidentally send your the the details of your customer list out onto the internet you can you can't take it back and distinguishing between reversible and irreversible decisions is really important so back to professor zaninoto he says it's these four factors that make operating complicated systems so difficult and extreme programming makes perfect sense as a way of addressing this kind of complication in software development because it takes many many decisions that previously were irreversible and makes them reversible so if you plan every day it plan every day then something changes you realize yesterday's plan was bad you only lost a day you reorganized the priorities and away you go so compare that to the old-timey waterfally which no one would ever ever do except this is another one where the wheel is turned and somehow people are talking about waterfall like it works and it doesn't work for all the reasons it never worked and there are alternatives okay thought i'd slain that dragon nah but uh in a a big waterfall so we've got this is the scope and we're gonna deliver in six months and that's that that's an irreversible decision if you decide if you realize oh that's the wrong thing to do it's really hard to change that because you've made commitments about what's going to be delivered when but in the xp planning style and iterative planning style uh okay last week we thought we needed this and we don't really need it and now it's now we don't have it anymore and away we go you re-plan and and and off you go or if the design is wrong the architecture is wrong you discover that later because you always discover things because the alternative to discovering things is being dead and nobody likes that um then you change it there aren't irreversible decisions in extreme programming of of that sort now as i tried to apply as a geek i try to apply these principles to my life and it turns out there's plenty of irreversible decisions in your life you can't just take back a statement that you made to someone you're in a relationship with it's there's no revert for for uh dumb things that you say and i've said plenty of dumb things so it's not always possible but there are certainly cases where you have irreversible decisions which can be turned into reversible decisions and that's part of the power of this style of thinking about complicated systems i was noticing just today i used i used the phrase oh that ship has sailed that's a that that means that is the decision was irreversible and it's already made so even baked into our languages we have these metaphors for describing reversibility so that's that's part number one that's you've got complicated systems you can't control them because they have too many states they have too many interconnections between the elements there's too much variation you can't possibly see and the decisions that you make are irreversible so henry ford for example in the big model t plant he chose to reduce the number of states as a way of controlling the system so the reason that all the you can have a car any color you want as long as it's black is not because henry ford thought that black was the greatest color henry ford realized that yes i have paint no i don't have paint is much simpler to manage than do i have the right amounts of these various colors so he deliberately simplified the product to reduce the number of states so that he can operate that big complicated factory um in a way that nobody really had before okay so that's reversibility now i'm going to talk about some of my more recent uh research which is on software design been designing software for a long time uh feel confident about but the boundaries of what i can design and can't design but i started to dig into it and i realized oh i don't really understand this very well at all and um i started working on a book called tidy first which this is this diagram is is taken from uh i'm still working on the book hopefully we'll get it done we'll see what happens anyway so here's the basic loop in software development we'll go with a different color just because uh you have an idea so we'd like the software to do x y and z okay and from that idea you need to change the behavior of the system so we need a button that does x y and z okay so we add the button now the behavior is different and now we can evaluate okay was that really a good idea do people use it do people like it are there any problems with it and from a certain perspective this is what software development is if you're not a programmer this is what software development looks like to you there's a team you say i want a button that does x some later time a button that does x appears as programmers we know that this isn't the whole picture that changing the behavior of the system can be easier or harder depending on its design so the whole reason we design software is so we so we can change it if we never needed to change it then all variables could be global all uh we wouldn't need sub routines we just have a routine and you know income the inputs and out outcome the outputs the reason that we break our software systems into parts is so that we can change them and that that change that we those changes that we make rely on the structure of the system and this is the part that's kind of underwater if you're not a developer you say well i could add this button but i'd have to go change here and here and here and here and if we rearrange the design then i'd only have to change one place that's a change to the structure of the system that leads to a change in the behavior so there's a flow that you need sometimes you can go straight from an idea to a change in the behavior and away you go and it's not hard sometimes though you go you take an idea and you're thinking ah this is harder than it needs to be so i'm gonna this is the tidy first flow from the title of the book i'm gonna tidy first i'm gonna change the structure in a way that makes it easy for me to change the behavior later so i change the structure now changing the behavior is easy and away i go that's not the whole story now from the the this brings up it's a whole book's worth of stuff and i'm giving you half of the talk is about it so how can i possibly get everything in i can't in through the nose out through the mouth another that would be worth the whole talk right there i promise okay okay i i got this so sometimes you change the behavior and you if you had to do it in a messy way because sometimes you sometimes there's not a clean way you can't think of a clean way so you just go from your idea to the change the behavior and then you say oh you're sitting sitting there this offense happens to me in the middle of the night i wake up and i go oh if only the system was structured like this then those behavior changes we wanted to make would be easy so there's another flow that goes from i change the behavior to i change then i change the structure this is not this is tidy after this is okay i had to mess stuff up to get this finished and now i now i invest in the structure so that future changes like that will be cheaper easier safer simpler easier to teach other people to do and so on all the good things about a structure that's adapted to the kind of behavior changes that we want to make part of the magic of software as a business is that sometimes the structure itself will suggest ideas and this is where this rigid separation between product and engineering uh is a sub-optimal because the programmers know what's cheap and easy it's difficult to have that kind of intuition from outside without having an appreciation for the structure of the system so an example at gusto we had a tax calculator we actually had two tax calculators we had one that worked let me see i'll make something up that sounds plausible and then i'll check later one that worked when you were signing people up and one that worked when you were actually running payroll and it made at the very beginnings it made sense different teams were working on these two things and they wasn't until they'd grown big and complicated because the tax calculator oh my goodness if you want interesting domains working on uh payroll and benefits is actually super interesting because it's got so many corner cases um we had two full-fledged tax calculators before we noticed that we really had two and that every time we changed one we had to change the other which is the definition of coupling so uh one of the senior engineers said hey this isn't right a couple of senior people went off and merged the two calculators into into one well as soon as we had this this one tax calculator with a very simple interface it was all primitives coming into it instead of being wired into rails this and database that we had one calculator simple input simple outputs we said oh so someone from marketing said oh i i wish we we could just have a tax calculator on our home page so now there is because a programmer overheard this conversation they said oh that's easy now it would have been really hard before investing in the structure but after investing in the structure it's quite simple so if you go to gusto.com i don't remember what you can say what would my paycheck look like if i'm in maryland and you put in the all that stuff and out come the numbers and those are exactly the same numbers that would occur were you to sign up for the service so sometimes the structure itself creates ideas okay so here we have this is this is development and it's uh it's a this is a complicated system there are a bunch of people involved there are a bunch of uh technologies involved um it has all those the development of a software system has all those features that we just went through as many many many states there's interconnections between stuff that nobody has a clue about there's all kinds of variation covid hits and all of a sudden all of your road maps which aren't roadmap is a lousy metaphor anyway should be like a compass directions that would make more sense we think we're going this direction well covid comes along and you're not going that direction anymore all of a sudden you have to deal with the payroll protection program and off you go and everything has changed so that's variation happens all the time people coming and going on and on and on and on there's lots of variation and uh you're making if you're working in large blocks of time you're making irreversible decisions and if you're making irreversible decisions that whole structure of software development is going to be impossible to control um even if you break it down into smaller reverse and more easily reversible decisions you can't control it but neither is it is it completely out of your control so that's where this is where uh okay so i'm about to get to reversibility here's the here's the thing to note if you have the behavior changes that you make to the system are irreversible if if uh if i change a line of code i guess so uh and we now submit the wrong reports to the irs you can't just say oh baxies no no no it had if i change the behavior of the system it has real irreversible consequences in the world so i want to treat these decisions irreversible decisions very carefully i want to vet them i want to validate them i want to be really really cautious with them but this is the point that like had escaped me for so so long structured decisions about the structure system of the system are are reversible easily reversible i extract out some helper method and then somebody comes along and says i don't like that click okay inline it boof it's as if i hadn't extracted that at all when you get to larger scales it can be hard harder to reverse decisions so for example if i extract a service don't get me started on microservices all right but anyway extract the service in lining that back in it's going to be more work than that there isn't uh in my ide there isn't an extract microservice inline microservice that doesn't exist just yet i wouldn't put it past you guys to go and figure that one out and i hope you do but most decisions about structure are easily reversible so we should treat behavioral decisions completely differently than we treat structural decisions i have an experiment for you uh if you wanted to try to apply this uh first be very careful i i'm gonna assume that you do uh this pull request blocking asynchronous review stuff which is again don't get me started but assuming that you work in that style each pull request contains either behavior changes or structure changes but never both that's the first one then the the second part of this is you clearly label which of those you're operating under and then pay attention to the results of review of structure changes and behavior changes and uh i would go so far as to say once you're once you're comfortable with making this strong division between structure changes and behavior changes the structure changes can be fast-tracked as long as they pass all the tests uh and away it goes you don't really need more review than that because if somebody doesn't like it oh that violates our layers blah blah blah okay go fix it or i'll go fix it either way it's fine so make this strong distinction between behavior p behavioral pr's and structural pr's and then see how you can apply uh your review process differently depending on which of those you're dealing with now sometimes you'll need to just go and you'll go and program and behavior changes and structure changes everything's all munched together then if you're performing this experiment you need to go back to you take that big bunch of changes and you reverse engineer you say okay well i can make change this about the structure and this about the structure and then i change that about the behavior and then i change this about and away you go and in the end you'll have a sequence of really small diffs each of which does uh prepares the either prepares for for changing the behavior or actually changes the behavior so um one of my uh most popular my most widely viewed tweets i guess i know popular seems like more of a value judgment by measurement said uh don't make hard changes first make the change easy warning this may be hard then make the easy change so this being ruby land i'll turn that into an almost pronounceable acronym make it matte mick make the change easy then make the easy change so this is uh this is a style of development a a choice for how you approach development that says when i'm faced with a change that's gonna be hard rather than just oh i'm gonna do this what could you do that would make that change easier how could you invest in the structure so that the change would actually be a you know once we then this is a one-liner okay sometimes what you want to do before you make that behavior change is which would be hard is to make it easy first so uh make it mac it says uh rather than doing hard things make the hard things easy something about this seems to great on a certain class of programmers now i grew up as a programmer my dad was a programmer grew up in silicon valley the whole thing so i'm i've known programmers literally my whole life and some of them seem to have a masochistic streak to them a streak that says uh you know yeah i'm gonna go in and i'm gonna through the power of my magical brain i'm going to change 50 12 things and all at once and then the first time i run it it's all gonna run and whoa fantastic and and there seems to be a kind of a power rush that comes of making that kind of a magical huge change and a huge psychic payoff the one time in your career when it actually works maybe like every 10 years you get one of those that actually works and there also seems to be some kind of psychic blinders about the many many many many many many times when you try that trick and it doesn't work and it's a gigantic mess and it turns out that it's 10 times harder than you thought it was or it would have been easier but because of the way you did it it turned out to be much much harder and it just doesn't phase this class of programmers and i i don't understand that um now i think it helps that i was never a big complexity person i could never take a huge problem and put it all into my brain and fix it all so from very early on in in my programming career i had to make things simpler not out of some i mean it's just it's just a a a survival mechanism for me i just couldn't make behavioral changes if i didn't make the structural changes first this just wasn't an option for me and uh my good friend kevin ryan who's still out there programming and doing wonderful work on on games he was the exact opposite he could just take enormous amounts of complexity put it into his head and somehow manage the manage that whole thing and get stuff that would work so incredible machine is one of his his things anyway he could do that i couldn't do that so i was forced into this tidy first and then once once you're in the world of making structural changes refactoring comes as a very natural consequence because you don't want to break things and you want to work in small pieces and you want to be able to abandon structural changes halfway through if you learn something or priorities change without having lost all of the investment that you make now this does presume i was hoping i'd have a chance to talk about this this is a little bit of a finger wag so prepare yourselves um this presumes that making a single change is quick and cheap and another one of these wheels that's turned is when i started out in programming you'd submit a deck of punch cards and then hours or days later you get a stack of green stripe paper that's the output of it many many very smart very wise people worked extremely hard so you could just change something and see it so this is the certainly the small talk ethos it's been the ruby ethos from very early and we would always thumb our noses at the c plus people with their 48 hour builds like ah yeah you guys you know if if a change takes 48 hours to validate you have to make big changes you have to make big changes and we had gotten on to this new style of programming where we could just make change i could make 10 changes in a minute and it's just fine i get feedback from each of those changes test driven development took that substrate that you could make changes and get feedback quickly and and uh amplified it by giving you better feedback on more of the system in in those short periods of time somehow we have lost the plot in software tools i'm now seeing build times that take 10 minutes or an hour or multiple hours and no shorter path to any decent feedback than running the entire build and it's i i don't understand it it's like we're back to punched cards and again this is maybe a little masochism or a little gatekeeping like oh if you're not smart enough to program like this then you're not smart enough to program and i think it's i think it's uh horrible and i the the measure that i wished that we could adopt for our programming tools is latency instead of throughput how quickly can i get feedback and if somebody comes along and says oh a tool chain this and blah blah that and here's this thing and it only adds 12 minutes to the tool chain which is always already an hour and a half long oh who cares no i think that's not okay i think that i would much rather have less feedback in a second so that my flow of thought wasn't interrupted and i could get back to work so if you're working on software tools and every programmer should at least think about working on software tools because they affect you all the time think about the latency of the feedback that's provided so uh the end of end of finger wag but so let's take this idea and crank it up to 11. i don't have very many tricks you know so let's crank this style of development up to 11 and see what happens i i again i'm short of time to tell you about all of this but i have another experiment for you which is cheap and easy to do uh and it's an alternative to test driven development oh i said i wasn't gonna do polls but i would love to do a poll and find out how many people use test driven development on a daily basis uh speaking to the meeting gods if that happened i would be happy thank you so uh tdd encourages you to work in small cycles but could it be better uh i was giving a code camp in norway at iterate and i told my the the participants about this workflow that i had where i would run my tests and if they passed i would make a little get commit and that meant that any time i got into that state where you're like it's broken and i didn't change anything you always change something that's the first rule you'd always change something how can i get back to a known good state there was always a commit for that you could always go back to it and admon one of the the participants said well by symmetry which is another one of my tricks and i didn't think of it this time so i'm like a little bit miffed but there you go by symmetry if you commit when the tests pass shouldn't you revert when the tests fail so here's how that works you program program program you say save automatically the tests are run if they fail the last commit which was the last time the tesla passed per definition just gets gets pulled in so i write 10 lines of code that i'm sure works and i press save and it poof it just disappears and uh i'm like well that can't be pos i know that works so i'm going to type it in again so i type it in again poof it disappears again it goes straight to this revert and now i'm thinking oh so now i better think about what's actually going wrong so is there a way for me to type two lines of code that will be consistent with the current tests and then that'll make a commit and then at least those two lines aren't going to get poofed on me okay so and and that's the that's the magic moment when you think here's this single chunk of code that i can't make that's irreducibly smaller and i make it even smaller than that um as soon as i started using tcr uh i would had gotten kind of bored with tdd it's like i know the moves yes you can apply it in different domains but the workflow itself was like old hat tcr lit me back up again like oh this is impossible these five lines don't work and it's impossible to figure out how to introduce them one at a time maybe not and uh so what tcr is is an incentive system that incentivizes you to make changes smaller and smaller and this is easy easy to um to experiment with uh i have a [Music] a youtube video of of like an hour of me or hour and a half of me doing tcr on a data structure the rope data structure and there's a video in there about setting up your system so that the vs code in particular so that tcr happens to you automatically this is another this is one of these this is a easily reversible you can try this out it won't ruin your life it's not like uh i don't know some drug that you take that eliminates your ability to have joy you try this out doesn't work it's fine but if it does work for you the the there's for me part of the payoff of tdd is a reduction in anxiety it's like oh does this work well i just run the test sometimes i'll run the test three four times before i feel relaxed enough to move forward tcr is that squared because every single little change that you've made has been validated and i have a blast with it i recommend that you try it and that's what i have prepared for you i will be on slack um if you have questions about what we've talked about what we the royal we have talked about if you have questions about what i've talked about or how to apply it or how does it come into ruby please let me know be glad to discuss it and one more banjo tune [Music] [Music] all right let me say this has been one of the most fun keynotes i've ever experienced in my life mostly because it started it ended with a banjo so massive appreciation and thank you to you huge huge uh thanks like you said head over to the slack channel follow up with him there if you have any questions otherwise have a wonderful and fantastic dive into day three everybody make sure to find your tribe on any of the slack channels that speak and resonate to you and of course if you have any questions we'll see you on slack thank you again kent much appreciated my friend my pleasure okay

Channel: Ruby Central

Views: 746

Rating: 5 out of 5

Keywords:

Id: UIyMs7xV6eo

Length: 53min 54sec (3234 seconds)

Published: Fri Dec 18 2020