Habits of Efficient Developers

[Music] yeah hello everybody my name is Daniel I work for a company called odd phone and we are here today to talk about efficient developers so the first thing that I want to do is define what we mean by efficient to be efficient means achieving maximum productivity without wasting resources and in our case as developers that resource is usually time which means to be efficient is to do things fast but this definition is missing one key element for us that we can see in this quote by Peter Drucker to be efficient is to do the things right well to be effective is to do the right things so the be efficient is not that we have to be very very fast it's the things that we do we have to do them in a proper way so the decisions that we take today don't slow us down in the future now that we have this quote here you maybe wonder well what is more important to be efficient or to be effective obviously doesn't make any sense to go really really fast if you end up in the wrong place but equally if we know where we want to go but we never achieve that place it doesn't make sense either in fact there is some synergy between to the between the two if you are efficient it means that you spend less time takes you less time to do things which means that you have more time in your hands to stop look around and make sure that you're going in the right direction so to be efficient allows you to be more effective now in this talk we are just going to focus on what it takes what it makes us efficient and we're going to stop stop talking about focus there are plenty of studies they tried to quantify what is the cost of an interruption for us developers and it seems that the cost is around ten or fifteen minutes so every time that somebody comes and interrupts you it take us between ten and fifteen minutes to load the context reload the context of the tasks that we were doing to be able to be productive so it's fair amount to be efficient to minimize the number of interruptions that we get so we have long periods of time where we can focus on the task at hand there are basically two types of interruptions the ones that you control and the ones that other people control the ones that you control this one's email notifications I probably the worst offenders if you think that that little pop-up doesn't nothing for your concentration the truth is that for your brain it looks more something like this you cannot just stop looking at it millions of years of evolution have made our brain really sensible to any unexpected movement mostly because the fear of being eaten so when that little pop-up shows up on your screen you have to focus on it you don't have an option so efficient developers the first thing that they do they disable all notification not just email notifications but absolutely all notifications in fact you don't even want to see that little number with the number of in that the number of unread notifications on your screen because as soon as that little number changes your brain is going to pick up the change and you're going to start thinking about well what could send my an email or what do I need to do so you should always you can always deal with emails whenever you want whenever you have the time nobody should expect that you'd reply immediately to their emails there are other means of of communication that are more appropriate if something is really really urgent emails are asynchronous and it's more efficient to deal with them in batches the only notification that you want to say is the one that tells you that you broke the build and please never be one of these guys that they type an email and they want to tell you just to make sure that you received an email this is really really annoying and this brings us to the other types of interruptions they want that you don't control what can you do with somebody comes to your desk and interrupt your flow I know three possible options the first one is to wear some headphones really really big so when somebody comes you pretend that you didn't see him and you hope that he will just walk a row we'll walk away the second option is that you have a very good team late somebody like this guy somebody that is able to tackle any interruption before it reaches the team the third option is to do peripheral grameen if you are doing pair programming when somebody comes to interrupt you what should happen is that one of the two developers in the pair so stand up walk away a couple of meters and deal with the interruption and when he's done he goes back to the other pair and that all the guy that was able to keep focus it works like a really fast cash to get him into a productive State a lot faster the additional benefit of pair programming is that because you have another developer looking at what you are doing all the time you are not going to check the news or your phone or or your email as often so that peer pressure is just going to cause you to be more efficient I don't think I need to explain this right we all know this and I don't like to sound like your mom when she tells you to get your greens so let's move to the next one efficient developers just do one thing at a time and the reason is exactly the same why we hate interruptions yeah because of the context switches here we see that doing the blue tasks after doing finis in the green tasks it just takes less time in fact it is not just that it takes less time when you try to do multiple things at the same time the quality of your work usually suffers we all know that the definition of multitasking is just screwing several things at the same time so you should always focus on one thing if you finish and then you move to the next task you may we are all going to spend thousands upon thousands of hours in front of your ID it's one of our main tools so you really need to know it inside out because any efficiency that you can use in your IDE is going to be multiplied but those are thousands of hours that you are going to spend front of it yes basically need to know two things its functionality and its or cuts now just because you are sitting already in front of it for six hours a day it doesn't mean that you are going to master it to master your ID you have to make a conscious and deliberate effort to learn it to find what functionality you don't know about it you can't read the release notes you can follow blogs or YouTube channels of people using it or you can just do pair programming when you do pair programming each of your partners is going to show you how they use the ID and it's going to show you functionality that you didn't know about or it's going to show you more efficient ways of doing some tasks also you can teach him your tips and tricks so you make the whole team more efficient I'm always surprised about the amount of manual work that with developers can put up with and I found it very paradoxical given that we are paid to automate all these people's job manual work is not just slower to do but it's dull boring and it's error problem so I'll always wonder well why we keep doing it in one of the main reason is that we sometimes for God that we are developers and as developers we have this very rare and powerful skill that allow us to create an army of minions that will do as we say they will not complain it they never get tired and they do it really really fast and I think we don't use this skill often enough sometimes it may be because we just end up with this kind of minions but that's a different talk just to make sure that these things I'm going to repeat it again you are developers you don't do things that a computer that your computer can do for you so efficient developers before starting any task they always think well can I write a program to do the task or at least to help me to do the task and I'm not just talking about automating some work that can take you hours I'm also talking about automating tasks that can take you five seconds but you do several times a day and I am so talking about driving programs for one of tasks that you're never going to do again first because maybe is more efficient you can do it faster but second because I hope that writing programs is fun this is fun for me more finalists and doing things manually to write simple programs there is nothing like all good but she'll have been a developer for eighteen years and during those 18 years I have changed operating systems I have changed programming languages I have changed IDs I have changed my mind up about all kinds of ideas and practices the only thing that has been constant during those 18 years has been bash so I want to show a little demo about what bash can do for you the beginning of picking off in the fall I didn't cope so let's say that your business manager tells you that some other some other team has created a program and that program is collecting news and he wants to know how many news per country we are we have so you jump into the box and the first thing that you are going to do is write a program this is a program that is going to tell you how many news we have this is a program right from 4000 so now let's see what we have in one of those news so it seems that it's a piece of JSON right but kind of hard to read so we format it so we see here some news with an ID some social stats the site that we come from and we have here the country yeah so what we are going to do is write a little program to extract that country so country code quote single quote one single code okay let's see if that works yep so we see always make mouse here the country so now let's try to extract it we start doing grab - oh we get something and now we want to get the whole line so so you don't get too lost here it is our result country and then we have the u.s. so what we are going to do is now split the line with a split line with a delimiter of quote and one day feel I think is the threat of the fourth is the fourth feel cool so well now what we have it's a program to strike the news they the country for news so we just want to do the same for all the news and now we just need to sort it and count it this because we want to sort it again so we sit in order so we get that for this country there are around three thousand years but now that you have this program let's say that instead of the country we're interested on the side yeah we see there number of news per side but now your business manager comes inside like well I want to know what are the top three website for each country so we're just going to modify this program a little bit we grab country let's try for example I L and if I didn't get that wrong does that all the countries so we just want we just want to sort them and take the top three that's it now we are going to format it so it all have chosen one line so now we have a program that for one given country it tell us the top three so we just need to do a for loop right we just need to find all the countries that we can get basically from our previous program and we just need to write a for loop for in this two we echo the name of the country and we finished the for-loop Papa Papa back instead of IL is the country that we want to know about and because this is bash I need to quote quote quote quote unquote and it got something wrong did I miss anything mmm it's a new error site what what it doesn't matter so I'm going to then move to the next thing that is whenever you are writing a program you should always time limit the amount of time that you are expected to use on it this is a good example right because if I keep going I will spend the next 25 minutes just trying to get your work in so whenever you are trying to write a program or Eltham it a task the first thing that you should do it's time limited and if after paint that time limit you are not able to finish it just move and do it things manually right now even if you think that that's a waste of time right I tried to for five minutes to get this thing working and it didn't get it well the truth is that you have learned a little bit that's not waste time that's invested time on you learning and getting better okay so whatever yep there is a nice table from a CD that tells you how much time you can expend to automate some tasks so have a look at that and if we are talking about pro writing programs what you should always do it's about you will want about graphical user interfaces why because you cannot put a UI inside a for loop you guys don't compost they just live in their little world now I'm not saying that you should never use them because they are extremely useful when you are getting started when you are learning something new but once you are past that phase of beginner you we'll actually want to do more complex stuff and you guys just constrain what you what you can do and if we're talking about a body in your eyes the first way that you want to avoid is your own applications you are right there is nothing less efficient than starting application clicking things around and filling up forms to know if you're featured the new feature is working or if you broke anything a part of making this a more efficient automated test also give us the give us the confidence to refactor and change code because it's going to catch bugs and bugs are the worst time waste of all first you need to write that the bug then somebody has to review the back then you need to put the back into production and then by the time some user notice the bug you have gone through this massive context which because you probably wrote the bug several weeks ago and so even if you wrote the code that has debug the code is already alien for you and you have to dig into it and then you need to fix it you need to go review it you need to explain it to your boss you need to fill some JIRA issues and then you need to go again through all the release process so bugs are just a big waste of thing but worse than a bug it's having the same bike twice right so whenever you go and fix a bug the first thing that you should do is write a test to prove that you are able to reproduce the bug you see it fail and then you fix it and the last thing that you want to avoid to do manually is setting up the development environment right this is not going to make it just more efficient but the whole team more efficient this is how distractions for any project that I joined look like from my point of view and the only thing clear on them about them is they're going to they are not going to work maybe they are missing some step or they're not precise enough or maybe I will make some silly mistake when I try to follow them and the result is always the same two three four days of wasted time what you want to achieve its instructions as close as possible to this just one command and that one command should bring all the tools and configure them to be able to build run and test your application if you need a database it should install the database and configure it and seed it with some data if you need any bill to maven NPM whatever it will download the correct version of maven and install it and configure any SDK that you need as you can see my tool of choice right now to do this it's docker compose which is part of the toker suite if you are not familiar with it it looks this an example and here we are think that our development environment in its three containers Postgres DP Redis DP and our own application this has multiple benefits right first thing it takes use minutes for somebody new to get started but also if something stops working on your development environment you can just easily just wipe the whole thing and start again if there any change on the development environment you know share immediately with the whole team and these structures never get out of date also because docker is running things in isolated environments it means that if two projects that you're working on they use completely different versions of a database or a JD SDK well they're going to be completely isolated so it doesn't bother one and the other and also because it's so easy to make changes it allows you it encourage you to experiment if you want to try a new JDK or SDK or a new version of the database just make the changes started and if you don't like it you just completely what the whole environment and the last section that we are going to talk about feedback doesn't matter what you were what you are working on you should always try to find the shortest and tightest feedback loop possible feedback is what it tell us if we are going in the right direction feedback make us at the same time more efficient and more effective you want feedback often and early to make sure that you don't wander on the wrong path for too long with the consequent waste of time an energy if we talk about the benefits of automated test yeah we save time give us save it with it catches bugs allow us to the factor one is the best moment to try test well my opinion is before you start doing any coding if you're not familiar with the TDD workflow it's basically this going to go really fast through it you first write one test and only one test you run it you see it fail you see it right and then just write enough code to make that test pass and then you refactor you clean up your code running the test just to make sure that you didn't break anything there are least four reasons why you want to use the this workflow the first one is the fast feed but that gives you as you are building the new feature to note that your code is doing what you spread it to do the second reason is that if you truly believe that automated test saves you time you want that benefit as soon as possible as you are developing the new feature the third reason is organizational I have here years too many times the phrase I don't have time to write this or I'm not given the time to write this and for me just actually means that well I always write my code I finish my feature and once I finish my features when I do try my test and if there is any time pressure well you know I'm not going to I don't get time to write those tests and because you don't write tests it means that you don't refactor your code because to refactor code you need a very good automated persuade and because you don't know factor code it means that your code starts to accumulate garbage and because your code starts to accumulate garbage it takes you a little more time to actually build new features and because it takes you more time to build features you get more time pressure and you add more time pressure so you have less time to write test closing a vicious circle cycle that always end up with the same with us developers crying for our right and the four reason why you want to write your test first it's one of a mechanical reason because seen a test fail is the test that tests that the test test what is supposed to test or in simple words how do you know that your test doesn't have any bug if you write a test and you see it right there is a strong indication that is some piece of production code some logic that is not there if you write the test and you never say bread what you don't know if it is because you're ready implemented a feature or because you forget on a certain in your test or the setup code is not correct now when you present this idea to a lot of people they always come up with this phrase I can't write a test first because I don't know what I'm going to build and this can mean different things it can mean that you don't understand what business is asking you to do right and in this case it's true you cannot write any test but you cannot write any production code either what you have to do is go back to business and ask for clarification what do you want to do the other case is that you actually understand business and you're too early understand the logic that you need to build but you don't know if you are going to write one class or ten classes or if you are going to put an if statement or a switch or a factory factory factory you don't know what you're going to do right but you know understand the logic and you know understand the mechanics of the side effects so you know which database you are going to use you have juicy ten thousand times already you know the table you know everything in all these cases you can actually run a test first but it's true that sometimes we actually don't know what how to do the side effects that we are asked for we for example maybe the logic for your new application functionality in its it needs to cause some restful endpoint to get some for exchange and you have never used it and you don't know the end point and you don't know what you need to give to it and you don't know what it's going to give you about or maybe you need to consume some messages from a message queue and you have never done that so you don't know which libraries to use you don't know how they work in all those cases you don't really know what you need to what you are going to do there is always this face of exploration that we have in our in our job that is that we used to fill up those gaps to convert known side-effects into known side-effects and that's something that TDD doesn't help you with what you want to do it first read the documentation to see if you are able to fill those gaps and the second thing you want to write a lot of little programs to test to play around with that technology for this the best tool that I know it's a rebel rebel stands for read eval print loop and it's just basically a fancy way of saying that you have like a common line interface inside your application starts off trying to explain it let's see it in action if it works this time so have already start an application with a rebel inside and what I'm going to do it from my IDE I'm going to connect to that rebel so let's say that you didn't know how the plus function works so I'd write a piece of code in my IDE and I'm not should using a shortcut to send that piece of code to the application and the application tells me that 2 plus 3 is 5 yep so it writes the code on the top screen and I get the result on the bottom screen so as as I was saying this allows you to experiment with the library so maybe what happens if I pass three parameters seems to work what happens if I pass a very big number I get an exception what happens if I just pass one parameter it works no parameters it works so this is just understanding how they are how the library works and this could be an HCP library messaging library some concurrency library your were just writing little programs and executing them to see what's the result let's do something slightly more fancy let's say that your business manager it tells you that you have to build a new feature and you know it some for exchange for that feature and one of your mates told you that there is a restful endpoint to do that and it gives you the URL so we're all an HTP we make an estimate request and we see that we are getting some exception let try to format that sketched exception try/catch exception okay try it again so it tell us it's a 400 which means it's our fault and we see here somebody so what we are going to do is let's get the body okay that seems some piece of JSON so let's parse the JSON there it is so it seems that we're missing some date some query parameters query parameters yeah we get these change rates what happens if I pass all and older what happens if I pass something in the future I'll still returns data that sorry to be worried what happens if I pass a string I get that error so what we are doing is proving how the real world works and how we are doing it we write a little program we run it we see the result so it's a very very fast feedback cycle now you may be when the world why don't you use something like postman to do this right it's just xdp restful must be postman well there's somebody feats of doing it like this way the first thing is you have a full language this is a production language the one that they use in production which means that I can do four loops and if statements if I want to mix this data with something from the database well I know how to make database calls from the JVM and also if I now go and I grab this exploratory code inside a function this that you see here this is production code as you see it there is going to go to production I'm making the changes in the project this is not a different tool that then I need to get what I got from the tool and translated to Java or.net or whatever you are using this is production code it's ready to go also because the repple is running inside your running application you can actually go and poke at the state you can look at the state of your running application and what we are doing here if you notice we are modifying or running application and we are doing all of this without having to compile or restart anything that's a very very quick feedback loop and I don't know if I mention it but we are connecting to this rebel through a socket and because we are connecting through a circuit it means that we don't really need to be running this process in my local box it can be running tests or production so you could be suspecting modifying adding log statements into production code as without stopping the application this is extremely power powerful and you know with great power power comes great responsibility so use it with care the last thing that we are going to talk about it's code reviews code reviews tell us if the design of the code that we are doing if it fits the application it allows other other one of your your teammates to tell you if you have any bugs and it also we can use it to share knowledge right it's a way of sharing knowledge so efficient developers want that code to be code review now there is something very truth behind code reviews when we are presented with this huge massive changes I don't know what your reaction but my reaction is something like oh my god yep when we get those but when we get small changes we are able to give useful feedback to the alpha of all the of the change right because we are able to understand the change also even if you are very disciplined developer and you go through that really painful review process in my experience what does it happen when you go and tell the other like well you know I think your design is your no no no your sorry it's gonna improve your design or we could use a different library that will save us some time or some resources or whatever what usually happens tell whoever say like yeah I think you are right but you know I have already spent like several days or weeks working on this and the end of the Sprint is tomorrow so even if I think you're right I don't think I'm going to have time to do your change what you're suggesting because it's going to take me several more days to do it also you know it's already working so let's do something different let's just commit the change as it is and we are going to ask the product owner to create a refactoring story I'm sure he will be delighted to put it on top of the priority queue I will know that those things never happen so you end up again with words code that leads to this lower implemented feature with plaplapla blah blah blah so efficient developers they don't want just code reviews they want small and early code reviews so what they actually want discontinues co reviews this practice consists on on getting one of your teammates to sit just beside you and as you are implementing the future this this developer sitting beside you is going to suggest improvements on your code it's going to be catching bugs that you are doing and for their for the reviewer the changes are really really small yeah as you type them he see those those changes and for you as the author you can get feedback even before you start writing any code additionally if for whatever reason you cannot able to finish the feature this other developer it's able to pick up that feature without any effort because he has been behind each of your decisions so you avoid those knowledge silos within the team also this this other developer can work as your personal stack overflow because maybe he has already found that similar issue and he already knows how to fix it and sometimes you don't even need to ask the question because he sees what you are doing some people call also this program so that's all that I have very briefly focus master your ID your tools are both manual work and find yourself the fastest feedback loop possible and last words you should always find time to stop reflect on how you are working and never ever stop learning thank you very much thank you so much for your tips I will definitely start with the notifications part tomorrow we got a lot of questions during your talk so let's start with the first one how do we balance avoiding interruption with work in small dynamic teams these need rapid feedback loops and frequent communication okay if your work is if your team is really small and if you are doing pair programming your team becomes tiny yeah and because the thing becomes tiny it means that that need of communication the number of not ages on day on the communication graph it just reduces so try to pair programming Thanks where can we find your slides everybody wants Terry my laptop if somebody wants to grab my laptop the other can somebody come and pick up I would polish them in my personal blog that probably none of you great I don't know if they I will tweet it I will treat them now and would put them in in someplace that you can find it that would be great additionally there are recordings of all sessions so you can watch them later or sent the links to your colleagues another question how can we efficiently automate ourselves out of the job it depends if you work for yourself that this is the best thing that you can do yeah this is it free money I think it's it depends on your ethics right if you can actually if you think that you can actually automate your work why not write you finish people that are using that tool or your business will be very thankful and you know we have plenty of jobs around the world so don't worry about your job there is a better world job working for you okay I think it's time for our last question what's the worst distraction for a developer and it's it's like well why is it slick I don't think it is luck to be honest I think the worst distraction if you have a two-year-old that is knocking on your door and you work from home I think that worse but I don't think I'm a remote worker most of the advice that I give you it's when I was not a remote worker and we used to slack a lot and I just mute everybody but they know that is a really neat Mian they'd really need to reach me they know how to get hold of me so I don't know what we feel offended because somebody did don't reply to your joke immediately right we should so you know it doesn't matter so here I think the computer is the thing that actually distracted the most news phone I found my phone more distracting that slack so yeah I don't know if that answers the question to be honest okay then thanks again and you

Channel: WeAreDevelopers

Views: 127,741

Keywords: technical architect, backend, developer, programmer, programming, software engineer, software, conference, congress, Europe, WeAreDevelopers, WeAreDevs, IT, tech, technology, people, code, future, coding

Id: 9-cyC6O81Bk

Length: 37min 8sec (2228 seconds)

Published: Fri Jun 29 2018