If we only code 20% of the time, how do we get better?

Transcript is auto-generated and may contain errors.

Hey folks, going to the comments for this one. This is from GPL Taylor and this reads, "If we live in a world where we only code 20% of the time, how can we get better? Practice makes perfect but only for tight feedback loops. If we spend all day in meetings, we may end up writing subpar code due to skill issues." That's a question. Um, so let's talk about this. Um I think this is an interesting question but the way it's framed I think is kind of making some assumptions. So um yeah, like if as even a junior developer, let's say if you were only coding 20% of the time, it's going to take you like in your day job, it's going to take you a lot longer to be able to build up skills, right? Like the whole point or what this question is implying is that if we are supposed to be spending more time writing software, but we spend more time in meetings, aren't we actually not practicing the writing software part?

And so the answer is yes, that's accurate. But um I think that you know if you're starting out somewhere as a junior developer and most of your time like is in meetings or something and 20% of your time is just building software, it's probably not a good spot to be in. Probably not uh for that level. And the reason why is that a lot of the stuff that you're working on as a more junior developer should be mostly well understood. mostly. So what I mean by that is it's not um ambiguous. It's not a nebulous problem to go solve most of the time and that's because you are working in a team perhaps with more senior people and they are giving you level appropriate work to work through. That's not going to be the case everywhere. I understand what I'm saying. I have worked at a startup before.

I am currently at big tech. But most of the time this is how teams try to structure work for more junior people. It's of course possible. You could be the only developer and be junior and then everything I'm saying doesn't seem to make sense. But ideally, right, as a more junior person, you are absolutely spending more of your time writing code or at least going through code and like working with code. When I say writing, I just mean like at least spending time navigating the codebase and trying to work on on solutions. As you get more senior, there are going to be other types of work that you're doing that is not just the implementation. So everything I was just describing was like writing code or going through the codebase to read about things and navigate stuff. Um when you're more and more senior, you spend more time doing other things, but it should still be part of the software development life cycle.

So that might be creating uh designs to be reviewed. That might be meeting with other stakeholders to understand requirements. That might be part of planning conversations. Could be part of strategy conversations. It could be spending more time reviewing other people's code. Like you're doing other things that are in fact level appropriate, but less time writing code. So, the tricky thing with answering this question is like it's almost like I can't tell what the person asking the question is assuming about the setup of the question. It's kind of weird. Um, so yeah, like the the very short answer is of course if you only spend 20% of your time actually doing the software development part, then sure, it's going to be um, you know, a a lot more difficult to build or create quality software. But I think the reality is that as you become more senior, you do spend less time on the keyboard writing code.

Sort of the nature of the different types of things that you're involved in. But what's interesting about that is that by that point in time, you've likely built up a lot of technical skills. So, I don't have like a graph and I don't have data to show this, but like I would suspect that your learning curve as a more junior person, like you're going to be more like a sponge absorbing data and information and learning about what you're doing and a lot on the technical side. As you're more and more senior, it's not like you're not learning anything, but you are more solidifying the things you know. You might have certain things that you're kind of exploring, but always learning for sure, but you're going to be doing more of these other things that aren't just coding. So, yes, like yes, I think practice makes perfect.

Um, yes, you need to still spend time writing code and doing that. Um, but I I don't I don't think that spend like as a more senior person spending time outside of writing code on other things related to software development is is wrong or bad or going to be an issue. I think it's actually required. Um, so I have a difficult time answering this because I don't know the direction that they are hoping to have information about. So part of me is like okay do we want to look at how we get more time back because I think that's part of it. So you know if you are working somewhere if most of your time is in meetings like that should be a conversation. It doesn't matter what level you're at that should be a conversation. It's a little bit different if your role is different.

So like as an engineering manager, most of my time is meetings because I am working with people. As an engineering manager, I am a people leader. I am a people manager. I need to spend time working with people on stuff. Doesn't mean I don't have things that I'm doing on my own, but a lot of what I do is working with other people. So it's a little bit different for me. Um you might have a a product manager might look, you know, very different from an individual contributor software developer. They might also need to have a lot of meetings and conversations with stakeholders. Perhaps the same thing with a project manager. But for a software engineer, there needs to be some time carved out for working on things like on your own. And if you don't have that time, I would absolutely try to raise awareness.

This could be that your team has been trying to put different processes in place to help, you know, help out, right? Like maybe I'm just going to make some of these up. Maybe you have a daily standup and that's supposed to help with raising visibility, but we've all kind of seen and heard about these standups where it's like it's supposed to be 10 minutes, but they take an hour and a half and they're every day. Like, you should be speaking up about how to fix that, how to make that better, right? Maybe you have information sharing sessions. Like our team currently at Microsoft, we are we're investing more and more into trying to do knowledge sharing and learning opportunities. But I could imagine that if we stay on this path without giving it any consideration, you could overindex on it and then it's like every day there's a meeting that's like a learning opportunity.

But that doesn't actually make a lot of sense, right? That might disrupt people's flow time or their time to actually work on things. So they're recorded, right? You can follow up and go watch that later when it makes more sense for you, when your schedule is free to go do so. So, I think that we need to be aware of what's going on. We need to understand that if we're having these meetings where they're taking up all of our time, we have to speak up about them. Like, as an engineering manager, my goal is to make sure that people are not put into situations like that, but I also need that feedback from people if they're like, "Hey, you might not think that's a lot, but I'm completely overwhelmed." I've had the opposite where I'm like, "Hey, sorry. Like, we got to do this meeting, talk about this." And people are like, "That's cool." Oh, like my calendar is like basically free all week.

Like awesome news, right? Like that means I know that you can get your work done focused. So if you're finding that that's not the case, you need to raise awareness about it. Um, and that might be a team culture kind of thing. Maybe other people are feeling that no one's speaking up. Maybe people are trying to but nothing's changing, right? I'm not saying it's trivial, but at least you need to try to speak up to get some of that time back. Same thing if you have meetings that don't have clear agendas. Respond to the person that organized it. Say, "Hey, I see that I'm invited to this. Number one, I don't know why I'm invited. Number two, I can't really tell what the goal of the meeting is." Like, you could you could be very transparent and say, "I need, you know, I need to keep my my schedule clear so I have some time to focus on stuff.

Can you tell me why I am needed?" It doesn't have to be, you know, super defensive. You can find your own wording for it. You don't have to attack the other person, but if you genuinely don't understand the value of the meeting, you can express that and just say, "Hey, could you clarify, right? They might just be trying to include people so they have visibility." Great. Cool. You're not needed there, but you can follow up or get the summary from co-pilot or whatever AI tool. Cool. But try to find ways to get that time back because as you are more and more senior, you will be spending more time outside of just writing code. Um personally I don't think that let me see how to phrase this. I mentioned that as you know as a software developer even as when you're more senior you will be spending time still learning.

Of course software engineering is a field where in my opinion if you are not interested in like constantly learning new things it's gonna feel like there's a lot of friction. It's just going to feel that way because things are always changing and evolving. So, you will always need to have time for that. You will always be learning. But I think that once you have a lot of these foundational skills, I kind of think of it's almost like the gym where it's like, sure, like, you know, you're you're getting bigger and stronger and like you're putting in all this time, but at some point you can put in less effort to maintain those things. Maybe not at the absolute peak of your performance, but you can put in significantly less time and still maintain.

And for example, like if I if I were a junior person and I took, you know, a month off from writing C, for me to go back into writing C, I would be like, oh man, like it's going to feel like it's all new. But I've been writing in C for like over a decade. If I at this point, if I took six months off from writing C#, it's going to be okay when I go back to writing C. It's ingrained up here. So, I think that there's this opportunity where we don't need to spend as much time hands on with certain things and we have that like sort of muscle memory. Um, we have these things that are sort of ingrained. Um, it's not going to be perfect.

you might have a little bit of uh you know catch up to do but I don't know I think the reality is that you need less time on that stuff to maintain it and that means that you have more time for learning different things or more time for these other types of activities like working with stakeholders design documents code reviews this other type of stuff that you're doing more as a senior developer so um yeah I think that's what I have to say about this one Like I said, I don't know maybe the direction that they were hoping this would go, but um I I don't know. Like they say subpar code due to skill issues. I think that if you're starting off as a junior and kind of continuing on this path where you're not given time to actually go work on building software, yeah, probably over time you're going to have some skill issues or you're going to feel like you're progressing slower because you're not building up that technical muscle.

But um I think that as a more senior person, you are probably expected to be spending time on those other things as well. The technical stuff is just sort of um going to be expected to be where it's at and continue to improve at at some pace. But anyway, I hope that helps. I realize it's kind of all over the place, but that's my take on that. And if you're interested in having your questions answered, leave them below in the comments or go to codecute.com. You can submit your question anonymously. And a friendly reminder, my main channel is devleader. That's where I have my car.net and other programming tutorials. Go check that out. I am splitting my content out from that channel into two other channels. There is a podcast and live stream channel that's called the Devleer podcast. You can go check that out. That's uh an AMA style live stream and the podcast are interviews with other software engineers.

you get to hear about their career journeys and some interesting things that they're doing in their careers. And the other channel is Dev Leader Path to Tech and that's where I do resume reviews for free and I will be putting up videos with interview recommendations and guidance and that kind of stuff for helping you get into tech. So, I hope you found that at least somewhat interesting and I will see you next time. Take care.