266. Staying Visible and Valued as a Developer

How do I stay valuable to my company so I don't get laid off? How do I continue to be seen in a positive light when I am a remote developer? How do I show my boss that I am an asset to the team? These are the questions we will 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

How do you stay visible and valued as a developer, especially if you work remotely? Ensuring that you are valued as a developer is something that all developers have to figure out. Just putting your head down and working hard often isn't enough. People who do that often see others getting promoted ahead of themselves. And when you work remotely, it's even more difficult since you often can be forgotten just because you aren't in the same room with your boss on a daily basis. So what can you do about it? That's what I'm gonna talk about in today's episode of Dev Questions.

SPEAKER_01 0:43

Welcome to the Dev Questions Podcast with Tim Corey.

SPEAKER_00 0:47

Software development is more than just writing code. So let's talk about the rest of it. Specifically, let's talk about staying visible and valuable to your management as a developer. As I see it, there are six straightforward ways to stay visible and be valued as a developer. Let's talk through it with number one, communicate your accomplishments. So it's important to tell your management and others what you're doing. Now, this is not the same thing as just bragging or announcing to the world, hey, I completed another ticket, I fixed another bug. That's not what we're talking about here. But there are ways to communicate what you're doing in ways that aren't just bragging. So for example, if you have a one-on-one with your boss, make sure you have a list of things that you have done recently. Hey, I completed 14 tickets this week. I you know fixed that that bug that's been bugging us for a while. I added that feature that we talked about. And be clear about what you've done. Also, if you are emailing, including there, hey, by the way, that thing is done now. Okay. Communicate, over-communicate, and make sure that when you do, don't again, don't just brag. But what you're doing is making sure you're also not being silent about what you're doing. Don't just put your head down and get stuff done and not tell anybody. Make sure that you communicate what you've done. And number two kind of goes along with this is identify and capture value add tasks. So for instance, think of it like your resume. When you, on your resume, say, I worked at Acme Corp, usually you have three to five bullet points that say what you did or what you accomplished at that job. And they should be something that is a value add. So in your daily life, you do this. You do a lot of these things in your job. They just might not be huge and grandiose things, and that's okay, but you still need to identify and capture them. For example, you took a query, you optimized it, went from running for five minutes down to 30 milliseconds. Write that down. Identify and capture that value add. What if you worked on a feature that improved the numbers of customers per hour that you can that you can uh service? Well, write that down. What is the business impact that you have had? Look for those business impacts. Anytime you make a business impact, you write it down. This is addition to just your normal accomplishments. These are I had an impact because of. These are things that, yes, you still communicate that to management in your one-ones or in email and other things, but you also save this list for your annual review. Now, personally, I'm not a huge fan of annual reviews because they often turn into the what can I think about what you did last year and this past year and what didn't I like? Because if you didn't like something, why don't you tell me before? Sidetrack. But you can head that off at the pass a bit by coming in with your list of value ads to the business, to the business. Show your business impact. Say, here's the list of 15 things that I did this past year that saved us money, that saved us time, that improved our ability to help customers, that improved our service to other departments, that made our lives easier. Show off what you have done to add value to the company, because that's going to short circuit a lot of the, well, you didn't come in on time three times in the past 18 months. Yeah, I may, okay, maybe not. I worked overtime hours and hours, but you forgot about that. But you come in instead of just fighting back and forth with, you know, yeah, but, yeah, but you come in with, here's how I made an improvement. Here's how I made an impact for our business, the end goal of what you want to do to business. The business really doesn't care about you. They care about what you can provide for them. They pay you money, you give them value. Well, you're showing how you're giving value, especially value that's above and beyond what's expected. So that's number two, identify and capture those value add tax. By the way, by doing this, you should have a very long list by the time you leave a company. You should be able to find impacts, maybe even once a week, for your company. Now, some might be tiny, but others are maybe larger. When you capture all of those, and then you say, hey, you know what? I don't like where I'm working. I want to get a different job, or I just got laid off because just because you add value to a company doesn't mean you're not or you're immune to being laid off. But now that you're in that situation and you need a new job, guess what you have? You have a list of 50, 100 value add impacts on the customer, on the on the business, things that you've done that create a real business impact. And you've you don't have to think them up. You don't have to think about, oh, did I do this? Or you have the list. Now you just pare that down to the most impressive ones. Now you have an even better resume. So it helps your current job, helps your next job too. Number three, engage with other developers. So by this I mean share ideas, gain, you know, ask for input and give input. Help debug. You want to be talking to the user and saying, hey, or to the your coworkers and saying, hey, here's how I can help you. Here's how I, you know, am trying to be visible around you. But really, what you're doing is you're saying, I am part of a team. Let me help you. Let's work together, let's pair a program. You're becoming valuable to somebody else on the team. Don't just self-isolate and do your own thing and don't talk to anybody. Reach out, talk, help, especially help. Whenever you can add value to somebody else, that makes a big impact. But here's one way to help people like you is to ask them to do something small for you, which sounds weird, but when you ask them to do something small for you, and then you are appropriately thankful for as well, what that does is it makes them feel better about you. And all of a sudden, if you are asking for help, something little and then valuing that and then giving help back, it becomes a more collaborative relationship. And when your coworker thinks about who they like on the team, who is helpful on the team, you're there. They know you because you've actually done something of value. Number four, own something. This is one that you can do on day one, which sounds weird, but taking ownership over something where you are the go-to for that thing is valuable because now you're the point person on something. So when the team needs something from that thing or for that thing, they come to you. So own something. But how can you do that on day one? Well, day one, guess what you go through? The onboarding process. And guess what is almost never a smooth process? The onboarding process. Guess what takes you know, talking to coworkers and asking lots of annoying questions and you know, a lot of time to get up to speed on the onboarding process. So document it. Document the onboarding process. Write down everything you learn. Get people to validate. Hey, this is what I learned. Summarize it, of course. Don't just give them a huge document, but summarize it and say, these are the things I've learned. Is this correct? Again, that's a small thing you can ask for. That's a previous step that gets them to like you a bit better because you're open for feedback and open for help. But also, you start to own the process of onboarding people. Because when you go to hire the next developer in your department, you can go to your boss and say, hey, I have this onboarding documentation. Would this be helpful? This is the stuff that I was told when onboarding, I've kept it up to date even afterwards with new things. Would you like this to help onboard that person? And what your boss may even say is, I've got one better. How about I give them to you to onboard? And they'll be very thankful for that. You'll take something off their plate and you'll now become the owner of the onboarding process. Now, there's other things besides just owning the onboarding process. And if you know two people are hired at the same time and they're both listening to my advice, only one can own it, probably, unless you team up, and that could be that could work too. But there are other things to own as you mature in your role. So owning an app or owning a feature or owning a system, owning a piece of the domain where you're the one to go to about logging, or you're the one to go to about authentication, or you're the one to go to about talking to your database. Whatever it is, find one area of your system specifically and go deep into it. Understand it well. Learn it really well. Get better and better. If you have the opportunity, pick the tickets that relate to that system over and over again because that will help you get even better. But learn one thing really well. Study it, learn things around it. So if you're learning SQL Server and you're working with SQL Server, well, learn a lot more about SQL Server. Learn how to optimize it, learn how to read query execution plans, learn how to create indexes and how to evaluate indexes and evaluate queries and learn all this because it's going to make you better at your job and it will help you become the owner of something. And then when the team needs a query optimized, who do they go to? They go to you. So own something. It makes you more visible. It makes you more valuable. Number five, be visible learning something. Now, this is not sitting in the hallway outside of cubicles with a book open learning or watching videos at full volume. Don't do that. That's not what I'm talking about by being visible. What I mean by that is learn something that is of value to your department, and then use that new knowledge. Show off what you can do and show that you're continuing to add new value to the team. You're not just adding the same value you've always added, you're adding new things to your skill set to be even more valuable. Be visible learning something. Yes, you may be learning things, but are you showing that off in any way? Are you in any way becoming better at the company, better at your role because of what you've learned? If not, then you're not really visible, therefore it's not adding much to your visibility or your value. But by showing off what you can do, you become more valuable over time. Okay. Number six, pick one area and add unexpected value. This is something that I have done in almost every role I've been in. And I did it at first accidentally. And part of that's because as a developer, I like to fix things. I like to make things better. I don't like to repeat myself. I like to build an app that does it for me. I say that I'm a lazy person because I don't want to do the work. I want to write an application to do the work for me. And that has served me really well over my career. But what it's also done is it's taught me to build helper apps. So one of the things that my wife was working at a small nonprofit, and they did this golf outing, and they had to capture a bunch of information from people, and then they had to send emails out. And you know, it was her job to try and collate all this. And it's it's one of those things where it's like it takes time, but you know, that's what you do. That's that's your job is that is to do that. Well, I wrote a small access database system that did most of that work for her. Well, guess what? That was just what I had done in my roles previously. And I was like, hey, you know what? This might help. And because of that, she added unexpected value at work. So all of a sudden now her boss is like, well, that's pretty cool. You're getting a lot more done than I expected you to. I've done that at multiple roles, where I'm like, hey, I could automate this and we could do this task. When I worked at a college, I ended up taking on more and more responsibilities from other departments because I could automate it. So it wasn't much time on my part once I wrote the code, but yet I could take a lot of work off of their plate. All of a sudden, those departments realize that. And if I'm taking work away from them in a good way, not in a bad way, but if I'm taking work away from them and making their lives easier, well, that makes them happy and I'm more visible. Okay. So it can be small. Build a helper app. Maybe you do a repetitive task every week. It's as simple as writing a script. So there are times where maybe you have a problem. Uh, this is going back a few years now, but we have a problem back in the day where after so many days of operation, our SQL servers got clogged up. Now, the reason for it is because we had applications that were opening connections to SQL and not closing them. That's an important thing. If you're writing code, think about closing the connections all the time, every time. So we have using statements in C. But for you know, the the server got clogged up and it just wouldn't work anymore. And so we had to do a number of steps where shut down the server, shut down SQL itself, then shut down the server, then restart the server, then restart SQL, then test to make sure things are up. And there's just a few steps in that process. Well, write a small batch file that does all those steps. You don't forget one. And so that you can do that with just a click of your mouse. All of a sudden, you've now created something that has made you like the stakeholder in something, but also you provide unexpected value. Maybe it's you improve the CI CD process. So I'm not saying write a CI CD process or pipeline because you hopefully have one of those, but maybe do one little tweak to make things a little bit better. So one of the areas I worked on for a while was um we had websites, and I wanted to make sure those websites were uh properly formatted and they were actually we were creating good websites that were uh following all the best practices. And so I wanted to run Lighthouse, which is a tool that checks websites for following best practices and accessibility and all the rest. Well, put that into the CDI CD process as one extra step and say, hey, boss, I wrote this script. We could insert this into the CI CD process and generate a new Lighthouse score every time we publish a new web change. And that way we make sure that we are doing the right things and making sure we're not regressing in other parts of our site. That provides unexpected value. And guess what? When you provide unexpected value, even if it's a small thing, you stand out, you're remembered, you're seen as valuable. So don't just blend into the background and become forgettable. Take careful, calculated steps to stand out, because the value you bring to your team needs to be visible. So doing so will help your career and it will help you better prepare for your next job as well. Now thanks for listening. As always, I am Tim Corey.

SPEAKER_01 17:53

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 imtimcorey.com and enroll in a course.