OMG, I got the job! Now what?
Starting your first developer job is extremely exciting! But as with anything new, there will be things that will surprise you, and an adjustment period as you get familiar with your team, your company, and the products(s) you'll be working on.
Here are some things I wish I'd known to expect at my first (and second) engineering job, and some tips to get the most out of it.
It's normal to freak out a little bit when you first see the code you'll be working on
Working in a production-size codebase written by other people will feel very different than working on a bootcamp group project or a side project. You'll open up the app and there might a dozen folders, all filled with a dozen files...and even more sub-folders!? Filled with more files!?
If you're lucky, you might be working with a framework and libraries you've seen before, and there might be some familiar patterns and structure to the app....or not! If you're working with a set of new tools, things might feel completely foreign. Regardless, just remember this: No matter how many years of experience you have or how senior an engineer you are, it ALWAYS feels a little disorienting when you first open an unfamiliar application and start poking around. You don't know what the app is supposed to do. You'll see huge, complicated blocks of code with no comments, and terminology that you don't understand.
Whenever I open up an app for the first time, a tiny piece of me starts to freak out. But then I just remind myself that I'm a programmer, and this is just what it's like to start a new job! It's definitely understandable and expected that it will take you time--like, measured in months--to get comfortable. It takes time to develop a mental model of app architecture, especially if it's different than what you've seen before. So, relax.
You'll need to ask questions--and you should!
One mistake I've made in my first two engineering jobs was waiting too long to ask for help. I'd be assigned a task, and I'd spend many hours just searching through the codebase trying to figure out where the code that handled that feature was located. I think this is common among Jr Engineers because we tend to have imposter syndrome and we think that if we were REAL engineers we'd be able to figure it out on our own. But this isn't the case. It's expected that anyone new to a codebase will have questions. And, your team members would much rather you be asking for help than sitting stuck, wasting time.
At first it can be hard to know what to ask. If you spend some time searching the codebase for terms related to the feature you're supposed to be working on and you can't narrow it down, it's perfectly fine to ask someone on your team if they have an idea of where the logic lives. Then, you can start tracing it through the rest of the app and seeing what connects to what.
You'll overestimate how quickly you can do things. Try not to!
Another thing I've struggled with as a junior engineer is estimating how long it will take me to complete a task. I think this is really hard when you're new and still getting familiar with a codebase.
Moreover, it's well-established that people are pretty terrible in general at estimating how long things will take. (Behavioral economists call this the 'planning fallacy' and there's a great episode of the Freakonomics podcast about it if you're interested.)
Even so, if your product manager asks how long it will take you to do something so s/he can tell the client when they'll get their new feature, you can't very well say: "Well, I'm not going to give you a timeline because people are notoriously inaccurate at estimating! Haven't you heard of the planning fallacy?!" You need to give an estimate.
My advice here is come up with your best estimation of the longest it should take you to code the thing, multiply it by 2.5, and then add 3 to 4 days for code review. If you end up delivering earlier, great! If you're like me, you'll still be late but you'll get close in most cases.
My worse case bad guess of how long something would take was when I estimated that it would take me one day to write a script to read data from a series of Excel sheets and post that to our internal API. It took more than two weeks to get it in good shape. Why? SO MANY edge cases to account for in the data set. There was no way to know this at the outset.
(Another fun fact about this super annoying task is that I brought it on myself! Our product manager told our client that it couldn't be done and I CORRECTED HIM in the meeting and said I could do it in a day. Sigh. Seriously, don't do this.)
Make the most of your onboarding time
When you start a new job, it will probably take some time before you are regularly being assigned tasks that fill the whole day. This is because the things that need to be done quickly might take you too long to complete, might be too difficult, or likely require background knowledge that you don't have yet.
So, what's an engineer to do with this extra time?! Take advantage of it! Take the time to look through the app and try to get a sense of how it is structured. I don't mean read all the code line-buy-line per say, but try to get a sense of what logic lives in the different folders.
Is there tech in the app that's new to you? This is a great opportunity to learn it! Learning new tools is a huge part of being an engineer, so hit the documentation and see what libraries the app is using. Take notes and write down questions.
If you've spent a few days doing this and you still have extra time, ask your manager if you can help by writing tests or adding documentation to areas of the codebase where it's lacking. These are the types of tasks that often get de-prioritized when teams need to get a release out and working on them will help you learn more about the app while contributing work that no one else has time for.