Hey, everyone, I'm on come to Developer Tea. My name is Jonathan Cutrell, and in today's episode we're going to be talking about digging up your job description. This episode is a part of the great developer mindset episodes of Developer Tea. The series is dedicated to guiding you the listener towards the mindset of the great developer. My job on this podcast is to help provide you with the tools, the insights, and the inspiration you need to shape your career as a developer and become truly great at what you do. In today's episode we talk about digging up your real true job description. This is an interactive episode. So before I dive in, I want you to pause this episode, not yet, but before we dive in, you're going to pause the episode. If you're listening in the car or you're running or something, you can do this in your head. Otherwise, I'd like for you to take out a piece of paper and just pause the episode, take a moment to think about your job description. I want you to come up with two sentences. Just two. Don't go beyond that, at least two. That represent your job description. Don't move ahead with this episode until you've done that. And by the way, once this episode is over with, if you want to share this exercise with other people, I'd love to get pictures or maybe just the sentences themselves on Twitter. You can always tweet at me at at Developer Tea. I think this will be enlightening to you. So hopefully, hopefully you will write down your job description before you continue listening. Today's episode is sponsored by Refactor You, the 10-week JavaScript Bootcamp designed to help you reinvent yourself. We'll talk about the many things that Refactor You has to offer you as students later in today's episode. Because we're all students, aren't we? We're always learning. Of course, the good developer is always learning. So remember that as you go throughout your career. But now you should have your job description in your head. Those two sentences I asked you to write down or think about memorizing your head. You should have that in front of you or in your mind. What I want you to do is think about those two sentences and look for points where your job description says something along the lines of writing Python code or building web interfaces. If you have written those phrases in your job description, this episode is for you. If you're a user tester, then perhaps conducting user tests would be another one of these kind of task-oriented responses. Let's talk for a second about job descriptions. What is the job description of a local grocer? That first, it's easy to think that the grocer's job is to stock and sell the groceries. But really, these are tasks or responsibilities. To move new produce in and move the old produce out and to check people out at the counter. These are all responsibilities or tasks that the grocer has to accomplish. But a better job description for a grocer is to help people get the groceries they need. That's the ultimate goal. The reason that grocer exists. Of course, that grocer is conducting business as they go along. But the reason, the value that they provide is that they help people get the groceries that they need. The slight distinction here is incredibly important. The job description is not a listing of the specific tasks or skill-oriented responsibilities. You are required to complete. But rather, it's the reason you have the job. The value you are providing. This is not very difficult to understand for the grocer, of course. But for developers, this concept may seem a little bit foreign because we're used to thinking about jobs in terms of the language that we may be writing in. For those of you who work in an agency world, while you may be coding in the same language for the next three or four years, your job description may be changing on a weekly basis, maybe even on a daily basis, if you work with multiple clients. If you're working on an application, for example, as an optimization expert, your job description isn't simply to make the application load in under 0.2 seconds. Instead, you may perform the task of making the application fast, but you must understand the reason why the application needs to be fast. What makes a fast application valuable? Of course, that reason or number of reasons may be for user experience or for resources. But if you don't know what the reason is, if you don't have the reason the application should be fast, then as the optimization expert, you don't really have a job description, you just have tasks. We'll take a quick sponsor break and come back to talk about why having the real job description, understanding the value you deliver with the context of the purpose in mind is so important if you want to cultivate the mindset of a great developer. Today's episode is sponsored by RefactorU. RefactorU is an immersive 10 week JavaScript training bootcamp. They are dedicated to getting you hired and empowering you to reinvent yourself. If you have been trying to learn how to code online and you've hit a brick wall, well, it doesn't make sense to keep on doing the same thing over and over again. RefactorU may be the perfect opportunity for you. On top of that, RefactorU is GI Bill approved and they have diverse these scholarships available for each cohort. You'll learn from world class peers and instructors while you're working on real hands-on coding projects with JavaScript. Now, as kind of icing on the cake for Developer Tealisteners, RefactorU is offering a 20% tuition discount when you mention the show. Just go to spec.fm slash refactor and make sure you mention Developer Teawhen you sign up. That's spec.fm slash refactor. Thanks again to the folks at RefactorU for sponsoring Developer Tea. Having a full understanding of your job description is essential for many reasons, but today I'm going to focus on one primary reason. Now, again, let's go back over what a good job description looks like. It's not your responsibilities, your skill-based responsibilities, but rather it is the value you provide. The reason your job exists. To do your job well, having the context of why a specific task is being performed, it isn't only helpful, it's essential to performing that task to the highest standard of excellence. And that's really essential to being a great developer, isn't it? For example, if you know your task is to build a registration process that allows users to sign up for a service with minimal interaction. And if that's only you know, you may go down the path of building a login form that is optimized for the fastest login, it allows people to do auto complete or whatever number of features you decide are relevant. But if you knew that the ultimate goal of the application was to acquire user phone numbers so that you can text them updates, for example, from a specific event or something like a conference, you may change the entire strategy of that task. Instead of having people enter their emails in a password, you may simply have them enter their phone number. Or to return to our discussion on optimization, if you know the goal is to make the application feel fast, in other words, the perceived speed of the application, you may be able to accomplish that goal more effectively by putting your energy into the initial rendering steps rather than over optimizing the entire application. We talked about this specific concept in an episode last week called getting fast first, but really what we're talking about here is when you start optimizing an application, you have to understand what you're optimizing for. In other words, what are you doing? What value are you providing by performing that optimization? So take a few minutes today, write down your job description on your to-do list, write this at the top. Today, my job is to fill in the blank. Avoid writing specific tasks and instead think about the effect of your actions. Maybe call this a purpose statement for your day. For example, every day at Whiteboard, a significant part of my job is to encourage learning and an unwavering commitment to quality for the developers at our company. Notice that I didn't prescribe exactly what steps I need to take in order to do that, but instead this gives me an idea, some guardrails, some values of what effect I'm trying to achieve. Here's the underlying truth here that few job titles or descriptions are actually going to give you. The underlying truth is that specific skills, actions, techniques of your job, those are very likely and almost guaranteed to change. We change to different technology, for example. However, your goals may remain constant. Perhaps more importantly, the tasks for the same goal may change from day to day. You may decide to change the way that you approach a particular problem because something new has been released that accomplishes that particular goal better. The specifics of how you accomplish your job are fluid and as a result, the growth of your career will come when you truly internalize the concept that the effect and the value of what you do rather than the specific steps you take to do it are the most important detail of the work you do. Thank you so much for listening to today's episode of Developer Tea. Of course, thank you again to today's awesome sponsor Refactor U. If you are looking to reinvent yourself, Refactor U wants to come alongside you in their 10-week JavaScript training boot camp. Refactor U's goal is to turn you into the developer you want to be. If you have been stuck trying to learn how to code online, go and check it out. It's RefactorU. That's spec.fm slash refactor and don't forget you get a 20% tuition discount when you mention Developer Tea. Thank you so much for listening. If you enjoyed today's episode, make sure you subscribe. We actually had a record day of lessons on Monday. So thank you all for listening. I hope you stick around for future episodes. Subscribing is the best way to make sure you don't miss out on future episodes of Developer Tea. Thank you so much for listening and until next time, enjoy your tea.