If you're reading this, you probably just got your first tech job — so congratulations! Getting the first job is one of the hardest things you'll do in tech. There's so much work and effort already behind you.
Or maybe you don't have your first job yet, but you want to know what you should expect.
Either way, in this post I will address the common worries and questions about what to expect on the job, and how to succeed in a career as a developer.
Here's what we'll cover:
- What to expect on the job (early days/weeks)
- Your short to medium-term plan
- The mindset for success
- How to be an outstanding new developer
What to expect on the job
The day finally arrives. You walk into the office (or join the morning team standup remotely) for the first time as a new developer. Even if you're nervous, try to remember and take in your first day. It's an exciting time!
Your first day will likely be logistical things: setting up your computer, orientations or trainings, and HR logistics (banking information, insurance, and so on).
However, it is becoming a common practice to have new developers do a push to production on your first day. It's usually something very small—like adding your name and photo or fixing a typo on the company website. This tests that your computer setup is good to go, and it also gives you a very quick win and lets you join the rest of the team shipping software.
Your company wants you to succeed
As a new developer, the company that hired you knows the limitations of your current knowledge and skills. They understand they'll need to invest significant time into your growth to teach and train you.
Remember, this company wants you to succeed! They're on your side. This company went through enormous effort to find, interview, and hire you. It's a costly process from both a time and money perspective for the company. They're not going to hang you out to dry—that would be a poor way to treat their investment in you.
There are some skills that you bring to the table at the start, but there are some skills that are difficult (though not impossible) to acquire outside of a professional work environment.
Since this is your first job, it's likely you've never collaborated with a large team using source control or maintained production applications—and that's ok! These skills are easier to pick up in a production environment.
Your first days/weeks
Once your computer is setup and you have access to all of the tools that you need, your first tasks will likely be small feature improvements or fixing small bugs—just things to get your wet feet across the various projects.
Outside of pure technical knowledge, in every company there is domain knowledge or "business logic" (what the company's products or services do and how they do it) that you'll need to pick up.
If the company has multiple products, they may give you small tasks in each codebase to begin exploring those products. It's also likely that they will assign another person on the team to pair up with you—or at least be available for questions you have throughout the early weeks.
In these early days and weeks you only have one goal: learn, learn, learn.
Learn about the technology you're using, learn about the company and how it works, and learn how to work with your teammates. Your work output is not important at this point—your rate of growth is.
Diving into a production codebase
As you begin working your way through the various codebases at your company, you'll likely feel a like a fish out of water. This is totally normal—it's much easier to write code than it is to read it.
A production codebase is very different from the tutorials you've been working through or the toy projects you've been learning with.
For one, this codebase has likely existed for many years, and been worked on by many different people—each with their own style and each of them making their own mistakes.
It's also likely there are many more software packages or plugins injected into this application than you have come across before. All of the convenient shortcuts or edge cases that were ignored in a tutorial (like error handling) have to be handled here—this is a real app.
This can be overwhelming at first, but reading other people's code is a skill you have to develop, and it's one you'll use your entire career (and at the end of this post I'll give you some tips to help with that).
In the end, don't be afraid to ask for help! Your teammates are there to support you, and at some point in the past they had to ask the same exact questions.
New developer expectations
First things first: this company is not expecting you to jump in and start knocking out features. They know you'll need time to develop skills you don't have yet, understand the codebases, and learn how to work with the team effectively.
It's likely your boss will meet with you and create a 30/60/90 day plan. If they don't do this—ask! Any supervisor will appreciate you owning your job and job expectations.
In the first 30 days, you'll likely just be doing small feature improvements and small bug fixes—just things to get to know the company's products and codebases. At 60 days, it's likely you'll be doing slightly larger features and bug fixes. By 90 days, the scope will have grown a little more, but they still won't expect you to own and drive large features forward yourself.
Ultimately, the company just wants you to continue to learn and absorb the information around you. You're not going to know everything going in, or after 90 days, and that's ok! Take it a day at a time.
The new developer mindset
Walking into a new company, there are many things you can't control, but there is one very important thing you can: your mindset. Your daily thoughts, practices, and how you internalize what happens around you will determine your success.
At times you'll be confused, at times you'll feel overwhelmed, and at times you'll even doubt if you can do this (I did). How you internalize these thoughts matters. Remember, this isn't unique to you—every new developer has faced this. Keep your mind in check and you'll push through.
When you run into something confusing or frustrating, re-position your mind: this obstacle is a learning opportunity.
It's an opportunity to understand something new and grow. It sucks, it feels bad, but soon after this you will be a better developer. And this will happen a lot—that's just the reality of being new to something.
Instead of internalizing:
"I got stuck 10 times today."
Try instead:
"I had 10 opportunities to learn today."
It's a powerful shift, and it will be obvious to your teammates and in your job performance.
Staying on top of your mind and not allowing the feeling of defeat to creep in will not only help you perform better in the situation, but it also increases the knowledge and skill you leave the situation with. Take a deep breath, take a break, ask for help—but keep pushing through.
And then at the end of the day: shrug it all off. Drop it on the ground when you leave the office or close your computer for the day. Start the next day fresh and ready for its own adventures.
Also, remember to celebrate the little wins along the way! Those small wins will stack up and become a large mountain of success over time.
Here's another important thing to remember: give yourself the freedom to make mistakes. You're going to break production, you're going to make some bad database updates (I definitely have)—it's recoverable, it's not the end of the world or your job, and any experienced developer has done it. It's just a part of the process.
Your greatest skill as a new developer
You may not realize it, but your greatest skill as a new developer is that you've learned how to learn.
You've learned how to take something hard, complex, obscure, and break it into pieces—work through it step by step.
More than learning JavaScript, React, Ruby, or anything else, the best thing you've learned is how to teach yourself. Take this practiced skill you have and show up with it every single day.
Own your growth—no one else will.
This might be the most important statement for a developer at any stage of their career: your career is your own. You have to own it, and you have to own your growth.
Sometimes the your company, job position, or boss will help facilitate your growth, but in the end, it's up to you.
Most companies have some kind of scheduled review process—possibly quarterly or yearly. If they do, great, but if they don't, own your growth! Ask your supervisor regularly for feedback, and do what they say. If someone mentions something you've never heard of, ask them about it or go do your own research it!
"The Power of Tiny Gains"
One of my favorite books, Atomic Habits by James Clear, has a great diagram titled "The Power of Tiny Gains." It's a simple diagram. It shows the difference between a 1% improvement and 1% decline every day.
If you get 1% better every day, after a year you'll be almost 38 times better than you were at the start of the year! That's the power of "tiny gains," and it's just as true for becoming a great software developer.
Every day you have an opportunity to learn something new—no matter how tiny it is. Maybe it's a new function on arrays you didn't know about, a different method for structuring CSS, a new text editor shortcut, or something new entirely like learning SQL and how data is stored at the database level.
Regardless, aim to be 1% better every day (most days you'll end up doing much more) and the growth from the first few years of your career will be astounding.
One page per day
I heard a story on a developer podcast once about the guy who maintains the pg gem for Ruby. This is the gem that is the interface between your Ruby code and the Postgresql database. It's some pretty serious stuff, and it's used by most Ruby developers every single day.
The story of how he became the maintainer of this gem was interesting. He said that when he was first getting started, he would open up the Postgresql documentation and read one page—just one page each and every day.
Over time, he grew an extensive knowledge of Postgresql and was able to start contributing to the pg gem. After a little while longer, he became the maintainer of that gem.
It's the perfect example of tiny gains stacking up—just one page per day. Any of us can do that, and I encourage you to take the same philosophy and apply it to whatever language or system you're working with!
"Practice make perfect"
You've probably heard this phase before: "practice makes perfect."
My piano teacher growing up used a different phrase: "perfect practice makes perfect."
I think he was right. I could practice the piano in the wrong way—with bad technique, sloppy, without a steady rhythm—and that's the result I would get: sloppy piano playing.
It's not just practice, but how you practice that matters. I could practice the first measure of a song over and over and get it down perfectly, but if I never pushed beyond the first measure I would never learn the song. I could play that first measure of the song at the level of a world-class pianist, but I wanted to play the piano, so I had to learn the whole song.
This is a perfect parallel for development. The way you "practice" development (your daily habits, methods and routines for development) determines the type of developer you will become.
In the beginning you'll make lots of mistakes (everyone does), but if you're conscious of your work, you'll notice areas you can improve. These are perfect practice moments: the opportunity to learn something new or do something in a better way.
When you look back on your career ten years from now, you will want to have had ten years of growth, practice, and learning—not one year of growth, practice, and learning ten times.
So ask those dumb questions. Ask the obvious questions. When someone mentions something you don't know anything about, boldly ask, "What's that?" My hope is that they respond in a kind and teaching manner, but regardless, be ready to learn.
It all comes back to owning your growth.
T-shaped people
In the beginning of your development career, there are so many topics that you can benefit from knowing, so you want to spread your effort and knowledge across a wide range of subjects.
If you're aiming at becoming a full-stack developer, that list might include things like HTML, CSS, JS, a backend language of your choice, SQL, Git, etc. There's so much easily attainable knowledge and benefit right on the surface of each of those topics that can be acquired by casting a wide net and taking it all in.
Over time, you'll find what type of development you enjoy most. Maybe it's frontend, backend, database work, ops, design—or some combination of those and more.
As your career progresses, you'll start to become a "T-shaped person." A T-shaped person is someone who, like the letter "T" is visualized, has a wide but shallow knowledge and experience about a lot of things, and a couple areas with a deep amount of knowledge and experience.
This deep knowledge takes a while to build up, and each step down is increasingly more effort than the previous—that's just the reality as you approach mastery of a subject. In the beginning, scoop up all of those easier beginner gains across a wide field of subjects.
Having this T-shape ability will help you become a better developer as a whole. Frontend developers who understand the database schema or backend developers who understand how those database tables are going to be used as models in the frontend will be more knowledgeable and better teammates than those who are siloed in their own area.
In the beginning this little foray into all of the aspects of development is also useful to find what you're drawn to, and to give you the bigger picture of all of the moving pieces in the software world.
Follow your interests and stay hungry to learn!
Tips for being a great new developer
Now that we've covered your expectations and how to think about them, here's some practical tips to make you a great new developer—one your teammates love to work with.
#1 Communicate really really really really really really well
You may not have incredible development knowledge and skill walking into your first day, but you can have incredible communication skills.
As a new developer, you're going to ask for help and guidance—a lot. And that's ok! Here's a tip for how to ask for help effectively.
Getting stuck is frustrating (it was for me). In these moments, it's easy to let that frustration overwhelm you and fire off questions to your teammate next to you (or maybe via email or a chat app).
Things like:
"im stuck"
"it errored"
"the page won't load"
Now take a step back and view this from the perspective of the person you're asking help from. A message like "the page won't load" doesn't help this person help you at all. There's no context. There's no information for them to go on. In fact, they have to ask for more information from you. This is incredibly inefficient and very frustrating for the person that is trying to help you.
A better way to ask for help is to think of it like a Mad Lib™ (if you remember those):
I am working on _____,
but when I try _____,
_____ happens instead.
I've tried _____, _____, and _____.
and I've looked at _____ and _____.
An example of this message might be something like this:
I am working on the user password reset bug,
but when I try to generate a password reset link,
the user's token is already empty.
I've looked at where the token is set, and I can see the token in the database,
but the token is missing on line X of File Y.
If you sent someone the message above, they can understand:
- What you're working on
- What the problem is
- What you've tried already
- Where the problem is
This is a wealth of information for the person you're asking help from. They will greatly appreciate that you gave them that information so clearly—and that you've already tried to fix it yourself. This shows them that you respect their time, and you're not just looking for an easy handout.
There's nothing wrong with getting help, but if someone just fixes the problem for you they've really robbed you of the opportunity to learn and grow yourself.
It's not like there's ten problems you have to work through and you're done for the rest of your life—you'll face problems every single day as a developer. So the best outcome is if they give you enough help to get you unstuck but allow you to solve the problem yourself.
#2 Hone your Google Fu
Just like developing skill in the physical martial art of Kung Fu, over time as a developer you will develop skill in the art of Google Fu—that is the art of finding answers by Googling them. This is a real skill that every experienced developer has and it is developed over time.
Sometimes, you just need to google the exact problem you have (this works great with error messages):
Sometimes googling the exact error message will produce the correct result, as it did above. You ran into a technical problem, and someone else ran into the exact same problem.
But sometimes, you need to edit the search query a little bit to remove project-specific info:
In the image above, Google has never seen the function whos_that_pokemon_its_pikachu() in the file gotta_catchem_all.rb (except now it has since I searched it :)). Removing that project-specific info and adding generic info returns better results.
#3 Use a "try timer"
As a new developer you're going to get stuck a lot. There will be error messages you haven't seen before, and how you handle these situations will determine how quickly you grow as a developer.
Although these can be terribly frustrating moments, these are the moments where you will learn and you will grow. You don't learn by doing the same kind of work over and over again—it's by journeying through these bumps in the road that growth takes place.
When you run into one of these problems, take some time to try and figure it out yourself. Some companies will tell you this as a part of onboarding—something like "try for 30min before asking for help." In other companies it's not as clearly defined, but the message is still there: do your best and then if you're still stuck ask for help.
This not only allows you the opportunity to figure it out and learn for yourself, but it also respects the time of your teammates who are focused on their own work. Interrupting someone for something you could have quickly figured out yourself is a net loss for the team.
So give it a good try, and then of course ask for help!
Here's the secret to being a great new developer though: always reset the timer.
Let's say you get stuck, try for 30min, and then ask for help. The next time you get stuck try again for another 30min before asking for help.
This may seem obvious, but on those days where it feels like you hit nothing but problem after problem, you're going to get frustrated and you're going to want to start asking for help as soon as the next problem arrives—it's just natural.
Take a deep breath, go for a quick walk, and approach each problem with a fresh perspective.
(This is, of course, easier said than done!)
#4 Remember to relax and take breaks!
Remember to take breaks when things start to feel overwhelming.
Go for a walk. Go get a glass of water. Sleep on it if you can. Sometimes just getting up and moving for a minute can help you re-center yourself.
Remember that every developer was once in your place, and you will get through it.
Development will always be frustrating to some extent—you never stop making mistakes or running into problems. But over time you just get better at dealing with them, and your confidence to fix those problems increases so it bothers you less and less.
#5 Ask the duck
Have you ever written an email or a text message describing a problem you have to someone, and right before you hit send you realize the solution? In the software world there's a phrase for this—rubber duck debugging:
The name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug their code by forcing themselves to explain it, line-by-line, to the duck.
You see, by writing an email or talking to another person, you're forced to explain the entire context in a logical way in order for the other person to understand what's going on.
To explain the problem in this way, you yourself have to be able to think about and order it logically. Just the act of trying to prepare this context for someone else can cause you to think about the problem in a different light, and many times you'll find the solution yourself.
So relating back to using a try timer, before you ask for help, try explaining (or typing) up the summary of the problem in an email that you don't send. The chances are you'll gain new insight about the problem without having to interrupt another person, and worst case, you've got a great email or chat message to send them.
(I've seen many people put actual rubber ducks on their desk too!)
#6 Take notes
This tip may seem obvious...but take notes!
You will be introduced to many different things when you first join a company: codebases, products, people, business logic, and it will be impossible to remember it all. Write this stuff down.
When I started my first job, my boss told me he had no problem explaining anything to me, but he didn't want to have to do it twice. I understood then, but now eight years later I really understand—it's all about respecting your teammates and their time.
If he explains something to me and I forget it, we've wasted both of our time—and I'll have to ask him again. At his recommendation I even started putting physical sticky notes on my monitor of things I wanted to see often and remember. Things like:
- TRY FOR 30MIN
- CHECK THE BUILD PASSES BEFORE ASKING FOR PR REVIEW
- MAKE SURE YOU HAVE LATEST CODE
#7 Fight against imposter syndrome daily
If you don't know what imposter syndrome is, it sounds like this in your head:
I don't belong. I'm a fraud. Everyone else understands this but me.
This is a mindset you have to fight on a daily basis. There will be frustrating times as a developer, but you've faced frustration already and pushed through it. Every developer has felt this, and this too will pass.
In reality, imposter syndrome looks more like this:
The one key difference between a "senior" and "junior" developer
Sure, a senior developer has more knowledge and experience than a new developer, but that isn't what sets them apart. A senior developer has a problem solving system.
When I first started in development I thought eventually I would stop making mistakes—that I would stop running into errors.
The opposite happened. I still make an incredible number of mistakes every day. Wrong syntax, wrong file, wrong function.
I didn't stop making mistakes—I just got incredibly fast at fixing them.
This is a skill that is developed over time, and it requires intentional problem solving.
Here's some tips on how to build this system.
5 Debugging tips
#1 Don't thrash your code!
One of the things I did as a new developer—and something I see many other new developers do when they run into a problem—is they start wildly changing things in their code. Instead of having a systematic evaluation process, they just make a ton of quick changes trying to see if that fixes the problem.
This is a very bad habit. You will only create more mistakes doing this. What you should do is:
#2 Read the error message!
This tip may seem obvious, but actually read the message. What is the error? What is the file where this error is occurring? What line is this error coming from? This is all vital information.
If you resist just changing your code rapidly, you can jump straight to the exact place the error is happening.
This is what the experienced developer does. Read the message—go straight to the problem.
Doing this will save you an incredible amount of wasted time and mental effort.
#3 Don't waste time on the impossible! (Or at least the improbable)
This is something I see new developers do often. They face an error in their code, they find something that they think is the problem, and they can't believe how it's not true. As an example:
"I see the problem is on line 14, where it checks if theis_adminvariable istrue, and it's nottrue—but the user is an admin!!
They approach this problem thinking, "How can this be!!!" instead of, "How can this be?"
There are times when you will encounter a core language or framework bug, but 99.9% of the time, you did something wrong or the situation is not as it appears.
Instead of spending time marveling at the impossible unfolding before your eyes, question your assumptions about the situation. Something is not as it seems. Being aghast at the impossible is only a waste of time—start your problem-solving system.
#4 "When in doubt, print more out." - Some wise person
I don't know who originally said this, but it's one of the most effective debugging techniques out there. When you don't know what's happening, start printing the state of your program in places where you think the problem is happening.
What is in the user variable? What is the response from the HTTP request? Did we take the if or the else branch in this situation? Did we even call this function or are we even on this page?
I've seen countless developers trying to debug and fix an issue (and I've done it many times myself too) when they weren't even working in the right file! A quick print or console.log will show you that you are in fact looking at the actual code being run.
#5 Take it one step at a time.
A common mistake every new developer does: they do too much at once.
They want to write code for 30min, click run, and see it work. What they find is that they spent 30min writing bugs and errors, and it's now a nightmare to fix.
When I go to make a new page in an app, the first thing I do is put <p>hi</p> on the page. I want to make sure that all of my internal code is setup correctly and I see that hi on the page. I take it one. step. at. a. time.
Do one thing at a time. Get "hi" printing on the page. Next get the user input. Next validate the input. Next save the input. If you take small steps you know exactly where to fix the problem when it occurs.
Even eight years later into a development career I still take it step by step. I know I'm going to make a ton of mistakes, and I want to know immediately when and where that happens.
Conclusion
You've already come so far, but there's still a lot ahead of you.
There's much to learn, and many skills to develop, but there's also a lot of fun and rewarding work ahead as well!
Keep your head up, and remember to take breaks. Get 1% better every day, and in a year you'll be astonished at the results!
If you liked this post, I write similar things on my blog here.
Thanks for reading!