You're a brand new engineer or maybe a seasoned engineer, but you're starting a new job. What are some of the behaviors that you might think you shouldn't engage in, but actually you should? My name is Jonathan Cutrella listening to Developer Tea. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. When you start a new job, you can feel intimidating. In fact, for most people, it does feel intimidating. This is especially true for younger engineers who are joining a team of experienced engineers. The truth is, if you've been on a team for some time, you begin to acclimate. You start to adopt their language, maybe their patterns, some things become second nature to you. If you were to move to a different team, even within the same company, but certainly, if you were to move to a different team outside of that company, then all of those norms, all of those patterns, all of that muscle memory that you have from that team, what kind of disappears. Far too often, what this in-zoop, encouraging new members of teams to do was a handful of behaviors, but actually, they should really be doing the opposite. We're going to talk about those behaviors today. We're specifically going to focus on three of those behaviors. The first is the tendency to sit back and soak it all in. The idea that you need to take time to understand the norms, that you need to take time to listen to all of the acronyms or all of the special language, all of the various process language that your new team is using. This is kind of problematic. The reason it's problematic is because the next engineer that comes along is going to have the same amount of energy loss, the inefficiency of that onboarding process. It makes sense to take the time to clarify. Here's the special position that you find yourself in as a newcomer. You have what you've probably heard, termed as fresh eyes. Usually, when we talk about fresh eyes, we're talking about solving a problem that somebody else has been trying to solve for a while. You come into a PR, you come into a code base that you haven't seen before and your fresh eyes bring a new perspective that the other person may have some kind of attention blindness to. Some blindness is the tendency to look over something that might be obvious to another person because you've spent so much time looking at it from a different perspective. When you come into a new team, you have fresh eyes. Specifically, you have the eyes of a new engineer. This is a valuable and critically, an expiring aspect of your participation, your position on the team. So why is this important? Well, if it's expiring, that means you're not going to be able to go back and become a new engineer on this team again. It's difficult to go back and have fresh eyes all over again because as you begin to adopt the same heuristics that your team members adopt, as you begin to gain similar language, you can no longer feel that very important confusion that you're feeling right now. It's necessary and critical to take advantage of your confusion. What does it mean to take advantage of your confusion? When you have a moment of confusion as a new member of a team, you should speak up. You should be able to raise your hand, proverbially, send a message to your team in Slack or send an email or add a comment to a PR wherever it is that you can raise your voice and say, this is confusing to me. The intent here is twofold. One, for future newcomers, the less confusion, the less time necessary to acclimate, the faster that person can become productive with that team. So your work done as a new member to identify points of confusion will likely help kind of blaze the path for the newcomers after you. But perhaps even more critically, as you reduce the confusion of the institutional knowledge, all of the kind of in-club language on your new team, that clarification process will improve your documentation. It will improve your communication with other teams within your company, for example. And ultimately, it will reduce the cognitive load necessary to work with your team. So here's what I want you to do to kind of re-situate your brain as a newcomer. I want you to think about your position, your unique position as a prime time, a prime opportunity to identify high cognitive load barriers to entry. Your job as a newcomer is to both become more aware of what's going on within your team, but also to recognize and identify high points of cognitive load for barrier to entry. And the reason for this is because other people have already passed that barrier to entry. It's very difficult for people who are on the team to go back and recognize how much of a cognitive load it would take to become part of the team. But you as a newcomer, you have a unique opportunity to do that. This can be intimidating. So if you're already on a team, if you're a manager, especially, it's your job to encourage the new engineers on your team, the newcomers, the incoming people or people who are interacting with your team for the first time, to state even what seems like it should be an obvious thing if it's confusing them to raise their hand and say so. Here's the critical reality, all of that cognitive load does nothing to produce value for the team. Let me say that again. All of that loss of energy, all of the extra energy needed to understand all of the process language, all of the institutional language, all of that stuff that is confusing to a newcomer, none of that produces extra value. So by identifying areas of high cognitive load, you are increasing the value production of the team, not only now, but all the way into the future. We're going to take a quick break and then come back and talk about two other behaviors you might be resisting, but that you actually should embrace as a newcomer. Developer Tea is proudly sponsored by Square. There are millions of sellers across the globe using Square to run every aspect of their business. Many are looking for customized solutions that are deeply connected and easy to use. This is where you, as the engineer, come in. You can grow your business by extending or integrating with Square using the free APIs and SDKs to build tools for sellers. And more by going to developertea.com slash square. That's developertea.com slash square. Thanks again to Square for their support of Developer Tea. The second behavior that we want to discuss today, remember the first was to speak up when you are confused, even if you feel like this is something that you'll eventually learn, you'll eventually catch on. Go ahead and speak up whenever that moment of confusion occurs. The second behavior I want to encourage you today is kind of in the same theme. It's another speak up kind of behavior, but it's about your opinion. If you are having a discussion with your team about software design, solving a particular problem and you have an idea, it's very possible that you will feel a sense of pause in sharing your ideas too soon. And the kind of internal reasoning that I've heard and that I myself have experienced is that you may not know everything about the problem yet. You may not have all the context that the engineers who are talking right now have. And there's a sense of intimidation that really you need to be solving smaller problems or that you need to be paying attention to other things and just listening, soaking it all in. This is similar to the first problem of needing to soak in all the language, except in this case you're trying to soak in all of the architectural inconsistencies or specific context of the architecture of the software. The problem if we allow ourselves to wait until we have all the contexts is twofold. First, the software is changing every day. And so all of the contexts that we learned yesterday might change today. And additionally, this goes back to the same problems that we faced in the first behavior of speaking up when you're confused. If your ideas coming from the outside in can't be applied, there's likely a reason that shouldn't be true. In other words, the team has put itself for one reason or another into an exceptional state. If you were to bring a best practice to a team that says, well, we can't do that because X, Y, or Z. Only those X, Y, or Z reasons are giving the team some kind of exceptional state that those best practices don't apply to us because we do something special. Now, that's something special may actually be important, but most of the time it's not. Most of the time it's an artifact of some decision that was made well before you joined the team. And so, that's what we're talking about. By using a best practice that has been off limits, it's bringing up the conversation again and recognizing explicitly what are our exception states. In other words, what are the exceptions that our team has? And this is particularly important for managers to pay attention to. Are those exceptions actually providing value? If the exception doesn't provide value, then all it does is, once again, increase cognitive load. Exception states on a team are usually not value producers, but you wouldn't know that until you have the discussion. Figuring out whether that exception is a valuable exception to have is a critical exercise for the team to do and for this evaluation to be made on a regular basis. As the new member of the team, this kind of discussion, this kind of input that you provide may trigger those very important discussions at the team level. The final behavior that I encourage you as a new engineer on a team to adopt is one that is probably the most controversial. That is to take on a relatively difficult task. Usually teams have tags, and this is true also in open source, the tag might be something like good first issue or good for newcomers. The goal of these tags is to provide some relatively low complexity, low context tasks for those engineers to take on. This gets the engineer to the point where they have set up their machine. They have been able to run tests. They have been able to make a minor change and submit that as a PR or something similar, and get that merged into the primary code base. There is nothing necessarily wrong with this approach, and certainly I wouldn't tell you to stop doing this. But soon after, I would recommend that you pick up a relatively complex task. What this does is it provides a sort of tracer, and this tracer finds its way through all of the kind of ugly parts of a project. Why is it that this isn't a good first issue? If we think about all of the aspects that make issues a good first issue, then we can kind of think about the opposite aspects for the issues that are not that. It's difficult to test. Maybe it's difficult to understand the context around it. Maybe the change that is necessary is somewhat ambiguous. Maybe the work that needs to be done requires a lot of context or a lot of input from other services, other teams, multiple stakeholders. All of this creates a situation of complexity. By having this tracer for yourself and for the team, you can start to identify areas of dense complexity that are not being actively simplified. What you want to do with these dense areas of complexity depends on your team. Just because something has complexity doesn't necessarily mean it's worth the time to unravel that complexity. Maybe an area that is rarely touched, for example, in the code base and the investment necessary to unravel it is not going to give you the return you need. Knowing about these complex areas will be necessary for you to perform on the team with the context that you need to perform with. These tasks may seem intimidating, but at some point the team needs to solve the problem of intimidation. One way that you can reduce the effect of that intimidation is to have someone who is on the team, someone who does have that context to pair with you or to provide you live feedback as you're going through that problem. This also has a secondary effect and it's an important one. Sometimes when new members join a team for the first couple of months or a year they are seen as the person who is on tap to fulfill the small tasks. This isn't necessarily a good alignment of our skill sets. It's not a good alignment for a bus factor, for example, when those other more experienced engineers are out, can we continue to be productive on the most important work on work that is difficult to do? And additionally, are you able to provide value in terms of review and collaboration with those more experienced engineers? Ultimately, you and your team will benefit if you jump into the deep end sooner rather than later. Thanks so much for listening to today's episode of Developer Tea. Thank you again to today's sponsor, Square Head over to developertea.com slash square to get started today, building tools for sellers all around the world. Thanks so much for listening to this episode. If you enjoyed the discussion on this episode, you can continue it with other engineers. Add your opinions and perhaps see the opinions of others. They're probably going to be different than mine. Maybe the list of three is extended to a list of ten. Head over to developertea.com slash discord. That discord community is free for engineers to join. Free for listeners of the show to join specifically. We're never going to charge for that. Once again, that's developertea.com slash discord. Thanks so much for listening and until next time, enjoy your tea.