We can all expect to change daily, monthly and yearly. In today's episode, we're going through an exercise to identify changes we've experienced in our lives to identify how far we've come and where we're headed.
If you have questions about today's episode, want to start a conversation about today's topic or just want to let us know if you found this episode valuable I encourage you to join the conversation or start your own on our community platform Spectrum.chat/specfm/developer-tea
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.
Stackbit lets you build and deploy a full JAMstack site, with an SSG and headless CMS in just a few clicks. You can already choose from about a dozen prebuilt themes for Hugo, Jekyll and Gatsby and connect to Forestry, NetlifyCMS, DatoCMS or Contentful.
Transcript (Generated by OpenAI Whisper)
Something difficult to accept is the fact that you will probably change. And you're probably going to change much more than you think you will. There's some good evidence that says that change happens not only when you're young, but throughout your life. Whether you're 18 or 58. You can expect to change a pretty significant amount in the next decade or so. And so it's useful and perhaps provides a bit of humility to take time to remember. Remember the way that you were and how you've changed. In today's episode, I'm going through that exercise publicly by giving you advice that I probably would have rejected 10 years ago. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal in this show is to help driven developers like you find clarity, perspective, and purpose in your career. And the truth is, I'm probably going to have new advice in 10 years from now that I would probably reject today. If we imagine that we are done changing, then we're probably going to cut ourselves off from growth. But that change is going to occur and we have to prepare for it. So one of the ways that you can prepare for it is to start accepting that it's likely that it's going to happen. And to remind yourself that this has happened in the past, that allows you to feel safer. Feel safer when you recognize that you're changing, that you have some new information that is prompting you to that change. These changes happen because of a variety of things, but most often because we learn new things about ourselves. We form new beliefs based on our experiences. And so there are times where we might feel like we'd like to travel back to our younger selves and provide some advice. And that's kind of what we're doing in today's episode. I'm mentally taking myself back to 10 years ago and trying to give myself a bit of advice that I can take forward into my career. And while I might not be able to benefit from this, perhaps the younger developers who are listening to this, or really anybody who's listening to this, may be able to take this advice. So we're going to start with a piece of advice about learning. But it's not just about learning, it's also about making decisions, making decisions about what you're locking yourself into. As humans, we have a little bit of an aversion to choosing something that destroys our optionality. In other words, locking ourselves into a given choice. This makes us have anxiety when we think about losing our options. But the truth is, research and experiences will show you that you're happier once you've made a locked-in decision. Now, some of this is because of our post-rationality. In other words, once you make that decision, you convince yourself that it was a good decision. But beyond that, for developers specifically, when you're learning, a lot of the deep knowledge that you have in a narrow area is likely to be transferable. In other words, if you learn very deeply about performance in one language, it's probable that the information that you learn about performance in that language will transfer at a deep level to another language. And so your intuition may tell you that you need to learn a broad set of things. And necessarily, when you start learning that broad set of things, you're likely to only go to a shallow depth. My advice to you is to narrow the things that you're considering learning. Many times on this podcast, I've recommended learning one language for six months, just focusing on one language for at least six months. This may sound like a short amount of time. But when you spend that focused energy, especially very early on, in learning that one area, you'll realize that you can take a pretty good step into the depth of that thing, even in six short months. So, this is something I recommend because I experienced this feeling, this need of trying to learn everything, trying to get some familiarity with everything. And this feeling comes from the sense, the incorrect sense that everyone else is learning everything. And we get this maybe because we expose ourselves to social media, maybe hacker news or something like that. And we see all of these different technologies. And we have the perception that all other great Developer That we respect and admire, they already know all of these tools. They already know all of this information, their experts in algorithms, their experts in data structures, their experts in 10 different languages, and they've architected, scaled systems, all of them. But the truth is, very few of them have done something across the board and almost all of the ones that have careers have focused in some area for a significant period of those careers. So, that's my first piece of advice, care less about your optionality and instead be willing to commit. The power of commitment will be felt in your kind of personal contentment. You'll appreciate the fact that you've committed and no longer do you have to kind of keep your head on a swivel. But you'll also realize that there's a compounding effect. If you can commit to a narrower range of things, there's a compounding effect when you start building true, deep expertise and that expertise is most often transferable. We're going to take a quick sponsor break and then we're going to come back and talk about two more pieces of advice that I probably would have rejected 10 years ago. Today's episode is sponsored by Stackbit. Stack sites and the Jamstack are growing fast. Front end developers pretty much already get it. It's fast, it's secure and as a developer, you still have full control over the markup and the design. But convincing clients to go static is a little bit harder to do. How will they update their content? This is kind of the main question that comes up in these conversations. Where's the CMS? The mainstream adoption of the Jamstack in a commercial context relies largely on solving this particular issue of content management. This is where our friends from Stackbit come in. Stackbit lets you build and deploy a Jamstack site, a full Jamstack site with a static site generator and a headless CMS in just a few clicks. You can already choose from a dozen prebuilt themes for Hugo, Jekyll and Gatsby and connect to pretty much all of the headless CMSs that you're used to using, like forestry or netlify or contentful. On top of that, Stackbit just released custom themes. Now you can import your own themes built on any static site generator, including the ones that we've already mentioned, but also from ViewPress, GridSum and others. Just add a Stackbit.Niamo file and define your content models. Your theme is ready to connect to any headless CMS. Stackbit allows you to test the strengths and weaknesses of the popular headless CMSs quickly and explore, which one is the right fit for your client or your project. Most of all, the source code for sites you provisioned through Stackbit stored right back in your own Git repo. So you can continue to design and develop locally without compromising your developer workflow. Go and check it out, Stackbit.com slash Developer Tea. That's Stackbit.com slash Developer Tea. Let us know what you think. So we're talking about advice that I probably would have rejected a decade ago. And you should have your own list of these things that you've learned in a decade and imagine yourself giving the advice to that younger version of yourself. And the way that you can think about this is, what are some of the major mistakes that you made and how would you go about hopefully rectifying those mistakes if you could replay history? Now, of course, this isn't a failproof way. All of this advice comes with a grain of salt as does everything that we say on this show. But this is a way to kind of post-mortem the past 10 years, a long-term version of yourself, a post-mortem over the last decade. There's a lot you can learn in that. So we're going to run through the next two pieces of advice that I probably would have rejected 10 years ago. The first piece of advice is to view every job you have for the rest of your life as temporary. And this is actually more in line with reality. Not only are people very likely to have many jobs, I think the average is somewhere around six or seven jobs in their careers. It may have changed since I looked at it last, but not only are we very likely to change jobs, very few people have long-running careers in a certain workplace. But we also eventually all leave the job one way or another. We are temporary as humans. We aren't here forever. And everything around us is changing. There are so many things about your job that you can't even control. For example, it's possible that the company that you work for will fold. So this has deep ramifications into your behaviors and the way that you operate with the people around you, the way that you collaborate, and all of the ways that you set yourself up in your career. Treats every job as temporary. Now this kind of clashes with our previous piece of advice of committing and being willing to let go of optionality. Our point here isn't to say that you're always keeping your eye out for the next job. The advice is still kind of cohesive with staying in the moment and working to the best of your ability in the job that you currently have. But there's a big difference in viewing your job as temporary and still committing to doing great work at that job versus viewing your job as the last job that you'll ever have. When you view your job as the last job that you'll ever have, then a lot of the things that otherwise might be possible very quickly become impossible. A lot of good habits that you may develop, like for example, taking time to build good documentation, paying attention to the impact that your work has on the people that are using your software or paying attention to the kinds of interactions that you have with your teammates. All of these things are necessary to building a long career that's full of change. If you imagine that your next job is going to be awarded based on the behaviors in your current job or based on the accomplishments in your current job, you're much more likely, and this is kind of the paradox here, you're much more likely to do a good job. You are paying more attention to the work you're doing today because it has ramifications on your future. You're taking nothing for granted in a lot of ways when you see your jobs as temporary. The final piece of advice is kind of along the same lines and really comes out of the second piece of advice we just gave about seeing your jobs as temporary. That is that you are not a good predictor of your own future. This is not only true based on the things that you think you will do, but also the things you think you will want, the way you think you'll behave, the kinds of problems that you'll want to solve or the kinds of personal issues that you'll have. A lot of the things that we expect to happen probably won't and a lot of the things that we don't expect to happen might. Of course, when we say it this way, it sounds obvious, it's hard to predict the future. But a lot of the things that we think we're good at predicting, we're just as bad at predicting those as we are at predicting random things that have nothing to do with us. We like to think that the things that we want today or the things that we envision for the next five years today are likely to come true or likely to stay the same and they aren't. And so when we imagine the future and when we try to put our minds into that future, we very often create these worlds that are never going to exist. And very often we also forget these imaginations. We forget the world that we thought might exist as we move into the future. Only enough, it feels like a lot of our imagination about the future ends up getting wasted. It's not that we shouldn't try to think about the future. In fact, I highly recommend that everything you do be done with the future in mind. But rather that we don't tie our happiness to some specific picture of the future that we've kind of imagined for ourselves. Instead, we keep the future in mind, but we take everything day by day. Thank you so much for listening to today's episode of Developer Tea. I hope this was helpful to those of you who are early in your careers especially, but also people who are kind of facing these changes and looking back and trying to remember or trying to remind yourself that you have changed, I highly encourage this kind of activity, this kind of exercise, because I think it gives you a moment to remind yourself that everything is temporary. Thank you so much for listening. Today's episode wouldn't be possible without our awesome sponsor, Stackbit, head over to Stackbit.com slash Developer Tea. And check out the magic today. Thank you so much for listening to today's episode. It also wouldn't be possible without spec.fm. Today's producer with Sarah Jackson, my name is Jonathan Cutrell. Until next time, enjoy your tea.