118 How Do I Improve the Technical Skills of a Team?

With a team of mixed skill levels, how do we improve our skills together? Are there ways to do so efficiently?  These are the questions we are going to answer in today's episode of Dev Questions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_00 0:00

Welcome to the Dev Questions Podcast with Tim Corey. Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology. If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered. Now, here's your host, expert developer and online educator, Tim Corey.

SPEAKER_02 0:24

How do I improve the technical skills of my team? My team has a mixed level of skills and how do you bring everything up together? This is a question I was asked recently on the suggestion site, and it's one that I thought we'd tackle in today's episode of DevQuesti. Now, if you have a question, go to suggestions.iamtimcorey.com, leave your suggestion there, and hopefully you'll see your question answered in a future episode of DevQuestions. So let's talk about bringing the level of your team skill up. So you have some people that know more, some that know less. How do you improve together? And this will be applicable to not just the management, but also a person on the team. So let's talk through six different ways that you can improve the skill level of a team. Number one, every developer should have a learning plan. This is something that is not just the responsibility of management, although if you are a manager, you should listen. Make sure that your people have a development plan, a plan to improve and get better over time, not just by working, but by looking outside of just the specific area focusing in and kind of broaden and improve their skills over time. Now, as a developer, you might say, my boss doesn't care about that. Or worse yet, my boss says, don't do that, just focus on work. Guess what? It's still your responsibility because it's your responsibility to maintain and improve your career. It's not your boss's desire to make you more marketable. Now, hopefully, your boss is going to focus in on if you get better, you'll be a better employee, you'll have more to offer. But sometimes people are short-sighted. Also, the pressure of day-to-day tasks does tend to kind of creep in. I worked for a company once where they hired me, brought me in because they knew that almost at a very clear point, there was a point in time for their company where they only had a couple of developers and they stopped looking up. They stopped looking at what the industry was doing. They stopped looking at new features and new improvements to languages and uh frameworks and all the rest. And they started just focusing in on we need to do the job. And when they finally picked their head up, it had been years. And they had to change basically everything about their application because it was so old. And they had invested so heavily in an old system that was no longer a great representation of how to do things. So by just putting your head down and getting the job done, you often miss some of these opportunities to improve slowly over time and instead work your way into a corner. So as a developer, you want to make sure you keep your head up, even if you have to do it off of work hours. Now, do I advocate doing work outside of work hours? No, I don't. But I do advocate improving your ability to get a better job outside of work hours. So if you are improving yourself, try to do it on company time because your company is going to benefit. But if they don't offer that, then you probably have to off the clock. But maybe use that as an opportunity to improve your skills enough to find a better position. So number one is everyone should have a development plan. If you are managing a team of people with different skill levels, they should all have their own individual plan in order to get better. Now, number two, pair programming. And this is one that often people who have not experienced it kind of think, well, I'm going to reduce how effective my team is. You're really not. In fact, a lot of times pair programming allows you to improve your overall efficiency as a team. Now, what is pair programming? The idea is that two people work together on one computer. Not two computers, one computer. One person kind of talks through the problem and drives the work. The other person is more of the type it out and actually do the work. So there's two people working there in tandem, and often you switch roles. So for a while, there's a person behind, next they switch, and that person's now the keyboard. But the idea is that you work together. So why is it so effective at improving skill level? Well, it's effective because when you work together, whether you are at the same rough skill level or not, doesn't really matter. What matters is that you're each individuals who have different experiences. Maybe you have a certain key combination you use a lot. For example, moving lines up and down. You can use, I believe it's alt and the up and down arrow. I always forget that. But when you see somebody else do it, you go, wait, how did you do that? And you might learn something new just in that little bit. Or it may be more dramatic than that. Maybe you start working on a project and say, oh, we have a library that helps us do this. And the other person says, wait, we do? And you talk through, yeah, here's how you use it. And you show them how to use it. Now it's almost a training session directly. But either way with pair programming, you really speed up your work as well. And how do you do that? Because there's two people doing a job of one. Well, first of all, when you are developing on your own, do you get distracted? Do you find yourself starting at Stack Overflow and then heading off to Twitter and then to ESPN or somewhere else? Or do you always stay directly on task? Well, usually you wander a little bit. Maybe your email pops up. Maybe you have a message from Teams or from Slack that pops up that you go, ooh, I need to see that. Well, when you're working together, those distractions are harder to take hold. Because the distraction of let's see what the layout sports cores are, isn't as big a driver when you have someone literally over your shoulder. So that's one thing. It cuts down on distractions. Even email, Teams messages, Slack messages, those aren't as big of an interruption because you think, hey, I'm doing something. We're doing something. So this has to wait. And so you actually will get more done because you have more of an excuse not to be distracted. Also, when you work together, you come up with solutions a little faster. Because if one person gets stumped, the other person might not. When you speak the problem out loud or when you talk through a solution out loud, you often find the bugs faster, you find solutions faster, and you generally do a better job as a developer. This is why there's a technique in software development where you talk to a rubber duck. By doing so, you actually lay out the problem in a way that you go, wait, I know a solution now. And you go on about it. And the rubber duck again saves you, makes you better. Well, if you're working on a pair, okay, it's not a rubber duck, it's a person who can talk back and say, wait, you seem to skip a step. What's your assumption here? And you go, oh, I did skip a step. And you are able to resolve that. So it's even better than a rubber duck. So pair of programming is number two. Number three, co-review. When you do work and you go to submit, if you can, I'm your team, set up a process where somebody else reviews the code. Now, this can be intimidating. On a bad team, it can be a bad thing, but you have to work through, make this a good process. This is not about pointing out all the flaws. I mean, in some ways it is, but it's not about saying, oh, you're a bad developer because you did this. Instead, it's it allows for questions. It allows for, hey, why are you doing it that way? Or, oops, I think you missed this. That exposes problems. It exposes ways of doing things that aren't the standard of the company, but it also allows you to grow as a developer. You just need to have an environment where you encourage that to be a safe discussion, where it's not an attack, it's a ability to grow. Now, you do have to somewhat thicken your skin. If you cannot handle criticism, you need to work on that. Because criticism can be and usually is very, very beneficial. Now, the person speaking has to also be careful how they say it, obviously. Saying things like, hey, you idiot, you forgot the comma, not great. Now, personally, I say it to myself all the time. Hey, you idiot, you forgot the comma. That's why everything's broken. But when you start to trust your teammates, when you start to realize they're not here to get me, they're here to help. When you start to realize the person you're reviewing is someone that you want to encourage and build up so they can help contribute even more to the team, that's when you start to see real benefit from code review. So that's number three. Number four, lunch and learns. This is one that people often get a little taken aback by. They they struggle with because the concept is that you present what you're learning. That can be a big scary thought for some people. The idea that you're going to present something. But it's important. In fact, I am highly, highly uh encouraged whenever I see teams that do this. I am really, really adamant that teams that want to grow need to do this. I can't express clearly how much that I think this is important. Because the lunch and learn does more than it looks like on the service. So let's talk first about the actual system, and then we'll talk through how to make it great. So the actual system is that on a regular schedule, whether it's every week, whether it's twice a month, whether it's once a month, on a regular schedule, one person from a team will present what they are learning. And this presentation is just, hey, this is what I've been learning about. And then you show off a bit about how it works. You talk through what it does, why it does it, and how it does it. Think of it as one of my Monday videos. Not nearly as in depth, not nearly as long, but think of it as one of my Monday videos. So what are you learning? Well, it can be really anything. And it probably should be something close to what you are working on, but not necessarily exactly what you're working on. For example, maybe you are a company that has a React front end with a C sharp API in the middle and SQL data access in the back end. Okay, that's your basic process. And you do deployments through a manual process. Well, maybe you can learn about an Azure DevOps deployment process or a GitHub Actions deployment process, or maybe you can learn about Blazor Server or Blazor WebAssembly. Things that you might not use right away. You might not use in the next six months, but they kind of spark some new thoughts in your mind. So you'll learn about something new, you grow your knowledge base, and then you share it. Now, why is this so important? Why am I so insistent that this be done? Well, a lunch and learn isn't just about presentations. Okay. First of all, the person doing a presentation. And by the way, it's called lunch and learn because you used to do it or lunch break. So everybody's their food, they eat, you present. That's the way it is. So the person presenting has to not only learn a topic, they have to learn it enough to present it. Believe it or not, when you present material, you learn it better. In fact, the way to become a really good C sharp developer is to start teaching. Now, don't start teaching necessarily at day one, but once you get some experience, start teaching what you know. And then as you get more experience, teach that too. Because when you teach, you need to be able to present the topic in a clear, focused manner. You need to have the ability to take a person from where they are, maybe knowing nothing, to knowing something about the topic. You need to be able to answer questions that they might have. And so as you start to get experience with this, you'll start to think of the questions ahead of time. So you might say, well, this is the thing I've learned. But the question is going to come up is how we do this. And so you think, okay, if if somebody asks that question, how will I answer? And you start going down the rabbit hole of learning, well, how would you answer? And then you've learned even more than you would normally. Now, see, that's where the real power comes in. Because now, when you learn other topics, you will start to think of those same questions. And you will start to go deeper than you normally would. And all of a sudden, your learning ability has grown. You become a better learner. And by becoming a better learner, you become a better developer. So just in the presentation perspective, it's a huge deal to do this. But then from the learner's perspective, from the rest of the team, by just coming in, eating your bag lunch at a table while somebody presents, you get exposed to something new. And you didn't have to go and look at it, track it down, figure out how it works. You just got exposed to a new topic. Now, maybe that's all it is, but by doing so, you've seen a broader picture of the world. Believe it or not, there's a broader picture than just C sharp. And if you start to see other languages and other processes, it may start you to go on the road of questioning well, does C sharp do that? And you might find out, yes, it does. I just didn't know about it. And you start to learn your language better because you've seen the way a different language does things. So that exposure can be excellent as well. That's beneficial to the whole team. Now, the way I recommend doing this is doing it every about every two months, one to two months, depending on your team size. Let's just say you decide on once every two months. Well, then you figure out how many team members do we have? A total of six, let's say. Well, that would be six people over two months, which is about three per month. So the first three weeks of the month, somebody presents. That way, your cadence is only every two months. It's six times a year. You have plenty of time to learn something new and present on it, which does, though, force you to be learning something new. C point one. So by learning, being forced to learn something new, you have a deadline. And then by presenting that, you'll learn it deeper. But then your team gets exposed to three different topics every month. Now, what that fourth week? We'll get to that in a minute. But let's just say that's where you're at. Now, maybe if you get good at this, you start doing it every month and you have more of them. But let's focus now on every two months. It's only six times a year. So with those three, you have three weeks a month, three times a month, that you'll be exposed to new things, to new opportunities to learn and grow. That's a huge benefit to your team and it lifts everyone up. Now, number four is that you want to, I'm sorry, that wasn't number four, lunch and learn. Number five is team documentation sessions. This might fit into a spare week you have in that month. Maybe you do have six people and you're taking three months or three weeks or three, yeah, say three weeks out of the month to do lunch and learns. Every, let's say, Friday. Friday at noon, we're going to do lunch and learns the first three weeks of the month. The fourth week, focus in on team documentation. This is an interesting one where you bring the whole team together. If you have laptops, bring them. And what you do is you document a feature or a system in your organization together. That's important. This is not a solo task for every person. That's different. This is a together, think of it like pair programming in a larger group and maybe mob programming. But it's not programming, it's documentation. And so what you do is you work together to document a system. So one person types and everybody else talks through what this system does. Let's organize it this way and talk through the process because it makes sure that everybody then understands what a system does. If one person says, wait, that does that? Well, now you've learned something new. Or if a person that built the system says, okay, and here are the three different options you can run with. And someone says, We have options, now you've all learned something new. And so by document together, you all learn something new about your own system. Plus, at the end, you have documentation on a part of your system. Whether that's your DevOps process, whether that's your SQL database structure, whether it's your a piece of your coding application, whatever it is, you document a process in that time. Okay, so that's number five. And then number six, this is a fun one if you have time. I'd encourage you to make the time. And that is short-term coding jams. This is the opportunity for the team to come together and work on something short term that's fresh and new. If you have the opportunity, take one week a year. Pick a week in the summer where things are slow, downtime, whatever it is, pick a week and work together on something that's different. If you have a dress code, let's say, where you have to wear, you know, pants and a two-button shirt or something like that, cut it out for that week. Shorts and t-shirts. We're going to have a Hawaiian theme, we're going to have whatever it is, make it different and fun. Then if you can, move everything into one room. So if you have the opportunity, take a table, a conference table, something like that, and fill it up with laptops and work there. Work together if possible. If not, then try to at least have one central room you're working in or something like that. But come together and pick at least one task you're going to work on. Now, if you can't do a week, try one Friday a month or one Friday every quarter that you do this. Pick something that is not in your normal work process. Work gets long, it gets hard, you have crunch time, you have deadlines, you have things you have to do, and you kind of get heads down just doing the work. The problem is that when you do that, other things slide because they're not as important. Maybe it's your internal processes. Yeah, you want to automate that CICE process, we just don't have time. Or yeah, we could create this little automation, but we just do it manually for now. Okay. Pick something that's in your process that will never get worked on normally. Maybe it's an internal tool, or it's a it's a workflow process, or it's a deployment process. Pick something like that that will benefit your team and then build it in that one period of time. Work together, work on various parts of it, bring it together, and then create something that will make your life better. This will improve your whole team because they'll work together on a project, maybe pair programming in groups, or even just as one big group, but you work together on something and you make yourself better for the rest of the year. Because if you work on something where you're automating a process or a workflow or something like that, you're making your life better from then on. So by doing that, you not only improve all your skills, you also improve your team's efficiency for the rest of the year and beyond. So those are my suggestions of things you can do to work together to build everyone's skill up, lift everybody's skill to a higher level, and kind of level out those skills a bit by working together collaboratively in ways that can benefit the organization in your efficiency, but also benefit those who need more skills. All right. I hope that answered your question. I hope that you found some value, found a nugget or two you can use. I look forward to seeing you back here next week. So thanks for listening. And as always, I am Tim Corey.

SPEAKER_01 23:54

Thank you for joining us for this episode of Dev Questions. Tim is committed to making it easier for you to become a developer. If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions. You can also send your questions to questions at IamtimCore.com. Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did. When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.