Habits of Efficient Developers

yes, hello everyone, 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 I want to do is define what we mean by

efficient

. Being efficient means achieving maximum productivity without waste. resources and in our case as

developers

that resource is usually time, which means that being efficient is doing things quickly, but this definition is missing a key element for us that we can see in this quote from Peter Drucker. Being efficient is getting things done. Well, being effective is doing the right things, so being efficient is not that we have to be very, very fast, but that the things we do we have to do properly so that the decisions we make today do not. slow us down in the future now that we have this quote here, you might be wondering what is more important to be efficient or effective, obviously there is no point in going very very fast if you end up in the wrong place, but equally if we know where we want to go but we never get to that place, it doesn't make sense either, in fact there is some synergy between the two, if you are efficient it means you spend less time, it takes you less time to do things, which means you have more time on your hands to stop look around and make sure you are going in the right direction, so being efficient allows you to be more effective.

Now in this talk we will only focus on what it means. take what makes us efficient and let's stop talking about focus there are many studies that tried to quantify what the cost of an interruption is for us developers and it seems that the cost is around ten or fifteen minutes so every time someone comes and it interrupts you, it takes us ten to fifteen minutes to load the context, reload the context of the tasks we were doing in order to be productive, so it's quite efficient to minimize the amount of interruptions we do. So we have long periods of time in which we can focus on the task at hand.

There are basically two types of interruptions: those you control and those other people control. The ones you control. Email notifications from this. Probably the worst offenders. If you think that that little pop-up doesn't help your concentration at all, the truth is that for your brain it looks more like this, you can't stop looking at it. Millions of years of evolution have made our brain really sensitive to any unforeseen movement, mainly for fear of being eaten, so when that little popup appears on your screen you have to focus on it, you don't have a choice, so efficient developers the first thing they do is disable all notifications, not just email notifications. but absolutely all notifications, in fact, you don't even want to see that little number with the number of unread notifications on your screen because as soon as that little number changes, your brain will catch the change and you'll start thinking about what could send me an email or what should I do so that you can always handle emails when you want, when you have time, no one should expect you to respond immediately to their Emails there are other means of communication that are more appropriate if something is really urgent.

Emails are asynchronous and it is more efficient to process them in batches. The only notification you want to send is the one informing you that you broke the build. and please never be one of those guys who writes an email and wants to tell you just to make sure you received an email. This is actually very annoying and this leads to other types of interruptions that they want and that you don't. control what you can do if someone comes to your desk and interrupts your flow. I know three possible options. The first is to wear very, very big headphones, so when someone comes you pretend you didn't see them and hope they do. just walk in a line and we'll go.

The second option is that you have a very good team. Someone like this guy, someone who is able to address any disruption before it reaches the team. The third option is to make peripheral grameen if you are doing that. pair programming, when someone comes to interrupt you, what should happen is one of the two developers in the pair, so get up, walk away a couple of meters and deal with the interruption and when it's done, come back to the other pair and That every guy that was able to maintain focus, works like real quick cash to get you to a productive state much faster.

The added benefit of pair programming is that, because you have another developer watching what you're doing all the time, you're not going to do it. checking the news or your phone or your email so often that peer pressure makes you more efficient. I don't think I need to explain this well, we all know this and I don't like to sound like your mom when she tells you to get your vegetables, so let's move on to the next, efficient developers only do one thing at a time and the reason is exactly the same why we hate interruptions, yes, because of context switches here we see that doing the blue tasks after finishing, in the green tasks it simply takes less time, in fact, it's not just that it takes less time when you try to do several things at the same time, the quality of your work usually suffers, we all know that the definition of Multitasking is simply screwing several things at the same time, so you should always focus on one thing, if you finish and then move on to the next task, we may all spend thousands and thousands of hours in front of your id, it's one of our main tools, so you really need to know them inside out because any efficiency that you can use in your IDE will be multiplied, but those are thousands of hours that will pass in front of him.

Yes, you basically need to know two things: The functionality and its cuts Now just because you're already sitting in front of it for six hours a day doesn't mean you're going to master it to master your ID, you have to make a conscious and deliberate effort to learn how to do it. . find out what functionality you don't know about, you can't read the release notes, you can follow blogs or YouTube channels of people who use it or you can just do pair programming, when you do pair programming each of your partners will show you how use the ID and it will show you features you didn't know about or show you more efficient ways to perform some tasks.

You can also teach them their tips and tricks to make the entire team more efficient. I am always amazed at the amount of manual work that developers can endure and found it very paradoxical given that we are paid to automate the work of all these people. Manual work is not only slower to do, but it is also boring and creates error problems. so I will always wonder why we keep doing it, one of the main reasons is that sometimes for goodness sake we are developers and as developers we have this very rare and powerful ability that allows us to create an army of minions that do what we say , they won't complain, they never get tired and they do it very, very fast and I think we don't use this ability often enough, sometimes it may be because we end up with these types of minions, but that's different. talk just to make sure these things I'm going to repeat it again you are developers you don't do things that a computer your computer can do for you so efficient developers before starting any task you always think well can I write a program to do the homework or at least to help me do the homework 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 it several times a day and I'm talking about managing programs for one of the tasks you will never do again, first because maybe it's more efficient, you can do it faster, but second, because I hope that writing programs is fun, this is more fun for me. finalists and doing things manually to write simple programs there is nothing like everything good but she will have been a developer for eighteen years and during those 18 years I have changed my operating system I have changed my programming language I have changed my ID I have changed my mind about everything kind of ideas and practices, the only thing that has been constant over those 18 years has been bash, so I want to show a little demo of what bash can do for you.

The beginning of success in the fall I could not cope. So let's say your business manager tells you that another team has created a program and that program is collecting news and you want to know how much news we have per country, so you jump into the box and the first thing you're going to do is write a program, this is a program that will tell you how much news we have, this is a program from 4000, so now let's see what we have in one of those news, so it looks like it's a piece. of correct JSON, but it's a little hard to read, so we format it and we see here some news with an id, some social statistics, the site we came from and we have here the country, yes, so what we are going to do is write a small program. to extract that country, so country code, single quotes, single code, okay, let's see if that works, yeah, so we always see the mouse here in the country, so now let's try to extract it and start grabbing: oh, we get something and now we want. get the whole line so you don't miss too much here is our result country and then we have US so what we're going to do now is split the line with a split line with a quote delimiter and one day I feel like I think the threat of the fourth is the fourth, I feel good, so now what we have is a program to attack the news, they are the country for the news, so we just want to do the same with all the news and now we just need sort them and count them because we want to sort them again, so we sit down in order to get that for this country there.

It's about three thousand years, but now that you have this program, let's say that instead of the country that we are interested in on the side, yes, we see a number of news per side, but now your business manager comes in and says, well, I want to know what they are. the three main websites for each country, so let's modify this program a little bit, take the country, let's try, for example, I L and if I'm not mistaken, all the countries, so we just want, we just want. sort them and take the top three, that's it, now let's format it so that everyone has chosen a line, so now we have a program that for a given country tells us the top three, so we just need to do a for loop to the right. we just need to find all the countries that we can basically get from our previous program and we just need to write a for loop, in these two we echo the country name and we end the for loop Papa Papa instead of IL. is the country we want to know about and because this is bash I need to quote quote quote quote quote and something went wrong, did I miss something? um it's a new error site, what, what, it doesn't matter, so I'm going to then move on to the next thing, which is, whenever you're writing a program, you should always limit the amount of time that you're expected to spend on it.

This is a good example, because if I continue, I'll spend the next 25 minutes just. trying to get your job done, so whenever you try to write a program or a task, the first thing you should do is for a limited time and if after painting that time limit you can't finish it, just move on and get things done. manually right now even if you think that's a waste of time, right? I tried for five minutes to get this to work and it didn't work well, the truth is that you have learned a little that it is not wasting time, it is time invested.

It's up to you to learn and improve, so whatever it is, yes, there is a nice table on a CD that tells you how much time you can spend automating some tasks, so check it out and if we're talking about writing programs professional, what should you always do? Is this what you want about graphical user interfaces? Why can't you put a UI inside a for loop? You don't compost, you just live in your own little world. I'm not saying you should never use them because they are extremely useful when you're just starting out when you're learning something new, but once you're past that beginner phase, we'll actually want to do more complex things and you'll just limit what you can do and if we're talking of a body in your eyes the first way you want to avoid is your own apps, you are right, there is nothing less efficient than launching the app, clicking on things and filling out forms to know if you show up, the new feature is working or if broke anything, as part of making this a more efficient automated test, it also gives us the confidence to refactor and change the code because it will catch errors and errors are the worst waste of time of all, first you have to write the error and then someone . you have to check the back, then you have to put the part back into production and then when someuser notice the error, you will have gone through this massive context, because you probably wrote the error several weeks ago, and even if you wrote the code that you have debugged, the code is already foreign to you and you have to dig into it and then you need to fix it , you need to review it, you need to explain it to your boss, you need to resolve some JIRA issues, and then you need to leave. again throughout the entire release process, so mistakes are just a big waste, but worse than a mistake is having the same bike right twice, so every time you go and fix a mistake, the first thing you 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 you want to avoid doing manually is properly configuring the development environment.

Not only will this make you more efficient, but the entire team will be more efficient. This is what distractions look like for any project I joined from my point of view and the only thing I am clear about. tell them about them is that they are going to do it they are not going to work maybe they are missing some step or they are not precise enough or maybe I 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 What you want to achieve is to get your instructions as close as possible to this single command and that command should bring in all the tools and configure them so you can build, run and test your application if you need a database. you need to install the database configure it and seed it with some data if you need any invoice for maven NPM whatever it will download the correct version of maven install it and configure whatever SDK you need as you can see my preferred tool at the moment .

To do this, it is Docker Compose, which is part of the Toker suite. If you're not familiar with it, it looks like an example and here we are thinking that our development environment in its three Postgres DP Redis DP containers and our own application has multiple benefits. The first thing you need is a few minutes for someone new to get started, but also if something stops working in your development environment, you can just delete everything and start again if there are any changes in the development environment that you know about, share immediately with everyone . The team and these structures never become obsolete, plus because Docker runs things in isolated environments, it means that if two projects you're working on use completely different versions of a database or a JD SDK, they're going to be completely different. isolated so that it does not bother one or the other and also because it is so easy to make changes it allows you to encourage yourself to experiment if you want to try a new JDK or SDK or a new version of the database simply make the changes started and if you don't like it , just go through the whole environment and the last section on feedback, no matter what you were on, what you're working on, you should always try to find the shortest and most accurate feedback.

Possible feedback loop is what tells us whether we are going in the right direction. Feedback makes us more efficient and effective at the same time. You want to receive feedback often and early to ensure that you do not stray down the wrong path for too long with consequent waste of time and energy, if we talk about the benefits of automated testing, yes we save time, give it to us, save it, catch errors, let us factor one, it is the best time to try testing, well my opinion is before we start do it. any coding, if you're not familiar with the TDD workflow, basically this will go very fast.

First write a test and only run one test. See that it fails. You see it fine and then just write enough code to create. that test passes and then you refactor, clean up your code by running the test just to make sure you haven't broken anything. There are at least four reasons why you want to use this workflow. The first is fast feed, but that gives you as you create the new feature, keep in mind that your code is doing what you broadcast. The second reason is that if you really believe that automated testing saves you time, you want to get that benefit as soon as possible while developing the new feature.

The third reason is organizational. Here too many times the phrase I don't have time to write this or I don't have time to write this and for me it actually means that well, I always write my code, I finish my function and once I finish my functions, when I test my test and if there is some time pressure, you know I won't do it, I don't have time to write those tests and since you don't write tests it means you don't refactor your code because to refactor code you need very good automated persuasion and since you don't know factor code it means that your code starts accumulating garbage and because your code starts accumulating garbage it takes you a little longer to create new functions and because it takes you longer to create functions you get more time pressure and you add more time pressure, so you have less time to write tests, closing a vicious circle that always ends with the same thing with us, the developers. crying for our right and the four reasons why you want to write your test first is a mechanical reason because seeing a test fail is the test that proves what it is supposed to prove or in simple words how do you know that? your test doesn't have any errors if you write a test and see it fine, there is a strong indication that it is a piece of production code, some logic that isn't there if you write the test and never say what you say.

I don't know if it's because you already implemented a feature or because you forgot something in your test or the setup code is not correct. Now, when you present this idea to many people, they always come up with this phrase: "I can." I don'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 the business is asking you to do well and in this case it's true that you can't. write any tests, but you can't write any production code either, what you have to do is go back to business and ask for clarification on what you want to do.

The other case is that you really understand the business and it's too early to understand the logic you need to build but you don't know if you're going to write one class or ten classes or if you're going to put in an if statement or a switch or a factory factory factory you don't know. Do what you are going to do well, but you know how to understand the logic and you know how to understand the mechanics of side effects so that you know what database you are going to use. You already have juicy ten thousand times.

You know the table. You know everything. In all of these cases, you can actually execute. Let's do a test first, but it's true that sometimes we don't know how to do the side effects they ask us for. For example, maybe the logic for your app's new functionality needs to cause some quiet endpoint to get something. Exchange and you've never used it and you don't know the end point and you don't know what you need to give it and you don't know what it's going to give you or maybe you need to consume some messages. from a message queue and you've never done it, so you don't know what libraries to use, you don't know how they work, in all those cases you don't really know what you need and what you're going to do.

Always this exploration side that we have in our work is that we used to fill in those gaps to turn known side effects into known side effects and that's something that TDD doesn't help you with what you want to do. First read the documentation to see if you are able to fill in those gaps and the second thing you want to do is write lots of little programs to try and play with that technology. For this, the best tool I know is a rebel represents. read the evaluation print loop and it's basically a fancy way of saying you have a common line interface inside your application, you start by trying to explain it, let's see it in action if it works this time, so I've already started an application with a rebel inside and what I'm going to do from my IDE I'm going to connect to that rebel so let's say you didn't know how the plus function works then I would write a snippet in my IDE and I shouldn't use a shortcut to send that snippet code to the app and the app tells me that 2 plus 3 is 5, yes, so I write the code on the top screen and I get the result on the bottom screen, just as it 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 large number? I am getting an exception. What happens if I only pass one parameter? Works. Without parameters. Works. So this. it's just understanding what they are, how the library works and this could be a message library from the HCP library, some concurrency library, I was just writing little programs and running them to see what the result is, let's do something a little more sophisticated, say you say to your business manager you say you have to create a new feature and you know to trade for that feature and one of your colleagues told you that there is a quiet endpoint to do it and he gives you the URL so we are all an HTP we make. an estimate request and we see that we are getting some exception, let's try to format that sketched exception, try/catch the exception, try again, then it tells us it's a 400 which means it's our fault and we see someone here, so , what are we going to do?

What we do is we leave the body right, that looks like a piece of JSON, so let's parse the JSON there, so it looks like we're missing some date. Some query parameters. Query parameters. Yes, we get these exchange rates. What happens if I pass all of the above? What happens if something happens in the future? I will still return data. I'm sorry to worry. What happens if I pass a string? I get that error. So what we're doing is demonstrating how the real world works and how we're doing it. write a little program, we run it and see the result, so it's a very, very fast feedback loop, now you can be the time when the world why don't you use something like postman to do this right?

It's just xdp calm down, he must be a postman, well, there is someone with feats. Doing it this way, the first thing is that you have a complete language, this is a production language 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 take this exploratory code inside a function, this what you see here, this is the production code, as you see it, it will go to production. the changes in the project, this is not a different tool, so I need to get what I got from the tool and translate it to Java or.net or whatever I'm using, this is the production code, it's ready to go too because the repple is running inside your running application, you can go and examine the status; you can see the status of your application running and what we're doing here if you notice we're modifying or running the application and we're doing all this without having to build or restart anything it's a very, very fast feedback loop and I don't know yes 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 run this process. on my local box it may be running tests or production so I might suspect it is modified by adding logging statements in the production code as without stopping the application this is extremely powerful and you know that with great power comes great responsibility , so use it carefully in the end.

What we're going to talk about are code reviews. Code reviews tell us if the code design that we are doing, if it fits the application, allows another of your teammates to tell you if you have any errors and also. we can use it to share knowledge, it is a way of sharing knowledge, so efficient developers want the code to be a code review. Now there is something very true behind code reviews when we are presented with these huge changes. I don't know what his reaction will be. but my reaction is kind of like oh my gosh, yes, when we get them, but when we get small changes we can give useful feedback to the alpha of all the changes because we can also understand the change, even if you are. very disciplined developer and you go through that really painful review process in my experience, what happens when you go and tell the other guy?

Well, you know, I think your design is yours, no, no, sorry, will it improve your design or we could use it. a different library that will save us some time or some resources or whatever usually happens, tell whoever says, yeah, I think you're right, but you know, I've already spent several days or weeks working on this and the end of the Sprint It is tomorrow. So even if I think you're right, I don't think I'm going to have time to make the change you're suggesting because it will take me several more days to do so. Plus, you know it's already working, so let's go.

Let's do something different, make the change as it is andwe will ask the product owner to create a refactoring story. I'm sure he'll be happy to put you at the top of the priority queue. I will know that those things never happen. so you end up again with code words leading to this feature implemented less with plaplapla, blah blah blah, developers so efficient that they don't want just code reviews, they want small and early code reviews, so what they really want is to discontinue the joint reviews of which this practice consists. about having one of your teammates sit next to you and while you implement the future, this developer sitting next to you will suggest improvements to your code, catch the mistakes you are making and for the reviewer the changes. they are really very small, yes as you write them he sees those changes and you as the author can get feedback even before you start writing any code, also if for some reason you can't finish the feature this other developer You can choose. implement that feature without any effort because he has been behind each of his decisions to avoid those silos of knowledge within the team.

Also, this other developer can work as your personal stack overflow because maybe he has already encountered a similar problem and 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 also call this program, so that's all I focus on very briefly. Master your ID. Your tools are manual labor and find yourself the fastest possible feedback loop and last words, you should always find time to stop, reflect on how you are working and never stop learning, thank you very much, thank you very much for your advice.

I'll definitely start with the notifications part tomorrow, we have a lot of questions during your talk, so let's start with the first one, how do we balance avoiding interruptions with working in small, dynamic teams? These need quick feedback loops and frequent communication. That's okay, if your job is, if your team is really small, and if you're pair programming. The team gets small, yeah, and because the thing gets small, it means that need for communication, the number of non-ages in the day on the communication graph just goes down, so try to even out the schedule. Thanks, where can we find your slides?

Everyone wants Terry, my laptop, if anyone wants to take my laptop, the other one, can someone come pick it up? I would polish them on my personal blog. Probably none of you are great. I don't know if I'll tweet it. I'll deal with them now and put them somewhere. If you can find it, that would be great, plus there are recordings of all the sessions so you can watch them later or send the links to your colleagues. Another question, how can we efficiently automate outside of work? It depends if you work for yourself. It's the best thing you can do, yes this is free money.

I think it depends on your ethics. If you can, if you think you can automate your job, why don't you write to end the people who are using that tool or your companies will be very grateful and you know that we have many jobs around the world, so don't worry about your job, there is a job in a better world working for you. Well, I think it's time for our last question: what is the worst distraction for a developer? It's like well, why is it slippery? I don't think it's luck, to be honest, I think the worst distraction is if you have a two year old knocking on your door and you work from home.

I think it's worse, but I Don't think I'm a remote worker, most of the advice I give you is when I wasn't a remote worker and we used to slack off a lot and I would just mute everyone, but they know she's a really cool Mian. They really need to communicate with me, they know how to communicate with me, so I don't know what we feel offended that someone didn't respond to your joke right away, so we should do it, so you know, it doesn't matter, so here I think the the computer It's what really distracts the most phone news.

I found my phone more distracting than lazy, so yeah, I don't know if that answers the question, to be honest, okay, so thanks again.