5 tips to help you in your first month as a new developer
Photo by Andrew Umansky on Unsplash. Cropped for aspect ratio.
Everybody has been the newbie at the company before.
Everybody that calls themselves an engineer, developer or programmer has had a first job where they felt like they knew nothing, and everybody was better than them.
After being the newbie, talking to other people about their first experiences in new developer jobs, and later onboarding new engineers onto my own team, I compiled a list of things to make your first month (or two) be less stressful, and to help you turn all the scary unknown things into an advantage.
1. Get used to the uncomfortable newness
Everything is new at a new job. Every time.
It doesn't matter if you have zero days or 10 years of experience working as a developer: it will always feel like everything is new. Mostly because it is.
Every time you start a new job there will be a bajillion things you've never seen before: every company works differently, and has different cultures and work habits; you'll work with new people, new codebases, sometimes new technologies, and all of those (and much more) are bound to take some time to grasp; especially if it's your first job ever.
If no one ever told you this, let me tell you this right now: you're not required to be good at your first job right away. As a new developer we're not so used to the newness of it all, but as time goes by you'll probably get better at dealing with the new and quickly adapting to it. So you shouldn't stress too much about it.
But, if you want to get up to speed faster, you'll need to get used to the uncomfortable feeling of the new and use it as a resource rather than a hindrance. Take a deep breath and rely on your peers. They all know what it was like being new (although some may have forgotten).
Here is a list of things you can do:
Ask as many questions as you need, sometimes to the
point of being annoying. Being annoying for a few weeks is better than being completely lost for a few months. (But also, find out who you can annoy and who you can't.)Ask a more senior colleague if they can walk you through the codebase or, alternatively, ask for some smaller bugs to solve if you prefer investigating on your own. This will help you get acquainted with the codebase faster and also will show initiative and ownership.
Ask if you can shadow a colleague for a day and watch how they work and interact with other people. Shadow more than one, if you can.
If they don't do this already, set up 1:1 meetings with people on your team and some other people your team might interact with on a regular basis. Ask about your team and their work, how they interact, and anything else you may want to know. This is especially useful to understand who and how people are and who to go to when you have questions.
Ask if they have any documentation that you could read to help you understand the work better and faster.
"Being annoying for a few weeks is better than being completely lost for a few months."
2. Document everything
If they don't have documentation, you might be the one writing it. And rather than seeing that as something bad, you can make it work in your favor.
Pause for a little personal story.
When I joined my team they didn't have an onboarding document, so my manager loosely suggested that I take notes of my onboarding process (everything I learned in my first month on the team), and make a document that could help the next people coming in.
At first, I didn't fully listen, and never took notes of my environment setup as I didn't think it was going to be needed - it was not a set environment, we were allowed to use whatever was the better fit for us, so I thought nobody else would need my environment setup details.
Oh boy, was I wrong… and I was the one who suffered the consequences as just two weeks later they needed to exchange my computer for a different model and I had to re-do the whole setup.
After those two days I spent re-learning how to set up my computer, I realized that even though some of the things I was learning might not be useful to other people, I could be the one benefitting from them in the future.
That helped me realize the importance of documentation: it's useful not only to speed processes (my second setup could've taken me a couple hours instead of two days), but also to make sure everybody's on the same page and understands the work that is being done.
Since those early days, I have gotten better and better at documenting processes, and even earned a documentation award. Only I know how many times I had to go back to my own onboarding document when I needed some information I had already forgotten.
Without a proper onboarding document, things might take more time to figure out - and this might not be a problem, but a blessing in disguise.
My advice to you is: take notes about everything you're learning, everything you think might be important to remember later, all your team's meetings and rituals; If you don't know a process, ask a colleague to go over the process with you and take notes of it.
You'll then get all these notes and format them into an onboarding document the way you prefer. On the other hand, if there's already an onboarding document, you can compare your experience with it to check if anything changed or if there's anything missing and you can help improve it with your new found knowledge. First project done. And you haven't even touched the codebase yet.
By the way, it's always good to document every time you get any compliments on your work or you've done a successful task. Keeping a "Brag Document" is a great way to help yourself through imposter syndrome and also helps your manager and colleagues through performance reviews.
"Get your work recognized: write a brag document", by Julia Evans
3. Take it one day at a time
These first days or weeks can feel daunting and the imposter syndrome might pay you a visit. Just remember: your colleagues have been there too. Everybody had their first job once and a lot of people feel imposter syndrome, even after many years of experience.
There will always be days where everything seems too overwhelming and you feel like you don't understand anything. This is very normal, everybody has been there and although this is an uncomfortable feeling, with time, you'll learn to recognize it and not give into it.
My way of mitigating imposter syndrome is going through my brag document.f that doesn't bolster me, I'll try to solve a problem. Everybody's different, you just need to find what makes you not feel that way. But this is a feeling that more likely than not will accompany you for the rest of your career, especially if you're a young woman. Like imposter syndrome, some things need time and experience for you to understand.
There's this one debugging technique that I thought I knew how to use but every time I needed to use it, I couldn't figure out for the life of me what I was doing wrong and it never worked out. Imposter syndrome screamed at me every time I tried to debug something.
It took me asking my manager over and over again for a year and a half how to do it every time I needed to debug anything until one day I didn't need to ask him anymore.
Some things might take you a day, while others might take you one and a half years and several attempts to grasp. And that is ok. In development, the more we fail at something, the more we see it and re-learn it, and when we finally grasp the concept, the easier it is to remember it later.
Every failure you have is just a way for you to cement that knowledge deeper into your head. So you might need a few days of being overwhelmed with something until you get it. Be easy on yourself.
"Some things might take you a day, while others might take you one and a half years and several attempts to grasp. And that is ok."
4. Don't be a deer in headlights
It's common for some people to freeze whenever they feel overwhelmed, and like I said before, this first experience in a new company is filled with opportunities to feel that way.
As a way to mitigate this feeling of overwhelm, you should do something you know and feel comfortable with to keep you in motion: figure out a bug, review a PR, talk to someone about something you like, write about your experiences or like I did, survey people about your team and product. What?! Yeah. I did that.
I came from a very - VERY - different background than computer science: I used to be an assistant director in movies and television. So, my first ever job as a developer was more than overwhelming; It was completely different than anything I ever knew. I had never worked in an office, or with technology, and in a different language than mine before. Everything from meetings' structure, to zoom, to having managers, to sharing a codebase to working in a design system, to working with people from another country, were new to me.
I had a month to spare between signing my offer letter and the day I started working, and my manager had bought me a book about design systems to bring me up to speed faster. In the book (Design Systems by Alla Kholmatova), they described in depth the process of creating a design system from scratch, and went into a lot of detail about how you need to understand the purpose of the design system before making decisions about it through surveying the team and stakeholders. This book, along with a lot of UX I was learning at the time, gave me the idea to create a survey that I could ask people when doing my 1:1s.
The survey consisted of a quick 5–10 minutes personal interview about how they viewed my team, our customer service, which were their favorite and least favorite components in the design system, how they would describe the design system in three words, and a few other questions. I also interviewed my teammates with slightly different questions than the rest.
I promised anonymity and assured them I had no stakes in this as I was just joining and was not responsible for anything. I did that in hopes they would be as truthful as possible and I could gather good insights. After a month of interviews and crunching numbers I created a presentation for my team.
This survey had nothing to do with the development work per se, but this helped me understand a lot about my team, the work they did, how other teams viewed them, and what I had to do to catch up with them (one of the top phrases in the surveys was "great customer service" and I felt I needed to match that from there on).
This helped me not to be stuck with feeling overwhelmed, and also helped my team find pain points in the design system that they had not known before.
This whole story is just to show you that if you feel overwhelmed, you might want to rely on something that feels more familiar to you at first. Try and find something that you're used to doing and can bring value to your team.
This doesn't even need to involve code or be something necessarily expected from a developer. Just doing something familiar to you will help with feeling overwhelmed and might actually help your team in ways they were not expecting. A lot of the time your fresh eyes will help see things your more senior teammates can't.
5. It will end one day so, enjoy while it lasts
The best part about being a new developer is, most of the time, people will cut you more slack as you're still learning and getting the grasp of things. This opens the door for you to make mistakes, try new things and learn a lot.
Don't waste this time by thinking you don't know anything or that you're less than your peers. Believe me, you're not. You were hired because they saw something in you. Ask your manager how many people you were competing with for the job. This might give you some of the assurance you need.
Also, embrace the fact that you have a lot of room to grow and each interaction you have with your team or a new part of the code is an opportunity to learn something new or solidify knowledge you already have.
If you have the opportunity, go ahead and create your own project, make something from scratch and allow yourself to learn and make mistakes in the process. Nothing teaches us how to fall and get back up again like falling and getting back up. And there's no feeling better than seeing something you idealized and built yourself come to life.
As time goes by, you won't be the new developer you once were, you might even get a promotion or two and you'll see the responsibilities grow and mistakes might become more costly - even though mistakes will always happen, and that's fine too. So allow yourself to experiment before that time comes.
Being a developer can be a roller coaster ride, where you have great and not-so-great days. There will be times when everything feels like a mess and you can't make sense of anything, but when you finally find the solution for a problem that has been bothering you for days, it's magical and will fill you with euphoria.
Remember that even experienced developers make mistakes and continue learning everyday. You're not alone in this journey, so reach out to your colleagues for support and guidance. Embrace the process of constantly learning and enjoy the ride.
Don't let anyone undermine your abilities or discourage you, and welcome to the team!
If you want to learn more about your first year as a developer, read my other article:
Copy editing: Jessica Appelbaum
Top comments (0)