So, you've learned all the syntax and patterns, written a hundred and fifty-four apps demonstrating different abilities. You've graduated university or bootcamp and stocked your resume chock full of awesome. Your portfolio is looking sharp and really shows off all your skills and abilities. You've survived 38 phone calls, interviews and rejections with little to no feedback.

You've found that one employer who looks right. You were smooth and suave. You nailed that Fizzbuzz backward in ANSI C on the whiteboard while blindfolded and they've offered you a job!

At the end of it all, a large gruff man with a large grizzled beard has informed you: "yer a developer Harry!" (Ok... maybe not that one...)

Now what?

What should you expect on your first day as a developer? What shouldn't you expect? What's going to be expected of you? These are the sorts of questions that could keep a new developer up at night worried, battling with impostor syndrome, burying themselves into books about best practices and dealing with headless branches in Git. (Sounds like a horror story... 🎃)

I recently enjoyed a conversation with my podcast co-host, Kel Piffner about exactly this topic. We came up with quite a few things that really do cover a lot of what to expect as well as some things we've seen a lot of new developers come in expecting that were way off base.. Without further ado and wizard references... 🧙‍♂️🧙‍♀️

You aren't going to know what's going on

Even experienced developers will walk into a new role and be completely lost. Unless this is a completely green field project, there will be a history of code, architecture, infrastructure, constraints and processes in place. These will have grown organically and won't be exactly the same as any other environment you've ever worked in.

This is completely normal! It's a lot to digest and it takes some time to memorise them and know your way around all the different aspects that make up software development.

How are projects managed? Is there infrastructure in house or is it all in the cloud, what the hell is Server08? Oh, that's the UAT server. Wait... What's a UAT server? FYI: User Acceptance Testing (UAT) is like a proposed release in a special environment for end-users to give it a go and make sure it meets all their acceptance criteria... the things they wanted in the first place. There may well be special change control processes in place, the code will be arranged in a particular manner. The company might use micro services, serverless setups, massive crazy continuous integration processes, etc.

These are all things you'll need to learn and understand. Even if you know what everything is, you still need to figure out where things are and how they fit into the grand scheme. It's daunting, but... again... perfectly normal.

The tech stack

I've seen a lot of folks show up and be surprised and upset by the fact that they weren't able to use their preferred tech stack or tools. You don't get to pick the stack you're going to work with.

There will likely be a rich history of technical decisions and organic growth which has caused a particular tech stack to be in place. Or there may well have been a concerted effort to make the decision to use that stack. In either case, what you see is what you get and you're going to have to work with it for the foreseeable.

That doesn't mean everything is set in stone. There may well also be exceptions to this. In general, though, you'll be well served to accept this and start learning as much as you can about the stack you've got to work with.

Your new team!

Hopefully you'll be working with other teams. The company you work for may assign a mentor or buddy to you. They might even assign multiple! Or they might not assign anyone at all....

You are absolutely within you rights to ASK for one if they don't tell you who to ask questions and get advice from, but when it comes down to it every organisation has their own policies for how teams are structured and how on boarding new developers works.

If the company you're working for doesn't offer any of these things, talk to the other developers on your team and get to know them. That can be an excellent way to build a rapport with them as well as finding unofficial mentors!

At the very least, in most organisations you'll be paired up with someone early on to walk through the project(s) and give you a bit of a tour. It's important to pay attention to this, but most folks won't expect you to memorise absolutely everything you learn on the first day (or days)!

Getting help

One of the most important things you'll learn in the first days of your new job is how and where to get help when you need it.

Communicating well with the team is going to make everything go smoother for everyone! That means asking questions when appropriate. If you're stuck on something, you've given it a good go for 30-60 minutes and you're not getting anywhere? Ask someone. Think you know what someone asked for, but you're not sure? Ask them to clarify. It's much better to ask a few more questions now than to go spend two days building the wrong thing!

Back to tech stacks and tooling, if you don't understand why something is in use, it's perfectly ok to ask respectfully about it. "Previously I've used X, it worked really well. I noticed we use Y here, could you explain it a little to me?" goes over a lot better than "I always use X, it's so much better than Y. Y sucks."

I don't know how many times, early in my career, I declared that X was vastly superior to Y, only to have someone more senior explain Y to me and realise I was completely wrong! Don't be me! 😬

Some things expected of you

Above all else, in a new position, you're expected to be willing to learn. As a bunch, I think developers tend to be pretty open to this, so I don't think I need to discuss it too much, but it is probably the single most important thing.

Some things that might be less obvious:

Estimation: You should be able to estimate how long tasks will take you. The better you are at estimating, the easier it makes things on everyone else. They'll be able to plan around you easier and will begin to trust you much faster than if you don't have this skill.

Setting expectations: This is a huge part of communication. Being able to set expectations appropriately makes all the difference in anything. If someone asks for something, make it clear what's involved, how long it will take and what the risks are.

Infrastructure: Having some knowledge of infrastructure is extremely beneficial in all IT. It's not traditionally the role of developers to understand a company's infrastructure, but knowing this helps you develop software better and gives you a greater understanding of what's going on with the software in general. 🖥

Process: Following the existing processes and understanding them is hugely important. This is part of how a team works together. If you're not following the process that can make things much harder on everyone else. So learn them and use them!

You're an important part of the team

Don't go into this thinking there will be senior developers who are shining examples of wonder and splendour. (I am, of course.... 😁) There will be other developers with other experience. They might be more experienced at some things and less at others. But their value doesn't negate yours!

You provide value to the team, and by learning you add more value to the team. It's in everyone's best interest to support that. So always keep in mind that you asking questions and learning is a contribution, not a bother or a nuisance!

There's a good chance you won't be writing code!

In most organisations you're not going to be writing much code at first. It's possible you'll get to work on some low priority items, but there's a very good chance you'll actually be tasked with a non-development job at first. Don't take it personally.

A lot of organisations will start new developers off vetting tickets. I'm a huge fan of this. This is one of the best ways to become a better developer. It's a very different point of view that is extremely important.

You immediately get to talk to the end-users, understand their frustrations as well as their mindset. You start to build mental images of their user personas which will help you make decisions that will improve the product in the long term.

It's also a really great way to get to know the product. By the time you're done verifying issues do exist or figuring out why you'll know the product inside and out. You'll start to understand it's strengths and weaknesses as well as its overall structure.

Take advantage of this opportunity, don't be offended by it! This is a good way to ease you into a new role while allowing you to provide value early on. Providing useful debugging information and possible solutions as well as keeping the queues clear will make you the senior developer's best friend very quickly!

It won't take long at all before they're happily pairing with you or allowing you to write your own bug fixes and feature additions.

It’s going to be different than you expected

I think the big thing to keep in mind is just that it’s going to be different than you have in your head. You’re going to be different as well. You’ll discover some things you thought were strengths really aren’t and you’ll discover new strengths you never knew you had.

It will be weird and wonderful and terrible all together. But this is the start of a journey that has so many possible routes and options!

I’d like to leave you with one parting note before I finish rambling. Many of the developers I see taking entry level positions now are better developers than I was while getting paid to do it professionally! 🤯 Give yourself more credit than you believe you’re due, because you’re probably going to be your harshest critic!

If you’re interested in listening to Kel and I chat about this on our developer podcast check out the latest episode at: https://gettingappsdone.com/episodes/your-first-day/