If you remember your first day in high school, or any school, it's alot like that. You don't know anyone or where anything is. There's alot of asking for help from people as you try and find your way across campus. And slowly but surely, you end up finding your way around and making friends.
But let's get into some technicalities, because I think that's what most people are looking for.
Your first couple of weeks at your first programming job are probably going to be the most boring weeks of your life. You won't be asked to attend every meeting and to rebuild Google in your image. Odds are that you might not be asked to do anything really. At least not just yet. Regardless of how many years of experience you bring to the table, you simply have no idea how this new company operates or where anything is.
So in a sense, you are kind of a liability. At least in the beginning.
Onboarding
This looks different for every company. But onboarding is real and it takes a long time to get through it. You are looking at a few weeks at least. There's forms to fill out and videos to watch and mandatory meetings to attend and typically those don't happen in a single day and they don't really involve your actual job.
This is more about corporate life than about programming life. You can't escape corporate life. But once you get that out of the way, odds are you are going to be reading documentation to see how things work. It might not be the most well written content and much of it you might not understand. For example:
Dev serv 1 - IP: 0 0 0 0
Pre deployment server per Steven Q.
That might have absolutely no meaning to you when you first read it. And there's probably going to be alot of that. Eventually though (one day) that will make sense, as you learn who Steven is and why they needed a pre-deployment server.
Some companies don't have documentation, in which case, you might be off to fend for yourself as you try and figure out where everything is. Typically a newer company problem. After this, comes the fun part, and the most painful in the process.
Setting up your dev environment
In every job that I've ever had, this has been the biggest pain point and you can't outrun it. Setting up your development environment with the right codebase, database, dependencies and permissions is a challenge most of the time under typical conditions. Now mix the whole being the new person at a company and it can add a bit of stress.
This could take anywhere from 2-3 days to 2-3 weeks depending on the project and how well organized the company is.
For one, you need the software. This means the IDE's that your lead recommends or that the coding language requires. No you can't just code on Sublime forever. In real life, code needs to be compiled, transpiled, obfuscated and encrypted if need be. Sublime is a great text editor, but it isn't a development environment.
Once your software is up and running, you need to pull a fresh copy of the latest codebase into your local machine. You might need permissions created by the system admins, in which case, you might just be sitting around for a few days waiting for that to get approved. But once approved, you'll be good to go.
Next up, you'll need the database. If not connecting to a shared development database, you might need to clone one onto your local environment. How to do that will depend entirely on the type of database that you are using and on the company's setup.
Now it's time to put it together and to build the project and run it locally. This is typically where everything collapses and where you spend the next week trying to resolve small errors so that you can get your code to run.
There is always something missed in this step. Typically, it involves some sort of 3rd party library that nobody really knows about and that has invalid credentials. And finding the credentials can become its own journey.
But once you do figure all of this out, congratulations. You are now ready to be a developer for your new company.
Shadowing
Don't get too confident, because you still have no idea where anything is. And odds are you are working on a very expensive website (otherwise they wouldn't be able to hire you). Which means that any good lead can't just have you running around changing the code to your whim.
You'll probably spend a few weeks shadowing another junior to mid level developer and getting the hang of where everything is. You might want to pay close attention here, as odds are that you will be taking over for their work soon as they get bumped up to bigger and better things.
At my first job as a programmer, I spent the first month sitting next to another junior developer and watching them tackle their daily tasks. I would ask questions and point things out along the way. I'd go to meetings with them and take notes and in general just did my best to absorb how everything worked.
After about a month or so, they got moved to a bigger project. But their workload was still there, which is where I came in and took over. I had seen them navigate around the databases and remote desktop in to the many environments and had plenty of notes on the directories where the project files resided. Because they are never where you think they are.
And this became my first big developer job. Until we had a new junior hire join the team. And you could guess that they spend the first month shadowing me and my current workload in the same fashion. And a month after that I was placed on a bigger project, in which case the new developer took over for my old work.
Your first project
At some point within your first month you'll get your first assignment. And there's a good chance that it might not go as planned. I still remember my first big programming task and it wasn't actually that big, but things still went not quite so correct.
It was a simple request for a simple form to collect data from the user. I jumped on it quick and wanted to impress everyone so I made short work of it and then spent the day patting myself on the back. Until one of the lead developers came over to ask about it.
I proudly showcased the work and ran through a simple test case. They then of course proceeded to test it out and pretty much hit every edge case that you can think of spewing out error after error. It's a humbling experience. Much of the errors were caused by me not quite reading the specification correctly and missing out on a few key components.
This is where I learned that attention to detail is key in the corporate world. It's not just about having a fancy algorithm that runs super quick. But more so about, "did you finish item #3 on the spec sheet?".
Final words
Every company is different of course and they might have their own processes that they put you through. But this has been the constant theme throughout my career spanning the past 15 years.
It's not the most glamorous and high tech way to start a job. But believe me, it is important to be humble and to listen and take notes. The last thing that you want to do is to barge in to someone else's work environment and to break something that wasn't yours to begin with causing a chain of problems that are difficult to correct. So take your time and enjoy the process of being the new coder, because you only get to experience that one time.
Walter Guevara is a software engineer, startup founder and currently teaches programming for a coding bootcamp. He is currently building things that don't yet exist.
Stay up to date
Sign up for my FREE newsletter. Get informed of the latest happenings in the programming world.