HOW TO PROGRAM

the title of this presentation is how to program and it's a rumination on a word workflow two part word work being what programs are their structure and behavior flow being how we program our thoughts and actions and when I look back on my experience learning as a computer science student he taught me things like data structures and P versus NP and big-oh analysis and cryptography and not very much about how to think or how to work and boot schools nowadays are you know actually analogous even though they're more market practical skills like web standards and system tooling and languages and frameworks not so much how to think through problems and solve stuff and really write code and you might think that's the job of thought leaders because the word thought is right there but really thought leaders when they're talking about design patterns or solid principles even when they talk about agile and test-driven development those are nice because they describe work activities but it's pretty discreet and mostly about how people in Iraq not so much how to think through things so it's reasonable to ask you know when do we actually learn flow as programmers who teaches us how to think and if you're lucky you know ten years into your career you'll stumble upon or somebody will show you you know the only productivity tip that any of us have ever been taught where you work for 20 minutes and even take a three minute break it's really awesome but honestly it kind of feels like you put ten years a hard service in to to get a you know four dollar plastic pin it's kind of insulting that that's the best that we have to offer so sure somehow we all learn what programs are but I hazard a guess that most of us nobody ever really taught us how to program look no further than a Google search how to program and you get a whole bunch of terrible results starting with the traditional way of teaching people how to program you start with nothing and then some of you shows you a completely finished example the finished product what the program should be and then as for connecting it it's a good luck have fun and every single computer science assignment that I had in college you know really resembled the how to draw a little comic where you start with two circles and they don't draw the rest of the owl and I spend entire weekends cooped up in a lab trying to figure out you know we're staring at a blank end there no idea how to write code and it was that moment but I realized that programming is almost a philosophical activity that happens mostly in our heads of course we've now innovated quite a lot in programmer education since I was in college now now we instead of just one big finished example we've broken it up into two or three steps over the course of a book or a screencast but very rarely does the prose or the explanation actually explain the thinking of how to make that thing more real it's might take years before you're able to imitate you know even an example application from a book but that were an invitation stands out because I think that most of us are just imitating other programmers we see somebody successful or well-known and we just try to do things like they seem to be doing things and that's how we kind of learn and get by you can see that this is endemic in our society as programmers because we're really bad at how questions if I ask how do I know when to create a new method when should I break this thing up into more than one thing you know you get really unsophisticated responses like methods should be about three lines long [Laughter] and when my wife she likes telling her story when she was in first grade Becky she was told by a teacher that sentences were two lines long and so then dutifully for the next several years until she was corrected he just stamped a period at the end of every other and that's funny because she's not an adult and yet here we are with these unsophisticated ideas like and I think she'd be about three lines long and no ability to communicate above and beyond that but let's say in spite of all of this somehow you write a really good program one day and you're really proud of it and really happy and I ask you okay so what actions were productive or unproductive that led you to that point or what thoughts led you there which which thought processes were successful or unsuccessful would you be able to answer those questions or not most of us wouldn't be able to and it leads to rampant insecurity from how we educate programmers to the work that we do to the colleagues that we keep in the overall industry now 99% of the work that I've done as a professional programmer could be boiled down as a businessperson trying to get a spreadsheet onto the Internet and yet it's taken me ten years or so to even become a merely competent programmer and that's clearly something's wrong and how we teach people to program and this industry is 60 or 70 years old but we're still searching for silver bullets we always are externalizing the problem and hoping the next language or framework or library or process is going to suddenly make programming explicable and it never works out and think about that situation you know where everyone's either making stuff up as they go or pretending they understand it who's gonna succeed in that environment it's genuinely brilliant people and people with the overconfidence of having been told that they're brilliant their whole lives so imagine that you don't look like other programmers and you walk into a room and you lack that privilege of having been told that you're brilliant by society this is a terrifying line of work to walk into because no one can actually explain how to program and I think that if you want to make programming a more diverse and inclusive industry we really need to solve this [Applause] and it's obvious that the industry has no idea how software works because they're constantly analogizing it to literally any other industry like construction or like design or manufacturing and because of that they control the handful of things that they do understand like estimates and when people work and where they work instead of like the true none of it which is like how we think as software developers and how we solve problems so how do we fix it well fortunately yesterday at the keynote DHH offered us one solution but I'm gonna talk about a different one I'm gonna talk about feedback loops because programmers through compilation and through testing we're used to establishing feedback loops to make forward progress and we can do the same things inside of our heads improving as developers we're gonna practice this today by reflecting on the actions we take and whether you're successful or not and how to improve our actions you can do the same thing for feelings and actually reflect on your emotional state so you can reinforce positive emotions or mitigate negative ones and spoiler alert you can actually think about thinking and produce better thought processes that turn out to be more productive this is really the path to program or enlightenment but I realize that we're starting from scratch here we got a walk before we can run and ask yourself what do we do with teams that are so kind of emotionally immature they struggle to even talk about feelings well we handle crappy personality tests like the myers-briggs Type Indicator if you're not familiar with the myers-briggs just know that it's the worst type system the reason we rag on it is because it puts people into these silly buckets like ENTJ and isfp and the implication is that there's only 16 types of people out there but we know that that's there's much much more but when you're starting from 0 16 starts sounding pretty good so that's why today I'm pleased to announce the Searls Briggs Type Indicator and instead of pontificating to you today about how to program and dictating that this is the magical way this is the Silver Bullet instead I'm just gonna humbly take my own test show you how I feel and my inclinations in my personality and what I've done over the course of my career to reflect and improve and result in better outcomes as a programmer to do that we need an example feature so let's make one up like I mentioned I work at a company test double and we have always been a distributed company but we're still learning that that does not mean evenly distributed so if you've got a flat organization you might think that there's all these spontaneous relationships that form but of course that's not accurate we all have our assigned pairs and we all have flown home to an account manager our org chart looks like one of those 1980s suction COBOL things but there's nothing wrong with that per se unless like two people on the team both really want to learn Elm but there's nothing systemically that's gonna get those two people talking together necessarily so somebody raised the idea why don't we have virtual coffee dates on the team and just randomly assign people to talk to people who talk to each other that otherwise wouldn't be it's actually an expression for math though it's called a handshake problem which which just calculates the number of potential relationships of any group of people and you see that there's just tons of them and so what the system should do is just send an email every week to pair up people who might not otherwise be talking to one another and tell them go spend 15 minutes on this Google hangout URL and chat about something doesn't have to be about work and so we're gonna put my test to the test and build this future together this morning as a group and the first bucket that I'm gonna put us in is sensitive versus fearless and the first question is I prefer hearing all requirements upfront even if I can't tackle them all right away I strongly disagree with that I get overwhelmed relieved to adding to a long function feels like more code just won't fit absolutely I once I had a certain amount of complexity I can't imagine adding another case three I look forward to being assigned to new projects and teams no way new projects give me night sweats for I often feel paralyzed while staring at a blank editor screen yeah I already admitted to that does that make me sensitive or fearless pretty obvious in this case I'm sensitive a big part of being sensitive is that I get overwhelmed easily so think about this feature and all I've got to do you know create pairs great that's not so hard but I do have to go and send the email and I also have to look up all these people from a database but I got to be careful not to repeat so I got to randomize the pairings and I gotta not repeat week to week either which means I also have to persist them there's a lot of work so I I don't want to think about all that I just want to focus on the core problem so my inclination is like just do that put a unit around it think hard about the problem I can do my little test-driven development thing I'm feeling really good about that unit of code so then I go to the controller that's gonna call it and I realize that the method signature doesn't quite line up or somebody else might say hey this this unit you just made is doing all this extra redundant work that's actually handled elsewhere my inclination was to overcome that paralysis that I felt and find some productivity by just putting on blinders and I fell into that rabbit hole often enough that I had to think and reflect and actually I've inverted how I work as a programmer so what I just showed you is often called bottom-up programming but now I practice top-down it looks better for me you might also call it outside in where I think from the perspective of the controller at the top level entry point and I start there and I asked what do I need why me something to create these pairs and when your brain is focused that way the caller knows exactly what inputs are available what output it's gonna want is also a way that like minimize like waste because it has the broader context in terms of you know life what guard clauses need to be inserted or can be omitted the other aspect of being sensitive is that I'm really afraid of failure and when you work outside in you do have to juggle all these different concerns at once which can again be overwhelming and so what I try to do is just rush into solving it like my inclination is just today open up an editor and prove that I can write this code so I start with a module and I make a method I go and load up a bunch of users I loop over them I skip anyone who's already had their hand shaken otherwise I'll go and add a tuple of like a you know represent the pairing and they'll go and slam it through some mailer and now I feel really good because I just proved I could do it and someone will remind me you remember got to randomize it and you don't want to leave out the 15th person every week and you've also got to prevent repeats from happening week to week and now I'm terrified because I can this is already really dense I don't know how I'm gonna make it more complicated and I am very familiar with this corner of the room as a result so I keep paying myself into this corner and the root causes fear I'm way to failing I'm afraid of big things that I don't know how to break down so my solution is avoid that fear by breaking things down in a systematized way give myself some help and I've been practicing over the last few years iterating on an approach to test-driven development that I call a discovery testing and it's really an upper in breaking big scary problems into smaller more manageable ones it works with I start with just a test of that top level thing so I write a single test case I invoke the thing and then I ask myself a crucial question what's the code that I wish I had that I could defer and hand this work out to well something to find these hands something returning Satan's hand something to mail them and then persist them then I use my testable library which in Ruby is gimme so it treats these four fake things and I set up a stubbing so I say hey when finds hands is called it gets you have this thing to symbolize the hands and if I pass that to the thing that you tell me is the shakes another stubbing will give me B as Pam shakes this is all the tests said if I need to be able to actually assert that I mail out all those handshakes and then I persist them now this is an unusual-looking test to a lot of you I'm sure but what it does is it perfectly specifies the behavior of that top level unit and so I get this test to pass and I never have to worry about that top level again in fact if you list out all the files that shake out from just getting that Tusker pass now I have a pretty clear you know work cut out for me I know exactly what I mean do I can start making forward progress so I start off with a big scary thing but as I build that test I identify the units that I would need to actually carve out the work and instead of one big scary thing I now have four more digestible problems then I can focus on and if any of them are scary I know have in my back pocket a tool that I can use to like reduce and break things up even further the second bucket I'm going to talk about is inventive versus aesthetic so there's some quiz questions to determine my my type question one it's more important to build the right thing than to build the thing right yeah these are both important but I'm more implementation focused question two I love experimenting with new tools frameworks and build systems not at all like I do spend a lot of my time in open-source here but it's expressly so I don't have to worry about it at work question three I strive to write visually appealing code down to syntax and symmetry absolutely I don't know why but I really like pretty symmetrical code question four it's boring when all the code in a project is structured similarly I disagree i really like consistency in code so you gotta make me inventive or aesthetic well I think it makes me a little aesthetic and one part of being ascetic as I have refined tastes now the problem with taste is that nobody knows what it is until somebody on your team says you know what I'd prefer a 300 line function to all these well named little small units that you keep creating and then my face looks like this that's taste there's a wide members develop taste well it's obvious when you're staring at a blank on your screen there are infinitely many ways to solve any given problem we need something to constrain ourselves some some patterns to follow to just not be stuck in analysis paralysis forever and that's why I think that prose is a much better analogy to writing software than construction is in fact I think of programming is just communication to the next developer who's gonna pick it up and it's just hard because it has to happen through this filter that's just formal enough for an interpreter or a compiler to understand and so what I hear this feedback I reflect and I take it to meet it as I think that maybe I'm writing code that's meant to be read by myself as opposed to another human because the other developer they're not in the room so I tend to write code that I think that I would want to read and this leads to self centered design so if I just wrote a book on design patterns I'm gonna create a bunch of units like services and factories and repositories and I'm gonna feel really brilliant having done all this but then somebody else can list out all of the files I just created a one big listing from their perspective it's gonna be impenetrably complex it's a forest of all these objects no idea how things are gonna work and so now when I hear that critique they've got a pretty good point and I found this happen on team after team and what I realize is I got to start working differently to make my code more discoverable and approachable for other developers and now I do things much differently it started with realizing programs are directed graphs so all of these units are really kind of nodes in this graph and all of the edges or vertices are function calls so then locator calls the service which calls this repository which causes mapper which instantiates Hands service also calls this factory which calls that thing in that thing and we already can we think of programs this way we have some taste we have some constraining principles that we share like for instance if this repository where it called this service we would all wait a second you know that's a that's a dependency cycle we'd realize there's a risk of a infinite recursion or like you know a stack overflow there and so most of the programs that we write as developers try to be a cyclic diagraphs and remember Mike here is just to prove that I'm right I want to tell this person no small units is better than 300 lines objectively and to do that I thought maybe there's a liberating constraint maybe if I refine my tastes further I can solve this problem and and where I landed was I want to express all of my features not as just general grasp but as trees because I tree is just a special subtype of a graph you can take this exact same menagerie of units and organize it in a tree shape where you have your value objects on the left and the function future behavior on the right and now if it's true that I have any need listing direction it stands out in a tree because it's just got one child so that service locator yeah I can probably get rid of that and if somebody asks you know it's been what they're looking for is how to compare two hands they can search the tree much more easily and quickly than just a gigantic directory of files and and find what they're looking for so it's more discoverable the other aspect of my aesthetic is I'm a minimalist so when you look at our app you see it's a car it drives you think about what its function is and why it exists when I look at our app all I see is the clutter and the mess and as a minimalist my productivity goes up when things are tidy and symmetrical and terse and it goes down when things are cluttered or inconsistent and what the software is supposed to be doing is it's essential complexity everything it actually does is it's incidental complexity the other stuff think of everything that goes into writing a program you're writing deploy tooling and app config and dependencies and framework appeasement then of course there's whatever the Apple is supposed to do there's style rules continuous integration build systems and then of course unnecessary stuff as a minimalist I'm the person on the project who's always chiseling away to try to minimize the amount of incidental complexity in the system and trying to maximize the time that the team spends on whatever is really important that means I'm always tweaking my code style like maybe I'd start writing future behavior inside of my model objects but then separate them out into separate units but then maybe make them callable is what maybe ultimately landed module methods these are all fine you can debate the finer points by the end of the day really six of one half a dozen the other kinds of arguments and they represent a sort of trap because earlier I said like style of rules debating style is a type of incidental complexity because style is subjective and so it changes around arbitrarily and arbitrary decisions breed inconsistency and oh it turns out that inconsistency is another form of incidental complexity and so oops because I thought Monday I organized code this way and on Tuesday this way and Wednesday that way and then by Thursday I've decided this is the best way to organize code everyone's gonna get mad at me because I just littered thirty-six custom little Styles all throughout the system so my temptation to continuously be improving stuff actually breeds inconsistency and creates bigger messes elsewhere so I reflected on how I think what would happen is I chased the local optimization at the expense of like the global optimization of what's best for the overall project and I had to learn to avoid miss oscillation in my design and it really required me to just realize I'd spend the entire project spinning my tires and so instead I decided I need to lock in these decisions and say we're just gonna do things this style whether or not it's better or worse it doesn't matter so we can try to carve out time to be productive and as I got better at that at flexing that muscle I can recognize where I'm spinning my wheels earlier and spend more of my time being productive it was a way for me to both be minimalist but also really consistent in my applications even when it meant hewing really strongly to arbitrary decisions of things that didn't really matter and when you do that especially with your incidental complexity it brings the essential complexity into sharper relief so you can all as a team really just focus much spend more time on what your app really needs to do the third bucket is naive versus leery question one publishing metrics like a code coverage is always a good idea and I think radical transparency often backfires question two writing good commit messages today will pay off in the future secret I don't actually read commit messages three software teams will make smarter use of time under pressure disagree I think pressure kills cognition for software is generally improving over time and we are not doomed past so does that make me naive or leery I'm starting to realize this is a pretty obvious test in my case I'm weary it all starts with my distrust of all of you because most teams operate in a pressure cooker they're under pressure to get as much stuff done as fast as possible and as a result their brains turn off and it you know results in really really bad outcomes in fact it's not very fair to pressure-cook nurse because pressure cookers serve a useful purpose so I'll find another analogy where we're just being squeezed for all of the Ruby and JavaScript that we're worth and again not being creative not resulting in good code one person on teams I don't trust is I don't trust product owners I love them but I don't trust them back in the waterfall days you know product owner would be able to specify 300 bullet points of everything that they ever wanted and then force them upon us and we'd say hey this is awful but you know in a way at least it was honest they got to articulate everything that they wanted upfront it was just us who didn't know how to handle that much complexity scrum and agile stuff kind of gave us a little bit of a backbone and we said no sir you only get one index card at a time and in fact that's gonna be 20 points and I made up what points mean so naturally then it becomes a debate of no I think it's five points and any system can be gained and really savvy product owners I know are really good at this like oh you know this is not that complex it's just a little cartoon whale you guys can do that right you have time and we'll say oh yeah sure we can do that and then we realize it's much more complex than we really thought and by then they're out to lunch and we're left holding the bag so I don't trust product owners for someone I trust even less than front versus other developers and it's because of a feature we neglect to realize a very basic fact our brains can only hold so much stuff in them at once and so I think the developers have this bias toward sizing features to just whatever number of things they can hold in their head in time and naturally the conclusion that we draw about how big our objects and methods should be is the same size because then in that way we can just put all the things in one place it seems like this simple solution but then a month passes and somebody says hey you need to add a couple additional aspects to this feature you know it has to do this and this as well well that means that the other stuff like I'm brain is finite we can't you know keep it all in our heads at once anymore but units we can make files as long as we want so we just even though we're incurring a paging cost we can slam in those additional attributes to the feature but it creates a blind spot for us where you know now that we're not thinking about the the persistence you know bugs can creep in through that door and if you work this way a year passes and pretty soon your units are just as gigantic and they look like this and they're riddled with bugs and normally they four hundred is the day that I get a phone call saying hey can you help improve our tests of course this isn't a testing problem right it's like a complexity management problem and it's hard for me when I see this cycle repeat over and over again to let that distrust kind of like grow into cynicism and that's not good and in fact if I'm empathetic I realize that at the root of this industry all of us really struggle to predict how complexity is going to change and to guess the complexity of stuff and I do it too and so what I want to do is is is change the question and instead focus on how to prepare myself and other people for an inevitable increase of complexity because I'm any maintaining system almost any of them they're gonna complexity is gonna go up over time it's just a matter of what that graph looks like and so like Pascal I made up sources wager in my head we're sure complexity might remain constant or it might go up and yeah we could keep writing these brain sized units or much smaller ones and the complexity doesn't change you know no harm no foul it doesn't really matter how we factor our code what if it goes up we have a lot of evidence that these larger units cause problems and the nice thing about small ones is they can actually accommodate some additional complexity without too much pain that's why I'm day one of every feature I break things up into any bitty tiny units to the point where people criticize me and you know if you think that my units are too small don't worry because I trust that you're gonna go and make them bigger later it'll work out it's a great way if you struggle with like trying to make follow the single responsibility principle I have every object do one thing this makes it really really easy in fact this is what the tree of functionality kind of shipped out as in this example and every single unit serves exactly one purpose and they all follow one of three roles that I've kind of observed over the years of practicing this the parent nodes are delegator objects they don't really have any logic or branching maybe just like one if condition or something they mostly just break up the work and hand it off to other things and the way that I happen to do that is I use this test-driven design where I used Eskimos to identify and think of once you know what's the code I wish I had that they would actually do the real work what you want to try to maximize is these leaf nodes so this is where the core logic of the application is it takes inputs and transforms into some kind of output you know these are pure functions and you don't need test doubles you just are actually testing real logic these are the kinds of unit tests that everyone likes to write and it's sort of like functional programming for people who don't want to think too hard about functional programming it makes it very accessible because you can still do it and you know Ruby you don't have to change languages or something on the left are my values and value objects they just wrap a little bit of data maybe they just hold on to a hash or an array and the methods on them are only allowed to elucidate in the data and answer questions about the data as opposed to doing feature work they're not there to actually build features instead I think of them as the sludge that flows through the pipes of my feature occurred they're the types in those method signatures and even if all of us abstraction doesn't ultimately pay off and even if that feature doesn't change a lot in the future in the very worst case I've got a very discoverable system of carefully named thing that are obvious and small and comprehensible so it's not the worst outcome in the world the third aspect here is that I distrust myself even more than all of you it's because I worry about the future and even though I'm not super confident in today in these skills I'm even more worried that my future self won't be able to program either for some reason and so when I'm writing a feature somebody says build this thing I'll think about how to build it and then I'll build kind of a message in a bottle for myself in the form of better tests and documentation and commit messages things to try to help and my future self who's wearing sunglasses is told to change that feature he gives really frustrated because what those tests mean is now he's got a bunch of other stuff to do every time he wants to make a change and my future self would much rather just start fresh and be able to write new code and so I kept trying to do myself favors by writing a lot of extra tests and adding in all this quality at the beginning but it would actually tie my hands and so I had to reflect how do I bake quality into my applications without creating an undue burden for my future self and so I started working a little bit differently because if this is our tree of functionality and our manager comes in and says new requirement like thanks to some HR Fiasco all handshakes have to happen between three people the traditional way to solve this is to carefully read the existing code add remove change tests change the code and then trying to make a small of a mess as possible and I say small mess because any time the purpose of a piece of code has many two things whenever we change a unit it kind of carries with it technical debt it confuses the story of why it existed because it's changed over time so instead I've been trying to make my code disposable uh what that means is that when I look at this tree I search for all of the affected units by the changes these are two units they're gonna change and so then I find the smallest subtree that encapsulates that change and so there it is right there and then I do something unusual I blow it all up I just knock it out because I trust that my future self is gonna be able to see that top level thing and understand what the contract is so there he is he's gonna drive out a new solution and as opposed to just changing these old units that implement in Viet logic the old way and thus rack up technical debt today I trust me to drive out a new solution and in fact the future US is gonna have more experience than present-day us they'll probably have a better understanding of the business they'll be able to write better units in the future than a week ever could hope to you today so this is a healthy way to work it does mean that I try not to reuse code too much in my future code because any code reuse like if you have a mention that's called in nine places it's just really hard to change that method cuz you have to consider nine different places callers and what they need it's also really hard to throw it away and replace it so I try not to reuse too much code and it also forced me to let go of this idea that maintainable code has to live forever in fact you know is as opposed to that this incremental rewrite in the small as part of your process is a way to pay technical debt you know without saving a rainy day fund for when you finally get to refactor and in doing that I actually made myself happier because future me does not want his job to be you know fixing all of Justin's old jakey tests every time that he changes something wants to be able to write code for a living and so this is this process by making like you know death a part of life while we're working through features is a great way to keep your team's happy I found the last bucket here is economical versus thorough the question one better to ship code quickly than wait until everything is tested and I feel like I just need bailing out water in that case two design principles are useful but most teams waste too much time on them it's possible for sure but few teams are at risk of this three most teams lack of sufficient understanding of their dependencies absolutely you know 90% of us have no clue how most of our code works in our applications and four it's okay for everyone on the team to maintain separate coding styles I actually strongly disagree because this means two siloed development it's kind of like a Conway's law of style so does that make any economical or thorough well of course it makes me thorough some of you are noticing that this spells salt that's because when you make up the quiz you can make it spell whatever you want it's gonna surprise a few of you to learn today a confession to make I'm a bit of a control freak and that means I'm dubious of free stuff so when you see a sign that says free puppies all I read is extra work and another thing in our industry that makes me think extra work is open source and so just keep that in your head next time you're on you know asking for free labor from an open-source maintainer imagine you're yelling at a puppy instead because who yells at puppy's jerk and open source isn't free because just like puppies we have to learn how to use it or if they learn how it's changing and follow it and and and it's not just this panacea that we can pull off the internet and instead of having to build stuff ourselves and if that open source has a bug you know in theory sure we can fix it ourselves but in practice we're not going to understand all that stuff we're probably gonna have to rely on a maintainer or an expert to come and fix it later finally like if we have you know like let's say that this is our graph of objects and it's all very consistent everywhere and we slam in some third party API that's gonna create a certain amount of friction and pain because it's not going to look like all of our other objects in fact third party dependencies have this really nasty habit of leaking references all over our code base which makes it really hard to change or replace or upgrade those third-party dependencies over time so my temptation of all these negative things about open source and puppies instant well I don't have a puppy first of all again much to my wife Becky use consternation but - I try to like avoid using open source and that's what my gut tells me to do but that's increasingly untenable these days because I'd be reinventing wheels constantly so I had to change how I thought about open source instead - maybe protecting myself from its blast radius as opposed to avoiding it entirely and the way that I do that is I write wrappers of all the third-party code that I write in fact we already have one up on this tree it's that finds Hands unit on the left so there's a wrapper object that starts it's just a well named delegator it's a no op it doesn't do anything interesting but it comes to encode all of our understanding of that dependency it is the carpet under which we sweep all of the stuff that we have to do to make that third party dependency happy and I integration test it but only in proportion to how suspicious I am of it breaking otherwise I trust that in itself is tested well and it might feel like a needless new direction but I need you to trust me that it's not of course if this is where we're calling finds hands in our in our top-level code and I just told you not to trust other developers so you don't trust me you assume that like that wrapper is unnecessary let's say and instead of using that call we're just gonna call user dot all instead that way it's much more direct we got rid of that needless indirection which means we have a bigger test so this is our original test we can get rid of that fake finder and instead have an array of real users that we create in the database of course validation failed so now I have to add like a birthday some other arbitrary thing to make this work but I can also get rid of the stubbing here and pass real users into the other stubbing and yeah I gotta make an integration test as opposed to a unit test and ask yourself now what did we just do because the value of this test used to be crystal-clear its purpose was to break the work up in the floor clear responsibilities and now what is it it's an it's calling through to the database so it's making sure that the thing works but only when 3/4 and the code paths are fake like that doesn't seem right that seems wrong to me and it's really becomes obviously wrong when this becomes more complex because if we add a couple scopes like only search for full-time and active employees then our test is needs nothing anymore because those scopes are like branches so now we need two or three test cases to cover everything and now it's abundantly obvious that we sliced things wrong so when I hear teams complaining you have too many instructions or too many objects typically the thing that's it's not wrong it's something you're making not in too many abstractions and of no abstraction is somehow better it's that you're probably mixing the levels of abstraction in your system because life with wrappers is much easier if I look at that same thing and dive into what that record looks like yes I'm day one it looks like a needless indirection but I'm day two when it gives more context there is a it's easy to write a test for this there's a place for that complexity to go and over time you know it might become a little bit more complicated as distance yourself further here with like a transformer to a type that you own as opposed to you know an active record user so let's say our boss comes in and says we're gonna change from active record to the sequel gem traditionally this would really panic everyone in the room because if it had a billion references to active record all over your system but when you're writing rappers carefully on your third party dependencies you're actually prevent from preparing for yourself an adapter interface that's minimal and specifies exactly how you use that dependency so you can even answer questions like would it be possible to switch to this third party thing and if you did you can create an alternate implementation and run both in parallel for a while it's a much much better way to work and when I found those it's a way to maintain you still have all that convenience of open source and sucking in these useful libraries while maintaining control over how you work so when you're is introspective about this stuff as I am you run the risk of explaining the universe through yourself in fact if you ask anyone who's ever worked on a project with me what my favorite way to write code is it's my way and I'll fight you for it so my inclination is just work really hard to convince you all that my way is best and I'd love to say that that's an altruistic thing and I want you all to be better programmers but it's not it's selfish what it really is is I'm afraid I'm gonna have a manager someday tell me that I can't write code my favorite way anymore and when I reflect on that even if I were to come up with the perfect way to write code and hand it to you I run the risk of robbing you of that same autonomy so that wouldn't be good either and so that's why I'm getting out in the silver bullet business so even though I talked a lot today about how I program I'm not here to sell you on that I mean I hope you find some of it useful but what I really am here to sell you on is the idea of pausing and introspecting about how you act feel and think while you're programming so that it becomes more explicable to you and then you can articulate it to other people it and Cheryl you might ask yourself hey if we all start thought leading ourselves won't I just create chaos on our teams and I think that's actually a valid concern so let's spend a minute to talk about that because earlier I said if you lock down all those arbitrary decisions up front you can spend more time being productive that's true individually but it's also true as teams and that's why when you have disagreements with other people on teams you should aggressively pull those forward because the earlier you have that discussion and say okay you know we'll use these semicolons we will follow this style if you can agree to that stuff early and lock it and you'll as a team be more productive and in fact if you look at the average team remember what I said earlier we're all just imitating other programmers so most teams actually like the idea of normalizing in fact some of them like it too much where if you have a creative idea of doing things differently no I don't want to rock the boat you know I don't want to like you know do my own thing off here or go off the reservation quote-unquote so instead we tend to just gravitate towards the lowest common denominator a lot of teams and that's not good but that's not you anymore right because after today you're going to be thinking about how the actions you take could be improved your feelings improving your thought processes and I'm your next team when you draw in a team of all enlightened Hugh Jackman's some of whom will be salt and some of whom will be fine which is literally what the other for trade spell and some will be sale and some of these fault when you look at this team yeah sure they all in very strongly held opinions that of different ways of doing things but the one thing they have in common is when they're approached with a new idea they have a system for testing it and figuring out whether they do adopt or reject it so they're not afraid of trying new things and that's why I think that really introspecting developers rather when they're on a team they might just look like they're talking at the whiteboard all day but they can actually have a multiplicative impact on each other as they grow and that's really my dream today is that if we can as an industry normalize the concept of metacognition and as self-improvement so that we can explain how to program this whole place might start making a whole lot more sense and that is how the program so I appreciate your time here today if you're looking for a company to work with that's going to support you on this kind of journey I hope you'd consider checking us out that's our page explain what it's like to work with us a test double and if you're a company that like is looking for additional developers on your team I hope you consider working with us we join other teams just as additional developers with an interest in helping everyone get better as we go and you can learn more about us on our site by the way I really made this quiz it's a real thing I actually print it out like a hundred copies and I have it in my bag so you get a special commemorative edition today if you come up and say hi to me I'll hand you one I also have a lot of testable stickers if you don't want to say in person you can actually go to test double comm / salt and fill it out we made a Google Form and the two of our agents yesterday actually figure out how to automate Google Form so it'll calculate your your program or type and email you run away so you know check that out too but most importantly of all I'm really thankful for this opportunity and for your time this morning thank you [Applause]

Channel: Coding Tech

Views: 35,979

Keywords: how to program, programming, software development

Id: KNjiKbSSlCM

Length: 43min 19sec (2599 seconds)

Published: Sat Dec 23 2017