I'm A Senior Software Engineer And Most Of My Time Is Writing Docs

Transcript is auto-generated and may contain errors.

Hey folks, we are going to experience devs subreddit for today's topic will be a few topics today in general because we'll do multiple videos today, but this one is about dock writing as a senior and uh the author is essentially writing that as a senior developer, they're finding that they're doing a lot of dock writing like that's most of their time and um they kind of said in the past three their examples like in the past 3 weeks or so they've done like three to five trivial like code changes and saying like they're you know they're finding this this is really not enjoyable and uh kind of looking for people's thoughts on this. There's a there's more in the post but like high level kind of acknowledging like hey look I get it as a senior I'll be spending more time doing things that aren't directly coding but like seems like seems like something's a little off here.

Uh, so then I was reading through some of the comments. Um, I kind of feel like I I based on what I was reading, I think that people are having a relatively aligned experience sharing things like kind of what I've already said where it's like, hey, you know, as someone who's more senior, yeah, there's less time writing code. But I I think what was more surprising for me is sort of the the extreme of it and like and that's kind of seeming normal. So, you know, I mean, someone jumped in and they were like, well, I'm a staff engineer and like if I'm writing if I'm writing any code, then I'm I'm the bottleneck. And I'm like, I I don't I actually don't know about that. Uh, like to me that doesn't actually make sense because like if I had principal engineers on my team not writing code, we'd have a really big problem.

Um, but like at the same time, do I think that the principles that I have on my team are spending more time doing design work? Like the answer is yes. Like 100% yes. Um, so that's why I'm saying like the extreme nature of what I was seeing in some of the comments is kind of like kind of weird. Um, you know, some people were acknowledging what the the author was saying and then again not really offering um sort of any in between like yes like that is expected. It's like but but is it because if you're a senior engineer and all that you're doing is dock writing and then trivial PRs like who is actually doing the complex coding because in my like you know if we kind of tear out developers it's like does that mean like the juniors or the mid levels are

doing all of the hard coding because even at the senior level you're not doing that and certainly that would mean staff, principal or anything above is like is also by definition than not like something seems a little bit off about that to me personally. Um, so I wanted to say that like I do personally agree that yeah, as you become more and more senior, there's going to be less the the proportion of your time that's spent coding is is I feel like almost by definition going to be less because you have other responsibilities being introduced that are not coding, right? Just to give you a very simple example is like even even at more junior levels when people start having this expectation of you to be like mentoring others around you, helping grow others around you, like kind of getting into a senior position that becomes a bit more of an expectation of you.

Like that is not coding and that is some type of time commitment, right? doing design and writing docs for that is not coding and there is a higher expectation of that. So like there are more things that get introduced that are not coding. Being able to work across teams, get people bought into things, right? Making sure that if you're trying to build stuff and you need other teams to collaborate with, again, that is not strictly coding like that. that's going to be meetings and conversations to like to align on those things. It's not coding. So, there will be more and more things that truly just aren't coding and that's that is normal. Um, I think when I read this post and and maybe it's just how I read it, but my bigger sort of concern is like is like it's almost the proportions of things

and makes me a little bit nervous because I even with my own teams I've seen this kind of thing happen where you know it's it is good that I have an engineer that's putting a dog together like yes thank you for you know putting thought ahead of time to design things get people bought into what we're trying to create getting their input making adjustments to that but like I think it becomes problematic when the back and forth on this kind of stuff is so long when we're talking about like taking a month to go write a document I mean depending on the the scope of the work, but that's a month of of planning. So like to take one month of planning things to me seems like a really big inefficiency. And that's not saying, oh, the engineer who's organizing it must be bad, right? I I I to me it kind of points to something more systematically that seems off.

Right? Could it be like just as an example, could it be all on the engineer organizing it? Sure. You know, they're they're maybe distracted doing other things. Maybe they have a really difficult time organizing thoughts in a document or interpreting other people's feedback. Like, sure, that's entirely in the realm of possibility. I don't think it's the most likely that it's 100%, you know, the the writer sort of uh like fault air quotes. Um but I think that points to like much larger inefficiencies and is it like are we trying to build something where we don't actually understand what the goals are? Do we are people going into this so unaligned that putting a technical doc together to build out the architecture is already the wrong phase, right?

Like should we have done like a different meeting where we got together with a very simple doc or you know couple of slides just to like get people on the same page for what we're even talking about because maybe when people are reading through an architectural design they're like I can't I can't move forward on this because the things you're describing in here are like fundamentally I don't I'm not even aligned with what we're trying to do. we might need to have taken a step like maybe for next time or something we take a step back and start getting alignment at an earlier phase like I'm wondering if the these are things that are are people are running into um I have also seen that people participating in like feedback on documents like this sort of systematic like pattern of inefficiency I guess is I'm just going to make up an example, right?

Like you have one person who's writing the dock and then you have five other engineers that are participating just to make up numbers, right? Um and you have two two of those five engineers are very responsive with giving feedback. You know, they're reading the document and you know, they they leave comments right away and like all good. So, like, thank you so much for your feedback. Excellent. From like day one, you when you shared it out with people, you can already work on iterating through some of that feedback. That's great. By the way, I I left out maybe there was a a meeting to go like walk through it together or something. Maybe you're starting asynchronous. I'm not prescribing anything in this example, but you get some feedback from two people pretty quick.

But then you have three people out of the five that we're discussing where um it takes, you know, one person two days to get back to it, one person 3 days, and one person by the end of the week cuz you gave it to them on a Monday. So by Friday you have someone leaving feedback. like you you have lost and you can't address all the feedback instantly, but you have you've been pushed out one week because of that last person leaving feedback. Okay. So, you're like, "All right." Like on end of day Friday or or Monday, you're addressing that last person's feedback and then even the next week it takes them a week to get back to your stuff. So, like any time that you're trying to address this person's feedback, you're getting pushed out an entire week on the iteration. And I have seen this type of thing just completely destroy momentum on things like who who do we point the finger at, right?

I don't think that's fair. I don't think that in this even this example it's like a single person's fault. Like, do you blame the person that's taking a week to respond? Like, I don't know, man. Like, what are their other priorities? Are they maybe that that's that document's such a low priority on their list of things to do because genuinely they're they're not really involved in that thing. Maybe they're like actively working through some high priority like I don't know, they're like work they're on call and they're like doing incident related work. So, they're not even focused on anything else. You know, I'm just making up random examples. Like, should should the the dock writer be like, "Look, like maybe it doesn't make sense to include this person in this capacity." Like, you know, maybe it's more like heads up, I'm writing this thing and like we can't let you block the entire development of whatever's going on, right?

Like, maybe that's on the dog rider to go do that. Um, I don't know. So, I don't I don't think it's fair just to like blanket statement like blame people for things, but I think we have to understand them situationally. Point is that um I I have seen firsthand where we have what seems like it should be a straightforward thing just like get completely ballooned out of proportion for like timelines. And um I I don't know. I feel like there's a lot of missed opportunity that comes up from this. And at least in my experience, it typically is something like this last example where it's like, you know, trying to include someone and like they happen to be behind. Uh I like I rarely find like this is a malicious thing. Um this is not specific to dock writing by the way. Okay, that's what this topic is from from Reddit.

But like this example I'm walking through applies to to pull requests and code reviews as well, right? Like you get to a standup and it's like, hey, like you know, people are doing their updates and they're like, well, I am blocked on this and I'm like waiting for so and so to like to put their review up. And it's like, well, what do you mean? Like, have you talked to them? And it's like, "Yeah, I've actually sent so and so like three messages this past week and like they're not responding." And it's like, "Whoa, okay." Like, so we've gone we've got a whole week where you've been blocked on just not having the feedback on your poll request. Like, oh Like, um, and it's not for them lack of trying, right?

But uh you know lesson there is like maybe at some point within the week is like finding an opportunity to escalate it to to me as the manager where I can jump in and try to help and see uh maybe it's a matter of like again maybe that person's truly unavailable. And if we dig in a little bit, it's like look, like if this person's not going to be able to respond, like we need to get them to to delegate to someone else to review, right? That I'm giving examples here and I I want to acknowledge that like we don't trivially just find ways around things like this. Like usually it's like um you know in the example I just gave it's like maybe yeah maybe literally you can't delegate it to someone trivially like that because the thing that you're working on you really need this person's feedback because you know they had a lot of concerns originally.

Um, like just to give you an example, I have um a code review I was just asked to do and I'm going to do it, but the feedback on this review prior was like, "This design is too complicated. Go follow this other thing that I have. Incorporate that." Which I think, you know, fair feedback. That's all fine and dandy. Um, but now that person's saying, "Well, Nick, I like I'm not available. Like, you need to review it." And I'm happy to go do the code review, but my biggest concern is like if I read that and I'm okay with it, like, are they are they telling me like, "I trust you because I don't want to go read through it, be okay with it, and then afterwards have them be like, "Well, what the hell?" like that's a that's a weird spot to be in.

So, uh the way I look at it though is like if I read through that code, you know, I I am basically taking that as a stance of like I'm not available to do this. I don't want to keep this blocked. So, like I'm I'm delegating my sign off to you on this. And if that's the case, then great. Like awesome. We'll move forward. Um unless you know I review it and I'm like, "Oh crap." Like no. But, you know, it's it's tricky. Um, so it's not I don't want like talking about this stuff and making it sound like trivial where oh, just quite simply you just talk to this other person and everything works like it's not not always like that. But yeah, dog writing is a bigger part um you know as you're as you're more a senior. I I also have like a like admittedly a bias against uh dock writing.

And I don't mean that to sound like I think that it's not worth it or I think there's no value. Um I much prefer a bias for conversation, a bias for action. Um, and I I think my threshold for what I want to see a dock written for is thus higher. So I think if I compare myself maybe with some other people they're like oh it's you know a type of change with this amount of complexity like write a dock for it. And in my mind I'm like I don't like why like why why go spend more time doing that? Well it's like it's only you know a short dock or whatever. I'm like, "Yeah, but we've all seen like you can say it's a simple code review and we can go through back to the example of like takes someone a week to get

the sign off on it from one person uh or to get feedback and then it's another whole week on top of that to get their sign off." Like I think that when we introduce steps like this, you can balloon out time like crazy. Now, don't get me wrong, like the the intention of the document is to get alignment on things, but like that that is a tool to do that. I think that you can also get alignment in different ways. I just think that my threshold for what I want to see documented and go back and forth on in like a in a written way is uh my threshold's much higher. And this probably again where the bias I'm assuming where this bias comes from for me is like from working in a startup for a long time and being like we got to just get going.

um and like leaning into that more and more and I work in big tech now and I think the bias is a lot more for like let's get it written down but um it's like is one of those right and one of those is wrong like no but the you know the truth or the the happy spot is probably somewhere in between those so yeah I I don't I think every decision we make needs a needs a formal document for it. It just feels like it's overkill. And I'm not saying that's what happens either, but I'm just saying like sometimes when I see people suggesting documents for things, I'm like I don't know. Like do you are you you want someone to write it down because it's not clear to you? If so, like can we just talk about it?

Like can you and that way you can basically get the the the the the floor like the time with the person to be able to go back and forth and like you know spending half an hour synchronously on something to get clarity record the the the meeting get co-pilot or whatever tools you use to go like summarize it um so that you have you have some written record of it uh so you're not losing at like is that going to be overall more effective in terms of a timeline? Like yes, it meant 30 minutes of your time synchronously, 30 minutes of this person's time, but it's not pushing things out a whole week. I just think that there's there's middle grounds to these things and where that middle ground is for me is I I feel like is a is a different spot compared to some people.

But um overall, just cuz I'm getting to CrossFit here, I I do think that you'll spend more and more time on non-coding things as you become more senior. But I do caution people if it feels like you're just like you're just doing this other work and there is no time to code. uh like there's like there's architects that are still writing code, you know, like principal level architects that are still writing code like regularly. I don't know, especially for this person saying like that's an interest of theirs like they're not get they're not engaged by not doing it. Like another reason where maybe there's something going going wonky there. But thanks for watching. If you have questions you want answered, leave below in the comments. And of course, if you want to be anonymous, go to codemute.com, submit questions that way, and I'm happy to make a video response for you because I enjoy this kind of thing.

So, take care.