Fast Track to Impact: A Software Engineer’s First Week Guide

Starting a new job as a software engineer is always exciting.

There are new challenges to prove yourself, learning opportunities to grow professionally, and a big fat paycheck—or one on a diet these days.

But it can be overwhelming, right?

In corporate software development, getting to know software takes time. You’ll need months to fully grasp the intricacies of one app’s features, team conventions, and best practices. It takes years to be comfortable with the entire architecture, but each step of this learning process is a step toward becoming a seasoned software engineer.

At the same time, you’ll be tempted from day one to be useful and show them why they hired you instead of someone else.

Here are my tips on what you can do during your first week as an engineer before you’re familiar with most of the code.

🏔️ Learning the Landscape

Freelancing changed how I think about software development.

At my first workplace, I loved that I didn’t talk to clients and that I was a “coding guru” who focused on nothing but technical excellence.

Figure out what’s going on in the company at the moment.

• Business: Clients drive your company. Look for recent business goals: recordings of yearly kickoff meetings or documents. You’re not responsible for sales as a software developer, but most of your future tasks directly result from these goals. With more profit, you’ll have higher chances for a pay raise, promotion, or new roles you can fill.

• Organization: Your HR software likely has an OrgChart. Learn more about your company’s structure, who reports to whom, and how many teams there are. Take the time to explore this because you’ll meet them soon in your next meeting!

• Product: If you have multiple products, it’s a great idea to become familiar with their purpose, at least on a high level. Take extra time to explore the product your team works on. This might vary between organizations, but besides technical questions, I’m always curious about users’ pain points. Where is most development time spent, and what features are most wanted?

On Exploring The Codebase

You will hear this often: “Just look around until we find something for you!”. You can randomly look at PRs or the entire codebase, but here’s something more strategic.

Identify an effort your team focused on and see how they tackled it.

If you’re a senior engineer, after looking at some PRs, you might already have some thoughts about them. This is great. That’s why they hired you!

Don’t jump to conclusions!

Your knowledge of the codebase is limited, and things were probably done in a specific way for a reason. So, hold on with comments. If something seems way off, ask the PR’s author or your mentor for clarification, but always assume that you just got the first pieces of this big puzzle.

🤝 Building Relationships

• Find Your Mentor: If possible, identify a lead developer or team lead who can mentor and answer your questions as you navigate the new environment. They’ll be helpful if you’re stuck with your environment setup or need help with the first few tasks.

• Introduce Yourself: I keep this short while trying to answer “How can I be helpful to you?”. I tell what I did before and how I can help others. Early on, you might not have any assigned tasks, and while this period lasts, it is the perfect time to pair with people and give your high-level opinion on things you have experience with—if they want it, of course. For example, a team I just joined recently revamped its testing practices. They read my blog posts about testing on my tech blog and were eager to hear my comments on some of their implementation.

🙋 Asking Questions

• Don’t Hesitate: Your questions are valuable—and even more valuable if you’re a senior engineer. Don’t be afraid to ask clarifying questions to fully understand the context and expectations. It might happen that something you always did in a specific way didn’t even occur to your team, and you already have a better solution!

• Seek Out Challenges: Once you have a basic grasp, express your interest in taking on challenging tasks or projects. This demonstrates your initiative and desire to contribute. Take notes during onboarding. When you come to this step, you might already have ideas to tackle. Maybe a command is missing from the README steps, and you might have spotted a typo on the UI or stuck in a weird state!

♻️ Summary

• Learn more about the business. Explore teams and projects. Oganization-wide goals, both business and development.

• Identify your mentor

• Introduce yourself and offer your expertise

• Be curious: if something seems off or you don’t understand it, ask questions

• Be proactive during onboarding

How did your first week go in your company? What did you do to be useful?

📰 Weekly shoutout

1. Stateless Architecture - What’s the Deal? - simple and easy-to-understand explanation of the differences between stateful and stateless architecture types from Saurabh Dashora!

2. Organizing the best Cleanathon your company has seen - if you love deleting code as much as I do, this is for you. A genius idea from Anton Zaides (runs by Cleananton from now) on how to save money and time while deleting code.

3. I read 300 books in 6 years. How to read faster (and learn more). - great post from Fran Soto on how he gets the most out of the stuff he reads. This is an area where I have to improve a lot!

---

📣 Share

There’s no easier way to help this newsletter grow than by sharing it with the world. If you liked it, found something helpful, or you know someone who knows someone to whom this could be helpful, share it:

🏆 Subscribe

Actually, there’s one easier thing you can do to grow and help grow: subscribe to this newsletter. I’ll keep putting in the work and distilling what I learn/learned as a software engineer/consultant. Simply sign up here: