If you're a budding developer wondering what your first month on the job might look like, you're not alone. I'm Fatima, and I'm here to share my experience with you as someone who recently transitioned into full-stack development after 5 years as a tester. I'll take you through a week-by-week breakdown of what I did, the challenges I faced and even some tips on what I did to make the most of this first month. Let's get into it.

Week By Week Breakdown

Week 1

The first week as a full-time developer was all about onboarding, so I was in meetings nearly every day. They usually consisted of me pairing with other developers on my team to get up to speed, shadowing them as they worked on their issues and trying to get a high-level understanding of the projects they were working on. I also spent time setting up my development environment, which included cloning all the codebases I'd be working with, installing any necessary dependencies & setting up my IDE.

Truth be told, this week was full of extreme excitement but also lowkey anxiety because I kept expecting it to be worse than it was, but it wasn't!

Week 2

In the second week, I continued my onboarding process with the usual pairing. I also made sure to start participating in code reviews this week, and I highly recommend any new full-time dev do as soon as they can. I went through the pull requests, line by line, and digested what my teammates implemented. This had so many benefits, including intimately exposing me to the codebases, showing me alternative ways to implement tasks and also familiarizing myself with the team's standards for documenting and submitting their code changes.

Week 3

In the third week, I got assigned my first solo feature, and although it was both extremely exciting and nerve-wracking, I learned a LOT. I got a chance to do some React development and deep dive into unit testing.

Week 4

In the final week of my first month, I got a few research-heavy tickets. I spent time looking through some legacy code bases, filling in gaps in my knowledge, documenting my findings, and working with the team to determine the next steps.

Challenges I Faced

In the spirit of transparency, let's chat through some things that didn't come easy to me in the first month.

1. Understanding how to properly unit test

   • It's ironic, right? I was a software test engineer for 5 years who wrote automation tests day in and out, yet writing unit tests was a struggle for me to wrap my head around as a developer. This was truly humbling, to say the least. 😂 I didn't want to wallow in my frustration for too long, so I worked towards strengthening my weakness in unit testing by upping my training and practical skills outside of work. Am I perfect at it? Nah. Did I make progress? Absolutely.

2. Trusting my own opinion

   • I noticed when I pair programmed, I put my own opinion on the back burner a few times even though my reasoning was valid. To combat this moving forward, I am challenging myself to share my opinion, even if it doesn't necessarily align with that of my coworkers. How else will I get feedback to learn and grow?

3. Not asking more questions. Especially in group settings.

   • Because I came in with some years of professional experience as a test engineer, I got hired as a mid-level developer. I realized I subconsciously put expectations on myself to have it all figured out. That's not reasonable, so I'm practicing extending grace to myself & giving myself the space to ask & fail & grow. And who knows, maybe asking questions during those group meetings yields answers someone else needed to hear too.

4. Imposter syndrome

   • It's been a struggle. I needed more help than I asked for, and I kinda internalized it a few times and questioned if dev work was for me. I had a genuine conversation with my coworker who reminded me that this path doesn't have to be a lonely one. Software engineering is a communal practice. There will always be times when I don't know something, and that's ok. Instead of internalizing it and finding fault within myself, I can use curiosity as fuel to grow & fall on the strengths of my peers.

5. Understanding the new codebase

   • This is something I knew would happen because I'd worked on some open-source projects in the past, but working with a new codebase isn't always a walk in the park. Working on your own projects is very different than coming into one that you didn't establish. You might struggle at first. You might ask the same question 3 different times. This is completely normal. You will eventually get it!

     

6. Timeboxing

   • I noticed that this was an issue when I was working on implementing my first feature. I ended up spending more time than I probably should have debugging when I could have just hit up my teammates to solve in 2 minutes what I had spent 2 hours trying to figure out. I ended up working unnecessarily late into the night a few times and came out looking like 👇🏾

How I made the most of my first month

As I reflect on my first month as a developer, here are some tips and tricks that I found helpful:

1. Recording every training session

   • We mostly use slack calls to pair on my team, so I used my mac's built-in QuickTime screen recorder to capture every meeting. This was super helpful because instead of spending time taking in depth notes, I just wrote down the time and the topic being discussed in my notes so that I could refer to the specific point in the video later on.

2. Setting up one on one meetings with my team members

   • I took the initiative to schedule one on one meetings with my team members, and this turned out to be beneficial for many reasons, including :

     • Building trust and forming connections with my team members,

     • Learning about the team culture,

     • and getting up to speed on the state of the current project(s) being worked on.

   • Because I work on a cross-functional team where everyone is not a developer, I also took this opportunity to ask very tailored questions to my teammates depending on their roles. From the product owner, I was able to get a demo of the various apps the team was working on and also get an understanding of the future of the product. This helped me scope what I should be studying at the moment to get up to speed, and helped me determine what technical questions to ask the devs, like:

     • "Can you give me an overview of the architecture of the product(s), and how the different components fit together?"

     • "Are there any upcoming initiatives with X project that you're excited about, or that you think will be particularly challenging to implement

       

3. Documenting my work

   • Documentation is a part of the development process, so I made time to take notes on everything in notion. For every ticket I Was assigned, whether it was development or research related, I documented the problem, my findings and my suggested approaches for the solution. This made it easy for me to refer back to during meetings where I needed to present my findings, and also helped challenge my communication skills. I also made sure to document testing steps for the tester on my GitHub pull request, so he would have an easier time testing my work.

4. Making time to reflect

   • I've had times in the past when I've lived on autopilot, and that hasn't always ended well for me. I wanted to be extremely intentional in my development journey, so I made a promise to myself that I'd make time to actively reflect on my progress and the things I'm struggling with. My goal with this is to make sure that I am constantly conscious and holding myself accountable to growing my career, a lil sumn sumn I picked up on while reading the Pragmatic Programmer which I highly recommend!

Conclusion

Overall, my first month as a developer was a challenging learning experience, but I'm so grateful I got to do the damn thing! There's something about pushing yourself out of your comfort zone and exceeding your expectations that is absolutely empowering.

To my fellow baby devs, know that although it will most likely be uncomfortable, you are more than capable, and as my friend Ramón Huidobro says, "not knowing is part of learning."