Beauty in Code 2018, 7 of 7 — Kent Beck: "Summarizing the Beauty in Code Conference"

Kent Beck thank you so much is my voice booming - oh good it's an unenviable position to be between the audience and their beer but here I am and and I get you for an hour who's who's calling time for me ah hi thank you I'm gonna start with a story I'm a storyteller so I'll start with a story it was a kind of lay dish maybe so I I don't have the exact date but I was in my office I was living in Southern Oregon at that time it was a night time I remember whose dark outside and David's apps is about 2005 six something like that David staff and I were working on J unit J unit was originally written on an airplane going from Vienna to Washington DC long story was a big surprise how popular J unit was but it had it became surprisingly popular the more popular it got the more people added value to it the more people added value to it the more popular it got and eventually becomes a platform and then there's even more ways for people to add value to it as is the way with anything that grows incrementally the the tree requires pruning from time to time and the the there was one function that did actually you have a test case and you want to run it and that function had gotten bigger and bigger and more more complicated overtime and it had gotten to the place where we couldn't change anything about it without breaking something else and open-source software is an interesting economic proposition because you have a very small budget for development you have very demanding users and especially at that point j-unit was a very fundamental piece of infrastructure who's you know if you wanted to build the entire world of Java software janet was one of the first things that that you had to build because everything else had J unit tests so we took backwards compatibility very seriously we took regression testing very seriously because if we didn't trying to fix those problems would be way more effort than we had time available to devote to it at the same time we knew that we wanted to continue evolving it and this function run test I think it was called it just gotten so big and complicated that it had become the the always Adams phrase it's this the intersection of complexity and frequency of change so over the the the development rhythm for j-unit is once a week david staff and I would get together David said Google now at the Boston office we'd get together remotely and we pair programming so all development on j-unit happened via pair programming remotely if necessary because we couldn't always be on airplanes and so we had recognized that this that this function was a was our bottleneck and we started doing our version of Adams splinter what was it the splinter pattern so we started teasing this bowl of spaghetti apart into individual strands of spaghetti and what resulted from from that extracting one function after another was a long chain of function calls so instead of being one big function it was a function that would do a little bit of work and then call another function that would do a little bit of work that would call another function that did all the way down and one of the the varsity level the graduate level refactorings in object-oriented programming is taking a function and creating an object out of it and done at the right time in the right place that can be absolutely magic so over the course of this to our programming session David and I took the functions in this long chain which was itself hard to understand and we created objects for each one of those and as we were doing it it was it was dead easy because we'd set up the little functions in this long chain we're all quite simple and quite separated so creating an object for it and the next one and the next one and the next one so that was that was step one and kind of that happened quickly and then then we looked at this and we said well instead of just calling into this object will call that object we'll call that I we're going to create a collection of these objects and invoke them externally one at a time and then we thought well what do we call these these objects that we've just created well there was a there was an object that would set stuff up before the tests ran and then there was another one that would tear stuff down after the test ran and we thought you know these are kind of these are kind of the the rules of the game of running a test and this two-hour session which was which was easy and magical at the same time was the origin of of je units rule feature because once we'd created these objects we said well I mean these are just the ones that we want other people could want other rules how are we gonna let them say I want my rule to execute as well well let's let's just add an annotation for that and it was kind of an afterthought we hadn't set out at the beginning of those two hours to create the rule annotation it was something that emerged out of a bunch of little tiny individually easy changes and those little tiny individual changes emerged out of probably six weeks worth of careful preparation for that taking this big bowl of spaghetti and pulling it apart how many people have used rules in JUnit tests or something yeah they're not like the it's not like a major feature but when you need it it's really cool because you can create context for your tests that context is easily reused in other tests without having to confuse that with inheritance between test classes and and it works out really nicely so that the lesson for me there was that making big changes doesn't have to be the result of making big changes it can emerge just from little locally optimizing changes that you make just really for reasons of aesthetics so my name is Kent Beck I am a recovering Facebook employee it's been two weeks since my last employment at Facebook do you recognize this introduction you're supposed to say hi Kent now but you don't thank you very much this has been an interesting transition you know it's still my good hoodies are still facebook hoodies so I'm clearly haven't separated yet I was at Facebook for seven years and I learned lots and lots of interesting lessons there many of the lessons that I learned at Facebook was that I didn't know near as much as I thought I knew Facebook has a very particular way of doing things that's quite different than anything that I'd written down in one of my books and so I had to kind of swallow my pride when I went there too to learn how things were done differently in in the Facebook style so this is my first public talk since since I left Facebook and actually I gave a workshop yesterday and I kept saying we and us in speaking with Facebook it's gonna take me a while to to get rid of that but there you have it I wanted to try something fairly ambitious I spent most of my time at Facebook focused on engineering education so teaching engineers how to be better better engineers and I I wasn't working I didn't write lots of code I didn't think lots of thoughts about I don't know design patterns or something I was thinking about engineering culture so I decided to give myself a fairly ambitious abstract of four for this talk to talk about the uses of symmetry in coding and I worked on the talk in little bits and pieces over the last couple of weeks especially and this morning as I was just preparing to put the final finishing touches on the talk the entire thing fell apart so that was interesting to to realize that that the the topic I'd chosen I I couldn't speak to at all and so it's kind of good news bad news the bad news is I for me I didn't understand this topic of symmetry nearly as well as I thought I did and the the bad news for you is you don't get to hear about it but the good news is I get to turn around my topic and Here I am the the anchor leg of your day of thinking about development I get to summarize what I've heard from all of the other excellent speakers and the even better news for me is they don't get to respond so so here's what I heard all of the talks - in one way or another were about making sense of of programming and programs so you know we weren't given lots of details besides this beautiful title beauty and code we weren't given a lot of direction about what to talk about at least I wasn't so it's always interesting to to step back in a situation like that and see what emerges and sometimes there's no particular common thread in this case this theme of making sense came out of what everyone did so James talked about making sense of the emergent properties of of programs the looking carefully at the actual behavior programs and seeing how that compared to the specification now I want to issue an apology publicly for dissing what he does well I'll say in my defense that that what you think thank you James that was the the 18 years earlier narcissistic bastard me and so I can believe that I said that but it's got to be hard to be really good at something that you know is important and have somebody piss on it so my my apologies one of the challenges that we have is we use this word test and we each mean something and we each mean something valuable but we don't mean the same thing about it so this idea I mean one of the things I had to learn at Facebook is pass/fail is is while it's important it isn't the most important thing I remember the the first code that I ever pushed at Facebook you know nervously watching am I gonna crash the system you know I'd written all my tests and you know because I'm me and yeah I did crash the system but anyway so I see that came a little later in the story so I see the production code successfully pushed to 6500 of 6600 servers and I freaked out what's on the other hundred servers yeah who knows like really nobody knows like my code is mostly running but sometimes not running yeah yeah that's fine it doesn't break any like really so having code that will run under those conditions it's really hard to unit test that and that was one of the lessons feedback loops are really important tests are a feedback loop but they're not necessarily in the world of trade-offs the the most important ones to include and the kind of feedback loops that the James was talking about have to go through production before you can see how do all these pieces come together and and how do they how do they all behave as ylim took that a step further to talk about making sense of the development of a software system where the existence of the system changes its own requirements you know by you may or may not have heard my rants about this word requirement for things that aren't required because you don't necessarily have to do them all and people are still happy so why do we call them requirements that's why stories came out and then people polluted it by calling you user stories but that's another long story as ylim wanted to make sense of what we're doing not just in terms of the thing we're doing but the effect that it has on the world I think you know I get asked lots of questions about the agile manifesto and and I'm not just a signatory of the agile manifesto I am the first signatory of the agile manifesto alphabetically and Mike Beadle is still pissed off about this but be easy haha so something we missed I think in there like I get lots of questions I don't answer lots of questions and don't come ask me questions cuz like I was really sick at the meeting I was taking some industrial grade antibiotics and I can't remember about what happened there so plus like that's way old news there's new stuff you want to ask me about my new stuff I'll talk your ear off but in a case the there's a there's a line in there that the the best measure of a system is a running code and I think that's the issue that asslam was was addressing that's a remarkably narrow-minded statement the measure of a system is the effects it has on the world intended and unintended measurable and unmeasurable if you want to understand your system you have to go much beyond inputs and outputs and look at are we number one yet and if we're not what do we need to do to get to number three and then to to and then to crush those guys Adams presentation was again about making sense we build programs and they have a complexity all their own especially if multiple people work on them or even if one person works on them for any length of time complexity emerges that nobody really intended which is why we need the kinds of tools that's that Adams talking about to make sense of this thing that we've created this is a active area of experimentation of mine I enjoyed having a giant code base and a whole bunch of very active developers at Facebook I could go in mind the the repositories there now I have to go find other repos and and figure them out I'm looking forward to trying out the tool to see what it brings I think there's a ton of understanding of the social nature of a code as well as the actual structure of code to be had looking at at that kind of data but again Adams trying to make sense of hey we all got together we made this thing it behaves in bizarre ways this James would notice it has bizarre effects and unexpected effects on the world is Aslan would notice and an atom builds these tools that lets us say what the hell's going on Facebook's quite a cuss so I will probably use language that's not safe for children I'm in Sweden dude is that it does that make it okay or not okay okay sooo yeah all right Kevin's talk was again about sense making in this case sense making about what it is that we do these ideas that we have as somebody who tries to come up with now here's a I'm gonna I'm gonna backtrack on what I was about to say I was about to say as somebody who tries to come up with new things I don't try to come up with new things I try to make sense of the world oftentimes the things that I'm told I ought to be doing don't make any sense to me so I just do what makes sense to me as a weird person that's interpreted as innovation sometimes it's interpreted as courage like how could you say that we don't need big specs you know this is back in the extreme programming days how could you say that we what we don't that's how I can say it it didn't seem like a a matter of courage for me to express this just more like well this doesn't make any sense to me Kevin was pointing out that the the problems are our eternal and recurring and we've been trying to address these problems for as long as there have been programmers one of the magic things about the history of programming is just to get into programming early on you had to be wicked wicked smart so the early pioneers were just really smart and really thoughtful about what they did because if they weren't they couldn't do it at all so the if you go back and you read the historical documents there's oftentimes interesting bits and pieces that that you miss I've had the wonderful good fortune of interacting with with many computing pioneers and when I talked to somebody who was in at the beginning of something they always have a take on it that's surprising and unusual I was I was telling Kristin Nygaard stories last night at the gin bar and just remembering talking to him about object orientation he would say things you know and I'm like the an object guy he would say things that still surprise me because he understood it at a level that that nobody else understood it having been there at the beginnings the world takes on the part of the understanding that it's ready to take on but something's lost in the process and every once in a while so I'll use a vinyl reference since you know you kids are in a vinyl these days every once in a while we should take the 45 that that has the big hit and flip it over and play the b-side and go what what what's on the back of that there is something else there there are insights there the problems we face are not unique and brand-new which is how I made my living at Facebook you know I'd have some me poor young engineer come to me as a broker grammar here and everybody's gonna find out and as soon as they find out I'm gonna be fired and I'd say Oh imposter syndrome like there's a name for this oh yeah oh yeah let me tell you about last week and then I tell him some story and then I give them some exercises to do you know go have this conversation with that person and then write this down and then come talk to me and honest that's what kept me going at Facebook the look on some some little engineer the you know engineer lit what's the what's the term for like a little proto engineer there's got to be okay we'll come up with this one eventually the look on their face when they realized yeah I'm weird yeah you're weird but you're not alone you're not the first person to face a that it's just a wonderful feeling for me as a teacher the these problems that we're addressing you know concurrency been there for a long time yes we kind of got off into the weeds we don't have to stay there it's a choice there are alternatives there are alternatives from the past there's alternatives that make sense today maybe you'll come up with something brand new who knows do something that makes sense to you that was the message I got from Kevin that that we look at all of these big problems that we have and it's easy to be overwhelmed and think oh what can we do well you know what these problems have been around since the beginnings of programming and you know some of the problems that we deal with go back to Roman engineers probably went you know I just I don't know how to lay the stones to build this bridge and somebody's gonna figure out that I don't know anything about stones and then they're gonna chop my head off and some older Roman engineer probably went imposter syndrome and go write this thing and talk to the guy and then you'll be fine so there's this sense that that yeah it looks like we're in this crazy chaotic world but it's really not that bad yes we have problems to solve you know it's not going to be easy but we're in we are part of a history and a sweep and we all have our parts to play but it's not like we invented these horrible problems and there's just no way out a Louis's presentation was interesting to me I have I had to make a decision very early on in in extreme programming were we going to go the certification route or not and I can get kind of nasty about this so I'm gonna try and rein it in my decision was that there would be no extreme programming certification actually that's the lie there is this extreme programming certification and here's how it goes you come and you work for me for free for six months and you pay me a hundred and fifty thousand dollars and I will write 10 pages about your strengths and weaknesses and post it publicly that's the XP certification and nobody's taking me up on this yet but there it is because that those 10 pages would mean something right there's backing their skin in the game the incentives are pretty well aligned and I think of certification as an attempt to make sense of what we do as engineers like what's the repeatable process for teaching an engineer well if you looked at the process I went through to learn how to be an engineer you would not want to repeat that guaranteed and I think that's true of most people like we don't even I don't think we even have a grasp of what the fundamental skills are I mean I have my list but they're the things that I'm proud of and the things that I enjoy doing and that list is very different than other people lists so do I get to impose my list of basic skills on you do you get to impose your basic list of skills on me my my understanding of the problem grew more complicated and nuanced based on my experiences at Facebook so I when I got there there was very little unit testing no pair programming no particular planning cycle and yet they were kicking ass this 700 million people a month were using the surface service we were continuing to add feature see had we I just slip into it they were continuing to add features it was continuing to grow and scale like they were doing everything wrong and getting things mostly right so it took me five years to make sense of what was going on at Facebook turns out different parts of Facebook operate very differently in a very different structure and how many of you have heard about 3x explore expand extract ok so I can look at that as an opportunity for the rest of you to try and get the point across and then I can go on about this for hours but I'll give you the two minute version how much time do I have half an hour excellent I'll give you the three-minute version so here's how it goes you have the the early days of some project say you want to write a new testing framework who in the world would want to do that but anyway you wanted you want to write a new testing framework you're going to you don't have anything to lose so the value maximizing behavior in the early phases of a project is to try experiments and discard them if they don't work your biggest risk in the early days of a project is indifference nobody cares about this project Oh another testing framework and yet the one thing you know for sure is ten years from now 20 years from now they'll be somebody's gonna come up with the next testing framework or the next programming language or the next instruction set architecture all these things that seem like they're absolutely rock-solid today they all started as just somebody trying some stuff out if you want to maximize the value you create you say like I got this much money or I have this much time I'm going to run as many experiments as possible because I don't know what's going to be that one program like j-unit was for us we flew from from Vienna to to Washington DC and then on to Atlanta where the loop slow conference was we handed j-unit to Martin Fowler who said this is great Martin tends to be an encouraging person so I discount that the next day though we had 30 people clamoring to get floppy disks you know floppy just a little 3d printed save icon all these people just like how can I get a copy of this and this had never happened to us before so if you're if you're in this exploratory phase your best bet is to is is to minimize latency what would people care about this what's the shortest path to handing it to somebody to see if they care about it doesn't if I spent 10 times as long making something carefully polished with beautiful documentation and then I handed it to someone and they went and I'm not interested you could say well I could have just given you a crappy product and you would have given me the same feedback so next time I'm gonna treat this as an experiment not as a long-term debt but just an experiment so there are places in Facebook that work in this this exploratory style and it's when you the lifetime of the code is short the consequences of failure are either small or you can limit them and and you don't know how people are going to respond to it so that sometimes I call this a it's like a game it's like you've got a football you know the real football not the American one and and you figure out okay here's how we play football fine good now one of those ideas takes off poof now you're scaling rapidly the server's are catching fire you're running out of disk space and you're running out of power and you're running out of floor space each one of these problems that you run into you couldn't have anticipated before you scale because it's just never happened to you before and number two you don't have time to do more than just kind of duct tape the whole thing together to keep it up to get you to the next crisis so I call this the expand phase in expand phase one of these experiments has taken off unexpectedly and now you're scaling faster than you believe you can customers are screaming at you we want this and it doesn't work damn you that's wonderful progress because just before you try that experiment nobody cared about you thing at all now they're screaming at you ah thank you the rules of that game that expansion game are completely different than the rules of the exploration game exploration game crazy crazy creativity if you have a bad idea and you can make it cheap enough to try it you should just try it like this is out TDD came about I had built the first testing framework for in the ex family for a small talk and I remembered a book that I'd read as a kid so my dad was an engineer too and he bring books home and I would read these books like cover to cover absolutely obsessed with what was in them not understanding a single word and then I'd go back and I'd read the whole thing again so like the Burroughs 6,700 instruction set manual he's all in here someplace even though I didn't understand it at all it's a pretty cool architecture just in case you're looking for some light reading so one of these books was said here's how you write a program you you take the input tape you know tapes right it's like a long thin floppy disk a flock flattened and never mind anyway you take the input tape and you look at the contents and you type in the output tape that you expect is how data processing happened is was this tape to tape you divert a tape a program they would transform it now you have another tape and you mount that as the input to the next process and so on and so forth so you you type in the output tape do you expect manually and then programming is the process of writing this program until the actual output tape matches the expected output tape so that was floating around in my brain for 20-hour for many years and I had this testing framework and the two ideas collide cuz most valuable ideas is two or three ideas coming together cuz there isn't anything new Under the Sun so those ideas came together and I laughed out loud I thought well if I took this type the output tape thing first if I took that schema seriously then what I would do is I would write the test before I had the code that's so stupid because you know it's gonna fail you right you want the test to pass and that's why you write the test after you write the code cuz you're such a genius that you're gonna write the test and it's gonna pass and it's going to be proof positive of the the utter immensity of your skills except of course then the test fail and then you go through and I have a whole talk about that genius rollercoaster that people go through but that's maybe for another day okay so I had this crazy idea and I thought yeah but how hard would it be to try like this is a clearly a stupid idea how hard would it be to try that wall can just do stack and half an hour later I was hooked the anxieties that I felt while programming they just kept getting worse as I became more more experienced those anxieties just dropped away I'd say well I'm not done until all the tests that I can imagine are all passing but I don't have to make them all pass at once I can just type one in and then make that one work and type the next one and make that work and eventually I go can I think of any other tests no I must be done and I was just completely relaxed I thought what a remarkable transformation but that came out of a process of literally trying stupid ideas that's just a habit of mine you know somebody somebody says obviously X I always think well what if not X how hard would that be to test and usually yeah I mean the consequences this is you spend a lot of your time doing stupid stuff but then every once in a while one of these takes off and it's wonderful because you have no competition because nobody else is dumb enough to try the ideas there there's my recipe for for innovation okay so that's the explore phase you trying out crazy stuff as quickly as you can and you're exploring a space literally a space of possible problems to address and possible ways to address them and you don't know where that that magic is gonna happen you're gonna find that people really do care about this so to efficiently explore the space you should have a lot of diversity now when things start going crazy and you're having this vertical growth and you're constrained by some rate limiting resource the game is completely different that's all about focus and getting everybody into one room that phase doesn't last long which is good because it's not sustainable that's the one where you pull long hours and everybody's in there and they're there you know things are happening nobody's ever understood before but here's the I remembered I was talking about certification I can come back which of those do you teach right well like which of those is engineering behavior not even done yet because once vertical growth has started to tail off and the the limits to scaling are the ultimate limits of scaling are clearer then you can start doing something that looks like adult engineering you can start making estimates before that you can't make estimates you can just react once once the t you have a hundred people on the team and you have millions of users you can start plotted plotting the graph and looking out five years and it all makes sense but that's a completely different game again that extract game where you're extracting value to feed back into the next set of explorations that extract game is a completely different game than this reactive expansion game which is completely different than this wildly creative exploration game so if you're gonna certify which set of skills do you certify now the XP days I tried to write the one set of rules that would match all three phases because I didn't even know there were three phases and and so things like estimates versus no estimates right that depends on the face if you're exploring and you've never done this before don't estimate like time box or just be have attention deficit disorder so you're experimenting with this until you're experimenting with that until you're experimenting with that's a pretty good way to to do resource allocation when you're exploring it's a stupid way to do resource allocation when you have a hundred people working on the same system that's bringing in billions of dollars so if we were going to have certifications which set of these skills would we certify can we be wise enough to certify three different sets of skills but then there are other environments that don't fit this model all like life critical systems where there's there's still risk management there's still a sequence but that all the trade-offs are completely different so that's one of my my troubles with certification yes we seem to magically make enormous value in the world and no we don't have know how that works I have trouble with the certification as a way of understanding that because well first there's a huge incentive problem the incentives of the people being certified are not aligned with these incentives of the bodies doing the certification are not aligned with the incentives of the people perching purchasing certain the services of the people who are certified all those incentives are going completely different directions and so we see the kind of situation that we have today where there's a you'll simultaneously hear widespread contempt for certifications and you'll see more and more people getting more and more certifications putting their money exactly in contradiction to the the sense that what we're doing doesn't make any like doesn't go together that the incentives of the players are are dramatically misaligned so I I applaud the intention to understand what we do and how it creates value and I think it's just way premature to try and boil that down into the book of knowledge that will fit each and every situation and that we can use to throw at people who violate the precepts of that book of knowledge i knowes talk and i wanted to call out one thing that she did that I really appreciated which is before she talked she specified what she was going to to speak about now I understand there are there are differences of opinion about this whether you should say what you're going to do before you do what are you you just do things and then see what comes out of it I do like this let's call it test first style where you say what you're going to do in advance of doing and I think there's there's some some advantages to that - perspective is one of taking the sense that we have made of the world and spreading it to other people and something else I really liked about her presentation was the humanity of it we're all people we have these brains we're all you know we're not in the environment that these brains were tuned to operate well in you know predators are not trying to to kill us on a daily basis although I did hear I did hear a story last night in the gin bar about some wolf biting somebody on the butt so perhaps there are yes Martin that's my call out to you perhaps there are cases where there are predators that we have to worry about but yeah you know that's not a daily problem here we are we have the brains we have in this environment that they're not really built for and we have to adapt to that and and the the point that I know made is that understanding the other person's perspectives the best thing that we can do if we want to share the sense that we do make about the world so that was the theme for me of the day is trying to make sense of the world and understand not just do the next thing but to take that step back and say hey what is it that we just did what are we going to what can we learn from that to inform what it is that we do next I did want to address this question of beauty because that was the thing that really grabbed me about the the title of the conference I'm a big fan of beauty and code I think that there's there's code that evokes a sense of beauty in me when I read it there's certainly code that evokes a sense of revulsion in me when I read it sometimes that's my own code so there you go but I there's a point there about engineering that that I wanted to to make sure that I highlighted first there's a contradiction built into applying the standards of beauty to code there's two directions two forms of beauty that we can talk about we could talk about the beauty of the system as it exists so you you check out as I did I checked out the latest version of looking at Gradle something like that and you can look at it as a snapshot here's this thing and there's these functions I call those functions and they're composed in a way that's easy to understand and the the complexity is parceled out and the names are chosen just so so it's easy to understand both the large scale flow and then dive into the details of you want that evokes a sense of beauty in me when I look at it but there's another sense of beauty which is the beauty of changes that moment when you say you won't believe this we had this crazy idea all I had to do to implement that crazy idea was I overrode this and I changed this one if statement there and it just works those those deltas that just magically do something those feel wonderful those evoke in me are also a sense of beauty this system is beautiful because I was not because of it in its moment right now but it's beautiful because it enabled me to realize my dreams in a very efficient way and those two experiences of beauty are directly contradictory if I if I spend all of my time making beautiful changes I'm going to end up with ugly code and if I try to maintain beautiful code and and never never back out were you know those are those that's not the layers the layers are like this we can't violate that then I'm going to lose many of my experiences of the beauty of changes and the reason I think this is important for engineers is my experience of it is that beauty is processed in a different part of my brain than than other things so my symbolic thinking happens feels to me in a part of my brain you know it was activated when I was in high school and my angry algebra teacher gave me 40 trig identities because I'd been a jackass in class and I worked started working through these trig identities and about halfway through I was you know mad and about halfway through I got it and I went oh this if I can just transform this problem into that problem and I already know how to solve that ooh give me another one oh no I don't see how to do oh I can break this into these two parts and transform this one into that does it I had this this this aesthetic sense that part of my brain that there's a symbolic part of it which is just pure symbol manipulation but there's another part of it which is this enjoyment of the beauty of code and I think that I as an engineer do my best work when both of those senses are are invoked it's hard for us and you know this is not empirically proven I would love to see much more study about this but if I want to do my best work as a programmer I want the symbolic part of my my brain working I want my sense of beauty and wonder working I want to be emotionally activated I want to care about what I'm doing because I know I'm a better engineer when I care about what I'm doing oftentimes I listen to music because the patterns that go on there I think stimulate my thinking in ways that that isn't already stimulated so you could say Beauty is this abstract concept and wouldn't it be nice if we could work on beautiful code and I I think there's a lot more to it than that and so when I got the the invitation to come talk a beauty and code well this is great the you know I'll be around a bunch of people who were also talking about beauty and code and turned out the none of the other speakers addressed Beauty directly but I think that it's a it's a topic that I have way more questions than answers to but my nose just tells me understanding what makes for that experience of beauty in either looking at a snapshot of a system or looking at the change necessary to get a system to add some behavior I think that's going to make for better engineering over time I want to close with something that's very practical I had an experience about six months ago I was getting tired of all this people e stuff that I'd been doing at Facebook and I just sat down with some ugly code and cleaned it up for about a week and a half I just and you know is so I found I found this function you know that function and is about 500 lines long and then nested ifs I love Adams indentation the indentation metric that is a beautiful metric so it would have failed what you would have had buffer overruns if you'd tried to calculate it on this function because it was just so ugly and so I just started making little tiny changes if if the value of variable was computed here and it wasn't used until down here I moved the computation if I could based on data flow I just moved the computation down next to where the variable was used that kind of thing it changed names I and I recognize another refactoring put things that seem to change together together and so I made this this series of diffs of a single file and they all seem to be very trivial and the at some point I started to get the picture oh this is what this would look like if it was beautiful I hadn't seen that when I started I just had this one function which was horrible I could zoom out and say oh if this file was beautiful here's what it would look like okay and I remember the second-to-the-last if we had code reviews of course which is a horrible idea for different reasons but again I'll kid you know yeah I just have to drop stuff like that because I'm independent now and I got I need to leave some breadcrumbs so this series of code reviews and the initial set of comments from reviewers were all thank God somebody's just cleaning some stuff up because things just seemed to get worse and worse and the second-to-the-last if somebody actually made an honest comment on the code review they said you don't seem to be changing anything I said just wait and the final diff took I we had stuff that within this file there was stuff that was similar and stuff that was different so I'm I'm pulling the stuff that's different away from the stuff that's similar so that the stuff that similar becomes identical and then the identical stuff can get unified and the last diff was taking the entry points for this file and moving them all up together and now it read like a little essay said well here's the entry points this is like the table of contents here's what you're gonna see in the rest of this file but at no time did I make any big changes oh and so the that code reviewer on the final diff his comment was oh yes I win so I wrote this up as the life-changing magic of tidying up code and I realized oh I'm actually good at this that I have a process that I I go through in order to to do this kind of tidying up and and the rules are pretty simple if if it's hard don't do it so if I'm ever like I think I can move this to here but I'm not sure then I just don't do it I'm only gonna do obvious stuff another rule is put the intermediate stages into production immediately so as soon as I move that that variable calculation down three lines I'm just gonna put that into production because I don't want weighing on me oh you know maybe that I broke something I'll find out for sure another one is only do this kind of work when you're fresh when you're rested this isn't something to do when you're tired and a little woozy this is like okay you know I have half an hour before lunch I'm feeling like doing something but not something big I'm just gonna move some variable declarations around okay so you do that another rule is that I practice if I if I can see I want to get from here to here but I don't see how to do it in small steps I'll try it this way and then throw it away and then I'll try it that way and then throw it away so a lot of the work that I do when I'm tidying up just gets turned into lessons I was gonna say throw throw it away you don't throw it away you learn the lessons and you move on and this is something that I'd encourage you all to go and and try if it seems like a big deal you're doing it wrong it's a bunch of little deals that adds up to big deals and it doesn't need to be I'm gonna go spend two months cleaning up this happens in 15 minute half-an-hour chunks with frequent to frequent feedback and lots of rest and then you can go and add features to your code in between but making a habit of just tidying up will enable you to experience that sense that beauty is something that you you have influence over you have some crappy code okay happens I mean inevitably happens but you don't have to just live with it you can pull yourself out of that you can give yourself the experience of beauty a few minutes of at a time every day if you so choose and if you do I believe that your experience of engineering will be transformed my times up thank you all very much for your time and attention today and thank you to the organizers of the conference for putting together an absolutely fantastic day you

Channel: Beauty In Code

Views: 14,868

Rating: 4.6439791 out of 5

Keywords: Beauty in Code, Living IT, Malmö Live, Kent Beck

Id: tM1iOJsR7p4

Length: 59min 26sec (3566 seconds)

Published: Tue Mar 13 2018