The bright side of grunt work

This is Building Better Developers, the Develop-a-Noor podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Well, hello and welcome back. We are continuing our season where we're looking at the bright side of things, trying to stay positive, looking at all the little negatives and things that just annoy us on a maybe a daily basis. This episode, we're going to look at the bright side, the positive side of grunt work. Almost by definition, the work that doesn't have a positive and yet we're going to find one today. This may feel like our prior episode where we talked about office politics and something that I think most people do not see as a positive, and yet there are some. Grunt work is a really interesting one. By this, I really mean tedious work, the kinds of stuff that is, and tedious is in it requires us to do it, but you can almost not think about it. It's where you get to the point where you're just really writing code. You're not actually solving a problem necessarily. The problem is more or less, at least what you're working on at that time is more or less, we'll say solved, and it's just code that you have to write. It's the kind of stuff that actually is usually going to end up getting automated at some point. Somebody somewhere will look at that and say, you know what? That's just too time consuming. It's not terribly productive, so let's find a way to automate that thing. If you find yourself doing this kind of work, it obviously would be one of those things that you could look at as a potential product or new feature would be automating it. Some common examples in the development world would be creating a form, an HTML form or something like that. It's just a general webpage, whether it's a form or actually just a webpage in itself where you're maybe putting a little bit of header or a little footer. You basically know what it is, but you have to type out the form fields and the labels and the names and you'll map them back to some data source or object or something like that. It's not challenging basically. Maybe early on it might be, but this is the kind of stuff that can be done by entry level programmers more or less. Maybe not as fast as somebody that's done this a thousand times, but that's sort of the definition. It's something that you've done many times before. It's almost robotic. It's almost mechanical in how you do it. You're not really mentally engaged. You're just sort of cranking through stuff. You may be working off a requirements document or a list or something like that, but generally speaking you're just typing. The code is already in your head. It's just a matter of getting it from your head onto the screen or into the program. Now, something like this you would say, hmm, I wonder what on earth could be useful or positive that comes out of this kind of work. This took a little bit of thinking on this one because this is the work that it does show up regularly enough. I think it's not as bad as those problems that keep us up at night, but it is something that I think almost feels like it slows us down in our productivity because these are the things that you just look at and you go, oh, this is how it's going to be done. You can essentially see the solution in your head. You just can't focus it into, produce it in the computer without spending time and walking through it. And of course, worrying about typos and all the other stuff that can come up with this. The first positive I want to take from this is that this actually can allow us to be productive without exerting a lot of energy. There are things that have to be done. There's work that just needs to get done. And these are the things, and this actually extends way beyond the IT world, the programming world. Some of this grunt work, these mindless tasks, they are things that need to be done, but there's a lesser exertion of energy that's required to do so, which is in itself a positive. It's actually a break, I think, from a job like ours where a lot of times it's very mentally taxing to go through day. If you're actually sitting out and write code, writing codes, solving a problem, trying to logically work through something, and you do that eight hours straight, eight hour work day kind of thing, it is mentally exhausting. It's one of those things that you get to the end of the day and you're probably pretty shot. When you do these kinds of grunt work kinds of things, these lower end tasks, they allow you to almost, I hesitate to say, but I'll say the word rest, to sort of run at a lower pace for a while. Instead of having to spend so much energy working through a problem, you can just get stuff done. You're making progress. You are moving forward, but you're not utilizing 100% of your brain, we'll say. You're not focusing all of your mental efforts on getting this thing done. It's actually very, I think, refreshing to do that from time to time, particularly if you've gone through a period where you've worked on a really difficult problem and you've just been essentially racking your brain for days on end and working your way through this and just slugging through a difficult section. It's sometimes nice and refreshing to get this grunt work, to be in a situation where you look at it and you say, okay, here's work that I don't have to, essentially I'm not going to take it home with me. I'll be able to go get the work done and when it's done, it's not going to be sitting around in my head. a mental exercise where it's going to follow me when I leave work. That allows you essentially some rest and recuperation even while being productive, but it also allows you an opportunity to maybe your mind can wander a little bit while you're through this essentially mindless task and you can maybe do some design or look for opportunities, which is sort of our second bonus here or the positive, looking for opportunities for that automation, a way to take what you're doing and turn it into a feature, a function, a product, a batch, or some sort of automation so that while you're going through it and you're living it, you're also maybe in the back of your mind designing a way, developing a way so that you don't have to do it again, so that others don't have to go through this piece of work, that they can maybe click a button or worst case, they create a script or something, they write a little, you have to use a command line command and maybe a bunch of parameters or be able to load it up in a CSV or Excel spreadsheet or something like that instead of the more manual tedious tasks that you're doing, saving time, saving energy and allowing people to focus on the heavier duty tasks. These are, I guess really another positive of this is that these are tasks that can be done, as I mentioned, by entry-level developers and so it is a way to give them work that makes them very productive. It's value, there's a value to this. It also just helps them exercise their skills because they're going to do this over and over and over again. It is a way to have a lower end or also maybe very importantly, a lower cost resource contributing to getting the product done, getting it out the door, to being productive. And that is, it's not always, in some cases, it's almost not possible because of the way some of these projects are done. And that can be very daunting, I guess, as you put together a project plan and you try to estimate costs and you try to keep costs reasonable. If it's a situation where you have to use your top talent to get the thing done and there's really, they're the limiting factor, that's a problem. But if you've got some of these kinds of tasks that are lower end, that are grunt work, then you can farm those out and it allows you to essentially scale your top end resources without putting a lot of extra work into it. You simply just take that work off of their plate and say, okay, this is stuff that doesn't take much knowledge or experience to do. So even if another resource is going to take longer to get it done, it takes that load off of your high end resources. So you have actually a couple of positives that come out of this kind of work that you can look at when you're either a manager or PM or something like that, or lead that's trying to figure out how to slice and dice this kind of work. Or you're working on something where you see that you've got, we'll say some challenging kinds of problems and you've also got a little bit of grunt work that you've got to tackle along the way. And that holds whether this is a sprint or a product that you're building, some role that you have on a team where there's certain responsibilities or job requirements that fall in your lap. It can be very useful to have a mix. Maybe the tedious stuff, maybe you start your day with that, or more likely maybe you end your day with it. So when you come in fresh in the morning, you tackle the harder stuff and then you set aside some time to work on these mindless kinds of tasks at the end of the day to let you sort of essentially wind it down and also to allow you to not get stuck doing one type of work or the other. Sometimes just mixing things up a little bit is in itself refreshing. And sometimes this is a way to effectively stay productive or in quotes we'll say productive while trying to work through a tougher problem. We've talked about this and there are a lot of people who say that when you get stuck, when you find yourself facing a really difficult problem, one of the best things to do is just walk away. Go for a walk, take a breather, just step away for a minute. Give your mind a rest. Don't make that your primary focus. And sometimes it will magically, you'll have other ways to, will appear to you and other paths to solve that problem. Sometimes the solution itself will come to you. But it's just a way to allow your brain to essentially get out of a rut. That may be that you're in a situation where getting up and taking a walk for 15 minutes is frowned upon, or at least you're not going to get kudos for it. But if you've got something like this, or you've got some sort of grunt work, mindless task, then maybe it's a good time to do that. This is early on, this is one of the things that I used was a, essentially my status. If I had to do a daily status report or something along those lines, send out a daily email of, hey, here's what we're working on, those kinds of things. This was that kind of work. I could disengage my brain for a little bit. It wasn't a completely mindless task, but at least it was something that was not as challenging. It allowed me to rest, it allowed me to think a little differently, it allowed me probably to access different areas of my brain. It made it that I could get that stuff done that generally speaking would be, I don't know, considered a burden or some extra time. I guess you can even do this with busy work when it's not really serving a purpose or solving a problem. However, you have this, if it's hopefully mindless kind of busy work, sometimes you mix that in as essentially breaks from your higher difficulty, more mentally taxing tasks and assignments. I think that a lot of people give grunt work that has sort of a bad name and a bad connotation. Some people will even say they'll be prima donnas or however you want to refer to it, but they'll essentially say that they're above that kind of work. Honestly, in a sense, sometimes they are. If you've got somebody that you're paying five times more than anybody else on the team, then you want to utilize that, the skillset and that knowledge that is why they have that higher pay rate and push the other stuff off to people that are not as expensive a resource to get it done. But there's also times where, like I said, it's good to keep things moving forward. You're a little more productive than when you walk away from your desk and yet you're not really sucking up your mental, you're not emptying your mental gas tank as much. So that brings us to the challenge of the week. Look at your, this is a scheduling kind of thing. I think this is a planning kind of challenge. Look at your work that you've got either in a regular basis, if you've got a weekly series of tasks that you do that's fairly more or less the same stuff each week, or if you've got, let's say, an upcoming sprint that you're working through or lists of tasks that you know are coming up. Take a look at it, and this is a complete list. I mean, it doesn't have to be, there's probably going to be things you can leave out of it, but the more thorough the list is, the better. Because what we're going to do with this challenge is we're going to take a look at the work and see if there is some grunt work in there. Is there some stuff that is going to be mentally very challenging and some stuff that just isn't as challenging but needs to get done? If it's busy work, so be it, but ideally you don't have any busy work, but there is work that you need to do that is not as big a drain. Then see if there's, moving forward, if there's a way that you can mix up, intermix those different types of work in a way that, maybe try it out. If you're more fresh in the morning, then do the harder stuff in the morning, and then take that less mentally taxing stuff and move it to the afternoon so that every day you do the hard work in the morning and the easier stuff in the afternoon. If you're an afternoon person, if that's when you're stronger, if you're sort of slow to start, then start your day with some of that, the grunt work. Try that for a week or two, probably, I'd say at least two weeks per however you lay it out, and see if it doesn't make you more productive. If it doesn't actually allow you to get things done a little faster by mixing it up. There is a cost. There's a cost to do that mental switch from one type of work to the other usually, so you don't want to switch every five minutes or something like that. But I think if you bundle it a little bit and do it in sections, particularly if you do it in certain sections of the day that are better suited to your natural rhythms, I think you may find yourself to become more productive and actually be less tired at the end of the day. So maybe even a longer day is possible, or when you get home at the end of the day you can actually enjoy your life a little better and you're not exhausted when you finally get back home. That being said, however your day goes, I hope this has been a benefit to you, and as always that you have yourself a great day, great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Developer Noor podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon, and other podcast venues, or visit our site at developernoor.com. Just a step forward a day is still progress, so let's keep moving forward together. There are two things I want to mention to help you get a little further along in your embracing of the content of Developer Noor. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developer Noor site. You can also find it on Amazon, search for Rob Brodhead, or Source Code of Happiness. You can get it on Kindle. If you're an Amazon Prime member, you can read it free. A lot of good information there. That'll be a lot easier than trying to dig through all of our past blog posts. The other thing is our Masterminds-mentor group. We meet roughly every other week. This is an opportunity to meet with some other people from a lot of different areas of IT. We have a presentation every time. We talk about some cool tools and features and things that we've come across, things that we've learned, things that you can use to advance your career today. Just shoot us an email at info at developernoor.com if you would like more information. Now go out there and have yourself a great one.