Mastering Your First Days as a Software Developer
Written on
Chapter 1: Embracing a New Role
Starting at a new organization brings a mix of excitement and fulfillment. The early days are usually spent acclimating to the company culture, understanding procedures, completing required training, and setting up your work environment, along with the usual details about vacation policies and service requests.
Then comes the onboarding process at the team level, where you learn about the product you’ll be contributing to. This typically involves sessions on product familiarization, technical onboarding, and gaining access to necessary tools, all while grasping the team's workflow.
As a developer, the urge to dive straight into the codebase can be strong. However, it's crucial to adopt a broader perspective as a newcomer. There are various elements to familiarize yourself with before making any alterations to the code.
In this article, I will outline my strategy for comprehending the system from both product and technical viewpoints. With experience from multiple companies, I've refined this approach, making it easier to onboard efficiently and contribute meaningfully.
Reviewing the Documentation
The first step is identifying the tools your team utilizes to document design decisions, architectural frameworks, and domain knowledge. Always seek out the primary source of truth for information, as it may be dispersed across various platforms with slight variations.
Begin organizing your bookmarks into folders to categorize all relevant links. Once you develop a mental map of these resources, it will be much simpler to locate information when needed.
Product Documentation
Next, you can choose between reviewing product documentation or technical documentation. Personally, I prefer to start with the product documentation for two main reasons:
- It offers a comprehensive view of the product from the user's standpoint, helping me visualize possible user journeys.
- It aids in gathering domain knowledge, including client interactions, integrations, and third-party dependencies.
High-Level Technical Documentation
Afterward, you can shift your focus to the technical documentation of the components involved. Employ the C4 model approach, which simplifies understanding by breaking the system into smaller parts. A high-level overview encompasses levels 1 and 2.
Component-Level Technical Documentation
Once you have a grasp on the high-level aspects, delve into the specifics of individual components. Understand their responsibilities, inputs, outputs, and database tables. For instance, if a service manages transactions, consider:
- Who utilizes the service?
- What dependencies does it have?
- How many requests does it process daily?
- Is it more read-heavy or write-heavy?
- What database is in use?
- Is idempotency a factor?
- Does it implement caching? If so, for which scenarios?
Pose questions regarding the technical stack and design choices. If the system employs event-driven architecture, seek clarity on the rationale behind it. Understanding these design philosophies will facilitate your comprehension of the implementation details when you start exploring the codebase.
Picking Your Initial Task
Once you've gathered sufficient information, it's time to embark on your first tasks. Choose tasks that span multiple components, focusing on smaller assignments that do not necessitate extensive knowledge of the codebase initially.
As a newcomer, ensure you familiarize yourself with the codebase of the components your team manages. Depending on team size and component complexity, aiming for 2-3 components is a practical goal.
While working on these tasks, pay attention to the repository structure, utilized tools and libraries, the flow of individual endpoints, design patterns, error handling, configuration files, how secrets are managed, and deployment methods. Utilize a top-down approach, starting from the directory level and gradually delving into the specifics of classes or repository implementations.
Avoid the temptation to rush through tasks. It's vital to take your time and thoroughly understand the code. Look for opportunities to refactor or enhance test coverage, adhering to the Boy Scout principle. This will deepen your understanding, and since expectations are manageable, taking an extra day will not lead to any issues.
Regular Check-Ins
After your first week, arrange one-on-one meetings with team members. Depending on your team's size and other commitments, a bi-weekly or weekly cadence can be effective. This practice fosters a continuous feedback loop, builds trust, and enhances your confidence within the team.
Schedule 30-minute discussions to talk about your current tasks, your implementation thoughts, any challenges you're facing, and potential improvements. Feel free to address any concerns or provide feedback, and don't hesitate to engage in casual conversation unrelated to work.
In a remote work environment, maintaining regular communication is even more vital.
Becoming a Team Contributor
As you settle in over the weeks, you may identify areas for improvement. If you believe the team could benefit from fewer meetings, speak up. This is your opportunity to influence positive change.
Gather data on the issues, assess their short- and long-term impacts, and propose viable solutions. No team is flawless; even small contributions can make a significant difference. Ultimately, outcomes are what matter most.
For example, when a product manager introduced Notion for documentation in one of my teams, it significantly enhanced our workflow, and everyone appreciated the change.
There are many opportunities for you to contribute beyond just technical tasks. Remember, it's about being part of the team!
Proactive Communication
In my view, proactive communication is one of the most essential traits to cultivate. Always be forthcoming about any challenges you encounter. If you're stuck on a task, don’t hesitate to bring it up in standups or other team meetings. Clearly articulate any obstacles you're facing and seek assistance.
This approach keeps everyone informed about your progress. Team members are often preoccupied with their tasks and may not be aware of your struggles. It's your responsibility to share updates, whether through direct messages or emails, depending on your team's preferences. The goal is to ensure everyone is on the same page.
Don't hold back!
Closing Thoughts
Understand that you don't need to grasp everything immediately. It typically takes 2-3 months for a new engineer to fully onboard and become a consistent contributor. Use this initial period wisely to maximize your learning.
TL;DR
Navigating a new role can be challenging, but to excel and make a positive impression, focus on the following:
- Reviewing documentation: Transition from product to engineering documents to clarify business flows and components.
- Selecting your first task: Aim for a broad understanding by tackling smaller tasks across components.
- Regular check-ins: Engage in one-on-ones with team members to build strong relationships.
- Team contribution: Propose improvements to enhance team productivity based on your prior experiences.
- Proactive communication: Always ask questions and address challenges promptly.
Thank you for reading!