Ramping Up in a New Role

[00:00:00]
>> Francesca Sadikin: Let's start from the beginning. Making a good impression when you start your new role. So a very common fear for engineers when starting a new job is wanting to demonstrate their value as quickly as possible because they don't wanna get fired, right? And for engineers, that's usually ramping up in the code base quickly, starting to work on technical tasks.

[00:00:20]
And writing code well, so let's talk about how to do all of those well, starting with ramping up in a new role. Ask questions, I know this seems a little obvious, but I've noticed that engineers, are sometimes afraid to ask questions in the beginning. Because they don't wanna look like they don't know what's going on or what they're doing.

[00:00:40]
I argue the opposite in that, the first few months is the best time, because people are expecting you to ask a ton of questions, and they're gonna give you a lot of leeway. The opposite is that if you don't ask questions, you still don't know what's going on a few months later, when you start asking those types of questions, then it starts to look not great.

[00:01:05]
The other really big tip that I have is to request pair programming or shadowing another engineer that has at least been there for maybe a year. To pick up all of the unwritten cultural and coding norms that's for that company. This is usually something that managers don't offer you, but if you request it, it's not a problem at all.

[00:01:30]
And what it would look like is that you're going to ask to follow along with that other engineer as they work on their task for maybe a day or two, or even up to a week. And then you're gonna observe what they're doing and ask a ton of questions, including, what are the good and bad parts in the code base?

[00:01:52]
This seems like such a silly question, but when you're entering code bases, most of the time they're layers and layers of code throughout time with many different patterns. And so if you were trying to figure it out by yourself by reading the code, you're probably gonna get very, very confused.

[00:02:11]
And you're gonna waste time trying to figure out what is the most current set of code patterns. You'll also want to watch how they handle testing, so are they writing unit tests? Are they doing manual QA? What exactly are they doing to ensure maintainability? What's the PR process like?

[00:02:32]
So after you create a pull request, how many reviewers are they adding? What kind of feedback are they expecting to receive? And then how long generally are they waiting? And is it okay for them to just merge without an official approval? Other things are what's the pipeline to deployment?

[00:02:50]
So once your code is ready to merge, how many stages is it going through before it's actually live in front of I assume users. Does the engineer have to do anything to shepherd it forward? Which documentation sources are reliable? A lot of documentation out there in the companies, they're not usually kept up to date.

[00:03:13]
And so it's easy for you to go down the wrong rabbit hole trying to figure out if what you're reading is accurate or not. Having someone point that out to you will help you move a lot faster. Ideally, they're also going to start introducing you to who your partner teams are, who your customer teams are.

[00:03:32]
What do each of them do, who are the different points of contact in each of those teams, and when to go to them. And hopefully, if you have developed enough of a rapport with this engineer, they're also gonna share some company specific gotchas that you should know about.

[00:03:50]
So all of this, if you do it through this shadowing or peer programming experience, you can ramp up much more quickly as an engineer. Because all of these pieces are actually really important for you to start delivering your work.