by Rachel Bird

Hey web dev bootcamp grads: Here’s what you need to know for your first job.

You worked your butt off and gained all kinds of coding skills. Now it’s time to take them out into the real world and find out what you’re made of. It’s exciting and scary at the same time (‘cause those two feelings go together like peas and carrots).

Here are some things that can help you relax and feel like you’re right where you belong on day one.

JIRA (know how to pronounce it): This is a popular way companies handle project management. It’s part of the Atlassian suite. You should check that out and familiarize yourself with it, because their products are super popular in tech. You’re probably on a collision course with owning one of their t-shirts. You’ll get assigned tickets on JIRA and probably be put on a story board.

Side note: if your company uses Stash instead of GitHub, you’ll use virtually all the same commands you’d use with GitHub. Alternatively, they might use BitBucket. Either way, you’ll be fine using these Atlassian products.

There’s a chance they could use something else like GitLab. You can find out before you start and then research what the company uses.

New Relic: DevOps is going to manage how your company’s apps are performing, and this is a popular way to go about it. They’ll probably have a screen up with a graph, and everyone will flip when there are spikes on it. Don’t worry. You don’t have to deal with it (at least yet). But it’s good if you have an idea of what it is when you start.

Development, staging, and production: Now that you’re working on a project with a large team, it’s important you work on the appropriate branch. You’re going to branch off development to start. Make sure you know how your company’s branching and commit messaging processing works so you can tag your tickets appropriately.

QA handles staging to make sure everything works before your code gets pushed up to production (or “prod” as we call it in the biz). Then users will be actually using what you made!

Project management: The thing I found most interesting in the beginning with tickets was how they were prioritized. Something could be broken, but if there’s a workaround, it wouldn’t be a serious priority (as in not level 1 or even level 2). 500 error codes and spikes in New Relic meant serious problems.

QA (Quality Assurance): The team that makes sure everything works as expected. So when the users get the product, they aren’t going wtf?

There’s a process to doing QA right. QA people should be able to say in what browser(s) they experienced the problem, on what kind of device, and exactly what was going on when it happened (what view they were on, what they clicked, what the result was, etc.). What they’re reporting should be able to be replicated so it can be dealt with.

This is invaluable to developers who want to make good products (you’ll find that this isn’t everyone). And you’ll find that bugs are just part of the process — so no big deal.

Hotfixes: Sometimes there will be a bug in production that needs to be fixed ASAP. That’s called a hotfix. You probably won’t be responsible for these until you have some experience at the company and are super familiar with the codebase.

APIs: Your company will probably have its own APIs rather than only third party APIs. Sometimes you’ll need to talk to the people working on the APIs. Maybe you’ll need data that hasn’t been exposed yet, or you’ll need more data than is being exposed (if it limits to 10 records when you want 15+). Or perhaps you’re the first one to realize that the API is getting clobbered by somebody calling it incessantly and it needs to be dealt with. It’s just routine stuff.

Daily stand up meetings: Somebody thought these up and now basically everybody is doing them — agile development is all the rage. You will probably literally have to stand up with your team. Everyone will say, in turn, what they worked on since the last stand up, what they’re going to work on next, and if they have any blockers. Blockers are things that mean you can’t move forward, like maybe the person you need to work with has been assigned to something else and isn’t available.

Senior devs aren’t defined strictly by years on the job: Don’t look up to people just because they’ve worked in tech for X number of years. People that will be useful to you will be patient and open to explaining things so you can grow as a developer.

They’ll also have an interest in writing good clean code and growing as developers rather than just getting a paycheck. Seek these people out and maintain good relationships with them.

Work is a game and you’re there to win: Focusing on writing good code isn’t necessarily the straight path to getting a promotion. You won’t be working in a vacuum. Every tech company has its biases and interests. Start figuring out how your company operates on day one. There’s a very small likelihood that it runs as a meritocracy.

What really gets people promoted and gets them raises? How can you achieve your goals as a developer and employee? It might be disturbing to figure these things out, but the sooner you do, the faster you can win (or determine if your company is too toxic for you to stick around).