The Benefit of Our Predecessors
Published 11/27/2019
If you were born one year earlier, something would likely have changed in your life. In today's episode, we're taking a moment to express a bit of gratitude for the environment that we grew up in, and the people who helped us build our careers today.
What lessons we can learn from the people who developed before us?
🙏Thanks to our Sponsor: Abstract
Visit www.abstract.com and sign your team up for a 14-day free trial.
🧡 Leave a Review
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.
🍵 Subscribe to the Tea Break Challenge
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/.
Transcript (Generated by OpenAI Whisper)
Imagine if you had been born one day earlier than you were born. What would have changed about your life? Most reasonable people probably would answer that not much would have changed. That we likely would have followed very similar paths and whatever the differences were, were probably fairly well contained. And we'd have similar interests, opportunities, even similar jobs. But if we continue to move that marker, things change a little bit. In today's episode, we're taking a moment to express a bit of gratitude for our environment, the things that we couldn't control that have provided us the opportunity to work in this exciting field. My name is Jonathan Cottrell. You're listening to Developer Tea. And my goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. And so if you were born a day earlier, perhaps very little effect at all. But if you were born a few months or a year earlier, something would change. And we probably can't predict at all what would have changed, but certainly something. And even more so if we go back to the beginning of the world, we're talking about 10, 20, 30 years ago. This is particularly true in this industry. Because for those of us who grew up learning these languages that are abstracted far away from the metal, from sea or assembly, we've learned languages that weren't even around for many of us when we were born. And it's not just about the language. More abstractly, we're talking about the types of problems that have been solved collectively. The kinds of abstractions that we all rely on. The kinds of innovation that the entire industry is moved forward by. Faster processors, more memory in less space. All kinds of problems that are being solved in an open source format so everyone has access to those solutions. And tools that are free to use, even in commercial projects. Most of us have built our careers on the basis of work done by other people. And this isn't novel to computer science. This isn't novel to programming. This is something that is deeply human. Taking advantage of the work of the people who came before us and also the people who are around us now. This helps move us all forward. So what are the lessons that we can learn from the fact that much of our success, not just as programmers but as humans, is reliant on our ability to learn from the people who came before us? We're going to talk about that right after we talk about today's sponsor, Abstract. Today, designers spend a ton of time just doing administrative work around the design. They have to gather feedback from all kinds of sources, whether that's a stakeholder or another designer or even developers. And really, they never know what changes have been incorporated and approved, especially if it's multiple designers working on the same thing. This is why the former Twitter principal designer Josh Brewer co-founded Abstract. Abstract acts kind of like GitHub, but it's made for designers. It's your team's version-controlled source of truth for design work. This program is designed to help you get the most out of your work. It's designed to help you get the most out of your work. It's designed to help you get the most out of your work. It's designed to help you get the most out of your work. It's designed to help you get the most out of your work. brings all of the design into a single unified place for both those designers, but also the developers and stakeholders to come and provide collaboration and keep the work moving in the direction it needs to go. And this isn't a brand new company. In fact, companies that you know about, like Microsoft, Spotify, Cisco, thousands of others across 75 different countries, already rely on Abstract to improve their design workflows. You can version your design files, you canension your design files, you canension your design files, you canension your design files, present your work, you can request the reviews like you would on a PR, you can collect feedback, and you can even give your developers direct access to all the specs, all from single place. You can spend less time searching for those design files, tracking down feedback, and instead spend time doing the thing that designers do best, innovating and collaborating. Sign your team up for free today for a 14-day trial by going over to www.abstract.com. Thanks again to Abstract for sponsoring today's episode of Developer Tea. So in today's episode, we're talking about learning from the people who came before us and finding some level of gratitude for this platform of knowledge that we're able to work from, that we're able to benefit from. And it's not just a group of benevolent people that are gone now. We still are benefiting from each other on a regular basis. So what can we learn? Well, there's a couple of lessons. One of the lessons that sticks out most to me is that the problem itself doesn't define how important the work is. Think about this for a moment. Some of the most important work in computer science would seem trivial today. Some of the most important information that we can learn from each other is that the problem itself doesn't define how important it is. So think about this for a moment. Some of the most important work in computer science would seem trivial today. advancements, algorithms, thinking and writing, literature, some of the most important contributions to our industry would be trivial to implement today. Now, it's not that the problem was trivial to solve and not that the problem itself was unimportant, but instead that the problem was not relative to the intelligence of the person solving it. It was relative to the intelligence of the person solving it. It was relative to the intelligence of the person solving it. It was relative to the environment that they were solving the problem in. And so if you were to take a computer scientist from the earliest days of computer science before all of the wonderful abstractions that we use today were ever even thought of, if you were to take one of those computer scientists and drop them 10 or 20 or 30 years forward into the future, who knows what they would have worked on, but it certainly wouldn't have been the same problems that they worked on in the context that they were in. So I think that's a really important lesson to learn. And I think that's a really important lesson to learn. And I think that's a really important lesson to learn. And I think that's a really important So the lesson here is the work that you're doing, whatever's in front of you, whatever's in this context, the problems that you solve, the specifics of those problems don't define how good of a programmer you are. They don't define how valuable your career is. The next lesson that we can learn from all of those who came before us is regardless of if you open source every single bit of your work, you can't find the evolution of your evolution. work, or if you keep it copyrighted, if you hold on to it, you keep it close to the chest, regardless of what level of legality you wrap around your work. Many of us don't have the freedom to share every bit of our work because of whatever our employment situation is. But when we contribute, when we share either our thoughts, our code, our solutions, even if all we share is our time to help mentor another engineer, whenever we share, we all benefit. And those benefits may have ripples into the future that you can't really foresee. So as you reflect on the surroundings, the kind of platform that you work from as a programmer in today's industry, consider how you can share your work. And if you can share your work, consider what you can contribute to the people around you, to the industry itself. What can you provide back? And perhaps what are you already providing back that is building this industry every day? Thank you so much for listening to today's episode of Developer Tea. Thank you again to Abstract for sponsoring today's episode. Your 14-day free trial as a team can be started over at www.abstract.com. Thank you so much for listening. Today's episode was a part of the SPEC Network. Head over to spec.fm to find other podcasts like this one. Today's episode was also produced by Sarah Jackson. My name is Jonathan Cottrell. And until next time, enjoy your tea.