It Turns Out Code Is NOT The Bottleneck For Software Development?!

Transcript is auto-generated and may contain errors.

Hey folks, I am headed home from work. We're gonna go to experience devs for a topic. Um, I don't know. This one is probably obvious for a lot of people and maybe not obvious for a lot of other people. So, um, this Redditor was basically saying, "Has anyone else noticed that coding is not the bottleneck in terms of being able to ship?" and um I said it kind of feels like it's all the other activities um terms of like finding context and navigating different problems and stuff and like it's really not writing code that's the bottleneck and um I remember so I was just reading this and I'm thinking like really um that's what this that's what this is and uh I wasn't surprised because I mean by the comment because I was scrolling through the comments of course and uh every person's like dude like this has never this is never the bottleneck.

Code has never been the bottleneck ever. This isn't a new thing. And uh it got me thinking that like I don't know like you know I I I realize it's Reddit and there's going to be people that are kind of piling on and stuff and I don't I don't mean to be doing that even with my discussion of this but it's I think for those of us that have been working for at least a little while like you you quickly realize that like code is not code's not the bottleneck in a software development company. If only, right? This is another reason why like people talk about AI replacing software developers. It's like and and the metric for that is because it's writing code. Like dude, that was never the bottleneck. Great. Let it write the code. That's not it's not the problem we're trying to solve here.

There's a lot of other stuff going on. But I I realized that, you know, if someone wrote this on Reddit, there's going to be other people that don't actually realize this. And that's okay, right? Like there that's why I said when I was introducing this topic, like it's probably not a surprise for a lot of you and maybe for some people it totally is a surprise. And when I think about this, I think that how we set up, you know, in general, obviously a sweeping generalization here, but I feel like how we set up people to get into software development doesn't help with this, right? I I think about like even I was you know talking about this on a podcast recently but when I was going through school like I went to university and um I went for computer engineering and everything is just

like it was math it was physics it was chemistry it was you know low-level hardware um in terms of how like processors work and how memory works and then math and math and more math and then like a little bit of programming and then they release of the wild. And even that alone was setting me up to think that like everything I was going to be doing was like hyperfocused on like purely technical challenges. And don't get me wrong, we're building software. There's technical challenges, right? But there was no part of my schooling that even hinted at the fact that you're building software in Teams, you will have to think about navigating people problems. You're going to have to think about navigating code bases that are older than you. This is not happened to me necessarily, but um has happened to people I work with.

like, you know, it's it's not just go write code, go, you know, write some function that's going to go solve a problem, but so much of what we do sets people up to think this way. Think about even don't I'm going to get started on lead code. I was about to say, don't get me started, but I'm going to start myself. Um, lead code interview questions, right? you get people that that think that well I'm going to get asked these types of questions in my my coding round and um so like that's probably representative of of the real world and it's not but also lead code is like go go go write a function or a couple of functions to go solve this word problem that is like one of the most furthest removed types of things that you're doing in software engineering. If only if only it were go write a couple of functions to go solve this problem.

There's so many other things. And um like even on the on the purely technical side, it's it's way more than that. But um like I said, I don't think that we do a good job as a software development industry like getting people to think about this kind of stuff. And you know part of again part of my reason for thinking this is that from talking with people that are aspiring developers or junior developers that just got into the industry like it's a very consist I find it's a very consistent story obviously generalizing as I say this but it seems like this expectation is is purely around like how do like how do I optimize uh everything I'm doing to write code. I got to pass this person. This is so bad. This is so bad. I don't understand how people can drive so slow on the highway.

Like, it's it's almost dangerous. Sorry, I need one more sec here. Switch another lane. Um yeah. So like you know so many things we do set people up to think this way and uh and then as a result like a lot of their efforts go into optimizing or or focusing all their attention to optimize this pattern, right? like how do I just be better at coding programming? And um I think the unfortunate side effect of that is that so many other things get neglected. I'm trying to remember who I was talking to on my most recent podcast where this came up. Um God, that's not good cuz I'm forgetting. Um, but they were talking about their university experience and uh, oh, I think it was Ryan Barley is his name and Ryan was saying to me like, "Hey, here's what I was doing in school."

And he said something I think he said like, "Oh, when we, you know, we had this uh, you know, this course on testing." And I was like, "Hold on, man." Like I know like no one ever even talked about testing software in university. In 5 years of a computer engineering degree, no one talked about testing. How ridiculous is that? Right? In 5 years of a university degree, no one even talked about testing. And I can't possibly be surprised that we're not going to talk about, you know, how to work with other people, how to build software in teams, how to navigate legacy code bases, how to refactor code that's, you know, twice as old as you. Like it's just it's not a thing. How to work with stakeholders, right? working with different personality types, different experience levels, all these things, working across different teams, never gets taught.

And maybe like if you're watching this and you're like, actually, I went to school and and this awesome. I would love to hear that things are changing for the better that way. But I'm just kind of bringing this all up because to me it seems like there's there's overwhelming evidence to me that people are just not sort of uh taught that work is going to look like how it does. Everything is so much on the code part that that must be what we're hyper optimizing for. And I just I think that it kind of sets people up for a different expectation. So when I read this Reddit thread and I see someone going like, "Hey, is anyone else realized this?" Like again, I get why that seems silly to some people cuz some people have been doing it for a while and they're like, "Yeah, man." Like we learn this pretty quick, but maybe not, right?

Maybe that's just, you know, people's bias because they've they learned it years ago and now it seems like it was seems like it's quick in the grand scheme of things. But we don't know. I don't know how long this person's been in the industry. Maybe they said and I didn't read. But the point is that it just got me thinking that some people probably don't actually realize this. And I thought this would be important to talk through for two different reasons. One is that if you are more senior and you do know this and you're listening to what this person says and you're thinking, man, what an absolute idiot. How does this how does this dummy not know that? Like oh my god, these people. Like just a friendly reminder that all of us were junior at some point. And like I get it because it sounds funny to you because man, that was a big piece of metal on the road.

I almost hit that. Um, I get that it sounds funny to you based on the experience level you have now, but like you also don't have to be an about it. Like pretty easy, right? Um, and I say that as someone who literally had to challenge themselves when they were reading that because I looked at that and I said, "Really?" And I had to remind myself like, hey, like I don't know how long this person's been in the industry. I don't know. I to be honest, I would be quite shocked if they were in the industry for years and hadn't really come to this conclusion, but I'm not going to say like they're dumb for not knowing that or something. So anyway, I wanted to talk through it for that one reason is to remind more senior people, you know, like we were all junior, we all learned these things and that's okay.

And so the next time that you're feeling that way about some junior developer where you're like, how do you not know this? Like even if it's not this topic and it's something else, we all had to learn it at some point. Why is there so much debris on the road? What is going on today? The other reason I wanted to talk about it is because for the juniors to to remind you like yeah like you got lots to learn and that's cool. You're just starting out. You know that there should be no shame in that. Um even when people on the internet are shitty and saying like oh well you should know this blah blah blah. Um you know not I'm not saying all the comments on that thread were mean or anything like that. Um there's probably a couple that were a little condescending that way.

Um, but I think there was some helpful ones kind of saying like, "Yep, you know, actually this isn't like a new thing." So, right, they weren't they weren't saying like you're dumb for not realizing this, but they were they were saying, "Hey, this isn't a new trend, right? Like what you're observing is something that has been with us as software developers for a very long time and um and kind of like hinting at different reasons as to why." So, uh, I I wanted to be able to talk through this to give some more junior people that kind of window into like, hey, look, like I can rationalize why you would think that, you know, have this way of thinking before getting exposed to more industry time. It totally makes sense to me why, but I had to challenge myself to kind of look at it that way, and I'm glad I did.

Now, that might get you thinking like, well, so why is it like that? And uh I'm not actually sure I know the reason, but I I think that there's I don't know if it's like for me probably I would like boil it all down and oversimplify to just like communication challenges. Um honestly uh I don't have like stats or data to back that up but I think honestly most problems in software engineering come down to communication challenges unfortunately and um yeah like I'm trying to think like I'm thinking through like okay stakeholder interactions or like working with people on your team or um even you know timelines for things. Like I think a lot of stuff comes down to communication challenges. I I can't possibly sit here and say everything does, but I think a a large majority of things.

And in other videos where I've talked about communication challenges, one of the things that I like doing, I'm not going to repeat it for this, but I gave examples of how like you can have compounding effects of like very simple things that affect communication and they're very easy to stack and compound. And when you do that, it to me it seems a lot more obvious why we have so many communication challenges. So something to think about, right? But I I think a lot of the reason we have, you know, not um not the biggest bottleneck being code is like it's probably a lot of stuff that stems from communication. Someone gave an example and I think I can try to tie some of this together. They gave an example of like um collecting context, right? So, you know, before you even code anything, you might have to go through the legacy code.

You'll have to collect all the context, understand the situation, and one could argue that becomes a communication issue because like to go spend all the time collecting the right context. like was there no other way that we could have either documented some of this or communicated the context more clearly um so that someone doesn't have to go like start from from scratch building up a whole mental model around this right like by improving how we communicate and that might take different forms it would it would start to address some of that problem just one example right But it's uh I think a lot of things boil down to that. And it's interesting too cuz like when I say communication issues you can have um it's not just I have to yawn so bad. I could feel I was holding that one in and then it was just ready.

It's um it's not just as you're communicating like you are you're introducing noise and like uh distortion. I know that's probably a funny way to put that but it's not just like hey Mike as I'm communicating it's not effective. I think that can also include like not communicating enough right? It's not that how you communicate is necessarily bad, but it might be the frequency that you do it. It might be um the fact that you don't, right? Maybe there's situations where you're thinking like, hey, I'm communicating effectively. You know, I told my team something by the end of the week and it's like, hey, but that messaging actually needed like, you know, you should have done it at the beginning of the week whenever whatever happened. And that's more than a one-time thing. like maybe you should have done it twice in that first week and then followed up like a couple weeks later to like resolidify something.

I'm just making up, right? I don't have a scenario. But point being that you might think that you're doing a good job because what your message and your communication is genuinely is effective, but you're not doing it enough or in maybe in some cases you're just not communicating things that need to be communicated. And I think genuinely I think that a lot of this um you know is stuff that that really causes bottlenecks, right? Like some super simple examples. You have a design doc. You need the team to review. Okay, so you put this design dock together. Now you need the team to read it and sign off on it. Okay, you could think about probably 10 different ways this could go off the top of your head, but like you make the dock and then you um you share the word document and that

gets emailed to people and then you wait for a week hoping people are going to read it and then you remember you work at Microsoft and everyone gets 10,000 emails a day and then are you shocked that no one saw the email invite to go review the doc? Right? Like there's there's so many ways that this can go. And the side effect of that is that now you have your design dog process is your bottleneck. Right? It took a week for even people to see it. And by the time people reviewed it and you had a conversation about it, it was another week. Wasted two weeks. Two weeks that that wasn't code getting written. And by the time you write the code, you do it in a couple days or something. I'm just making up, right? But now think about your code review. Similar thing. You put the review up, but you're not you don't tell anyone cuz they should get the notification, right?

They should. Or you put it in the team the team chat, sorry. And um one person sees it, but you need two other people to sign off on it or something and they they were busy that day, so they didn't get to it. And then you're like, well, I already sent it. I'm just I'm not going to follow up. But s like make up whatever scenario you want here. The point is that design docks and code reviews are really simple examples of of like ineffective communication becoming a ridiculous bottleneck for something that maybe is way more simple. And um yes, the code review did require that you wrote code to get reviewed, but the point is that the code review itself and the design doc like those weren't necessarily coding being the bottleneck. You're waiting for a partner team to go finish some work for your team to deliver that as a dependency.

Code for you is not the bottleneck. It's waiting on other people. you're trying to find the right um on call engineer from another team, but your organization's too big and you can't really figure out how to look up the team that owns the service that's having this issue. Okay. Um takes you, you know, your whole on call shift. So, you're somewhere like I don't know, just making stuff up again. You're you're over 12 hours into like hunting and trying to solve problems. And uh turns out you finally find someone and they're like, "Oh, code fix is like one line of code. Let me get that done for you. Maybe it's a big one, right? I don't know. I'm just giving contrived examples, but you could you could paint that the other direction, I suppose. But genu like generally it's not um it's not code that is the bottleneck.

So wanted to wanted to talk through that. I hope that's helpful for some folks. maybe just different perspective to think through things. And um a friendly reminder that if you have questions around software engineering, career progression, that kind of stuff you want answered, leave them below in the comments or you can go to codecommute.com, submit your questions anonymously. Um Devleer is my main YouTube channel, so please check that out. Uh, I've started announcing that I have two other YouTube channels and I will move my Devleer content across those. So, Devleer will become the C and.NET and general programming tutorials. I will have the Devleer podcast as its own channel. That's where I will be doing my live streams from now on after this evening because I'm driving back to do a live stream right now. And then I will have a separate resume review channel and I'll probably include some interviewing tips and stuff like that there as well.

So, um, more on that, but if you check out my other channel, Dev Leader, you'll see over time that that content will get moved over and, uh, you can check it out from there. So, thank you so much for watching. I will see you in the next one. Take care.