AV-Portal 3.23.3 (4dfb8a34932102951b25870966c61d06d6b97156)

Get Off the Tightrope

Video in TIB AV-Portal: Get Off the Tightrope

Formal Metadata

Get Off the Tightrope
Title of Series
Number of Parts
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this license.
Release Date

Content Metadata

Subject Area
Do you feel stressed when you’re trying to hold a big problem in your head? Do you get frustrated when someone interrupts you and you have to start all over again? Those emotions are inevitable if you’re in the common habit of treating each programming task as a long, precarious, all-or-nothing tightrope walk. But it doesn’t have to be that way! In this talk I’ll explain why the tightrope walk is so harmful and show you some practical techniques for avoiding it.
Software Causality Root Personal digital assistant Different (Kate Ryan album) Multiplication sign Software developer Stress (mechanics) XML Information technology consulting
Programmer (hardware) Latent heat Process (computing) Code Multiplication sign Software developer Energy level Perspective (visual) Computer programming
Strategy game Causality Bit
Mathematics Software Software design pattern Energy level Software framework Quicksort Mereology Arithmetic progression Task (computing) Task (computing) Library (computing)
Context awareness Correlation and dependence Right angle Distance Task (computing)
Process (computing) Decision theory Mereology Library (computing)
Point (geometry) Context awareness Information Decision theory Stress (mechanics) Food energy Connected space
Email Programmer (hardware) Medical imaging Data management Backtracking Roundness (object) Moment of inertia View (database) Video tracking Moment (mathematics) Moving average Surreal number
Logical constant Scheduling (computing) Inheritance (object-oriented programming) Graph (mathematics) Software developer Point (geometry) Data recovery Lattice (order) Twitter Product (business) Exergie Medical imaging Word Interrupt <Informatik> Interrupt <Informatik>
Computer file Multiplication sign Computer file Interrupt <Informatik> Mass Lattice (order) Thread (computing)
Arithmetic progression Task (computing)
Complex (psychology) Process (computing) Causality Mapping Personal digital assistant Feedback Task (computing)
Programmer (hardware) Focus (optics) Data conversion Spacetime
Programmer (hardware) Collaborationism Word Process (computing) Information Multiplication sign Interrupt <Informatik> Planning Online help Lattice (order) Perspective (visual) Computer programming
Strategy game Software developer Multiplication sign Planning Right angle Software testing Arithmetic progression
Web page Point (geometry) Building Group action Mapping View (database) Texture mapping View (database) Web page Planning Bit Product (business) Word Software Order (biology) Website Pattern language Game theory Task (computing)
Point (geometry) Email Group action Structural load Multiplication sign Programmable read-only memory Plastikkarte Disk read-and-write head Product (business) Product (business) Process (computing) Visualization (computer graphics) Resultant Task (computing) Asynchronous Transfer Mode Form (programming)
Web page Point (geometry) Mapping Consistency View (database) Set (mathematics) Maxima and minima Complete metric space Product (business) Revision control Process (computing) Software Iteration Computer multitasking Series (mathematics) Arithmetic progression Task (computing) Stability theory
Point (geometry) Information Software developer Multiplication sign Control flow Independence (probability theory) Branch (computer science) Lattice (order) Shape (magazine) Disk read-and-write head Mereology Flow separation Shape (magazine) Programmer (hardware) Mathematics Goodness of fit Message passing Differenz <Mathematik> Causality Order (biology) Damping Metropolitan area network Task (computing) Spacetime
Mathematics Information Multiplication sign Video game Branch (computer science) Bit
Code Multiplication sign Electronic mailing list Branch (computer science) Mereology Mathematics Word Message passing Code refactoring Arithmetic progression Spacetime Social class Task (computing)
Goodness of fit Message passing Thread (computing) Multiplication sign Decision theory Order (biology) Branch (computer science) Software testing Bit Perspective (visual) Computer programming
Point (geometry) Asynchronous Transfer Mode Implementation Perfect group Service (economics) Code INTEGRAL Multiplication sign Execution unit Mereology Test-driven development Subset Neuroinformatik Product (business) Goodness of fit Different (Kate Ryan album) Green's function Software testing Code refactoring Physical system User interface Boss Corporation Planning Plastikkarte Unit testing Message passing Process (computing) Software Phase transition Order (biology) output Software testing Lipschitz-Stetigkeit Right angle Asynchronous Transfer Mode
Code Moment (mathematics) Content (media) Planning Bit Tangent Wave packet Type theory Process (computing) Personal digital assistant Different (Kate Ryan album) Phase transition Data conversion Arithmetic progression
Complex (psychology) Thread (computing) Process (computing) Strategy game 1 (number) Planning Data conversion Disk read-and-write head Freeware Test-driven development Planning
Web page Link (knot theory) Mapping Texture mapping Sound effect Insertion loss Disk read-and-write head Flow separation Process (computing) Strategy game Software Object (grammar) Blog Software Software testing Software testing Pattern language Figurate number Scalable Coherent Interface
Point (geometry) Code Network topology Software testing Right angle Unit testing Mereology
Point (geometry) Programming language Standard deviation Code Different (Kate Ryan album) Software developer 1 (number) Software framework Bookmark (World Wide Web) Library (computing)
Complex (psychology) Strategy game Software developer Natural number Different (Kate Ryan album) Differential (mechanical device) Software developer Multiplication sign Arithmetic progression
Coma Berenices
the the the the the the
the the the the the the of everyone my name's Thom
thank you very much for choosing to watch this talker and I'm very grateful for your time and attention this is going to be about 40 minutes of your life that you'll never get back so that I could do my best to make it worthwhile I'm here to talk to you about a
particular problem I see a lot for most of the last decade I've made a living as a consultant helping people to make better software and that's been like working with lots of different companies employ lots of different developers and this was by far the most common problem I had to help people with in almost every case it was the root cause of a lot of secondary problems and it usually ended up costing a lot of time and money and emotional stress a year ago I was fortunate enough to
join an online learning company called future learners their CTIA which means are now responsible for a whole team of brilliant developers and there'll fantastic at their jobs by still see them wrestle with this problem from time to time and that's
really because the problem affects everyone all levels of experience it certainly affects me whenever I sit down to write code and it's not even a program a specific problem but I'm talking to an audience of programmers right now so I'm gonna discuss the problem from a programmer's perspective on to talk about it because
although it's a serious problem with serious consequences is 1 you can actually fix poly just by being aware of it which is half the battle with any problem but also by learning some tools in coping strategies that can make it much less likely to affect you going to talk about some of those tools and strategies in a bit actually he is the overall plan for while be telling
you I'm gonna start by describing the problem and then tell you about some of its symptoms and causes also just a few example remedies to the problem based on my own experiences and then I'll wrap up by explaining why I think this is an important thing to talk about in the 1st place so 1st is the actual
problem trying to do a big thing
all at once all in 1 go that might not sound like a big deal but as I said is a surprisingly destructive tendency that that leads to all sorts of other problems I'm sure you recognize the
situation you have a large task to do you like adding a feature to some software or investigating a difficult but we're doing a major upgrade or making a big change from 1 library or framework or design pattern to another 1 and to make progress on it you need to think about all the large and small details all the moving parts or all of the interdependent problems and all the steps you have to take to get it done and you need to keep all those things in your head so that you can think about all of them or all levels of detail while you do the actual work and doing work on this big
monolithic task can feel like a long and precarious walk across a tight right you start out standing on safe ground before you begin but once you step out and begin the work you will be safe again and to be completed and reach the other end which could be way off in the distance in every step you take as go increasingly high-stakes if you fall off you'll have to terror thing up and start again you'll lose your context you flow will be ruined you'll forget what you were doing you have to go all the way back to safety and give it another try from the beginning to hear some symptoms of this
problem when you're experiencing this problem
the big thing that you're feels constantly stressful it feels difficult to get things right because so much is resting on it your constantly aware of the risk of falling often having to start all over again
because you're expecting a problem to be kind of large and messy it can be hard to see where the edges of the problem are now makes it very easy to accidentally get stuck investigating some like body third-party library or unpicking some questionable design decisions from 3 years ago and before you know it you've spent days down a rabbit hole chasing some dead end issue that wasn't even part of the job that you're originally trying to do
what you get past the halfway point your energy kind of starts to wane and you just kind of want the whole thing to be over with and that makes you less and less likely to be willing to revisit your original assumptions or question earlier decisions like when new information comes to light is almost certain that you're going to discover more information is you do the work that information is very valuable and it might make you realize that some of you earlier decisions were wrong but if you're desperate to just get this big project over with you are less likely to want to go back and revisit those decisions and then those mistakes baked-in forever
because of the stress and the sensation of your brain being full of connections and priorities and things to remember you hate being interrupted or distracted because it blows that meticulously constructed mental context go up and as an
aside as a particular strain of tech industry culture the reinforces that view by saying that programmers shouldn't be interrupted because of how complicated and difficult and intellectual or work is is a
popular comic about what happens when a programmer gets interrupted by some kind of tall wearing coffee drinker and all of their hard mental work so disappears into a black hole now I'm a programmer also a manager at the moment might do like drinking coffee so maybe it's me is a problem in this situation need to take everything I'm saying here with a giant grain of salt you might see in this image doing the rounds
on Twitter the accompanying caption so this was anyone whoever schedules meetings with developers please burn this image into your brain so you need 45 minutes of downtime to kind of psychologically prepare yourself for a 30 minute meeting and then you need another 45 minutes to ramp up again after words and similarly you
might have seen this graph of how circled geek productivity works if you were interrupted for 5 minutes then unknown geek might think the your productivity recovers immediately but in practice it might actually take an hour or more so over the course of the day the soft constants small interruptions might mean that you hardly ever actually being productive images like this 1 reinforce or cultural belief that interruptions and distractions are kind of objectively the enemy of productive and useful work another
symptom is that it takes a long time to pick up your friend again when you get back to work if you always in the middle of something massive and even if nobody interrupts you'll still take you ages to pick up your friend again for example the next day or after lunch or when you come back to work after the weekend so if when you get to work in the morning I'll get back from lunch is it's a really long time to ramp up and understand what you were working on then you might be suffering from this problem here are a few other symptoms are
not gonna talk about in any detail but you name I feel irritable about questions in meetings you might be worrying that you forget what to do next you might find yourself typing get status and seeing the you've modified 20 files and you can't quite remember what it was a you're trying to do we might have a big Long Branch with tons of commits from like the late at night saying like where can fix this and I change my mind that I need to redo this later so this is not a
sentence of this problem I'm talking about but why does this problem happen and 1
of the reasons why people get into this situation is just that you get to make progress they've got some big task in front of them and they just wanna charge right into it and get the work done so that they have a kind of psychological reward of being finished and that comes from a good place it's not a bad thing for someone to 1 but ultimately it might cause this problem to happen even though the intentions are good another way to get into this
situation is to be unsure how big a job is gonna be when you 1st start working on some you might not realize how large the task is in which case it's quite easy to accidentally end up in a situation where suddenly you've taken on way more complexity and detail than you originally intended to and that's happened because you don't have a good sense of the size of the problem up from a
related cause of this problem is that even if you do you know how big the job is gonna be you might be unsure how far through you are when you're working on it so even if he thought the star the this would be about a day or about a week's worth of work that less you have some kind of map of the territory than you might end up working on it without having any real sense of how close you are to being finished and that kind of lack of visibility tends to feedback anxiety and worry and fear of having to put your work down and pick it up again later
and as I mentioned before this is idea that's quite prevalent in tech culture the programmers are somehow special among knowledge workers in the kind of work that we did
about idea is very flattering to programmers in fact I think it's successful because it's flattering because it reassures us that we a special all work is an intricate and difficult so it requires special attention and focus and the people around us need to understand them and make space for us to do that kind of complicated intellectual work and they have to understand on needs a different and accept that they can't expect us to drop whatever we're doing just because they have a question or want to have a conversation with us but that's misguided for a
couple of reasons most significantly none of this is specific to programmers all like deakes or whatever all knowledge workers need time to concentrate on the job that they're doing all humans dislike being interrupted when they're right in the middle of something most rational people myself included wish that they could go to fewer meetings so we probably shouldn't allow ourselves to be so seduced too much by this idea that programmers are operating on a kind of higher mental plane and therefore should expect special treatment from the rest of the world the other reason
ideas misguided is that interruptions instructions do you have an upside they can be opportunities for empathy and collaboration now I'm not arguing in favor of them nobody likes being interrupted or distracted and interruptions and distractions can presented a serious obstacle to people with a learning disability or anyone else who is near a typical so we should still try to reduce them as much as possible the reality of the work we do is that interruptions and distractions are extremely difficult to avoid entirely and you'll misaligned useful information if you don't find ways to accept them and work around in other words if someone wants to talk to you it might be helpful to talk to them if literally nobody ever interrupted or distracted you could end up completely isolated from other people's questions priorities and perspectives and feelings and that might help you concentrate better today but it probably won't help you be a good program in the long run people who are beginners of programming tend to view the main work of programming is kind of typing out the solution because that's the most obvious thing they find difficult initially but to become more effective you have to widen your skills to include understanding and caring about what other people are thinking of what their needs are now that I've explained the
problem that let's tell you about some remedies for it now like spoilers I don't have a magic solution or make the whole problem go away altogether up over many years of working with great developers I have picked up a lot strategies for coping with it and so these are a few examples of things I've seen work for other people and I hope that if I share them with you you might find 1 or more of them helpful to you or you might be out think of some of your each of these examples could be an entire talk in its own right so I hope you forgive me for just kind of quickly advertising the ideas rather than properly explaining them in any detail the 1st remedies for this
problem is planning ahead is only possible for you to do small things you know you can write a method you can write a test you can fix apart you can create commit and if you want all those small things to add up to a big thing you need to have some kind of plan about how that's gonna happen you don't necessarily need to do all the small things immediately 1 after another you just need to know how they fit into the plan so that you can work through them steadily over time and gradually make overall progress toward your go story
mappings 1 good way to put together a high-level plan of how lots of small things again add up to make a big thing and story mappings as a bit like a thing consult would try to sell you but is really just a simple game you can play with posted notes was invented by Geico jeff pattern about 10 years ago Tunisia an
example quickly of how story mapping words let's imagine you're building e-commerce you know shopping website and you wanna out a particular story which is a customer buys a product and you start by getting a group of people together and asking everyone to write individual small tasks that might happen over the course of that story 1 task proposed it as many as you can think of the task is just someone doing something it doesn't matter he's doing it it might be the customer all the software or the company or whoever so you might write tasks like you product page ad product a basket view basket page enter payment details and to shipping details confirm order ship product cancel order and at this point just trying to
get all of the ideas out of your heads and written down so you keep going he think of other stuff remove product from basket up they all payment details request refunds say product the later update product quantity and basket browse related products search all products and product wishes to get the idea anything you can think of that someone might conceivably want to do at some point in this process it out of your head and onto a post what you have a load of tasks written
down like this you will try to stick them on the wall arranged so roughly chronologically and tasks that happened at around the same time can stack up vertically where these tasks kind of naturally form groups you can label the groups and usually call them activities on activity might be finding a product deciding whether to buy it actually buying it being shipped the product away what you've done that you should be able to tell the overall story by reading through the task from left to right to should be up say you know customer searches or products and then they view 1 of them and then add the product to the basket and then enter their payment details and so on the 1 advantage of mapping out a story like this is it gives you a visualization of whether kind of complicated task heavy activities are you can see at a glance that there all tasks that can happen at certain times and another advantage is the pen your brain into storytelling mode helps you to spot holes in your story if 1 task doesn't follow naturally from another or if the story is missing obvious important details you can go back and add more tasks to fill in the blanks c I forgot about actually charging and refunding the credit card or sending confirmation e-mails or sorting and filtering search results or vouchers and offers and so on so you can go back to your story
map and fill in the blanks but the other thing she thought of and feel confident you got a complete set of tasks to be you could ever built to satisfy this particular story once you fill in those blanks you can pick a minimal set of those tasks to form the 1st version of the thing that you're going to try to build so you might pick for example view product page ad product a basket enter payment details and ship product as the 1st really basics of tasks that you can try to build was called slicing the story it gives you the minimum set of tasks that lets you build something that makes coherent sense just to get yourself started so you go off and build some software that does just those few things and was last done you can come back to your story map and slice off another internally consistent set of tasks that makes sense to add in a kind of 2nd iteration
now this is useful because slicing the story map in this way give you a way of iteration your way to the complete thing by air a series of stable intermediate points by having this big problem broken down into small achievable subproblems gives you a much better sense of how large of the job is and also a much better sense of how much progress you making toward completing it or if your priorities change you can stop at any point and live with the slices you built so far and move on to building something different just enough about story
mapping another remedy I want suggest is learning to use get to maintain a clean and clear and coherent history of your work as programmers we're lucky to have access to tools like Git that give the like other people in other professions might never feel comfortable working with it gives a lot of freedom to revise and control the history of our work and that can really help to avoid a task becoming overwhelmingly complicated His 1
simple thing you can do together but history makes small focused comments that makes it way easier to understand what you've done so far and why you did so rather than having several independent changes or kind of smooshed together into a single death if you commit the smallest thing you can the smallest self-contained change it makes it a lot easier to understand rather than trying to understand 10 different changes and understand like why those changes have to go together into a single small commits also make it easier to see the causal relationship between changes if you need to implement any so that you can implement B so that you can implement see you can do that in 3 separate commits the man is obvious from the order of them which things depend on what again if the OSS much together into 1 it's not obvious just by looking at that change what the relationship is between those different parts it is also very helpful to write commit messages they explain your thinking at the time when you make a change a very likely to have the best possible information about why you are making the change it might be because your fixing about the customer complained about or it might be because you overheard someone else saying that it is bad to do things in a particular way or maybe you had a meeting where someone told you that you have to upgrade this dependency because in a month we're gonna need a new feature for something if you can put that information into the commit message it makes it much more likely the when you pick this work up again you gonna remember what you were thinking you might be picking up in an hour after lunch break or in 2 days after the weekend to anything you can get out of your head about why you're making this change and write it down in the commit message is going to be beneficial to you when you come to pick up again later the diff inside the commit already explains what what change you made but it doesn't tell you what you were thinking when you did it your history will be much more useful if you invest some time to keep your branch in good shape what you're working on something a branch might live for hours or days or even weeks if you're working on something really big you should always set aside time to make sure that branch is healthy and in good shape and is close to being ready as is possible for it to be about point in time rather than treating your branches this kind of big messy scratch space and saving up 1 huge piece of work at the end to make it yeah shippable merger below or whatever that means for the work you did there are a few different ways of keeping a branch healthy and exactly what this means the EU depends a lot on node your workflow and how you like to work with get so for example if if it makes sense to try to not diverge too much from the master branch away if you call your mainline development branch when I'm writing code or like to avoid diverging from master by constantly rebasing on top
of it so if I'm working with other people every hour or 2 all make sure I fetch the upstream master and take a minute to read my work on top of it now people want to argue about whether rebasing is better than merging they might prefer to regularly MergeMaster back into their branch for example in a bad luck on the 1 with a microphone and good thank I can see this opportunity to promote my opinion that rebasing is a much better way of keeping your brunch small and easy to understand and I think that's more important than other considerations so constant rebasing does generate more work during the life of your branch because it spreads out the effort of understanding how to incorporate upstream changes and the changes that you want to make but that's exactly what keeps the risk lawyer and keeps your branch healthy and straightforward all times anyway this of rebasing emerging doesn't really matter just do whatever works for you to try and avoid a situation where it's been hours or days or weeks since you last go information about what was happening on the branch the your ultimately gonna try your work it is also worth
looking for opportunities to cherry-pick bits of your work back onto the master branch to reduce your branches size and keep a completely focused on relevant changes is
very common to do some like preparatory refactoring as part of the word you're trying to do you make the change easy then make the easy changes can back it see might decides to rename a class all tidy up some messy covered before you try to change its behavior or just fix some white space been bugging you if you create a commit like that 1 work improves the code face independently of the overall task you're doing that's an ideal candidate for cherry-picking onto the master branch getting out there for other people to use and then we basing your branch on top of it so that is not part of your work in progress anymore if you constantly doing this and maintaining as small as possible amount of work that you are holding back for merging in the feature that is gonna make it much easier for you to keep your branch focused and coherence is gonna make it easier to land that work on master when you're done and allow other people to enjoy the benefits of your refactoring all cleaning up or renaming 1 of a much sooner you should get
more comfortable with interactive rebasing and taking time to regularly have a look at the list of your committes and either reorder horseplay or combine them all rewrite the commit messages to keep the story of what you're doing is clear and linear and natural as possible for
example if you change your mind about something halfway through your branch rather than just then I'd rather than just leaving it that way forever you can use interactive rebasing to fix it if you introduce a thing called for you and then later on rename it to bar then use interactive rebase to reorder your commits to put those things together in time and then you can squash them together and remove all evidence of your in decisions the and then whoever picks that work out whether it's you the next day or someone else is trying to work on in the future can read a shorter and less complicated story about what you've changed without having to pay attention to this extra detail that's ultimately a relevant my final piece of good
advice is to practice improving your get hygiene by regularly switching away from your branch just doing something else for rather than allowing yourself to only have 1 branch checked out for days at a time maybe do a bit of work on it and then whenever it's convenient for you to pause switch away from it and do something different when you come back to it you have a much better sense of whether the work you're doing their makes sense and where you can sit down and read in order to understand it without sweating blood a little bit of time away can give you a much better sense of perspective on what you're doing when you switch back to here pay attention to how easy or hard you find it to pick up the thread again and wide-eyed use if you realize that the commit messages or documentation or tests are unclear and fix that 1 you still remember it will be way easier if you to pick up next time His another program
tool that we're fortunate to have access to a test-driven development 1 way that you can
lean on test-driven development to remedy this big problem I'm talking about is to become comfortable with switching between the different mental modes of red green refactor a lot of talk too much about that now but the idea of test-driven development is that your either in the red phase where your thinking about what do I want the code to do you write failing test-run expressed that or your in the green phase we thinking about how do I write the code to do that and then you actually write the implementation or during their refactor phase where your thinking about how do I make this code better to having made your test pass you go back and revisit the work you don't try and make it more expressive will give a better names or remove unnecessary duplication of a lot people forget to use this is a kind of mind hack to focus your attention on what you're trying to do right now it is worth being aware of this and consciously thinking about 1 like trying to do right now I mean the red phase on trying to write a failing test and I'm not going to allow myself to get sucked into doing something different into I'm done with that and I'm convinced that my test is testing the thing I wanted to and then when you get into the green phase tried stay focused on what you need to do to make the test pass and not get distracted by that of doing other things you have written a test for yeah or going to sucked into thinking of that you know perfect names for things the whole point of the green phase is just to get the test of party no outstanding at schools can shameless green and similarly make sure you give yourself time to do that kind of refactoring phase we'll not worried about what problem your solving a new not worried about how you're going to solve it you just focus completely on how you're going to do a better job of it you know now that I've got code that works how can I get myself to a place where I've got good code that works another piece of test-driven development of ice is relevant here is to try working outside in with acceptance tests and by acceptance tests I mean what people Michael and Tuen tests or system tests or feature test or even integration tests and that's because outside in testing or acceptance test-driven development or whatever you wanna call it always tells you what the next thing to do is if you got convincing acceptance test those trying to use your software from the outside to know I'm gonna put brought to my boss and then I'm gonna end to my credit card details and to place my order or whatever than that gives you a top-level plan for what work you can have to do to deliver that feature you can always run acceptance testing you always know how far you walk toward your final goal because of how far that test gets before it fails if it fails immediately because there's you know no user interface for viewing a product that tells you the you need to be working on that now you can go work on input unit tests around it and get about that working and then if you can't remember what use was to be doing next you can take a step back run the acceptance test again see the 1st part of the past and then they'll be a new failures so you want to work on next you always know what the next big piece of work is when you're doing that piece of work you should always know what your currently working on it because you have a failing unit test as well so if you work in this style we have 1 big end-to-end or acceptance testing you run individual unit test as you go then would your interrupted you step away from your computer when you get back to it you should always try to have a failing unit test which means you're trying to get that small piece working all of you unit test surpassing in you've got failure in your acceptance test which means that now you have to write a new unit test push the acceptance us 1 step closer to complete the process despite you got no idea what I'm talking about it is outside in TDD stuff I links some proper resources in a minute incidentally I was talking to my friend Mary about this and he said that he never walks away from his computer without failing test and I means when he sits down again you can always get straight back into what he was doing before which was making the test passed I think that's good advice so I'm going to pretend that I thought of it thanks Mary put your enjoying being in London is probably raining and this flow of and finally on TDD right tests that really do you check what you care about rather than paying lip service to like doing the tests particularly after the implementation just as a kind of box-ticking sure that isn't having any value test should help to focus your attention on what aspects of your software's behavior you actually care about their very important tool for clarifying your thinking and communicating it to other people in particular remember the code that's hard to test will be hard to use and hard to change later so if it's hard to make a clear test then take the time to improve the design of your implementation now is that of saving up trouble for the future the final remedy I'm gonna suggest is to
use Notes and conversations and these things a powerful but they seem so obvious it's really easy to forget to lean on while you're working you can
practice taking notes and writing down things I like questions and mysteries and tangential problems as you find them rather let me and distract you from the primary goal the your working Towards just get them out of your brain and put them on a bit of paper you can always come back to the later once she finished what you're supposed to be doing this is 1 of the main things that can help you to avoid like tangents in rabbit holes so for example you meant to be focusing on the red phase of TDD then you spot something knees refactoring on unrelated but that means that if you feel confident that you've seen a problem at the corner of your eye you've written it down a bit of paper and you promised yourself the when you finish this piece of work you can go back to your notes and work through all of those little edge cases and we had problems is much less likely that you're gonna get bogged down in them as you go you should practice working with other people and explaining your train of thought rather keeping it all kind of scrunched up inside your brain use conversations with other people to externalize your current to do list your current goal your plan to make progress toward that goal the things that you're wearing about right now and so on pairing is 1 way of making sure that all of that stuff is going regularly explained in verbalized it's important to do that because the more you explain the contents of your brain to other people the more chance there is the you gonna notice that they don't make sense or they're too ambitious or too risky or you're trying to take on too much at once so you're going to call up in the wrong aspect of the problem however you choose to do it you should step away from your work regularly to talk to other people about what it is that you're doing and why you're doing it comparing is 1 way to do that another way is to have some kind of code review process or use pull requests or whatever and another is just a chapter people by the coffee machine or on slack about what you're doing in the moment different things work for different people and personality types and working preferences but why every your preferences are you should forget about the value of just talking to people and rehearsing your own understanding of what it is that you do so do we
have those are a few techniques that you can use to avoid that kind of dangerous tightrope-walking feeling you can make plans so you always know where you are I can easily pick up the thread again you can use gets more advanced features like interactive rebasing to keep your history straightforward and obvious and free from incidental complexity you can use test-driven development to focus your attention and you can get ideas on your head by writing notes and coming back to the later if you need to you can clarify your ideas by having conversations speaking them out loud seeing how they feel when you have to a concrete the articulate them rather than just so think them in an abstract of these
tools and strategies I've mentioned today are just the examples I could remember off the top my head from my own experiences working with other people on non-expert in you I don't know anything about your job or your work style your psychological and physiological needs so I'm sure you will have other different better strategies and the ones I've mentioned it but more important than any of my specific suggestions is the overall technique the meta-level way of approaching the way that you work on big things and the
meta-level strategy is to notice the risk and break it down to remember to spot the problem of taking on too much at once when you're working on something pay attention to how your feeling and notice when you start to put yourself into risky situation we feel like you're stepping out onto that long unstable tight you keeping them on in your head there losses separate things need to happen before your safe again you're getting nervous and stressed and praying that nobody distracts you and brings it will crashing down before you reach the other end and then once you notice that it's happening Get off the title and figure out which of your skills to use to break down the problem and approaches a series of small safe stepping stones instead of 1 giant leap so here are a few
links to resources for the ideas I by briefly mentioned just patterns got user story mapping page that links to a book that he wrote about in blog posts and stuff like that 1 of my colleagues at future learn right a blog post about using your gear history to tell stories which is very useful and the growing object-oriented software guided by test book is all about this kind of outside in the TDB process if you're interested in learning how to do that and the new OS but book that just came out recently has got stuff in about writing these kind of effective high-value tests them also been several good
talks ruby come from these topics or by coincidence and you should watch it if you haven't already seen them so yesterday I actually gave a great talk called get driven refactoring where she explains a lot better than I have in a lot more detail how get can help you to spot problems in your code and document your work as part of your commit history and on testing
earlier this afternoon Valerie gave a talk that's a useful introduction to unit testing if you haven't done it before and the tree right before this talk and all gave a talk about so high value tests which goes into more detail on some of the points I mentioned about now just run part I just
spend you know over half an hour talking about this tightrope-walking walking problem why did I choose to come all the way here from the beautiful rainy London to tell you about why is getting off the tight rope important what I want to talk about
this because based on what I've seen so far in my career I believe is what makes great developers great we 1st began as a developer you need to learn how to write covered but at some point it may be years later you start getting diminishing returns on that skill you can learn the syntax and behavior and standard library of your favorite programming language and framework but then how do you get better once you've done that I think that skills and tools like the ones I told you about today what makes the difference between someone who's good a writing code and someone he's great at being a developer if you get more
experience as a developer you learn the strategies for coping with the complexities of the problems you face and the shortcomings of the human brain by being determined and bloody-minded about applying those strategies you can make progress on problems of other people find too intimidating to work on other people will come to you with questions because they think you already know the answers when actually you just more persistent up breaking and impossible question down into smaller more answerable questions and working patiently and methodically toward their solutions that is my son blindingly obvious to you because you're probably smart than I am but it came as a real surprise to me when I realized and I still have to keep reminding people to stop stressing themselves out by trying to do too much at once so unfortunately is not yet obvious enough for me to shut up about this is 1 of the main
differentiators experienced developers and their ability to cope with large problems by using lots of different strategies and tools to break them down into manageable pieces these strategies and tools are learnable and they become 2nd nature if you practice them as if you were learning to ride a bike play the piano and I'm here to tell you that I believe that's worth doing I don't wait to get better at this by accident when you go back to work after this talk think consciously about how to cultivate the skill and make time to develop your own strategies and allow them to become 2nd nature if you can learn some of the strategies lent a spot when you feel yourself walking out onto that dangerous tight rope and practice stepping back to a place of common safety and methodical progress pro progress you create better software and be less stressed and frustrated while you're doing it thanks very much but this
happened and so