I am Tim Corey. I teach coding online and my inbox is full of questions from current and future developers. I wish I could sit down with each of you and share the answers I know will help you go further, faster in the world of development. This podcast is the next best thing. On this podcast, I will answer the biggest questions people are asking! Send us to your suggestion for a future Dev Questions at https://suggestions.iamtimcorey.com/ To keep the podcast coming, like, subscribe, rate, and share it with your friends and colleagues. See why thousands of students have chosen to learn to think and code like a professional developer at www.DevForge.com.
272. How To Learn From a Senior Developer Without Annoying Them
•Tim Corey•Season 6•Episode 272
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
0:00
|
11:56
How do I learn from a senior developer without frustrating them? How do I keep them happy while asking them lots of questions? These are the questions we will answer in today's episode of Dev Questions.
If you work with senior developers, they can have a wealth of knowledge. But if you aren't careful, you can end up annoying them and push them away. So, how do you learn from these developers without being annoying? That's what we're going to discuss on today's episode of Dev Questions.
SPEAKER_00
Welcome to the Dev Questions Podcast with Tim Corey.
SPEAKER_01
Software development is more than just writing code. So let's talk about the rest of it. Specifically, let's talk about how to get a ton of information out of your senior developers without annoying them. Now, here are some easy techniques to learn from other developers on your team while making friends at the same time. So, number one, try to figure things out on your own first. This is one that this is where you get a lot of frustration. I know because I also get this a lot. I've worked with junior developers. I've also have people on YouTube that ask questions. And a lot of times they're great questions. So please don't think this is the majority of the time. But I'll get sometimes people will ask a question where I'm like, that was a quick Google search away. That was something I said in the video, or that was something I already showed you how to do. A big one is error messages. They'll say, I'm getting an error. And I say, What's the message say? And you know, this is a fictional example. It might say something like, you know, you're missing a semicolon. Guess what the response I give them is? Put the semicolon back in, right? Like read the message. So take time to figure things out your own first. Now, I'm not saying, you know, one of the things that's also frustrating is a person who wastes three days trying to figure out a problem when I could have told you, oh, check this out. So this is not about take a ton of time, but do take some time to try to figure it out on your own first. Put in a bit of effort. Otherwise, what happens is you make it feel like that I'm your effort, that I am the thing that you you punch to get effort out, that I have to do the work, and you're just here to be along for the ride. So, step one, try to figure things out on your own first. This will greatly endear you to people. When it appears as though, when you show that you are working on the problem. You're not just using them as a way to do your work or do yeah, do your work for them. Um, so number two, ask concise questions. Along with this goes the idea of knowing what you're asking. Going back to that example of I've got an error. Um, why do I have to ask you what's the error? You should say, I've got an error that says, and I looked in this spot, or even better, if you say, hey, I'm working on this feature in this area, and I'm getting this exception when I try to run it, and I'm not sure why. I try to figure it out, but I can't figure it out. Concise question with the information in it that's relevant. So I'm not giving you my life story. I'm not spending 10 minutes asking you a question. I'm just giving you just the facts that are relevant, and I'm giving you all the information up front so that you can make an informed decision. So ask a concise question. Number three, here's another one. Take notes on the answer so you don't have to ask it again. For the most part. And again, we're speaking generally here, but for the most part. When you ask a person a question, they're happy to help. If they're on your team, they're like, sure, glad to help you out, glad to answer your question. You know, you get there the first day and you're like, How do I, you know, open a new issue? Happy to help you. Because I want you to be able to succeed. I want you to be a successful part of this team. But if the next day we come in and you say, How do I open an issue? I just told you yesterday. Yeah, but I forgot. Okay, so you didn't value my answer. You just decided that I'm your Google, I'm your chat GPT. Not great feeling. So take notes in the answer, write it down. Don't try to just remember it. Because that's where you get into the K3, like, uh oh, it's been four days and I forget how to do this again. I'm gonna have to ask that question again. It happens, and you know what? People are gracious, but I would lead with, listen, I I'm so sorry. I forgot, I didn't document this, and I forgot how to do it, and it's been a few days. Can you help me again? I will make sure that I write it down this time. Mistakes happen, fall your sword a bit, but write it down. That way you don't have to ask again. Number five, I'm sorry, number four, apply what you've learned. So I love helping people and then seeing that they have learned that lesson and are using that lesson. If I uh if you ask me how to open a ticket and I show you, and then I see you opening other tickets, that's great. You're showing me that you learned from what I told you and it made you a better developer. It empowered you to do your job. Awesome. Love that. If if I don't see you using it, if I see you trying to work around it or avoiding that because you don't know how to do it, you don't want to ask again, that's a problem. Number five, be thankful for the advice. Okay, you're asking for help from someone else. The very least you can do is be thankful for it. It's super frustrating to help somebody out, to take the time to help somebody else out and for them to be miserable about it. Don't do that. Be thankful. Be appreciative of the fact that they are giving you something that they don't have to give you. Even if it's their job, be thankful for it. Okay. You're looking to build better relationships. You're looking to work with the team. In order to do that, you need to be thankful for what you're given. Uh number six, be pleasant throughout. Again, it's coming back to number five a bit, but working with people who are miserable is a miserable experience. When you have a person ask you a question and they come in with like, oh, this system is so stupid. Can you just show me what to do here? Great. Sure. Love to. You haven't put me in a great mood. You kind of made me miserable. And I don't want to be miserable too. So come in with a be pleasant. Come in and be pleasant and have that a pleasant conversation. Be thankful throughout. Be attentive. You know, be a positive person. Again, you're learning to work with a team. And so being able to be positive in that relationship is important. Number seven, and here's a big one. Um help others out who might have the same issue. So essentially, pass it on. This is where I tell people when you're first starting off in a company, you have no ownership, you have no thing that you own. You you don't really have anything that people come to you for. You can change that almost right away. When you learn things, document them. That onboarding process, document it. Learn everything about that and write it down. Create good onboarding notes. Then when the next person goes to onboard, you can go to your boss and say, Listen, I've got all the notes from my onboarding. Do you want them? And you'll probably have your boss go, how about I just give the person to you to onboard? Well, all of a sudden, you've made your boss's life better either way, and you have become the person who is the go-to for something right away. So you've made the process better. If there is onboarding documentation, if there is an onboarding system, great. Still document things and figure out what parts are missing. And then at the end of it, go to your boss or go to your trainer and say, listen, these things weren't in the onboarding, but I think they'd be helpful. Can we can I put them in? Again, you're helping others out. And by so doing so, you're showing off that you learned it, and then that you're helping to apply it to the next person and make my life easier because I answered it once, and now that information is not just getting passed on to you, but also the next generation of people that would otherwise ask me about the question. So you're helping make the team better, and you are also becoming an expert in or a go-to in one section of your organization that is very easy to do. At the same time, it's very valuable. You're helping make sure that you're protecting everybody else's time. So learning from others is valuable. Um, learning from senior developers is a great way to elevate yourself and elevate your career. Um, this is why I do the Dev Questions podcast, because not everybody has a person over them that has been there and done that and will share those, that, that wisdom with you. So I do it. Um and so you get to learn from that. You get to learn things that I've done and learn to avoid the pitfalls that I fell into and learn the best practices I've you know learned over time. But you can do that in your organization. And by doing so, you will grow as a developer, but you have to do it well. Otherwise, what happens is you make people irritated towards you, and people kind of groan when they think about helping you, and they get frustrated at you, maybe without reason sometimes, because the actual reason is they're frustrated at you because of how you ask questions, but now they're applying that to every situation you're in. Um so even if you ask a reasonable question, they're already starting frustrated because of the fact that you've abused that privilege. So don't abuse the privilege. Learn how to talk well to people. So seven steps, again, are to figure things out on your own first if you can. Then number two, ask concise questions. Number three, take notes of the answer so you don't have to do it again. Number four, apply what you've learned. Number five, be thankful for the advice. Number six, be pleasant throughout. And number seven, help out others who may have the same issue. All right, thanks for listening. As always, I am Tim Corey.
SPEAKER_00
Thank you for joining us for this episode of Dev Questions. When you're ready to learn to think and code like a professional developer, head over to IamTimCorey.com and enroll in a course.