Starting Your First Job in Tech? Relax.
So you finally got that first job offer as a developer. The endless rounds of solving complex algorithm problems, showing off your GitHub projects, talking to recruiters about what you think your biggest weakness is… all of that has finally ended and you are now officially a software developer. You post a celebratory tweet on Twitter, get a billion likes, and enjoy that endorphin rush.
You can now relax, right? Nope.
Pretty soon, you’re beginning to freak out because you realize that starting next Monday you are actually going to be writing production code, working with seniors who have decades of experience, and your impostor syndrome is screaming at you.
Will you cause a major outage on your first day? Maybe you’ll accidentally execute an integration test in production and end up sending millions of emails to the users of the application, like that unfortunate HBO intern did?
Well, the good news is- you actually can relax. At least for a while.
In the first few weeks, you will probably only be on-boarding. This means you will be spending most of your time setting up your local environment, installing a bunch of software you will be using daily, setting up 2 factor authentication and other security related things, getting to know your teammates, and most importantly- reading A TON of documentation.
You’ll also be doing a bunch of boring administrative things, and if you’re unlucky and your company has certain security certificates (like the ISO 27001), you’ll have to learn a bunch of generally unimportant things so that you can pass the mandatory exam.
The main thing is, however, that no project manager in their right mind will give you anything really significant to do on your first few weeks of your first job in tech.
Although most job postings claim that they work in a “fast paced, agile environment”, the reality, from my experience, is that quite often it is anything but. Especially if you have just on-boarded, and especially if it is your first role in tech.
This doesn’t mean that you should just slack off. Use this time to ask as many questions as possible. Remember- there are no stupid questions. It’s better to ask immediately, then to give everyone the idea that you understood something that is not clear to you.
Get to know how the development process works in your new company. What do they use for issue tracking? Maybe JIRA? Get to know how it works. Project managers usually spend most of their time in there, so you should see what the modus operandi is regarding issue tracking. You’ll probably also be communicating with you co-workers via Slack a lot, so find out which channel is for what, and see who are some people who are the most active on Slack. Sometimes you will need a quick answer to a question, and the folks who are on Slack a lot will probably answer quickly (some employees barely ever look at Slack, an you have to @ them in order to get their attention).
After the first few weeks have passed, you will probably start getting assigned real tickets, and actually contributing to the project that is assigned to you. This is when your heart may start beating again, but you still shouldn’t panic. Your first tasks should be relatively simple, and remember that even if your code is awful, you will only be working on your feature branch, so you won’t get a chance to cause an outage or break anything in production. This is a good time to mention that you should absolutely master git and github/gitlab/bitbucket (whichever of them your company uses), because you can actually do something crazy like delete the main branch if you are not careful. Another thing to remember is that the production database is the holiest artifact in the entire industry, so if you are given access to it, do not mess around. Finally, you should know that most projects have at least two (sometimes even three) environments. The one that you will be deploying most often to is called the dev environment, or the sandbox. This is basically a copy of the production environment, but is available only to developers and QA analysts working on the project, never to end-users of the app. The dev environment can very often be a mess, because developers will constantly be deploying various experimental code to it, but that’s what it’s there for.
There might be a staging environment, which is a near perfect replica of the production environment, where a ton of tests are executed to insure that any new feature doesn’t break existing ones. And finally, the production environment, which is the version of the app that the end-users are using. Any deployment to prod is handled with the utmost care.
I remember the first couple of months on my first job. After the initial few weeks of on-boarding, I started getting actual tasks. I had literally no idea what I was doing. Each Friday I would tell myself- “Wow! You’ve made it through another week without getting fired!”. One week I even accidentally pushed some API credentials to Github (which is a big no-no, google environment variables for more info). Luckily they were only to the sandbox environment so no one got too sore about it.
About a month or so in, I realized that on occasion, some more senior developers were actually asking me for advice. It was then that I realized that either these folks also have no idea what they are doing, or I am actually good at something.
You see, software development is such a huge field, that no living developer on the planet knows everything. You, as the most junior of juniors, may actually know some technology that the team lead doesn’t know. It doesn’t mean that you are a better developer of course, it just means that you have worked with some technology that he/she hasn’t, and instead of googling and reading docs for 30 minutes (yes, seniors also google everything), they remembered that you implemented something similar on a previous ticket and your input would really be helpful.
When this happens, you realize your value. Yes, you are a junior, and yes you will probably do some embarrassing things in the beginning, but eventually you will be able to do all the work by yourself, and what’s even more unbelievable, in time you will actually be consulting your teammates. They will, of course, be consulting you the whole time too, but your opinions will start to matter, and you will probably know some specific technology better that most of your team members.
So, in conclusion, remember not to freak out just because you are starting your first tech job in a few days. Most people in the industry are friendly and more than happy to answer any of your questions.
And if you do cause a major outage, at least you’ll know how the HBO intern felt when they sent a million of these:
By the way, I’m pretty sure that he/she is a senior by now, with a huge salary and a master confidence level.
That’s all for this article. I honestly hope that if you are starting your first job soon, you found this at least a bit reassuring.
Thanks for reading!
