HELP! These Junior Devs SUCK At Designing Software!

Transcript is auto-generated and may contain errors.

All right, so it turns out that all of the junior engineers absolutely suck at designing things and what are we going to do about it? Okay, so no, there was a post on experienced dev subreddit and the person was asking about like, hey, you know, coming into a larger tech company and realizing that uh there's a bit of a gap with like uh juniors and designing things and like how do I how do I encourage the junior developers to to sort of get into this rhythm? Um, I wanted to talk through that. Uh, I don't know all the details about this person. I don't think it's necessarily super important to talk about the specifics of their situation, but I do think it's important to talk about how we can kind of encourage this kind of stuff and and uh kind of consider the context as well.

I'm going to channel my Derek Com Martin of code opinion who always says context is king because I think that it is pretty relevant here. Okay. So I have personally noticed like going from a startup to big tech there is a lot more emphasis on design upfront design in big tech uh closer like it's not like it goes hand in hand necessarily but um like there's a lot of stuff that feels closer to like waterfall and you know so design docks upfront reviews uh depending on the scope of whatever the project is like can feel pretty heavy. heavy-handed up front and that's kind of like the flow of things. And it's a little bit jarring coming from a place where it's not like we didn't do designs and stuff like that, but a lot of the time it was more like whiteboarding conversations and being like, "Cool, like we all feel like we're on the same page.

Yeah, like take a few pictures of the of what we're thinking we're going to go build and then someone goes off and and builds it." And so it's just a lot more formal, it seems. in uh in big tech and at least Microsoft that's my experience I can't speak for all of big tech now like is that better worse and it's like I don't think the answer is better or worse I think it's just different and different because of the nature of like where things are at right so especially in big tech companies like you might have many more teams many more people that are interested in that information um when you're a smaller company you might not have like a dedicated privacy and security team and some other type of team and like you actually really need to make sure that you're getting them like to review documentation or you're going to have like a privacy or security audit later and you want to make sure you can bring the architectural document along.

Like there's all these situations where I feel like it might be a lot more convenient to have prepped some type of formal documentation. Part of me is like a little like irked by that where I'm like, "Oh man, like we spend so much time on it." But that's because I think I'm probably a lot more, I don't know, aligned with like startup culture and just like moving faster personally, but I see the, you know, I see the value in it. So this person's kind of coming into a spot and they're like, "Hey, look, like I am the more experienced developer compared to a bunch of people on the team and like seems like there isn't a culture of doing it and I want to like you know help the juniors like understand the value of doing it." And so, you know, I haven't, if you're

watching this, I haven't yet thought of the title of this video, but I recently posted one uh and I basically said like, you know, junior engineers aren't getting it or whatever. And uh it seemed to do pretty well cuz it was I guess guess that's kind of like clickbait, but it's not really clickbait because that was really how the person in the Reddit post was kind of looking at it, right? And so, I'm going to do the same thing. I'll try to come up with a good title, but I hope that folks realize I'm not actually like picking on juniors. It's going to be quite the opposite. I had one person that left a comment on the other video and they're like, "I didn't even watch the video. I'm just responding to the title." And I'm like, "Probably shouldn't do that because the whole video was like me explaining the other perspective, not taking the side of the person on Reddit." It's going to be a similar thing here.

Not that this person's necessarily, you know, complaining about the juniors, but like it's an opportunity to help coach and educate them on on things that they might not be familiar with. Now, just to wrap up the context stuff, right? Like I think like if we don't fully know the context or I don't fully know the context of the working environment that you're in and you're listening to this like I'm not sitting here telling you like no the best thing that we need to do is to tell every junior engineer they must write super detailed specs and do you know two week reviews and you know whatever like security and privacy audits and all this stuff cuz like depending on your work environment if you were to do that like by the time you're done it. You might have completely just missed the opportunity to be delivering features and value to customers.

And if everyone on the team was doing that, maybe your agility in terms of shipping value is so low that like company just doesn't survive, right? It's like I'm not saying those things aren't valuable, but the amount of time and effort that goes into them in one situation versus another, it could look dramatically different. Okay? So you need to be thinking about like the environment in which you're working. I don't know that you do. And as I talk through this, my only goal is just to give you some different things to think about so that you can go make informed decisions, right? That's the same thing with like all my videos. It's like I'm not here to tell you like here's my perspective and it's the right answer. Here's my perspective based on my lived experiences. And I'm hoping that you can pull pieces away from that.

Even if everything I say you hate, just as an example, if you're like, "That doesn't make sense. I don't like it. I don't like it. I don't like it." At least you've heard a different perspective. And all that I want out of this is that when you're going forward making decisions on things that you feel more informed. That's all. Right. And I that's the same thing that I would want with anyone that I work with is like we don't have to agree on everything. We don't have to have the same opinion. But my goal is just to make sure that I can provide information and perspective and you know if you're the decision maker on something then I just want to give you whatever I can to help and trust that you make an awesome decision. Lots of smart people, right? I'm not I'm not making every decision.

So if you are in like an environment where you do need to be moving a lot faster, it might be that like how you approach designs and you know architectural documents and stuff like that, maybe that does look a lot different. Uh like from my personal experience, I would just recommend like at a minimum getting some people together and going through and like whiteboarding stuff or if you're remote like using you know some some type of tooling where you can kind of draw out like highle block diagrams and I don't I don't give a if it's UML or whatever just like draw like talk about the system talk about how these things interact like I think that stuff is super important to go through the conversation because that's the brainstorming that's the think tank. That's where you're getting, in my opinion, like almost all of the value is those conversations, right?

Like, you know, you're seeing it come together one way, someone's seeing it maybe similar but different. You get these things put down, you start to see where the strengths and weaknesses are. Someone else might call out a gap in both of your designs. Like, like going through this kind of stuff, I think personally is the most valuable part. Now, if you're not doing formal documentation in this context, like cool, like get it whiteboarded or drawn or whatever, just get a digital snapshot of it, right? There's and there's enough like AI tools and stuff now that if you were just recording your conversation as you were talking through it, you could get like an AI summary, like you can basically what I'm saying is you can try to do as low um what's the uh the phrase or word I want to say? um like as informal as possible, right?

Remove as much red tape as you can. Do it as informally as possible. Like the the most informal way I'm thinking is like literally get into a meet if you're in person, get into a meeting room, set up a laptop in there, just start recording a meeting like locally and then whiteboard stuff, take some pictures at the end. What is this? Oh, it's a Lotus. That's a very nice car. I would like one not in that color. He was checking out the GT. That's right. He's like, "What's up?" His car is pretty cool though. Um yeah, do the low like most informal approach you possibly can. um get some pictures after and then like AI summarize, right? And then go through the AI summary, touch it up or whatever is not correct. Now you have like at least something documented from the conversation, right? So like how do you get juniors to buy into that?

Like it's kind of like explaining the value and demonstrating the value of doing that. So again like hey like as I was just talking through it I was calling out some of the benefits of doing this are like you get other perspective right that's number one number two it's like informing other people okay maybe you don't need the entire team brought in on a design depending on how many people there are but what could be really good is like you can explain to people that if you know two or three people are designing something together whatever uh when you're all done figuring out what you want to do like maybe you should be presenting to the rest of the team so that they're informed. Why is that valuable, right? So they can learn or there might be some opportunities where someone's like, "Wait a second, we are or someone else is already building something that's kind of like that." So you you get these like earlier feedback loops, right?

There's there's so many like I'm just you know spitballing these random thoughts on this but the point is that you can do a similar thing with more junior engineers that maybe have not gone through some of these things to explain like having a lot of these early opportunities to collaborate to get different perspective is so valuable especially if you can keep the formality low because then the barrier to doing it is so much lower, right? I can literally try to Oh, buddy, that's not how you do that. Um, trying to cut around all these cars. Uh I can literally imagine myself trying to tell my formal self like hey like you know what you should be doing is getting a one-pager document put together sending that out waiting for the feedback then going and doing like a you know in-depth design document and then like sending that out for asynchronous review and then collecting the comments and then holding a meeting for the reviewers to kind of chat through it.

And then once you have that all done, you've polished up the document, now you're going to go present it to the rest of the team. Like my formal self would have been like, you're absolutely out of your mind. Like by the time you've done that, I've shipped like 10 things. Like we're not doing that. But it's because the context is now different, right? There are a lot of things that in in Microsoft, at least in the teams I work in, we do move slower. It doesn't mean that we move slow because like we suck at what we're doing or like because all the tools suck or because because Bill Gates like everyone seems to hate Bill Gates and Microsoft. I I don't know. Um Bill Gates doesn't work there. Uh just as a heads up, but we can we can still blame him for everything, right?

So we go slower because it's more methodical and there's different like I was saying there's different reasons why we need to do that and how you approach helping juniors understand that is also going to look different right so to give you an example I kind of hinted at like security and privacy earlier okay like this is the kind of stuff that like when your company is really small it's not that it's not important Buddy, it doesn't help if you tailgate me. You can keep trying. That's very stupid. Oh, BMW driver though. That makes a lot of sense. Um by the lack of signal and stupid driving. Uh I also have a BMW, so I understand. It's not that privacy and security is not important. It's that the amount of time and effort and what that looks like and the amount of other stakeholders involved looks different.

The amount of users and the surface area of users looks different, right? Um you might have like Microsoft will have customers that are like government agencies or they're like literally they have contracts with different you know uh representatives for countries in different parts of the world and they're like we need these guarantees around our data right and you might just be an app and you're like I don't know man like we're selling stuff and like we will address that problem when when it comes up. So you don't need like your company doesn't have a privacy team of 100 people. It doesn't have a security team with like red and blue teams and like of like 300 people that are like pentesting constantly and like you don't have that. So the amount of formality that goes into those types of things might make zero sense. When you're at a larger company and you do have things like that, this is where you need to be able to help the other people understand why that's important.

And it's okay if they don't know because they haven't been exposed to it, right? Like I'm being completely transparent about this. Like when I came to Microsoft, I was eight years out of university. I had two years of work experience from internships before that. So like 10 years working at companies and the amount of like focus on data and data access is like something that's just a whole other like level above anything I've ever had to consider. And that's saying something because I used to work in digital forensics and we had like users that were on airgapped machines like they were terrified about, you know, the data that they had for their cases being accessible or anything else. Same kind of people that need a hash for absolutely everything so that they can guarantee that no bit has changed at any point. Like they were extreme about their data.

But even like at Microsoft, it's an entirely different level because the scale. So these are things that I even had to like rationalize for myself and say like that is why this is valuable. That is why doing this more upfront is valuable. And that means that like when I understand that and I can think through that, I need to make sure that I can help educate other people on the team for it. Right? I have lots of very like motivated engineers on the team. There's I have uh Microsoft historically have had a lot of uh more junior to mid-level engineers and um you know it's great. They're they're excited. They're ready to learn. They're ready to like you know they they want to get into things and like that's cool. And there are times where it's like hey it's not it's not just about going faster here.

like we actually should pump the brakes a little bit because if we pump the brakes now and talk about these things now, we can save ourselves a ton of headaches later, right? So, um I was just talking about privacy and security, but like you know, one of the big projects I was leading earlier in the year was around resiliency. So, there's lots of lessons learned from that. So now it's a lot more I don't know like top of mind when people are building things. It's like hey wait like there's a very obvious gap here and it's only obvious because we spent so much time and effort like trying to you know address similar things, right? It was not obvious before. That's why we had gaps we had to go close. But now it's like okay like instead of just trying to rush to get this done like we have to go back to the drawing board on some of this.

We should talk through it a little bit more. Thanks for letting me in, pal. You're a true friend. Um, so yeah, like I I need to be able to educate the more junior people on the team about that. And it's like I need to be clear with my expectations. Well, they might be like, well, but you know, this is kind of falling a little bit behind already and like I want to move faster and like trying to do the right thing. And I need to be clear with them. I'm like, hey, look, like, no, this this came up. We we didn't see this before. Like this is this is software development. There's always going to be that comes up we didn't plan for, right? It's always going to be the case. If we're learning from this, then next time hopefully we think about it sooner. But it's never going to be perfect.

We're never going to get it like a 100% right. That's okay. We just strive to get better the next time we do it. And we just keep getting better. But it will never be perfect every time. So sure, let's take a couple more days. Like I want you to go back to the drawing board on this part. It's not meaning that you have to go scrap everything, but go invest some time into this. Go write it down. Collect your thoughts. Send it back out. We'll chat through it. Make sure everyone's like, "Hell yeah." and then we'll go. And like it's good that we did it now because if we didn't there's the possibility that in you know 2 months, 6 months, a year from now there's a lot bigger problem. We're spending a lot more time on it. I need to get into that lane, which means you have to figure out how to drive.

So yeah, I think it's more about being like, you know, compassionate to some of the juniors that they're not going to know some of this stuff. I think it's an awesome learning opportunity. I think it's an awesome coaching opportunity. It helps solidify your understanding for things, right? Like we're engineers. We have to make tradeoffs. Like what are we discussing? And now I think my mic's actually about to die. So I'm going to wrap this video up. Thank you so much for watching. Uh, if you have comments, leave them below. Questions, leave them below in the comments. Sorry. Otherwise, you can go to code.com and submit them anonymously. And I will see you guys in the next video. See you.