Usually on the show I talk about ideas and typically those ideas are not just my own ideas. A lot of the time it's based on research and my commentary around that research and how that might apply to you as a developer. Today's episode we're going to veer a little bit away from that. We're going to talk about my personal experience and on top of that we're actually going to talk about a specific technology. I've learned react over the past couple of years and even saying that sentence feels wrong to me because I think you don't really ever learn a technology. You use it in different ways and sometimes you use it well and other times maybe you're learning better ways to use it. Even though we're talking about using react in today's episode, a lot of what I'm going to talk about can apply to a lot of different technology. Really, this is an episode about the experience of learning and more importantly the experience of learning as kind of a non-beginner, learning something in your career as you're actually using it. More than approaching this from the perspective of trying to get from ground zero to workable to a higherable, instead I had to approach this from the perspective of already having usable skills, already having marketable skills and trying to add to that list. A lot of developers who are listening to the show right now, hopefully you can relate to this conundrum. That's what we're talking about in today's episode. It's a little bit different. My name is Jonathan Cutrell, you're listening to Developer Tea. My goal on this show is to help driven developers like you connect to your career purpose and do better work so you can have a positive influence on the people around you. Before we dive into today's episode any further, I want to take a moment to thank today's sponsor, Linode. If you've been listening to Developer Tea for very long at all, then you know about Linode. Linode is providing Developer Tealisteners with $20 worth of credit. That's equivalent to four free months on their service. Now what does that mean? That means that you can actually get started with Linode for as little as $5 a month. So even after that $20 worth of credit runs out, you're only going to be paying $5 a month on that intro plan. That plan gets you a gigabyte of RAM on in Linode server. Again, that's $5 a month. They also have much more sophisticated plans like their high memory plans that start at 16 gigabytes a month. They have a seven day money back guarantee and you can get a server running in just a few minutes with your choice of Linux distribution resources and the location, the physical location of that server. Now something that you may not know, even if you are a listener of Developer Tea is that Linode is hiring. You can find out more about Linode's positions, their open positions by going to Linode.com slash careers. And you can take advantage of that $20 worth of credit by using the promo code Developer Tea2018 at checkout head over to Linode.com slash Developer Teathat's all one word, Linode.com slash Developer Teato get started today. Thanks again to Linode for sponsoring today's episode. So if you are a developer, especially if you're already in your career, then either you have heard that it's important to continue learning or eventually you will. You'll hear it on this podcast, but you'll learn it from all of your peers. Hopefully you work in an environment where learning is encouraged. And even if you don't, eventually you're learning is kind of required anyway. Not only is it encouraged, but to stay afloat, to stay competitive as a developer, you almost will certainly will have to add to your skill list. We've talked about this on the show quite a bit. And this is a conundrum because the rate at which new tools are coming on the market, and even the rate at which the old tools that many of us already know and have used for years are being updated or otherwise deprecated and replaced, that rate far outpaces any of our ability to learn, to add those skills to our toolset. This is very different from a lot of other career paths. Developers face a new challenge in this arena because hypothetically speaking, most other career paths, they kind of merge best practices with best tooling. Think about that for a second. If you are a welder, your toolset is probably going to stay relatively static. You might get a new tool that looks a lot like the old one, perhaps. It's constructed better, made out of better materials, but the practice, the actual welding process is largely the same. The principles that underlie it, they're largely the same. And so the tool kind of becomes a part of the DNA of those best practices. And this isn't as true for developers. We have some best practices, but in many ways they become somewhat distant from the tooling itself. And the tooling, well, it's quite frankly a pretty large part of what we do as developers. It's not to say that it's all that we do or that it has to be complex or even that you have to have a wide variety of tools. You can succeed as a developer with a very narrow variety of tools. However, that is increasingly less true. Now again, that doesn't mean that you're doomed. The outpacing of those new tools on the market doesn't mean that suddenly the tool link that you do have the ability to learn and you do have the resources and time to learn that that tooling is not going to be valuable. That's not at all what it means. Instead it means that you have to choose a strategy. You have to decide not only what you should learn, but also what you shouldn't, things that you shouldn't put your time in to. Things or frameworks or ways of thinking and doing, even entire paradigms of programming, that you don't necessarily have to master to be successful. In particular, to be successful with a career in development. But with that said, there is this constant tension, this pulling between trying to learn new things and being productive with the things you already know how to use. And so there's a lot of ways to go about making a decision to finally pull the trigger to invest the time to learn something new. There are a lot of heuristics you can use and probably even formulas out there that people use to decide when they're going to learn a new tool. You may use something, for example, as a front end developer, like a front end budget. Your front end budget requires that you learn how to, for example, use SVGs. Right? Hopefully that's on your list of things that you use as a front end developer, but it's not always cut and dry. There's not a perfect, reliable formula for when you should pull that trigger, when you should spend the time to learn something. In this particular case, for me, the formula or maybe better put the heuristic, the gut feeling that I had was, I'm interested in this. And it seems like it's gaining a lot of traction. And the second part of the gut feeling that I had was, ideologically, appreciate what react is doing. And then the final gut feeling or perhaps draw the heuristic that I used was the pain that I was experiencing with my existing tooling. If you're not familiar with React, then you're probably not a web developer at this point. Or maybe you use something similar to React, or you've heard of something similar to React. But the pain that React, at least at the time, was going to solve for me was managing state in a reasonably complex web application, managing state of a variety of widgets on the page, or even routing state, what URL should I be on. And React wasn't the first on the scene to help with this kind of thing. I mostly had heard about other frameworks that addressed similar problems that created a little bit more structure, and this was appealing to me, even though if at first I didn't really understand exactly what that meant, I didn't really know how everything would fit together. I just was attracted to the idea of having a more structured application process. And so I started to look into these things, but I didn't have the time and I couldn't justify it to my employer at the time, because what we were doing was more or less working. We were able to accomplish what we were trying to accomplish, relatively under budget. And so this springs up kind of the first point. There's not always a direct and immediate monetary gain that you can prove. Sometimes it takes time and it takes measurement. And even then it's a theory until you actually go out and learn. Learning is risky, taking time to invest in something that doesn't have a direct return has latent returns. This is called investment and it's risky by nature. Most investments are. So you may feel the draw to learn and to add new skills to your list of capabilities. For you personally, but also even for your employer, you may feel that this is a strong move. But you have to understand that from your employer's perspective, it may not be as cut and dry as it is for you. And you'll notice that many things that we talk about in today's episode, they end up not being cut and dry. They end up being much more complicated and nuanced than simply finding a new tool that you think you should use and investing the time into using it. Eventually react, the early versions of react were released and I watched the progress of this early release and I was excited by kind of the ideological concepts again because everything that I was hearing was basically addressing the pain points that I saw in my existing code. The problem was that I couldn't be productive in it on day one. I didn't totally understand how JSX was working for example. So getting from the first kind of interest level to working code, there was a little bit of a barrier there. But I finally encountered an application that we were hired to build and the application was sufficiently complex that we couldn't really discuss out loud how we would build it without a better state management approach. So this was the perfect opportunity to use a tool that was better suited for the job and it just so happened that with react, the state management stuff became significantly easier. Well, that's what I thought anyway. Although at the surface level, the state management of the application seems like it would have been a whole lot easier to manage and react. I found out quickly that all of the example applications that I had seen before, they were clean. They represented the best parts. They were kind of the advertisement, the easy advertisement for react. And so I had to learn the hard way that apps still are ugly sometimes. Sometimes the first version, especially when you're learning, the first version is going to be maybe even uglier than if you hadn't used that new tool. Now I want to be very clear. It wasn't that using react was the wrong choice. Looking back now, I think I could write a much better application and I would absolutely use react for that application. But the problem that I had was expecting that the tool and learning the tool itself would kind of come with all of the benefits that the tool promised. This wasn't an accurate picture of reality. I had kind of misguided perception and misguided expectations of what react was providing to me. React was not providing me a restricted tool set where I couldn't screw up. It wasn't providing to me best practices in a library. It wasn't providing me a guarantee of clean code, of working code. It certainly didn't provide me an automatic button for cleaning up the code. It wasn't like I could take my old code and shove it into this new tool and suddenly expect things to get better. Instead, what react provided me was quite literally just a tool, a new tool. A new tool with new capabilities, but also new hazards, new ways of screwing up, new ways of introducing bad code. A few years later, I encountered an application that kind of took this to the max. The architecture of the application was very difficult to understand and a lot of the internals of the app were still kind of skirting around things that react provide support for. They're managing state on their own. They were manipulating the DOM and ultimately all of those details aside, a lot of the benefits of using React were not apparent. I consider this a kind of morphed type of appropriation where we take a tool as a developer and we put it into our tool set by including it in our code base somehow using parts and pieces and features from that particular tool set, but not really gaining the real benefits out of it. We're just kind of abusing it so that we can say that we're using it. This has been another lesson for me that as I use React, many times I'll find myself trying to force an old pattern or a pattern that is different from what the kind of the tool would naturally support. I have to take a step back and learn a different way of thinking. Ultimately, that may be my biggest message for today's episode and that is that when you learn new tools, you're not going to get the best practices that go along with those tools for free. You have to adapt the way that you think. If you're thinking about learning React, I encourage you to instead of viewing this as learning the tool, view this as learning the concept, start by understanding why React exists in the first place. This is true for any tool. Start by understanding what this tool does differently from another one. Try to learn the ideology of the tool. Bounce that against the best practices that you already know as developer. Bounce that against the design patterns that you know about. Watch out for things like code smells. Imagine what it would take to test that code as a side point. If your code becomes very difficult to test, then you're probably doing something poorly. You're probably doing something that you could be doing better differently. I've learned a lot more on my journey of learning React. I've learned a lot about people. You can learn this with any tool about how people gather around a tool and how the tool evolves in response to a community. It's especially true for open source tooling and for supporting tooling, things that use React and that React users can use as well. I've learned a lot about how to approach code differently. I'm going to share some of that in future episodes. For this episode, I just want to encourage you to think about your tooling a little bit differently. Instead of learning a tool, you're using a tool to learn a concept. The tool itself is kind of an implementation detail. It's an afterthought. The tool may make something possible, but the concept is what makes it valuable. If you take nothing away from today's episode, then take that away. You can transfer concepts between tools. When something comes along and unseats React, or perhaps is just a competitor to it, you can take the concepts that you've learned by using the tool React and transfer them. They become less volatile. They become much more sustainably valuable than if you only learned the syntax, how to use a tool. Thank you so much for listening to today's episode of DeveloperT. I hope this resounded with some of you who are learning React today. I encourage you to set a personal level, I think, React as an excellent tool set. Certainly not the only good JavaScript tooling available. If you're starting out as a developer, or if you are a seasoned web developer, or even not a web developer, if you're a native developer, then encourage you to take a look at React. If you haven't already, it seems like a little bit of a big of a thing now. Certainly, if this is the first time that you're hearing about it, spend some time doing what it would research, it is incredibly important to software Developer Today. Thank you so much for listening. Thank you again to today's episode sponsor, Linode. Linode is going to give you $20 worth of credit. Just by heading over to Linode.com slash developerT, you can get that credit applied to your account. $20 is worth four months on Linode's introductory service. Head over to Linode.com slash developerT. Thank you again to Linode. Thanks so much for listening. Until next time, enjoy your tea.