Uncle Bob Martin - The Craftsman's Oath at SC London Conference 2018

by the way my name is Bob Martin in case you didn't know why are we here now the long-range answer to that question is that there is a fundamental asymmetry in the weak force of nature that causes matter antimatter relationships to slightly prefer matter so that after the Big Bang when equal amounts of matter and antimatter were created and then began to recompile residue of matter leftover and that's us so that's kind of the long range version of why we are here but there's a shorter range question why are you and I here in this room today what is this craftsmanship thing interesting choice of word thing why is this craftsmanship thing something that attracts 300 people into a room what is software craftsmanship who are we if we are members of the software craftsmanship community what are the values that we hold why are we here and this is something I have pondered for a very long time what is it that draws a community of software developers together to meet in a room like this to talk about craftsmanship values how many of you are programmers damn that's like unanimous man everybody here is a programmer learning managers in the room out what not bad ok so we are here because we share a set of values and that set of values includes the desire to be proud of what we do we're programmers we write code for a living and for many many years there was very little pride in this a week we could build products and and I'm sure that some of you have been proud of the products that you have participated in but that's not really the question the question is are you proud of the way that you built those products did you go home everyday and look in the mirror and say today I did a really good job even if what you did was to delete everything you worked on that day at the end of the day you just threw it all away and you went home and said you know I did a good job today because I got rid of a bunch of really bad options how how do we become proud of the way we work not of the products we produce it's important to be proud of the products we produce but it's also important to be proud of the way we work people call this workmanship or craftsmanship we are craftsmen or we're members of the craftsmanship community we are craftspeople because we value the goal of being proud of the way we work who else do we want to be proud of the way we work well we want everyone to be proud of the way we work we want people to be able to observe the way we work and be struck by the discipline and orderliness and the care and the craftsmanship in the way we work and why do we want other people to share that pride with us we want other people to share that pride with us because it engenders trust your managers your employers the people you work for your customers if they are proud of the way you work then they trust you and if you are struggling because the problem is difficult or because the deadline was unreasonable they trust you they see the way you work they they see the effort they see the discipline they see how you value your own self-respect and they trust a very long time ago nearly twenty years ago Kent Beck said something that that struck me and it stayed with me all this time and it had occurred at the Snowbird meeting where we did the agile manifesto and he said the reason that he did extreme programming which was kind of the core of agile the reason he did extreme programming the reason he promoted it was to heel the divide between business and technology heal the divide between programmers and business and that's what we want that's why we want to be proud of the way we work we want that divide not to exist we want to be partners with our employers and we want our employers to consider us as partners and we want to consider them as partners we want to have a shared goal and a vision we want to be trustworthy how do you get to be trustworthy well you need to have some disciplines and what is craftsmanship craftsmanship is a bunch of disciplines it's a bunch of promises that you make to yourself a little bit later I will I will walk through a set of such promises that I think might be representative and I'll leave it to you these promises are promises that I make to myself and then secondly I make them to the community that I am a part of their promises about the way I behave what are those promises based on what basic disciplines do they come from I love technology let's see now what do you think the computer is doing right now I think it needs to be rebooted what was he doing what was that projector doing right that the signals were going in so what was it doing oh they had to hunt right because there's a whole bunch of possible signals that it could be receiving so it's got a hump through them all and I can't just go that's what this one this one now it's got a wait for each one to see if that one is the right one that's not the right one okay we got to try this one tried this one over here meanwhile you're sitting there going oh maybe I oughta unplug it again there's this state machine misalignment between the mistake machine and the projector and the state machine in your head and unless you know how that state machine works you're gonna screw it up over here so okay I'm a geek you know what you're looking at here are the practices of extreme programming and I bring them up very deliberately because for the last twenty years this has been the most well defined set of craftsmanship disciplines software behavior disciplines that have been enunciated there been some others but as a collective group as a whole this is one of the most cogent and intelligent set of disciplines that has been presented and it formed the core of the agile movement and it formed the core of the craftsmanship movement because make no mistake about it the craftsmanship movement is the direct descendant of the agile movement how many of you work on an agile project you see what I mean you cannot be in the craftsmanship movement without also being in the agile movement and although there are issues there and I'm not going to belabor those issues today it's important for us to realize that we are part of this larger community and you and I as part of the craftsmanship community are straining to guide the agile community as a whole in a good direction the disciplines you see on the screen here are the core of disciplines that a software craftsman might apply most of them I think would apply look at the inner red circle there how many of you practice test-driven development look at that now that's probably half of you if I counted that properly the years 2018 why isn't it all of you what's gone wrong why is this why is that still controversial it shouldn't be why is that still controversial I don't know the answer to that question it's a puzzle for me now I've been very encouraged that test-driven development has been advancing and more and more people adopt it I've also been somewhat discouraged by the fact that articles get published from time to time saying ridiculous things like TDD is dead there I won't ever do TDD again or TDD sucks or whatever but I wonder now in 2018 why this isn't the default way that programmers behave it's certainly the default way that accountants behave anyone who wants to make sure that they're not making critical errors in complex documents behaves this way why is it that half of us still don't and by the way this is a self-selected crowd you go out into the real software community you'll find it's about 10 percent maybe 10 percent what's the issue is it really that difficult to believe that we ought to test our code is it really that controversial to say that we should write a set of tests that prove our code is not faulty difficult for me to say prove correct because you can't prove correct but you can create a set of tests that prove the absence of fault sort've so I want to walk you through a set of promises this is a set of promises that I wrote Oh several years ago I called it the programmers oath I've called it the scribes oath I've called it a whole bunch of things they're all just a bunch of promises that that have been collected over the years promises that a software craftsman can make to themselves and to the community that they're part of and the first of course is I will not produce harmful code promise number one I will not produce harmful code but in order to make that promise we have to understand what harmful means and harmful can have a lot of definitions first of all it could be harmful to the society how many computers are in this room right now you think hundreds how many would say thousands are there thousands of computers in this room right now would anybody say tens of thousands could there be tens of thousands of computers in this room right now how many computers do I have on my body somewhere on my body how many processors are currently executing instructions written by a programmer sitting on my body let me roll up my sleeves cuz that's not one of them okay there's this the watch right and by the way just about everybody's watch whether it's an Apple watch or not has some kind of a processor in it nowadays unless you're a retro guy and you still like winding Springs but okay how many computers do you think are in this is it just one or is there a graphics processor and a Bluetooth processor at a main processor and it'll be an awful lot of processor sitting here of course I've got my iPhone how many processors are in this iPhone so I don't mean here a graphics processor bluetooth processor cellular process or GPS processor whole bunch of processors low loads of little tiny computers in here executing code written by programmers see what else I got we got air pods hmm and each one of these little earpieces has a processor in it at least one maybe two might be a Bluetooth processor and an audio processor I'm not quite sure so there's at least two and then of course the case has a processor in it and it weird our cases have processors by the way that's true of my Apple my iPhone too because my iPhone sits in this case here which is a battery charging case but there's a processor in here that knows how to keep the battery charged and a trickle charge the iPhone and so on and they wired me up here it's got to be a processor in this thing probably several of them anything else on my body it might be executing code not my brain now count the computers on your body how many computers are in this room how many computers were there in 1946 one how many computers are in the world today it must be many billions I hesitate to do a Sagan ISM billions and billions but I think it must be many billions maybe many tens of billions possibly hundreds of billions of computers in the world today all executing code written by programmers like you and I and what do these what do these computers do everything name an activity avoid certain biological activities but name an activity that can be done in our society that does not evolve a computer nowadays of course you cannot buy anything without using a computer at least the cash register but probably much more nowadays of course we go into Amazon so there's a lot of computers involved you can't sell anything no law can be enforced no law can be passed no law can be adjudicated insurance policies can't be made or or settled you can't make a telephone call without using a computer you can't watch the TV without using a computer you can't wash your clothes without using a computer or the dishes you can't turn on the air-conditioning or the heat in your home you can't do anything without a computer you think about how often human beings in Western society interact with a software system and think of your grandmother if you have one still how often does she interact with a software system and the answer to that is on a minute-by-minute basis because there is nothing you can do in our society without interacting with a software system software has become the blood of society the circulation system of society nothing happens without software you can't drive a car without software the traffic lights don't work without software airplanes don't fly without software trains don't run without software nothing happens without software it didn't used to be that way but over the last 30 years software has infiltrated everything and that infiltration continues to this day so afterwards wiggling its way into the most minut parts of our lives and most human beings do not realize it even we programmers don't really realize it is there a need for craftsmanship think of the depth of our influence think of how many lives you and I impact with the code that we write it's virtually everyone and lives have begun to depend upon what we do how many people have died because programmers were careless the code inside cars how many cars have fatally crashed because the code inside cars did something stupid like blew the stack I used the word blow the stack in reference to a fatal accident many of you have probably blown the stack from one time or another it's because most of us do but imagine that that kills people how many fortunes have been lost because a programmer forgot to boot up one particular server how many terrible situations have occurred because a programmer was careless and how long will it be until some programmer somewhere does some stupid thing and kills 10,000 people and you know that's going to happen it's bound to happen there's just too much software running around everywhere so some poor guy who knows who he is gonna forget a comma somewhere 10,000 people will die and of course the politicians of the world will do what they must they will rise up in righteous indignation and say well something's got to be done about these software people and you might hope that they'll get the managers of the software team up on stage and says you managers screwed up but we saw what happened when the CEO of Volkswagen North America was called before the Senate of the United States and asked how could this have happened how could you have written let this code get written that cheated the environmental machines and the CEO of Volkswagen North America stated and I quote well it was just a couple of software developers who did it for whatever reason the finger will not go to the managers oh it might but it'll get deflected right towards us and it should because it's our fingers on the keyboard you see it was a couple of software developers at Volkswagen who wrote that lying cheating code and whether they were told to or not is irrelevant whether it was part of their job to do it is irrelevant if you write lying cheating code because your boss told you to it's still your fault and you should go to jail as the developers at Volkswagen have done I will not produce harmful code it's a big call that's a big big promise what kind of harm well that's the one kind of harm let's not kill anybody let's not make anybody sick let's not lose fortunes but let's let's narrow the scope a little bit we're working on systems we're working on products our code should not harm the business that is paying us to build this software so we want to make sure that the code executes properly behaves properly does the right things but there's another kind of harm because software is a compound word and the first word in that compound word is soft which means changeable the reason software exists is because we needed a way to easily change the behavior of our machines we had machines already we just needed to be able to change their behavior easily and it's very hard to change the behavior of a machine with a soldering iron or a bunch of gears but if you have software you can very easily change the behavior of the machine that's why software exists and therefore if you do anything to the software that makes it hard to change you have thwarted the reason software exists you have harmed the company you work for you have harmed the system you are working on so this heartless idea of harm goes very far it covers a lot of ground you will not harm the people that that your system that use your system you will not harm the employers who have paid you to produce that system you will not harm the customers who bought the system from your employers you will not harm your employer by putting bugs in the code or leaving bugs in the code you will not harm your system by making it inflexible and in you maintainable and maintainable you will not make a mess and you might complain and say yes but we have deadlines well yeah everybody's got deadlines that doesn't alleviate the need for you not to harm is anybody released code that they knew was harmful to in some extent it wasn't the best code they could have produced they knew maybe it didn't have all the right behaviors maybe it had some minor bugs anybody released that and think well it's okay because I had to meet the deadline well maybe it was okay because you had to meet the deadline but did you tell anybody does they did everybody know listen we can release this but here's what's going on inside this code or did you kind of cross your fingers and say well Jesus I hope nobody discovers that promise number two this is a hard one the code I produce will always be my best work it's a real hard one because you will be tempted to not do your best work other things are going to get in the way and say I can't do my best work I've got to be less than my best work because there's some other constraint I need to meet like a deadline or something like that I will not knowingly allow code that is defective either in behavior or structure to accumulate I worded it this way because you are going to produce code that is that is defective in behavior and structure from time to time because we are imperfect creatures we write code we think it's pretty good later on we look at it and go my god that sucks I don't believe I wrote that and once you make that realization then you must not allow it to accumulate you must go back and fix it or refactor it by the way as I am reading these promises I want you to keep that circle of extreme programming practices in your mind and notice that every one of these promises is just a restatement of one of the practices if I'm going to be producing the best work I can all the time and that's not the best work it's just the best work that I can if I'm going to be doing that then I'm gonna have to be going over the code re all the time looking at it refactoring it improving it tweaking it adding new tests adding new structures trying to make it better all the time I am going to craft the code I am going to apply disciplines to the way I work I'm not going to write the code who's done this right you're writing the code and you can't get it to work try this try that it doesn't work doesn't work clock is ticking try this try that oh god it works all right don't touch it yeah you don't do that no see see programs are hard enough to get to work we will not write clean code no one writes clean code when we write code to make it work that code is always awful because it's hard enough to write code that actually behaves but once you've gotten it to where it behaves once you've gotten it to the point where it actually works then you step back and say okay but it sucks now how can I make it better how can I restructure it how many of you have written code in a stream of consciousness right so your start out with the function C all right and I got to get the account alright I'll get the account oh god I need a string buffer okay get a string buffer okay now yet get the account number oh god it might be no it's no okay it's not no yeah okay I need to I need to gain access to the amount account out amount have to deposit something in there and I gotta get the deposit that could be known if No this way you think rights the way we all think when we're writing code we're we're solving the problem and this thread of consciousness goes weaving in and out through levels of detail all the way from the highest level concepts in the system down to nulls and and if statements and dots and stupid stuff details way the hell down and we're sig zagging our way through trying to get it to work and then we get it to work then I go now comes the hard part that was the easy part the hard part is to say okay now can I rearrange this code so that it will make sense to someone else so that I don't force someone else to go through that horrible zig zaggy process in and out of app in and out of abstraction levels can I make this code express itself can I make it explanatory so that someone else can look at it and go oh yeah that's exactly what it does Ward Cunningham once said clean code you know you're dealing with clean code when each routine you read is pretty much what you expected when's the last time you read code and it was pretty much what you expected and by that I mean you're reading and going yeah yes yes yes most of the time we read code and go home you don't allow that to accumulate you may write it when you clean it three I will produce with each release a quick sure repeatable proof that every element of the code works as it should a quick sure repeatable proof that every element of the code works as it should now if you're someone in the outside world like your grandmother well that would just go without saying though the people who write programs they prove that they work don't they well of course they do because I mean I get in my car and I Drive it and there's software in my car of course they prove that it works I fly in an airplane and of course the people who write they prove that it wasn't I go to the store and I give them money in the cash register the people who develop the code and they they proved that it worked right of course our users expect that we have done this not only that we have done it but that we can prove it over and over again at a moment's notice someone should be able to come to us and say prove that works think of what we make we make these documents they're huge massive documents full of arcane symbols that no one can understand but us and all everybody else who uses them goes can you prove that works if they if they could see the code if they could see the complexity of it they could see the intricate nature of all the symbols that we try to manipulate on this source code they would react in horror I didn't know it was like that how do you know that works well that's one hell of a good question and the answer to that of course is that we write tests we do exactly what accountants do because the countless have the same problem they manipulate really big documents full of arcane symbols that no one understands except them and terrible things happen if they're wrong and so they enter every transaction into the books twice just like we do of course when we're doing test-driven development we enter everything twice because test-driven development is just our answer to the accountants discipline of double-entry bookkeeping accountants produce a quick sure and repeatable proof that the accounts they are accounting for are balanced that's part of the normal business practice every executive gets a balance sheet on that balance sheet there is a zero and that zero means zero tests failed every transaction balanced don't you think your CEO should get a balance sheet from the programmers zero tests failed four I will make frequent small releases so that I do not impede the progress of others it is tempting insult in the software world to take out a branch and then work on that branch for months and then try to integrate that branch back into the main line months later and chaos ensues thereafter and everybody gets stuck and oh my god the integration is terrible I want frequent small releases I want you to be checking in code daily hourly I want integration to be continuous I don't want you holding out a whole bunch of code and then at the last minute dumping it on us and say my code is great now go integrate it well I get beer but frequent small releases is more than just code frequent small releases is everything I want frequent small releases of the requirements I don't want a great big requirements document I don't want the programmers to sit there and go we cannot begin until there is a complete requirements document that specifies everything you know we used to do that right it was programmers who made those demands and we think about the waterfall process and how awful the waterfall process was but you must understand that it was the programmers who were demanding the massive requirements document was the programmers who were saying now we can't even start till we know everything is done because then we've got to derive the architecture in the design we've got to do all this stuff that's a bad attitude so I want frequent small releases regardless of how high or low in the hierarchy we go I want frequent small releases of everything because that is the only way to get feedback one of the extreme programming values feedback what are the four values from extreme programming anybody remember urghhh communication simplicity and feedback and I like to replace communication with honesty and there's respect that would be nice although that's part of honesty five I will fearlessly and relentlessly improve our work at every opportunity I will never allow it to degrade perhaps the most important part of that one is the last sentence I'll never allow it to degrade have you ever seen software degrade have you ever seen the structure of a software system rot like a piece of bad meat getting worse and worse and worse with time how can that happen software is not a biological substance that bacteria can invade how is it that software systems rot with time becoming evermore tangled and ever more corrupt how does that happen well obviously it's weird what we it's us who's doing it you know our fingers are on the keyboard we are the bacteria that rot the code but why why do we rot the code no nobody wants to rot the code why do we rot the code and I'll tell you why it's really easy how many of you brought code up on a screen and you look at it and say ah it's rotten it's awful I should clean it and your next thought is I'm not touching it because you know if you touch it you will break it and if you break it it becomes doors so you walk away not me I'm not gonna be the one to touch that code if somebody else can clean that code if this is the way you react in fear then the only thing that can happen to that code is that it will rot no one will ever do anything to make it better the only thing that will happen to it is that people will go into that code when they absolutely must and do the absolute least to fix a bug or add the feature and get out as soon as they can because they're terrified and I want you to think about how how wildly irresponsible it is to be afraid of the thing you created to have allowed it so far out of your control that you don't know what it's going to do when you change a line of code does anybody had that fear yeah god I don't know what's gonna happen if I change that line it could be anything hi who's had the experience of changing an obvious simple line of code just it clears day and and emptied exactly what you thought it was going to do fixed whatever problem or added new whatever feature but something over there broke some completely unrelated part of the system Brooke why because of some strange weird dependency that had crept through the code and that weird dependency was the was the outcome of a bunch of rot how do you prevent that how do you stop the rot well you've got to get rid of the fear you can't stop the rot if you're afraid so you've got to get rid of the fear how do you get rid of the fear well imagine that you've had a suite of tests a suite of tests that you trust with your life literally you know you trust this suite of tests with your job and then you look at the code on the screen and you say well man it's messy somebody should clean it I think I'll clean it and you change the name of the variable and you run the tests huh it didn't break anything okay break that function in half now it's two functions run the tests good didn't break anything take that function and move it into that class over there run the tests who broke see what they did I meant to move it over here run the tests if you had those tests cleaning would be easy natural you would want to do it it would make your life easier if you had those tests why don't you have them okay everybody can see how I'm on a legacy system and nobody wrote tests fine but are you making the problem better or worse today six I will do all that I can to keep the productivity of myself and others as high as possible and I will believe do nothing that decreases that productivity there's a lot of ways that you could spin this one one good way to decrease productivity is to omit one test just not right one yeah why would you not write a test by the way who writes who writes tests after the fact you write two code first and then you write the tests and you thought that was test-driven development never mind how much fun is that to write the tests after the fact it's not a lot of fun because you already know the code works you've tested it manually why would you write these tests after the fact after you've tested the whole thing manually well some process we need told you you had to so they guilt you into writing a bunch of tests you're right this test and and your attitude isn't it I can't I write that test it passes I knew it would write that you inevitably come across the function that's hard to test it's hard to test because it's coupled into the system in bizarre ways and you did not write the test for and therefore you did not design the system to be testable and therefore you come across the function that's hard to test and you look at it and go man I'm gonna have to restructure this and restructure that to make it work and I know it works I tested it manually and I've got other things to do and yeah whatever and you walk away and you leave it a hole in the test suite and you know if you're doing it everybody else is doing it how can you trust that test suite if you know there's holes in it if you're putting the holes in and other people are putting the holes in how can you trust that test suite how many of you have a test suite and you execute it and it passes and your reaction is yeah it passed well that's a worthless test suite that's a worthless test with it it's sometimes worthwhile because it can catch a malfunction it'll fail if there's a horrible malfunction but when it doesn't fail when it passes it provides you no information no decision you can make on passing and the test suite you want is the test suite that allows you to make a decision when it passes and the decision is ship this thing is shippable I can ship this because at least test pass that's the decision you want or the decision is I haven't broken it I can try can refactor I can clean it I haven't broken it that's the decision you want to be able to make with a test suite a test suite that doesn't allow you to make that decision is almost entirely worthless compared to the effort of creating it that's one way to decrease productivity just leave holes in the test suite another way to decrease productivity is to not clean the code to just continue to add massive amounts of code without refactoring that will decrease productivity of course another way to decrease productivity is to just be an in your team don't do that seven I will continually ensure that others can cover for me and that I can cover for them how does a team behave you got a bunch of guys there kicking the ball down the field right the attacking the opponents are trying to block them but they've got a whole rhythm down they're passing it back and forth they're moving it down the field everything's going great and then all of a sudden one of the players goes down trips Falls it's not injured fine he's waving saying no problem what are the other players do on his team or her team they changed their field positions they cover the hole they keep the ball going down the field that's how a team behaves when a team member goes down the team covers and keeps the ball moving down the field are you a team do you behave like a team if you are a team you must be able to cover for each other when Bill goes down because he's gotten sick or he's got a fight with his wife or god knows what does the team still make progress is Bill the only guy who knows the database hello God Bill's not here we can't make progress today anybody got one of those oh the gooey guys not here man can't do a thing that's stupid why would you allow something like that why would you allow those silos to block you you need to be able to cover for the guy who goes down so how do you cover for the guy who goes down well you better work with them how do I make sure that you can cover for me well I got to get you to sit down next to me and we need to write code together in the environment that you're going to try and cover if I go down we talk about the the practice of pair programming and a lot of people get you know all got controversial about peripera program this repair crap the reason we pair is that we know how to cover for each other if something bad happens that is the fundamental reason behind pair programming so that we can actually be a team and cover for each other eight I will produce estimates that are honest both in magnitude and precision and I will not make promises without certainty who's good at estimating that's the right answer good all right nobody's good at estimating quite right so we have to be able to estimate and a lot of people have said you know this a gist of is all about not estimating no that's that's wrong we do have to estimate and the estimates we create for our employers have to be honest and as accurate as possible in both magnitude and precision as possible is the key there so what is the most honest estimate you can make three little words I don't know how long is it gonna take you to do this I don't know now that's honest it's not particularly useful and there are some things that you do know so I want you to add to that I don't know with some other information for example well look if everything goes like perfect I can get this done in a week if everything goes the way it usually goes well it's gonna take three weeks and then you know if things really just go to hell well anybody take me ten weeks that's honest and it is honest in a very interesting way because it describes the shape of your uncertainty it's another way of saying I don't know but it provides a shape to I don't know and it's a shape that managers can use they can take go back from that and say oh okay first of all how the heck do I make sure that everything goes well because I'd really like that one week outcome - I got to prepare for the 10 week outcome cuz things sometimes do go to hell that's the most honest thing you can say to a manager if everything goes great this if everything goes to hell that and usually this now managers aren't gonna like that because managers don't want to manage management is the dealing with uncertainty that's what management is dealing with uncertainty making sure the probabilities line up making sure commitments are specified properly management is all about dealing with the uncertainties of business and you are providing this uncertainty our managers don't want any more uncertainty than they need because it's hard to manage uncertainty so they will try to push that back on you and say well you've got to do better than that come on you can do better than that I mean just assume everything is gonna go normally right so then it'll be three weeks right sometimes well you know I got sick last week don't play the funny game and the funny game is this yeah okay I think it'll be all right I'll get it done in three weeks don't worry about it that's that's lying you are now lying you have removed the uncertainty and the uncertainty is absolutely necessary for the manager to do their job and you have now made it impossible for the manager to do their job by lying to them now you will find that this is a difficult negotiation because managers are still gonna push back just come on you can do better than this work harder give me a better number and you may come back and say look there's no better number I can give you look it's it's one three and ten that's the best I can do and then though in frustration the manager will say well will you at least try and the answer to that is how dare you suggest that I am NOT trying you know don't you but that should be what's in your thoughts how dare you suggest that I am not trying I'm a craftsman I have disciplines I'm a professional of course I'm trying how can you even suggest that I am NOT trying now you want to be a little more gentle than that but but I mean the simple way to say that is no I I can't try anymore I'm trying as hard as I can now one three and ten that is what trying looks like it's very easy to say oh yeah I'll try don't worry and that's just another lie and the problem that we have as software developers is that we tend to lie an awful lot when it comes to estimates because we want we don't want the confrontation you know you and I programmers we didn't get into this business because we like people so negotiating with people in a confrontational environment is just not a lot of fun right we'd rather go back to the code cuz you don't have to argue with the code you just have to struggle with it 9 and the final one I will never stop learning and improving my craft the software craftsmanship movement got its first impetus I think it was 99 or 98 Pete McBrine wrote a book called software craftsmanship anybody remember that book and what he described in that book is very different from what you and I are now talking about except for one thing Pete McQueen's book was about apprenticeship it was about the model that was used in the Middle Ages about how you take junior people and advance them to become senior people and you do that by hands-on mentoring you have apprentices and they become journeyman and the journeyman then become masters that was his model and it's an old model we in our society have decided that that's not what we want to do right I mean our society you you go to college and when you come out of college you're an expert how many of you learn to program at home and then went to college and got a degree but didn't learn much yes okay the universities are not actually equipped to train software developers to be software developers they can teach you how to write a little bit of code here and there they also teach a lot of very bad habits like you know get the project on it the last ten minutes before that you know that kind of things every college student does and then emulates and in cutting in the work how many of you came out of university got a job and thought this isn't anything like college so the universities are not prepared to train and then the reason for that by the way is the professors have never worked professionally in software right most of them some have but most of them have not so they really don't know how to train you what we'd like to do is continuously mentor each other continuously train each other and and teach each other and you never stop learning because there's a lot to learn and nobody can learn it all never stop improving the craft and you know the best way to learn does anybody know the secret the best way to learn anything teach it that's the best way to learn anything because all of a sudden you're on the hook to know it and convey that information you know the best teachers stay one day ahead of their students in the book just one day ahead all you got to do the best way to learn is to teach and with that I think I'm done thank you all for your attention [Applause]

Channel: Codurance

Views: 41,346

Keywords: Uncle Bob Martin - The Craftsman's Oath at SC London Conference 2018, Robert C. Martin, Uncle Bob Martin, The Agile Manifesto, Software Craftsmanship, Software Developer, Programmer, Software Craftsmanship London 2018, SC London 2018, The Craftman's Oath, technology conference london

Id: 17vTLSkXTOo

Length: 54min 10sec (3250 seconds)

Published: Wed Oct 10 2018