effectively measuring things

Welcome to Building Better Developers, the Developer Nord podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well hello and welcome back. We are again getting into a special topic in between interview episodes. This is something we've talked about, sort of. We've definitely hit on it in some of our prior interviews. And I want to go back to it because I don't think as developers we spend quite enough time thinking about it. And that is effectively measuring things. And particularly being able to measure so we can manage, so we can improve. So we have a baseline that we can compare against and figure out if what we're doing is better or worse than what we were doing before. The cool thing is, the good news, in the world of development there's a ton of stuff. There are lots of metrics we can use. Modern tools make it that much easier. We can look at things like defects. We can look at code commits. We can look at failures, like bugs within a deployment and with a migration or moving from test to dev or dev to test to production. We can look at lines of code produced. We can look at lines of code deleted. We've got all kinds of stuff that we can put on our machines so we can see how often were we actually in a certain IDE or using a certain tool. What is the size of the code we're generating? There's all of this stuff, including all of our time-related stuff, which we probably sort of track. We probably put down to some extent, depending on where we're at. I know some people, you're salaried, it doesn't matter, you just show up, boom, you're off and running. You just show up, you work, you get to the end of the day or your day, and you go home and that's it. But even, I've been to a lot of places where I was a salaried employee, but there was project tracking stuff around. I had to put, I was working X hours on this project, or I had X hours in meetings today, things like that. Now, maybe you look out and you have that, but you're able to just go in and just go, I had 40 hours a week on that, 40 hours a week on that, 40 hours a week on that, and then you don't have to put any details. But if you do, if you track something like that and you pay a little more attention, you will be able to find ways to get better at what you're doing. Now, this is a follow-up, I think it's a nice follow-up to one of our prior special topics where we talked about getting things done and about being intentional about essentially the time wasters and things like that, is scheduling things in a way so that your transition from project A to project B was, it minimized the time lost in that transition. Now, in a similar sense, I think when we do, if we aggressively, and this is the challenge because as a developer, we don't want to do it. I don't want to do it, you don't want to do it. I would love to see the results, but I don't want to put the work in. And probably most developers are the same way. And that is to be able to really aggressively know how many minutes, for example, per hour am I actually writing code? Am I debugging something? Am I compiling stuff or waiting for something to build or a server to start or server to come down or connecting to a service or waiting for a query to return, stuff like that. Now there are tools out there that will help. And that is one of those things if you want to really like, you really want to ace the game, if you really want to get good, then go take a look at some of these tools. And if you look at like, you can probably just go, probably the best way to do it is go search time management recording tools on your favorite search engine and you will find some of them out there. There are several that are a little bit intrusive because you have to install them, because that's how good they are. You have to install them on basically all of the main applications you use or some will do it, they'll just work off of processes. You have to know a little bit more about what you're doing, but that's a nice thing if you can just slap it on your machine or machines if you use a couple of them and you have something that's just watching processes and just storing times that certain things were being run and then it spits out a report at the end of the day, the end of the week, end of the month. That can be very helpful. Because then, for example, there's one that I used for a while and I don't know if I still use it or not anyway, I don't think all those emails now go to junk, is it would show me, for example, how much I had the mail client, like I think at the time I was using Outlook, and I had Outlook as my primary app. Now, that can be a little bit skewed because initially it was great. I was on a laptop and if I had it up, okay, I'm probably looking at mail or working with mail. That was a little scary because it was, in a 40-hour week, it was not a half an hour. I think it was usually like six to eight hours, maybe more than that, that I was sitting in mail dealing with something. Now, granted, sometimes that was composing mail and things like that that was, we'll call it work, that was, well, we'll say it was productive, but I'm sure there's a lot of time that wasn't. However, that did get a little bit skewed when I went to a second machine because I would just have mail sitting up on that one machine but actually didn't look at it that much. It would look like I had mail up for 40 hours that week or something like that. So it did like, you have to watch what you're doing because you can end up essentially hiding your activities because you could be, if you've got a couple machines up, you're going to be doing, let's say, your 40-hour work week and you've got two machines up, it's going to report 80 hours of work even if you do 40 hours of work. And within that, there may be several things that are essentially seen to be up a lot, like they are your primary thing for one of your machines, but you may not have looked at that other than when you first fired the machine up. And so it's like everything you've got to, you have to be a little bit intentional about it but it is getting better where there are tools out there, there are these processes and these plugins and things like that that you can use to get an idea about where you're at. And I think that is an incredibly good insight for you even if it's not precise. And I'll give you an example. I've got one that tracks time and IDEs. So on a given week, let's say I've got 30 hours and a 40-hour week that is totaled up across these. And it's not just the IDEs, but it tells me which project I'm working on. It is amazing when I know that I spent, say, I'll have sometimes something that I'll say, oh, I know I spent 20 hours this week on this project. And I look at what the IDE says and maybe it says 10 hours. No, I can find some other hours because it's like, hey, I'm in the IDE but I'm also in DB Visualizer that I use for the database or I'm in Word or Pages or PowerPoint or something like that because I know I was doing some projects. But sometimes it is, it's hours I'm not really on the, I'm not working in because it looks for some sort of activity, I think. I'm not like writing code. I've got the IDE up. I've got code in front of me and I'm scanning it or I may be rocked back a little bit in my chair like designing something in my head. Things like that. That it is very informative, I think, for us to know how we work and to be able to look at things and go, wow, I spent a lot of time like heads down coding or wow, I only spent a little bit of time coding, but I spent a lot of time in design because that's going to help us become better not only to know where our time spent, but that's when we start estimating things. We can look at stuff and say, oh, yeah, it's going to take me 10 hours to code that, to write the code, but it's going to take me another 20 hours of design time because I know that's what I typically, that's my typical like, you know, code time per actual time ratio is maybe only a third. So for maybe every 20 minutes I code, it takes me an hour to get that 20 minutes of coding done because I'm designing and assessing and testing and thinking through stuff and things like that. So it's useful to find these tools. And even if the tool is pen and paper, even if it's you get to the day, end of the day, and you have a little breakdown of like, what did I do? I did this, I did this, I did this, I did this. Maybe it's you've got a calendar that you can use and that sometimes is very helpful because then you just look at if it's on your calendar, then you can go back and look at your calendar and figure out what you did then. That's actually really good if you've got a calendar and it's something that you've got saved when you get to like, say, the end of the quarter or the end of the year. For example, if you come up for your annual review, like, what did I do last year? Last year was like a year ago. That was a long time ago. You can go back and look at your calendar and say, oh, yeah, I was working on this and I worked on that project. And what's really cool is when you have that little bit more detail, you can look in it and go, oh, yeah, I lost two weeks working on that stupid configuration issue or that bug or that's right. I was sitting here waiting for them to get that stuff done because they couldn't get the server ready for me or whatever it is. And you may include in that's part of why now when we're, you know, this comes out around the turn of the year, around the end of a year, when we're thinking about that year ahead. And so maybe that's one of those things you can do either, you know, if it's close to New Year's resolution time, maybe one of your New Year's resolutions is that you're going to try to do a better time job of tracking what you do. And that doesn't need to be much. That's the frustrating thing is that we think it's a lot, but honestly, you could probably spend five or 10 minutes at the end of a day and write down some notes and it would be very helpful to you. You would know what you did. It will also help you when you come in the next day because you know, oh, yeah, that's where I left off yesterday. And over time, you can start looking at stuff and go, wow, I spent a lot of time doing X and I don't need to. Or this thing is falling behind me because, oh, yeah, because I don't ever work on Y enough. I need to find a way to adjust that in my schedule. Maybe I need to plan stuff differently. Maybe I need to. And maybe it's something like, hey, I changed tools and suddenly I'm spending twice as long getting this stuff done than I was before. Or hopefully I changed tools and now I'm getting stuff done in half the time. Those are the kinds of things that you now would have numbers to do that. It's not just the gut. Yeah, I feel like I'm more productive. You can look at it and say, hey, I used to spend four hours a day on this and now I'm only spending three. And I'm getting the same stuff done. So those measurements, those baselines, those metrics are really critical. And if you want to geek out on them, throw them in a spreadsheet or database or something like that where you can wheel and deal with those numbers and you can look at your averages, you can look at your trends, you can look at your min, minimums and your maximums and all that kind of stuff, because that is where the truth lies. That is where you're going to figure out, what do I get done? What do I do well? Where do I struggle? What interruptions cost me the most? What interruptions am I able to just roll with them? Those kinds of things. But you've got to have the data first. Even probably five or 10 years ago, getting that data would have been time consuming. It would have been costly. But now there are tools out there and there are ways that you can adjust how you work your day, what your workflow is. And part of it's going to be things like opening and closing certain applications and some stuff like that. So if you're not using it, close the stupid thing. That kind of stuff. But some of us, that can be very tough because we have browsers that have 1400 tabs open on them and things like that. But also, if we get into the habit of not having all that stuff, we have less distractions. The resources for our machines are more freed up to get stuff done with what we're focused on and so many other little things. And there are things that will show up that we don't even notice it during the day. There will be things like, for example, you may have, just like pick a messenger type app that's on your machine. Maybe that could be Slack. Let's say it's Slack, but you really never use Slack. You have Slack up, but you get a Slack message once a week. So it really doesn't need to, it never needs to be in the foreground or almost never. But let's say it has some sort of an alert or reminder or something like that, or you've got some little badge thing that causes you to check that on a regular basis. Well, it's really going to be insightful. If you get to the end of the week, or even end of the day if you get to that point, but if you get to the end of the week and you look back and you say, wow, my little counter thing says I spent two hours in Slack this week. I shouldn't have spent any time in Slack. I got one message. It should have been five seconds. I was just, I looked at it and I was done. That may be something that says to you, hey, I should turn off Slack because what probably is happening is in the background of your mind, of your processing through your day, it will pop up every so often. It'll pop up and you'll see it and you'll have to minimize the window or close it or something like that. And over time that adds up. It may not be that distracting because it's just a mindless task for you, but it does interrupt your flow. It's sort of like sleep apnea. What happens is people will be going through their night and they don't realize they wake up over and over and over and over and over and over again. And that adds up so that in an eight hour period of laying in a bed where they thought they were getting nine hours of sleep, maybe they only got four hours or less because they had all of these interruptions and it stopped the flow and then their body had to wind down again and all that kind of stuff. We have those same things occur during our workday. So if you look, for example, at your stats at the end of the week and you realize that, wow, I've got 15 hours that I spent in my mail client. Part of that may be that you get a lot of emails. We all do. But maybe what you want to do is say, well, what happens if instead of leaving my mail client open and having it check mail every minute or something like that, either I close my mail client completely and only check it a couple of times a day or set something up so it only checks mail once an hour or once every two hours or once every four hours because we all get those little badges and stuff like that. It's a little bumping, bouncing little thing that says, hey, I've got email. Well, maybe shut it off so it doesn't do that often or turn off notifications. Or if you've got some sort of like a do not disturb feature on your computer or whatever your tool is, your laptop, whatever it is, maybe do that. Go into do not disturb mode for a while so that you don't get disturbed, so that those notifications don't come up, they don't interrupt. And next thing you know, you're going to be getting more done. It's just like if you're working in a busy hallway and people are walking by, even if they're not talking to you, there's distractions. But if you're in a quiet little room, door shut, nobody's interrupting you other than they have to knock on the door, then at least you know when they knock on the door you're being interrupted. But all those little ones that are in the back of your mind that can sort of distract you, it becomes more obvious that those are distractions when you start actually measuring those things and looking at them and going, oh, yeah, I guess I do spend a lot of time having to click OK on that button or looking at that app because it tells me it's got something new that I really don't care to see. Those are the kinds of things that we can do to become better developers, is get ourselves a baseline so that we know what are we now. It's hard to say we're better if we don't know what we were before. So if we can figure out through metrics and get ourselves a baseline, I'm like, this is what I get done. This is how I get stuff done. This is the approach I take. This is how, quote, we'll say, and you can define how you want to. I'm productive I am. And when you can put numbers to it, then when you make changes, you can look at the numbers and say, yes, I got better. No, I didn't. And that is how we're really going to get better because we're going to be able to figure out what works for us, what doesn't, what works a lot, what works a little, and put those things together in a way that we become better developers, better developers, better developers that we're always improving. I think that's enough for now. I'm going to let you chew on that a little bit and see where maybe that will help you as you are planning your day, your week, your quarter, your year ahead. And next episode, we will come back, get to listen to somebody beside me. We will have an interview again, but we're not done with our special topics either. So go out there and have yourself a great day, a great week, and we will talk to you next. Thank you for listening to Building Better Developers, the Develop-a-Nor Podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. Please check out school.develop-a-nor.com. That is where we are starting to pour a lot of our content. We've taken the lessons, the things that we've learned, all of the things that make you a better developer, and we're putting it there. We have a range of courses from free short courses up to full paid boot camps. All of these include a number of things to help you get better, including templates, quick references, and other things that make us all better developers.