In today's episode, we continue the DCR traits of a great developer. Today's trait is having the grit of a scientist. Today's episode is sponsored by Fuse! Build native iOS and Android apps with less code and better collaboration. Head over to spec.fm/fuse to learn more today!
In today's episode, we continue the DCR traits of a great developer. Today's trait is having the grit of a scientist.
Today's episode is sponsored by Fuse! Build native iOS and Android apps with less code and better collaboration. Head over to spec.fm/fuse to learn more today!
New Promo Code: “dt” will give you listeners 70% off for 12 months. 70%!!! The code must be redeemed by December 31st 2017.
I'm going to start off this episode by giving you a quick heads up. You may hear rain sounds in the background and typically I would avoid recording during rain sounds if possible but as it turns out Hurricane Irma has just left Florida and has gone through Georgia and Alabama and now it's in Tennessee where I am currently recording this episode. You're going to hear a little bit of that in the background of course our thoughts are definitely with those of you who are listening from South Florida. I hope that you have stayed safe as this massive, massive storm has come through your area. Thank you so much for listening to today's episode. My name is Jonathan Cutrell. My goal on this show, Developer Tea, is to help you become a better developer. We have the short focused episodes typically covering one or two topics unless it's a longer interview. We try to keep these monologue style episodes as short as possible so that we deliver as much value in the least amount of time as possible because time is precious to me and to you. But just because these episodes are short does not mean that they are easy to digest. So I encourage you to take time to think about what we discussed on this episode. Some of discussions with other developers in person have discussions with people who are non-developers about the ideas that are presented on this show. You know this really only works if you take it out of your headphones and put it into conversation, take action on it. Take some time to journal your ideas. Maybe you have disagreements or maybe you have refinements on the ideas that are presented on this show. I highly encourage you to take this stuff we talk about into your own work. And that certainly applies to today's episode. We're talking about the traits that make a great developer. And perhaps the other way of saying it is what traits every great developer exhibits. And these are traits that every developer, every great developer, if you were to sit down and interview them, you could find that they have relied on these traits throughout their career. Maybe they wouldn't tell you this list explicitly. But you can uncover these things from any good developer. They would tell you these are important. So we're going to discuss one of those traits today. The last one we discussed was rational humility. And that is the foundation for learning. We discussed that you don't want to be all the way towards the side of artificial humility where you act humble by acting like you don't know anything or that you're not good enough for any job. Certainly that's not productive. But then on the opposite end where a lot of developers end up over the years is developing a sense of narcissism or arrogance. This is definitely something we want to avoid as developers as well. And both of those can be poisonous, but right there in the middle that rational humility, the idea that you recognize very reasonably that you have a lot left to learn. And that very often you're going to be wrong. And even the best developers very often they get things wrong and learning is a constant process. You'll never be done with that. So that should inform the idea that everything that you say and everything that you do, you're doing it with the recognition that something could go wrong. That a decision you make may just not be the best decision. You will make mistakes. And sometimes even when you have very good reasons for making decisions and for doing the things that you do, they're going to turn out poorly. And that actually leads directly into today's episode. And we're going to be talking about the next trait. And that is having the grit of a scientist, the grit of a scientist. I want to talk about the two parts of that first grit and then the second part of scientists. You know what is grit? Well, this is something that a lot of research has been done recently. Of course, Angela Duckworth has a book by the name of grit. It is grit, the power of passion and perseverance. If you want to go and read more about grit, there's videos of Angela and certainly podcast episodes on the subject of grit, including an excellent, free, economic episode on the subject of grit. But I want to present this to you through the light of what it means as a developer to utilize this concept of grit. What is grit? To put it very simply, grit is the ability to stick to something. In other words, you see something through to the end. And this is important because a lot of the work that we do as developers, there may be 80% of it that is really particularly interesting to us. And then 20% that is really not very interesting at all. There may be some custodial work that we do as developers. There may be some things that we have to do that are only business functions. They don't really necessarily excite the builder part of our brains or the architect part of our brains. And there may be developers who absolutely see value in those pieces as well. But it's important to recognize that you're not always going to have the most interesting problem to solve sitting on your desk. Sometimes you're going to be fighting with your command line. Sometimes you're going to be fighting with a bug that you can't quite figure out. And grit on its own means that you have the kind of the will, the will power to stick to something. And this also applies to your learning careers developer. We've discussed this on the show plenty of times before. But the idea that grit is important for your learning career. What this really means is if you choose to move forward, let's say with learning a particular language or new technology of any kind really, have the grit to see that learning process through. Of course, it's important to understand when is the right time to give up on something if the technology is not going to be viable or if it's not providing you with any particularly new perspective or knowledge that you didn't have before. There's plenty of reasons to give up on something. But what I see most often happening, especially with developers who are unsure of what to adopt next, is kind of a shotgun approach. And you learn a little bit of a lot of different things. And unfortunately, this leaves you basically in the same place that you started. So I recommend against that shotgun learning approach. And instead, adopting this concept, this gritty concept of sticking to one or two or three things that you learn a little bit deeper, learn a little bit more about. Now we mentioned that the attribute is not just grit, it is the grit of a scientist. And what does that mean? That's what we're going to talk about right after. We talk about today's sponsor, Fuse. With Fuse, you can build iOS and the Android apps with less code and better collaboration. If you've ever used something like Unity for game development, then you have a little bit of an idea of what Fuse provides for mobile application development. So Fuse 1.0 has launched their no longer in beta. And they have Fuse Studio now. It is their new premium editor and workspace for working with Fuse projects. This is included in the professional plan. But most people actually don't need the paid plan, which includes Fuse Studio. The Fuse platform itself and the free plan, they stand firmly on their own. So I highly recommend you go check it out, especially if you are a mobile application developer or if you're interested in becoming a mobile application developer. And the tool set has been a little bit daunting to you. I recommend you go and check it out. Spec.fm slash Fuse. You can learn more about what Fuse has to offer. Of course, it runs on Mac OS. It runs on Windows as well. And the Fuse installer, it includes everything that you need to get started. So there's no complicated process in getting started up. Go and check it out, Spec.fm slash Fuse. And you can learn more about the Fuse professional plan. You didn't go into a lot of detail on that, but you can learn more about what that professional plan offers for you when you're ready to upgrade to that. But you don't have to do that to begin with, Spec.fm slash Fuse. And it's free to get started. Thanks so much to Fuse for sponsoring today's episode of Developer Tea. So we're talking about grit and more specifically. We've already talked about grit a little bit. We're talking about having the grit of a scientist as developer. Now, I want to set this up for you because the idea that most people have in their mind, if they've heard and studied and learned about grit, is this idea that you stick to something until it succeeds. However, there is a reality that developers have to face. And that is the reality of failure. Whenever we sit down at our computers to write some code, or whenever we are drawing out an idea on a whiteboard. Whenever we have collaborative meetings with designers or product owners, we undertake the possibility of failure. We recognize it as developers very often in our work because we're constantly faced with perpetual failure. In fact, most of a project's life cycle is taking something that is failing and moving it to a non-failing state. This is really the concept of test-driven development. You write failing tests on purpose. And it's easy as a developer to take these failures to heart. This is why a lot of developers have a lot of frustration built up at the end of a given workday. This is a very emotional thing for a lot of people as well because we tie our own worth or our own competency to how many failures we are able to fix or, more importantly, how many failures we are unable to fix in a given day. And it may feel like as a developer that you're constantly in that failure state because quite honestly, you almost are. And this is why it's important to have the grit of a scientist. You see, scientists go through this as well. Whenever you set up an experiment, you create a hypothesis and you test that hypothesis. Of course, the scientific method allows for failure. This is not the kind of failure that grit will get you through, but rather, the grit needed for scientists is the ability to recognize failure, learn from that failure, and start a new experiment. So when you fail and you will fail many times as a developer, in fact, many times in a given day, when you do fail, the grit of a scientist is necessary for you to take a step back, observe the failure, recognize the components that contributed to the failure as much as practical, of course, and then learn from those components and start over. This is why it is so gritty. This is why it takes so much stick to itness to be a developer because you're constantly going back and trying again. The antithesis of this is pushing forward and accepting those failures as if they are now ingrained into a system, right? Pushing forward, not recognizing the components that are contributing to failure. This leads to incredibly poor code bases that are neglected because the failures were ignored instead of sticking to the problem and trying to solve it until it is solved through a process of iteration. The developer decides to move forward and solve it later or pass the buck to another developer or maybe accept the idea that the code base is bad. This is not something that a great developer will do. How can you develop this grit of a scientist? There's a few ways that you can practice this. The first is to actually go through that iterative process and specifically identify what stage you are in at a given point in time. You need to set up some assumptions and some hypotheses whenever you're getting ready to start solving a problem. You need to actually execute, go through the process of solving that problem and then you need to evaluate and then reiterate over that. The evaluation step is probably the most missed out of those three steps. Of course, this is an abbreviated version of the scientific method. I encourage you to go and Google and read a Wikipedia article on the scientific method. There's a lot that you can learn from this. If you take away one thing from today's episode, it is to evaluate and reiterate when you run into a problem. When you hit a point of failure, don't try to continue pushing. Evaluate that failure. If you ignore the failure and you never evaluate it, then you can't get better. It's impossible to recognize the patterns that lead to failure if you're not evaluating. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Fuse for sponsoring today's episode, head over to spec.fm slash Fuse, to get started with an all-in-one platform for iOS and Android development. It's going to totally change the way that people develop mobile applications. Thank you so much for listening. Make sure you subscribe if you don't want to miss out on the future traits of great developers. Once again, this is an extension of the Developer Career Roadmap episodes. If you haven't listened to those, you can find those on spec.fm. Thank you so much for listening and until next time, enjoy your tea.