 Okay, hi everyone. My name is Fatima and today I'll be walking you through my survival guide to being a junior engineer. Now, when I reflect back on my experience as a software engineer, I've realized that my biggest learnings have been in the non-technical parts of the job. There's so much unexplored territory that goes beyond the algorithmic requirements of your job, and these soft skills are extremely important in determining your success as an engineer. This unexplored territory is also where I feel that our classrooms somewhat fail us. We're sent to the workplace primed to pass technical interviews, but we're not sent to the workplace primed to be successful in our roles as software engineers, and that's because there's such a huge component to being a successful software engineer that we're not exposed to at all. Did anyone tell you how much ambiguity you were going to be dealing with? Were you taught about the complexities of project planning? Did anyone tell you what to do when an engineer leaves a project midway? I'm fairly sure that none of us here were. I feel that there's this undeniable delta that exists between what we're taught in school and what's needed to be successful in your roles as engineers, and my session is an attempt to bridge that delta. So, without further ado, let's get started. Now that we've talked about the what and why, I'll quickly talk about the who. I'll introduce myself and what makes me qualified to speak on the subject. So, I'm a software engineer at Yelp. Before Yelp I was working as a software developer at a trading firm called DRW. Going back even further, I completed four internships as part of my undergraduate degree at the University of Waterloo. So, needless to say, the experience of being a junior engineer is still quite fresh in my memory. I'm also wrapping up a master's in data science and should hopefully be done by the end of this year. Before we proceed, any opinions or views expressed in this session are my personal opinions and do not represent those held at Yelp. So, before I get started, I'd like to share a story. Now, a year ago I started on the biggest project of my career. This was basically a huge refactor that we were doing, and the goal was to eventually have a better architecture, a better user experience, latencies, etc. I'd never worked on a project of this scale before, and so there were multiple teams involved, multiple stakeholders, and I was very excited. Again, there were multiple teams involved, but it was my team that was at the heart of it. Obviously, I was understandably very nervous, but I was very excited because I was going to be working directly with two technical leads. Now, the project started off fairly simple. The first couple of months were pretty straightforward, but things got interesting around the mid-year mark, which is when three of the five engineers were working on this left. You can imagine that this was not at all a part of the plan. Never in my violinist imagination had I accounted for this. When the three engineers left, we were about 60% done with the project, but the remaining 40% was the really tricky part because this was when everything was going to start sort of coming together, we were going to slowly start rolling out the changes, see how metrics were being impacted. Now, obviously there was a huge vacuum that was created when these engineers left, and there were just the two of us remaining, but I was the only team member who'd sort of worked on this project throughout, so I was then made the project lead. You can imagine my excitement. Because of the circumstances, I like to call myself an accidental project lead. But anyway, we still had work to do. This was around eight months ago, and since then, it's been such a tug of war getting this project to the finish line. I really thought we couldn't do it. The story does have a happy ending though, because we officially wrapped up the project just last week, even though it was quite delayed, which is understandable given the circumstances. But what does this story have to do with why I'm here today? I've been doing a lot of reflection in the past couple of months, and there's some key learnings that I wanted to share in the aftermath of this experience. The first thing that I want to talk about is ambiguity, which was one of the first things that I also experienced as I worked on this project. Now, when you start out in your career, the work is mostly handed to you, right? You're likely handed tickets, which means that what gets to you is a small achievable and deliverable sub-task. All or most of the ambiguity has been removed from it, because it's likely undergone multiple iterations as part of like the project development cycle. Now, something that I experienced is that as you become more senior, the amount of ambiguity that you're going to be dealing with is going to start increasing as well, and that's because as you're moving up the seniority, you're becoming a part of the very initial stages of the project. Think of the project in terms of a timeline with the start and end denoted by conception and execution, respectively. Now, what I mean by conception is that you're basically identifying technical endeavors that you feel your team or company should undertake. As you become senior, you start moving from the execution end and more towards the conception end. You're likely going to be overseeing multiple services, multiple projects, and as your scope increases, so does the amount of ambiguity that you're going to be dealing with. Actively embracing ambiguity is an inevitable part of being an engineer. This is also where your understanding of the project will come in handy. The clearer your comprehension is of the what and why, the easier it will be for you to translate that ambiguity into the how with clear and actionable items. To understand the what and why, you need to understand the project inside it out and its value to the business. The better you understand it, the better you'll be able to define what needs to be done. A big part of your understanding is also realizing the value that you bring to the business. How is this initiative contributing to the overall goals of the company? Is the focus on accuracy or latency or both? How can revenue be potentially impacted? As an engineer, you always think about your project from a technical perspective, right? You think about the right way to implement a feature, you think about design patterns, you think about latencies, you think about testing the happy path versus the not so happy paths, among other things. But as an engineer, have you ever thought about revenue? Have you ever thought about how a faulty change could lead to a degraded user experience, which would inevitably be detrimental to your business's revenue? As you get to work on more high stakes projects and as you gain more visibility in your role, your mistakes could start becoming more costly. The point of this discussion is not to scare you from making mistakes because that's an inevitable part of your growth as an engineer. The point is, is that you need to be cognizant of the cost of that mistake so that you can learn to mitigate the risk accordingly. Think about it this way, an inexperienced engineer will deploy an experiment at any time of the day without thinking about traffic patterns or without thinking about how they could potentially mitigate the risk if their change is faulty. An experienced engineer on the other hand will know not to deploy right before a long weekend or during high traffic times or when there is an ongoing outage because they know that the impact to potential revenue could be significantly larger. Now, do you remember when I said that this project was really delayed? Yeah, that was a pretty awkward position for me to be in. You can imagine that as a project lead, there were tons of questions being directed towards me. So how did I navigate that time period? The trick was communication. Just like we're taught to ask clarifying questions when we're presented a technical problem within an interview, do the same for your project work as well. I remember working on this one task and I completed it in three days. I was very happy with myself. I presented it to my technical lead and I was told straight up that this is completely incorrect because I completed that task based on an assumption that I had made. That's three days of development work wasted and a further X number of days that it took me to redo the entire thing. Secondly, be transparent and proactive while conveying blockers and expected delays and there's going to be a lot of blockers and a lot of delays. Escalating issues on time can get you the help you may not even realize you need. I also learned to adjust the level of detail it is that I'm expected to share based on the audience, which is extremely important, especially when you're working on projects that involve multiple teams or stakeholders. You're likely going to be interacting with people from other teams, engineers on your team, engineers from other teams, project managers, technical leads and not everyone would necessarily require the same amount of detail. If I'm talking to an immediate team member, they would probably need a deeper technical dive, but if, say, I'm talking to a project manager, they might just be okay having more of a bird's eye view of what the current state of the project is. Moving on, politely ask people to repeat themselves if you're unsure, especially in meetings. A lot of the times most people are wondering the same thing, but because of diffusion of responsibility, no one ends up asking those questions. Similarly, if it was a very long meeting and a lot of things were discussed, take meeting minutes, summarize what was discussed at the very end, just quickly review what the follow-up items are and what action items are assigned to what team members. Lastly, I also want to talk about the importance of documentation, which is something that most engineers generally dread doing. Now, when you're actively working on a project, it's very easy to recall commonly used commands that you use for testing or debugging your code, especially if you're executing those commands to the terminal, you can just very easily access your most commonly used commands. This is okay as long as you're actively working on the project, but say you go on an extended vacation or you finish the project, but a couple of months later you have to come back and do a minor fix. Accessing those commands is not going to be as easy this time. I'm guilty of this myself. There's been so many times where I've had to like sift through, slack conversations, trying to find the command that I need. Documentation as you go along can save you potential headaches later on. Now, another lesson that I learned, particularly because of the three engineers that left, was that project planning is complex and nothing is set in stone. You have to account for surprises like these in your project timelines. So, account for vacation days, last minute time offs, civic holidays, people resigning or any other urgent tasks that might come up. Your timelines aren't meant to be perfect and that's okay, but it's important to be realistic about them. Now, going back to my story, when the two technical leads left and I was made the project lead, I was expected to share a new project completion date. Now, I'd never done this before, so using whatever little context I had and what my current understanding of the state of the project was, I shared a new completion date for the end of November. This was hilariously over-optimistic because I'd completely forgotten to account for holidays. Thanksgiving in the U.S. happens around like the late November time and that's because it's so close to Christmas season, a lot of people saved their vacation days for that same time as well. I'd completely forgotten to account for that. Luckily, this mistake wasn't too costly for me because I later found out that my manager had added a little buffer time to this November end deadline and the completion date that had been shared with stakeholders was for after new years. Needless to say, I was very grateful to my manager for having my back. To summarize the complexities and unpredictability of project planning, I would just like to remind you of Murphy's Law. Anything that can go wrong will go wrong. The eternal optimist in me has begrudgingly accepted this and I think you should acknowledge it as well. As inconvenient as that is, I do think that it makes you a better project planner because you'll know to add buffers in your timelines and you'll have contingency plans in case something goes awry. Just a couple of weeks ago, I had this experiment that I was ready to turn on. I was very excited. Everything was all set. I tested it and I was basically going to turn it on. It was going to run overnight and then the next day I would have data ready. So I mentioned this in like a team check-in meeting that we had and my manager just casually reminded me that in case there is an ongoing outage, just don't turn on the experiment. I agreed but internally I was like there's nothing that's going to go wrong. I've tested it. There's minimal risk. I'm just like I'm just collecting logs so like what can go wrong? It sounded like a perfect plan to me. As soon as I was about to turn on the experiment, I was alerted of an ongoing outage because of which I could not turn on the experiment. My perfect plan was out the window. There's no such thing. Now as a project lead, you can also imagine that there was more to my date than just coding and that happens to be the case for most engineers. You're attending meetings, you're updating documentation, you're doing code reviews, you're applying to emails and messages and yeah you happen to code as well. Now if you think back to your operating systems classes, this is exactly what context switching is and this is very detrimental to developer productivity. Now I worked long enough to intact to realize that it's unrealistic to expect that there's not going to be any context switching in your day but you can definitely reduce the amount that you do. This includes things like time blocking and time batching which basically means that you block off times where you can do focus uninterrupted or deep work even if those are just 30 minute chunks during your day. I'm also a big fan of prioritized to-do lists. Something that I really like to do on Sundays which is when I start feeling a sense of impending doom is to dump everything that I need to do for the week onto my to-do list. This can include very trivial things as well such as like making payments or getting groceries or whatnot. The next thing that I do is that I categorize these according to like work, school and like miscellaneous items but the most important aspect of this entire activity is to assign a priority to each item that I need to do. Mondays can be overwhelming for a lot of people but having this prioritized to-do list helps me feel more in control because I have an exact plan of attack for for my week. Making difficult decisions is part of any leadership position and project lead was no different. The most noteworthy decision that I remember debating was the question of taking on tech debt. This is the eternal question of getting it done versus doing it right. You want to finish the project on time but you also want to roll it out with minimum defects and those two things you usually do not go hand in hand. When I first started out as an engineer I had a very idealistic view on tech debt. I even remember expressing that opinion very strongly in an interview and needless to say I did get the job. Debt in general carries a very negative connotation right so I assume the same hell true for tech debt as well. Tech debt is basically the cost of getting it done as opposed to doing it right. It includes things like a last-minute hacky fix, poor or a complete lack of documentation altogether, or a poor testing suite among other things. Similar to context switching I think it's unrealistic to expect not to have any tech debt. There's definitely circumstances where it'll be you have to take that tech debt on but simultaneously you need to be cognizant to pay it off in a timely manner. Accumulating tech debt can lead to a slowdown in development work or worse having to rewrite the entire application. But if there's no alternative to taking on tech debt how do you alleviate the situation? By remembering to pay it off but there's more to it than that. Don't treat working on tech debt as a second-class citizen. Encourage a culture within your team where paying it off is celebrated. That's actually a custom that we have within our team. So if any engineer pays off any tech debt we remember to give them like a shout out during our weekly team meetings. Don't play the blame game if you have taken on tech debt own up to it. I would also suggest quantifying it. I think in general we understand numbers better right so if you're able to quantify the cost of that tech debt I think it's very easy. It becomes a bit easier to sort of assign a priority to that tech debt. For example if a lack of a testing suite resulted in a degraded user experience you can quantify that using the loss in revenue and it'll immediately assign a priority to that tech debt. Lastly share your knowledge. If you've paid off tech debt and you've noticed consistent themes in the tech debt that your team tends to take on share those themes so to prevent future occurrences of the same issue. So to quickly recap the lessons that I shared include embracing the ambiguity but to do that you need to understand your project inside it out and its value to the business. Next practice clear effective and efficient communication. Acknowledge that project planning is complex and that nothing is set in stone. Acknowledge that context switching is an unfortunate but inevitable part of your role and lastly realize that technical debt might be a necessary evil. This brings me to the end of my session. If you have any feedback or if you want to share your learnings from back when you were a junior engineer I would love to hear them please feel free to reach out either by LinkedIn or by email and yeah thank you for attending my session today.