This past week, I started a new job as a senior software engineer at Progressive Insurance (contracting via Dexian). Before starting, I read a lot of blog posts and forums online to discover what this job might be like. I wanted to know what to expect and what I could focus on to grow quickly.

So now that I’m a week in, I wanted to write my own post about what the first week is like as a senior software engineer. This is the resource I was looking for and wish I would have had before I started.

First, I’ll explain what happened in my first week that is likely to happen for all senior software engineer roles. Then I’ll dive into what I’m doing to learn fast and make a good impression early.

What happens in the first week?

A lot of what happens in the first week will depend on the organization and the job, but I’ll talk about my experience with Progressive. I’m sure much of it could be generalized across the industry.

The tasks you need to complete during your first week don’t differ much between the junior to senior level. The main difference is that as a senior, you’ll need to be more proactive in your own onboarding. There will be less hand-holding, but my experience has been that my team has still been patient with giving me time to learn and get up-to-speed.

Nobody expects you to contribute right away. So don’t try to rush it to the point that you’re not learning the things you need to learn early on. Feeling like you need to (and can) solve all the team’s problems is an arrogant belief that will lead to technical and relational mistakes. You need to build context before you can make meaningful changes.

In the first week, you can expect to:

  • Meet the team
  • Get added to all the chats, email distros, and meetings
  • Machine Setup
  • Learn the business context
  • Learn the high-level system architecture
  • Learn the codebase
  • Learn the logging and analytics

Meet the team

I met my team on the first day by attending the Daily Standup meeting, where everyone discusses what they’re working on and any blockers they’re encountering.

Meeting the team has two levels:

  1. Meeting the whole team together
  2. Scheduling time to meet with team members individually

While you’ll be able to associate names to faces by joining the Standup, meeting everyone individually is an important step that often isn’t required when you join. These one-on-one meetings are the perfect opportunity to find out what work each person is doing, what their strengths are, personal details of their lives, and who else they think you should talk to. That last one is a great way to build your internal network early-on.

But have some tact about when you schedule those meetings. Understand that the team may have an urgent priority they’re working on. Try to schedule a time when your meetings will not be too disruptive. I try to do it at the beginning of a new work cycle. I have not scheduled mine yet, because the day after I joined, my team had a big launch they had been working toward for months. So I’m planning to wait another week or two until things settle a bit.

Get added to all the chats, email distros, and meetings

If you’re at an enterprise org like me, there are lots of chats and distros you’ll need to be part of. I’ve never had this all get sorted out easily on my first day. Something(s) always gets missed. Make sure to be proactive about following up and asking various team members if there are chats or distros you should be part of. Sometimes you get assigned a person to help with this, but even that person may not be aware of all the chats that will be helpful to you, so ask around.

Machine Setup

Hopefully this step will be well documented. If not, you will likely get assigned someone to help walk you through it. Just make sure to get everything installed and set up early on. There are some things you might not need right away, but you’ll be embarrassed if you wait until you’re past onboarding and need to ask for help setting up something you should have already had.

In my case this includes things like:

  • Change the default browser to Chrome instead of Edge
  • Install VS Code and Visual Studio and get them configured how I like
  • Get access to GitHub Copilot
  • Install necessary browser extensions (e.g., Redux DevTools, Angular DevTools)
  • Clone the repos I’ll be working on and get the code to build and run
  • Get access to the databases via a Database Management System
  • Set up my container engine (e.g., Docker)
  • Start saving bookmarks left and right to all the links I’ll need later

Machine setup is tedious, but taking the time to do it well will set you up to be successful later.

Learn the business context

Before I jump too far into the code, I try to broadly understand the business context that the code lives in and serves. I ask questions like:

  • What is the company mission?
  • What is my department’s mission? How does it contribute to the company’s mission?
  • What is my team’s mission? How does it contribute to my department’s mission?

These questions help me understand the “Why” behind the changes we are making. Once I feel like I have a decent grasp on those questions, then I try to understand the “What/Who”.

Who is involved? What does the data look like? How do people talk about data and relationships between entities? In my case, since I’m working on the claims side of Progressive, pretty much everything falls within the scope of an insurance claim. Within that, I am on the payments team, so I work at the end of the lifecycle of a claim when payments are sent out.

So who is involved? Internal claims reps that process payments.

What does the data look like? Key data entities include invoices, line items, properties, parties, payments, correspondence, etc. Each department and team will have their own set of shared language to describe their data entities and the relationships between them.

It’s smart to learn this language quickly so you can have coherent conversations with your team about the problems you’re trying to solve. Knowing the “Why” will also help you steer your team away from trying to solve the wrong problems.

Learn the high-level system architecture

Learn the systems involved, where they live, how they’re organized, and how they talk to each other. Are things hosted on-prem, in the cloud, or both? What’s the tech stack (languages, frameworks, versions, important libraries, etc.)? Especially for the systems you support, figure out what the dependencies are. Which systems are you consuming, and which systems are you serving?

Hopefully there is documentation in place with diagrams to help you understand how everything fits together. I like to make my own system diagrams as I learn how things are architected. Then, I ask knowledgeable members of the team to critique my designs to test my understanding. Once I know that my diagram is correct, I’ll add it to the team’s documentation for others to reference later.

Learn the codebase

This part often feels the most overwhelming. Especially at a large enterprise, there is no way one person could understand and remember the entire codebase. It’s just too big.

Some people try to read all the code when they start. While I think there’s a place for reading, I find it’s hard for me to get a deep understanding from reading alone. I prefer to debug the application. I’ll pick a breakpoint, figure out how to hit it, and then observe the call stack and step through the code slowly. This is really helpful at first, when I have a very loose understanding of the classes in the code. I find it very helpful to see the actual data being passed around and manipulated at runtime.

I also love pair programming for this. In the beginning, I let someone else on the team drive so I can observe their workflow. This is a great opportunity to ask questions about why certain parts of the code work the way that they do. Or get insider knowledge on which parts of the code are minefields and which parts of the code have been written well. Much like a country, every codebase has good and bad areas. If someone doesn’t get assigned as a mentor for you to pair with, you need to seek this out. And try to pair with different members of the team, as everyone will have their own areas of expertise and ways of doing things that you can learn from.

For an example of using debugging to learn, I noticed that I was getting a 404 error from our API when trying to play around in our web client. When I debugged the API, I found that the stored procedure it calls was returning an empty array unexpectedly. When I went to test the stored procedure, I realized that the query had hard-coded values in it, instead of using the input parameters from the stored procedure. This looked like someone had accidentally modified the stored procedure while doing some testing, so I reached out to the team about it and one of the team members confirmed they had accidentally made this change. This was a pretty simple issue to debug, but it took me a little longer because I don’t know the codebase yet. But these are the perfect kind of issues to debug when you’re starting out, to see how everything connects between web, API, database, and any other layers you have in your architecture. I learned a lot from this simple debugging session.

These are the kind of things that help learn the codebase. Even if someone else finds a fix for a bug, see if you can dive deeper into the root cause and check with the team to see if your understanding makes sense.

Learn the logging and analytics

If you’re going to do any kind of production support, it’s important to learn where you can access your system logs and what kind of analytics you have available to you. Make sure to get access to team dashboards, and learn how to query any analytics tools our team is using. In my case, my team uses Splunk so I intend to brush up on my Splunk queries to be able to pinpoint issues we are encountering across our environments.

Things to focus on in the first week

While the topics above are things you’ll be told to do when you start, below you’ll find things that you probably won’t be explicitly told to do, but you should do if you want to start strong. These are all the things I focused on in my first week and will be continuing to focus on.

These include things like:

  • How to make a good impression
  • Embrace the beginner’s mindset
  • Figure out the strategic focus
  • Make little improvements
  • Document everything
  • Keep a WTF Notebook
  • Play

How to make a good impression

You don’t get to make a good impression twice. It’s tempting to try to create a good image of yourself by boasting or being impressive, but don’t fall into that trap.

Instead, I focused on being curious and listening well. My team doesn’t need to learn everything about me the first week. At a minimum, I just want my teammates to feel like they were listened to and respected after each of our interactions.

Also, I like to observe the team’s chats to see what kind of humor the team has developed over time. What jokes are they telling? Are people making fun of each other playfully? Memes? GIFs?

Learning the team’s humor will help you participate in it and is a good way to start connecting with your team.

Good listening and humor will go a long way toward making a good impression. Even more than elegant code, especially in your first week.

Embrace the beginner’s mindset

I noticed that my ego kept popping up in the first week. I wanted to prove myself. Especially since I am coming from a non-technical role back into a technical role, I wanted to prove to my team (but probably mostly to myself) that I am technically competent and will excel in my new role. But this is all ego and pride, and needs to be put aside.

The first week is not about proving anything. It’s a time to learn and absorb. The best way to do that is to let go of ego, and ask questions. It feels silly to get stuck on things and need to ask questions, especially when your new teammates seem to do things so effortlessly. But they’ve had years to work on this stuff. Acknowledge that they know more than you, and seek to use their knowledge as a resource.

Whether true or not, I’ve found it helpful to assume that everyone is smarter than me. At the very least, I assume that everybody has something to teach me, and it’s my job to figure out what it is.

Figure out the strategic focus

Leadership loves strategy. Figure out what are the primary strategic focuses in your area. Or in other words, figure out what leadership wants. Once you figure out what these are, commit to helping push the strategy forward.

In my case, leadership is very focused on getting GitHub Copilot into the hands of developers and focusing on new ways to integrate LLMs into our workflows. So, I’m committed to learning how to use Copilot to speed up my development workflows. To take it even a step further, I plan to become an expert on it so that I can be a resource for other members of my team and department.

Also, innovation is a big strategic focus for my department. To support innovation, they host quarterly hackathons. These hackathons are optional, and relative to the size of the organization, attendance is small. Leadership really wants more people to be participating in these hackathons they’ve set up. So, I’ve already submitted two ideas for our next hackathon coming up in December and plan to lead at least one of them so I can bring others into the hackathon with me.

As an example of contributing to strategic initiatives outside your normal development work, I’ll share the experiments I submitted. My ideas both incorporate LLMs since that is the big strategic push right now. One is to set up a RAG chat interface for our internal technical docs, so that we can “talk with our docs”. My other idea is to assemble the biggest team I can, and then to have everybody use AI to make small scripts or CLI tools to speed up development workflows. The idea here is that instead of using AI as the tool for everything, we can use AI to make our own bespoke tools, perfectly crafted to individuals, teams, or specific workflows.

Your organization may not have hackathons, and AI may not be one of their strategic initiatives, but try to figure out what those initiatives are and how you can contribute to making them successful. This should give you more opportunities for interesting work while also making you more visible across the organization, which will help with growing your career.

Make little improvements

When I’m getting started, no task is beneath me. I want to signal that I’m here to help early on, so I look for little helpful things I can do that are unlikely to get in the way. One of the first places I always look is documentation. Especially onboarding documentation. As a new hire, I have a unique vantage point on the onboarding docs. Almost always, there will be sections that have gone stale or are completely missing. I clean up the onboarding docs and make improvements to them as I go.

I find ways to do this in other documentation too. For example, my team has documentation of our app with a section for dependencies. This section was pretty outdated, so I spent some time digging in the config files to see all the dependencies we consume. I reviewed the config files of other apps across the company to see what other apps were consuming the APIs my team supports.

Another place I found to make little improvements was my department’s internal video library. The problem I found was that the videos have no description, so I would sometimes realize halfway into a video that there wasn’t any useful information for me. So to prevent that, I started downloading the transcripts and running them through an LLM to generate a summary of each video. I then pasted these into the description of the video in Microsoft Clipchamp, so that everybody else who clicks on these videos in the future can quickly see what they are about.

Document everything

The previous section focused on team documentation, but this section is all about personal documentation. I assume that I am incapable of remembering anything, which is nearly true. Based on that assumption, I write down anything and everything that I might need to remember later. If it is not written, it is not remembered.

I did not do great at this early in my career, and it came back to bite me during my job interviews. I could barely remember what I had worked on just a few years ago! I struggled to remember concrete examples of features I implemented or production issues I debugged and resolved.

So now I’ve started keeping a daily-log.md file that is always open in Notepad. This file is just one long list of everything noteworthy that happened each day, paraphrased in my own words. In the morning, I make a heading for the day, and then I just make bullets of each thing that happened. It looks something like this:

## November 3, 2025 Monday

- debugged form validation issue with John (#12344321)
- started building out new table
- meeting with manager: timesheets due every friday, focus on AI, update on functional reqs docs
  
## October 31, 2025 Friday

...

## October 30, 2025 Thursday

...

I write down anything notable that happened so that I have a record of it. Then every Monday morning, I look over all the past week’s daily notes and summarize them into the top 5 highlights for my weekly-log.md file. It looks like this:

## 2025 W45 Nov 3 - Nov 7

1. notable thing
2. notable thing  
3. notable thing
4. notable thing
5. notable thing
   
## 2025 W44 Oct 27 - Oct 31

...

Keeping a log like this is pretty low effort, but it at least gives me something to look back on to remember what I’ve accomplished. This is especially helpful for performance review season. If you do something like this, you could also ask your manager if they want a weekly email of your top 5 highlights each week.

Keep a WTF Notebook

I really like the premise of the WTF Notebook from this article. The idea is that you keep a log of everything that makes you say “What the f…” as you are learning about your new team.

Writing it down is meant to prevent you from jumping to conclusions right away, because there may be historical reasons the team is doing something that you are not aware of. It also serves to capture your valuable perspective as someone with fresh eyes. You can then share these reactions and opinions at a later time, once you’ve had a chance to reflect on whether they are valid or not.

I’ve started my own WTF Notebook and plan to share with my manager and team in a few weeks.

Play

The best way to learn is play. So I’ve gotten all of our code running and have been trying to navigate through our application, pretending I am one of our users. I’ve also been trying out SQL Queries against the database to find out how the tables relate and what the data looks like. Luckily, my team has put together something they call the “Super Query”, which joins together all the related tables under our main parent table and displays all the data together. If your team doesn’t have a super query, building one would be a great way to learn the data and would be a great resource for the team.

Conclusion

The first week of any job is a crucial time. It’s a unique space where not much is expected of you, and you have free rein to ask questions and learn. As a new senior software engineer, you can expect the usual first week things like meeting the team, chat setup, machine setup, and learning all about the business and technology. On top of that, it’s important to go the extra mile to make it an excellent experience. To do that, I like to focus on making a good impression, embracing a beginner’s mindset, understanding the strategy, making little improvements, documenting everything, tracking my WTFs, and playing around.

These points have helped my onboarding go extremely smooth, and I hope they can do the same for you if you’re looking to jump into a similar career path. The best engineers begin not with code or architecture, but with understanding.