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. And 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. Rather than approaching this from the perspective of trying to get from ground zero to workable to hireable, 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. So that's what we're talking about in today's episode. It's a little bit different. My name is Jonathan Cottrell, and you're listening to Developer Tea. My goal on the show is to help driven developers like you connect with the world of software and technology. I'm Jonathan Cottrell, and you're listening 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 Tea listeners 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. That's equivalent to $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 a 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 that you're using. So you can get started with 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. They're 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 DEVELOPERTEA2018 at checkout. Head over to linode.com slash DEVELOPERTEA. That's all one word. Linode.com slash DEVELOPERTEA to get started today. Thanks again to Linode for sponsoring today's show. So if you are a developer, and 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 learning is kind of required anyway. Not only is it encouraged, but to stay afloat, to stay competitive as a developer, you almost 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 kind of our tool set, right? And this is very different from a lot of other career paths. Developers face kind of 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 tool set 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, part of the kind 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 tool. It's a pretty large tool. It's a pretty large tool. It's a pretty large tool. At the same time, evolution brings evolution, evolution brings evolution, evolution brings evolution, of what we do as developers. That'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 tooling 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 into, languages or frameworks or ways of learning that you shouldn't put your time into. There's a lot 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 good product. 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. Perhaps your front-end budget requires that you learn how to, for example, use SVGs, right? Hopefully that's on the table. Hopefully that's on the table. Hopefully that's on the table. Hopefully that's on the table. Hopefully that's on the table. Hopefully that's on the table. 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, well, I 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 of 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 brings 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. 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 andensionally, I watched the progress of this early release, and I was excited by 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. And 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... better state management approach. And 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... to manage in 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... 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 could do anything. I was not providing 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 provides is a set of tools that are not just a tool. It's a tool that provides me 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 provides 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 in a way that it's not going to be used. And then we take a tool and we put it in a way that it's not going to be used. At the same time, they were bringing the evolution of React and bringing evolution of React At the same time, they were bringing evolution of React At the same time, they were bringing evolution of React At the same time, they were bringing evolution of React At the same time, they were bringing evolution of React At the same time, they were bringing evolution of React At the same time, they were bringing evolution of React At the same time, they were bringing evolution of React At the same time, they were bringing evolution of React At the same time, they were bringing evolution of React At the same time, they were bringing evolution of React At the same time, they were bringing evolution of React At the same time, they were bringing evolution of React At the same time, they were bringing evolution of React At the same time, they were bringing evolution of React At the same time, they were bringing evolution of React or a pattern that is different from what the tool would naturally support. So 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. Try to learn the concept of the tool. Bounce that against the best practices that you already know as a developer. Bounce that against the kind of design patterns that you know about. And watch out for things like code smells. And imagine what it would take to test that code. As kind of a side point, if your code becomes very difficult to test, 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. That'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. And I'm going to share some of that in future episodes. But 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. That 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 Developer Tea. I hope this resounded with some of you who are learning React today. I hope this resounded with some of you who are learning React today. I hope this resounded with some of you who are learning React today. I encourage you, I encourage you, just at a personal level, I think React is an excellent tool set. It's certainly not the only good JavaScript tooling available. But if you're starting out as a developer, or if you are a seasoned web developer, or even not a web developer, or even not a web developer, if you're a native developer, then I encourage you to take a look at React. If you haven't already, it seems like a little bit of a ubiquitous thing now. But certainly if this is the first time that you're hearing about it, spend some time doing a little bit of research. It is incredibly important to software developers 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 developer tea. 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 developer tea. Thank you again to Linode. Thanks so much for listening. And until next time, enjoy your tea.