Hey everyone, welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode I'm answering a question from listener Jonah. Today's episode is brought to you by the Spec Network. You can find other podcasts for designers and developers by going to Spec.fm. That is where the show notes are found for every Developer Teaepisode as well. Today's episode is sponsored by Rollbar. With Rollbar, you can detect, diagnose and defeat your errors. We will talk more about what Rollbar has to offer Developer Tealisteners. Later on in today's episode, first I want to read this question from listener Jonah. Jonah says hello. I'm a graphic designer with an interest in expanding my skills to include web development. I wanted to know if you have any advice for someone coming from my field. Jonah, you're certainly not the first designer to change paths or to expand your career into development. In fact, I originally thought I wanted to be a designer and it turned out I was better at designing systems than I was at perfecting aesthetics. But I want to take a moment to hopefully elevate this conversation for people other than designers who are also wanting to expand their skills or perhaps make a career change. One of the most amazing things about becoming a developer is that you can come from almost any background. The industry doesn't have a lot of regulation. There aren't many certification boundaries unless you're going to work in a corporate environment as something like a database administrator. But typically, there's not really any kind of regulation. There's not a lot of fences that you have to jump over. There's not a lot of people telling you what you have to do to become a developer. You can just flip a switch and say, I want to be a developer and start learning the skills necessary. But the freedom you have as a result of this is quite enticing for new developers and people who want to start a second or maybe a third career. In fact, it's even enticing for people who just want to start a side job or maybe a hobby or expand their current skill set to include some kind of programming. So here's the thing. The spec network is designed specifically to talk to people like Jonah because Jonah, you fit both of our audiences, designers and developers. And there's definitely a sliding scale between designers and developers. There are a lot of people who have done what you're trying to do, Jonah, very successfully. So in today's episode, I'm going to give four basic tips to remember as you transition into a new career as a developer or a developer, designer hybrid. And then we'll talk about how this applies to designers more specifically. So the first four tips are really for anybody who is trying to come from a different career path and expand or change to a development career path. Okay. Tip number one, becoming a developer doesn't necessarily mean changing the way your brain works. Okay. Focus on this for a second. Becoming a developer doesn't mean you have to change the way you think. This is a subtle point, but I think it's incredibly important because a lot of people come to this career and think that they have to suddenly become more logical, right, or that they have to change their personality even. And when you become a developer, you may feel the pressure to start adopting the opinions of the average developer. You may feel the pressure to change your previously held values. And I want to encourage you that becoming a developer doesn't mean you have to change the way your brain works, but rather your change is simply in the output what you are creating. In other words, you don't have to quote think like a developer. You simply cultivate new skills, continue with the values that you already hold. Or if you're going to change your values, don't make it because you're becoming a developer, but rather because you are refining those values, or maybe you're learning and you're adapting your values. You don't need to adopt new attitudes to be a developer. There's a lot of designers who become developers and they think that they have to stop caring about the aesthetics of the things that they're building. And that's not necessarily true. There's a lot of people who become developers and they think that they suddenly have to become anti-social. This is also not true. There are a lot of these poisonous mindsets that are a result of a lot of stereotyping that really are not helpful to you as a new developer. So ignore those things. Don't think that you have to change the way your brain works simply because of a career change. So that's tip number one. Becoming a developer doesn't necessarily mean changing the way your brain works. Number two, this is a very common subject on this show. Beware of imposter syndrome. We started mentioning something related to this earlier about the lack of regulation in this industry. And I'll link to the main episode where we talk about imposter syndrome quite a bit more in detail. But the basic idea here is that because there isn't a single authority on what makes you a good developer, there's not really like a measuring stick, right? It's easy to develop imposter syndrome because measuring your effectiveness as a developer is very different than most other career paths. If you come from, for example, the insurance industry, your value and your career pathway are a bit easier to identify. If you come from an academic background, your degrees, your peer reviews, even your grades may help identify how well you're doing. You don't have to guess at that. You don't have to self identify. Someone else is telling you, this is where you're at. Here are though areas you can improve. And as a developer, you don't have an objective standard to meet most of the time. You're going to be constantly failing as you learn something new. This is a very normal part of being a developer. You're going to fail at something almost every single day and usually more than once a day. This has a tendency to make people feel hopelessly behind, right? Especially as you're learning in the very early stages of being a developer or especially if you're learning very early stages of a new language. This is when you start failing constantly and you're going to feel hopelessly behind. This is very normal. And the best way to fight it is to keep building new things and working through the failure to success points so that you can remind yourself failure is normal. And I can work through that failure, learn from that failure and be better when it occurs again. Validate yourself and celebrate your own progress. Beware of imposter syndrome as it can kill your drive and stall your progress as a developer and perhaps even deter you from becoming a developer altogether. So that's number two. Beware of imposter syndrome and make sure you are self validating that you're reflecting on how much you've learned and the value of all of those failures. All of those failures are new opportunities for you to learn. So beware of imposter syndrome. Now we're going to talk about today's sponsor, Rollbar. You know, we're talking about failure and you are going to fail. You're going to deal with errors in your code. You're going to deal with errors even in your production code sometimes and dealing with errors. Honestly, it's sometimes it sucks because they're difficult to find. Sometimes you're relying on users to report those errors to you so you can actually know what's going wrong. You may end up going and digging through logs because maybe locally everything is working fine and all of your tests are passing locally. Rollbar helps solve this problem and it works with all major languages and frameworks. You can start tracking production errors and deployments in eight minutes or less and when you actually integrate Rollbar into existing development workflows, you can send things like alerts to Slack and Hibchat or you can create issues in your GitHub account or your Gira, Sona, Pivotal tracker. The ones that you probably are already using anyway. To validate the idea that Rollbar is a fantastic product, some of their major customers include Heroku and Twilio, Kayak, Instacart, Zendesk, Twitch. These are massive, massive software companies that are using Rollbar to help them solve production errors and Rollbar wants you to start tracking your production errors with them for free. You can do that as a listener of Developer Tea. They have the Bootstrap plan that's free for 90 days or 300,000 errors that I mentioned once again it is free. You can get that offer by going to rollbar.com slash Developer Tea. Of course, that link will be in the show notes. Go and check it out rollbar.com slash Developer Tea. Thanks again to Rollbar for sponsoring today's episode of Developer Tea. We're talking about listener Jonas. Jonas is a designer and he's thinking about expanding his skills to become a web developer. I'm giving Jonas and all of you advice on when you want to expand your skills or change your career path to include development. What you can be thinking about as you start down that path. Really, this is through the lens of someone who has already gained a bunch of skills in a different area. Someone who has already created a career for themselves in something else and you're wanting to adopt development whether that's web development, software development, front end development, whatever it is, you're wanting to become a developer. You're wanting to adopt programming skills and start thinking about systems. That's what we're talking about here. Really, all of the advice that I've given to beginners in the past applies in some way to you as well. Make sure you can go and check out those episodes. We've started with two of our four tips. The first one was becoming a developer doesn't mean you have to change the way your brain works. Number two, beware of imposter syndrome and now we're on to number three. Don't ignore expertise from your previous career. Let me say that again. Don't ignore expertise from your previous career or a better way to say it. Use the expertise that you've already gained in your previous career as a developer. It will make you a better developer when you use previous expertise. As a designer, Jonah, you will be using your design skills constantly to inform your development projects. People coming from all different backgrounds have gained skills from different fields because software development is largely based on abstraction and modeling, which means that software development is actually a descriptor for something else. Most of the time your code is describing a system in the real world or it's describing an idea in the real world. So you can benefit from almost any secondary skill set if you're willing to draw the correlations with development. For example, let's say you are a banker. Well, you understand interest rates. You understand rate of change and most likely you'll intuitively be able to understand how big O notation and algorithmic complexity work based on the math you already know, right? Based on the things that you're already being exposed to as a banker because some financial models are primarily based on trends or perhaps the human side of things as a banker, you might have a better understanding of economics and psychological trade offs and what causes people to make certain decisions with their money. And these are things that you can use as a developer. These are skills, these are ways of thinking that you can bring into your development process because the way people spend their money is also similar to the way that people spend their time. You understand economics of money, then you can also understand the economics of time, the decision making process. So if you ignored these skills as a developer, you might be missing out on a lot of context and the fulfillment that comes with exercising your expertise, not only that, but you may be missing out on a promotion in your job as a developer because you used extra skills that other people in your company may not necessarily have, right? It is a unique skill set that you are bringing into your new context. So again, number three, don't ignore the expertise from your previous career. In fact, you should integrate the expertise from your previous career. And number four, finally, provide yourself with consistent immersion in software development language. While being a developer doesn't mean you have to suddenly take on the stereotypical persona of the developer, you certainly need to expose your brain to the material you want to learn. Of course, there should be a balance here, right? And endating yourself with content at some point becomes a waste of your time and energy because you're only going to retain so much information, but you can't expect to be half-hearted in the learning process. You can't sort of kind of become a developer, right? Pursue the learning process and language fluency with consistency. Now, when I say language here, I'm talking about fluency with the concepts and the language that developers used to discuss the concepts of development, not necessarily a specific programming language. So this fluency, this consistency comes from immersing yourself in that language and doing it regularly, talking with other developers regularly, listen to this podcast or other development-related podcasts. Watch YouTube videos, go and read blog posts. These are the kinds of things that you can do to start becoming fluent in the language. You don't have to know exactly what everything means, but immersing yourself in that language, you'll start to pick up on what those things mean. And this is going to feel sort of like you're learning by Osmosis, but the truth is our brains have an enormous ability to process things without us actively processing them. In other words, they're kind of working on them in the background. And we don't have to be actively thinking about something. If we hear something over and over, we become familiar with the context associated with that particular word, for example, right? So listening to people talk about development can help you learn a lot about development because your brain is going to process that information and you start to learn the context in which a word is being used. So don't take the easy way out on a problem, work through it and allow yourself to struggle a bit. Don't take the fast way out every time. Struggle as often as you can. The more comfortable you become, being in the unfamiliar territory, the better you will become as a developer in the long run. So you're going to immerse yourself in the difficult parts of being a developer. Immerse yourself in hard projects. Immerse yourself in difficult errors. This is going to make you a significantly better developer. Now, specifically, Jonah, because you are a designer, you have a unique opportunity of seeing the whole stack of processes and pieces coming together in one final orchestrated creation. You see everything coming together. You have a unique perspective in that regard. I would highly recommend that you design and develop a few projects from start to finish so you can see the bumpy transition points required to take design iterations and execute them in practice. This will help you become both a better designer and a better developer. One of the developers main jobs is to communicate well with designers and that gives you a huge opportunity with your existing experience to become truly great at that particular skill. So because you are a designer, you're ultimately going to understand the beginning all the way to the end of the implementation process. That's where your unique value is going to come to play, Jonah. So once again, going back through these four tips for you, if you are coming to development from a different career field, number one, becoming a developer doesn't mean that you have to change the way your brain works. You're simply learning new skills. You do not have to change your value systems. Number two, beware of imposter syndrome. You are going to fail a lot. Don't allow those failures to keep you down. Beware of imposter syndrome and remind yourself of your own progress. Go back and reflect how much you have learned. Number three, don't ignore expertise from your previous career, but instead integrate the expertise from your previous career. And number four, provide yourself with consistent immersion in software development language. If you like to read, go and pick up a few books. If you like listening to podcasts, then subscribe to Developer Tea. It's a good, a good moment for a plug there. Subscribe to Developer Teaor other development related podcasts on spec as well as elsewhere. There's tons of content out there that you can immerse yourself in far more than you have the time to immerse yourself in. So be certain that you are also not over extending yourself. Don't try to take in more information than you can hold in because then you're going to burn out. You're not going to have enough rest, but certainly consistency, regularity with the immersion, the amount of studying you're doing, that is incredibly important. So that is why I included that as number four, immerse yourself in the language of the field. Thank you so much for listening to today's episode. Thank you, Jonna, for sending in your questions. If you have a question for me, you can reach me at developertea@gmail.com. You can join the spec Slack community by going to spec.fm slash Slack. And you can find me on Twitter at at Developer Tea. Thank you again to today's sponsor, Rollbar. If you have errors in production and all of you do and you're not tracking them, then Rollbar may be a great solution for you. Go and check it out. Free for 90 days on the bootstrap plan that's rollbar.com slash Developer Tea. Thanks again to Rollbar for sponsoring Developer Tea. Thank you again for listening. Make sure you subscribe. And until next time, enjoy your tea.