And today's episode, I'd like to share some things that I wish I knew when I first started out in my career as a developer. And hopefully some of you will share some of the things you wish you knew as well. These kinds of insights can provide kind of a fast forward button on the learning process for developers who are at the beginning of their careers or maybe even mid-career. The things I'm going to talk about today are certainly not just for beginners. These are ideas that middle-level senior level developers can still benefit from. And if we think about our entire career as a constant sense of learning, where we are always beginners at something where we're always refining our skills or refining our perspectives, then these kind of I wish I knew discussions can always provide value to us, regardless of where they're coming from, what context they're coming from. So I'd like to encourage you to respond to this episode by sharing your own, I wish I knew, do this on Twitter, bonus points, if you mentioned Developer Tea, so I can see them. I'd develop a T on Twitter, I'd love to hear from you all. My name is Jonathan Cutrell, you're listening to Developer Tea and I create the show to help you, driven developers, find clarity, perspective and purpose in your careers. And before we get started, I do want to have a little bit of a disclaimer here. By no means do I expect that this show is going to provide you all of the coaching and mentoring wisdom that you need. Certainly, I believe that the perspectives that we're able to provide on this show can be helpful, otherwise I wouldn't do this. But there's only a certain amount of context and perspective that I or any one person can provide. So I want to encourage you to find other perspectives, seek them out and seek them out as soon as you can in your career. That's kind of a bonus item for today's episode. One thing I wish that somebody had told me when I first started out is that the perspectives of a variety of people are going to be perhaps the most useful thing that you can find in your career. And this is true for developers, it's true for non-developers, true for everyone in almost every kind of career, just in life in general. If you can seek perspectives, especially perspectives that are different than your own, that is where true learning comes from. We've talked about this quite a bit on the show and this isn't just a value statement that we should appreciate all kinds of people from all kinds of backgrounds. That certainly is a value that I hold, but it's not the only reason that I recommend heavily that you seek out the perspectives of people that are different than you. From a basic social science level, this is a self-serving thing just as much as it is a community serving thing. When you seek out the perspectives of people that are different than you, then you start avoiding some of the cognitive traps that people who are like you probably have in common with you. You can think about it like this. If you combine a bunch of people who studied the same subject, for example, to solve a particular problem, the way that they solve that problem is likely to have some similarities. Now, that's not to say that you won't have similarities between two people who study different things, but rather when you combine people who have different backgrounds, in this case we're talking about academics, but you can fill in the blank. This cultural background, then the frame of reference that a person comes from is going to inform the way they see the world. So when you have multiple frames of reference, especially when those frames are as dissimilar as possible, you end up with a much richer array of information. With more information, generally speaking, you can make better decisions. So that's our bonus item for today. The thing that I wish I had learned earlier in my career is that these diverse perspectives are perhaps one of the most valuable things that you can have in your career. We're going to take a quick break and talk about today's sponsor, Linode, and then we're going to come back and talk about the other three things that I wish I knew when I was starting out my career as a software developer. Today's episode is sponsored by Linode. With Linode, you can instantly deploy and manage an SSD server in the Linode Cloud. Not just one SSD server, you can deploy and network a bunch of SSD servers. And what can you do with these? Pretty much anything you'd like. In fact, if you are used to the normal SSD server in the Cloud discussion, then you're probably are thinking, this is just a web service. Linode recently started offering dedicated CPU instances. So these are designed for a consistent high performance computing, like video encoding or game servers. But of course, you can build almost anything on Linode because it's built on top of Linode. Pretty much anything you can build with Linode. So continuous integration, continuous delivery, you can easily deploy and maintain your entire infrastructure simply and totally cost effectively. Linode's tools make it easy to provision, secure, monitor, and backup your Cloud. Go and check it out, head over to Linode.com slash Developer Tea. They're going to give you $20 worth of credit. When you use the promo code Developer Tea2019, that's Developer Tea 2019, all one word, Lynne.com slash Developer Tea. Of course, again, a huge thank you to Linode for sponsoring today's episode. So let's get straight into the three things that I wish somebody had told me before I started my career as a software engineer. And here's the reality. There's a lot more than three things. I wish I could put a list together of all of the things that I've learned that I wish I could have known earlier. But really, that's kind of what a career is about. It's about learning these things for yourself over the course of your experience. And you can't just read a book and have all that knowledge readily available. You kind of have to have the experiences that muscle memory to really take on all of the knowledge that you need to succeed in a career. That's why experience is so important. But with some of these things in mind, if you go and seek out the same kind of information from other developers, you can have good pointers. These are kind of things that you can look out for. Ways of thinking that you may not have thought about naturally on your own. So let's go straight through these three things. The first one is that learning how to code eventually becomes less important than learning how to think about code. I'm going to say that again. Learning how to code, like learning the language or learning the idiosyncrasies of a given language's community or learning framework. Learning how to code eventually becomes less important than learning how to think about code. This is why many senior developers can move between languages without much of an issue. It's not because they've invested hours on end learning syntax. Maybe they did, but they can move between these languages much easier because instead, they've learned how to see problems through the lens of different languages. Rather than understanding languages so they can use them as a tool to solve a problem, they look at a problem through the lens of a language. And maybe a better way of thinking about this is the problem exists whether the language exists or not. And so to solve a problem with the language, to solve a problem with code, you first have to think about the problem. And once you've kind of worked out some of the problem, then you can take those different languages, there's different ways of thinking in code, and apply them, map them over the problem. Sometimes multiple languages will map perfectly fine over a problem. Sometimes languages are better suited for one problem type than another. But great developers, great software engineers understand that the code is secondary to the thinking about the code. This is a slight shift, it's going to change the way that you think about learning because instead of learning just syntax, which is still an important part of the equation, you'll start learning about technique, about patterns. And you can apply patterns no matter what language you're using. So that's the first thing. Learning how to code eventually becomes less important than learning how to think about code. The second thing I wish I learned earlier in my career is that finding a team that you enjoy working on is not about defining a perfect process. In other words, you shouldn't go around looking for specific elements of a process that you think is perfect. It's about finding a team that instead, you can harmonize well with. There are some things that great teams have in common, but people are individually different, and those differences are even more pronounced when you combine them. And so it wouldn't really make sense to go and blanket, apply every single process thing that you think is perfect to a team. A team has its own idiosyncrasies, it has its own rhythms, its own restrictions, and so your process is probably going to change. It will evolve. And what is perfect for one team may not be perfect for another. So it's more difficult for you to find a team that you can work well on that is already using a perfect process that you love. It's much more likely that you will find a team that you can harmonize well with. What do I mean by harmonize well with? Well, you get along, you have compatible values. You see the problem together fairly clearly, and some of these things are process oriented. The process that one person really enjoys doesn't totally jar with the process that another person on the team really enjoys. So these are more complex ways of thinking about a team. Instead of being dogmatic about a given process, look for a team that you harmonize well with. The third thing that I wish somebody had told me earlier in my career is that more often than not, the simplest thing is the right answer. Composing a lot of simple things together actually provides sufficient complexity for very powerful systems. Now, let me qualify what I mean by simple. I don't mean that you allow a large amount of technical debt in the name of doing something small and quick. I also don't mean that you choose an ugly experience for whatever the user is, whatever the receiver of your product is. When I say simple, I mean the thing that you can fit in your head easiest. As developers, we often try to solve broader problems than necessary. Sometimes we create complex systems because we expect that we will need them rather than actually experiencing that need. So if you start by creating small atomic solutions to small atomic problems, then the entire problem and the entire solution can all fit in your head. You can reason about them all at once. When you take that atomic solution to an atomic problem and you compose it with other solutions, maybe solutions that others on your team are making or solutions that you are making. You can start to create a system of simple solutions that work together. Of course, we're talking in abstract terms and there are very concrete ways that you can apply this knowledge. I trust that you will take these conversations into discussions that you have with maybe your manager or your clients, co-workers, your team members. Find people that care about your career and care about the work that you're producing. Your co-workers certainly care about the work that you're producing. A good manager will care about your career. So checking these ideas with them and finding ways to apply the simplest possible solution, for example, that's how you grow in your career. One week, one meeting, one project at a time. Thank you so much for listening to today's episode of Developer Tea and thank you again to Linode for sponsoring today's episode. Head over to Linode.com slash Developer Tea. Use the code Developer Tea2019 to check out and you'll get $20 worth of credit on Linode's platform. Thanks so much for listening to today's episode. This episode wouldn't be possible without our awesome producer Sarah Jackson and spec.fm. Speck is a network for designers and developers just like you who are looking to level up in their career. I would encourage you to go and instead of subscribing to today's episode to this podcast, go and subscribe to another podcast on spec.fm. Again, going back to that diverse voices discussion that we had at the beginning of the episode, there are other diverse voices on spec.fm that are going to be valuable to add to that kind of input consumption that you're doing with podcasts. Don't just listen to this one. Listen to other perspectives as well and there's some really great ones on the network at spec.fm. Thank you so much for listening and until next time, enjoy your tea.