What to Really Expect as a Software Developer on the First Day

It was the night before my birthday and my family had just left town for a short vacation in Lake Tahoe.

I had been studying feverishly for the past two weeks after getting hired for my very first software developer role. The manager mentioned C#, SQL and Javascript as the core technologies our team. I kinda knew Javascript, so I bought some Udemy courses for C# and SQL that confused me more than anything.

I was completely self-taught and hadn’t even finished a bootcamp I enrolled in before getting hired. This was the night before I was going to start my new job as a Software Developer and I had no clue what to expect. One hell of a birthday present, I thought.

Would I be fired on site? Would anyone help me or would they just give me some assignments and see how I did? Was it appropriate to ask questions? How many? How soon?

I showed up prepared to be fired within the first few hours and was determined to make the best of the situation. Spoiler: I didn’t get fired that first day. I’ve gone through this first day experience 3 more times since then (add a few more if you count the contracts and bootcamp teaching gigs I’ve done in that time) and overall my first day/week/month experience has been similar at each company, whether it was a small startup or an established company.

Most people I’ve spoken with have an experience similar to mine as well. I think I can safely say your first day/week/month will follow a similar trajectory:

Psst… I am now an engineering manager and I run a coding training program. I want you to have a less stressful first day when you’re hired. 👉 Join me at Parsity.io

First Day

I’m assuming you are likely anticipating your first day on the job and haven’t yet worked as a professional developer. As a newbie to the world of coding, your peers are likely aware of your skill level which they’ve assessed from your coding interview and previous work experience. They know you are some level of junior and have their expectations appropriately set.

I’ve spent every first day at a new job just setting up my work station with a teammate. We’ll make sure my email, tools and any and every program I may need is set up. Depending on the complexity of the app I will be working on, we may get a local version up and running on my machine.

At this point, everything is a black box and I’m completely unsure of how different projects are related, why or what the code is supposed to do in many places and in general how the app works. That’s ok.

I’m a firm believer in writing things down. Usually on this first day, I will write down any questions I want to ask to a teammate later about pieces of the code which seem particularly abstract or difficult or processes which are still unclear.

First Week

In between administrative tasks like setting up healthcare and finding out where the good bathroom is, you will likely be writing some code. Usually, the first tasks I’ve been assigned are fairly trivial and there’s not much expectation or urgency surrounding them.

Some examples of first tasks I’ve been assigned:

• Change color of button
• Bug: Wrong property from object being passed to function
• Add some text to a page

These tasks will introduce you to the team’s processes for writing code. Your code will go through a code review where another developer will let you kn ow of any issues with your code or styling changes you need to make in order to enforce team standards.

Code reviews were the biggest shocker to me coming from a self-taught background. The matter-of-fact style that most people use to critique code felt cold and intimidating and it’s because I was too personally attached to my code. My advice to my former self would be to welcome code reviews and realize that the most critical reviews SHOULD teach you a lot about writing good code.

Every team I’ve joined does some form of morning standup and this was another point of confusion at my first job. Basically, everyone gathers around in the morn and lets the team lead or manager know what they did yesterday, what they plan on doing today and any blocking issues that may prevent them from doing their assigned work. It’s a short ~30 second per person (fingers crossed) monologue you’ll do each day.

During this period, it’s expected that you will ask lots of questions regarding processes and how code works in general. A good rule of thumb is to spend about 15–30 minutes on researching a question until you ask a team mate for help. Try to ping them on Slack or wait until they look like they are not consumed with work to ask a question. An unspoken rule on many teams is that when a developer has their earphones on, it means do not disturb them.

For many of your team mates, your questions may seem trivial and they will explain them away too quickly, forgetting their years of experience have allowed them to see things that you do not… don’t let them off the hook too easily and really press them when things are confusing.

First Month

The first four weeks on the job will be much like the first week. At each position, I received just slightly more tasks than the previous week and maybe had a not so trivial bug assigned to me by the end of the month. As a neurotic person, I continually wondered when/how I would be fired during the first month. A feeling that usually tapered around month 6 (oh, who am I kidding, on my first job I felt this way for about a year).

By the end of the first month, I usually felt I had a decent understanding of processes like code reviews, code merging, branching and the team’s general style. During my first job, this was a very loose grip and it took me nearly half a year to make any significant contributions to the team.

What’s Next?

The first day/week/month can feel like you’re just keeping your head above water and you will need a bit of blind faith in your abilities to know that one day you WILL be a regularly contributing member on the team. The few people I’ve seen do terribly during this critical introductory period are the ones who ask no questions, write nothing down and never admit when they are stuck. They suffer in silence, are perpetually late with tasks and eventually leave on their own accord or are let go (I’ve actually never seen someone fired from a team during this early stage but I have seen people just leave after not hacking it).

If you’re reading this the night before you start your first job, congratulations! Don’t worry, you won’t get fired… not yet at least.