{"id":3806,"date":"2021-07-09T13:27:24","date_gmt":"2021-07-09T03:27:24","guid":{"rendered":"https:\/\/eisabainyo.net\/weblog\/?p=3806"},"modified":"2021-07-09T15:38:18","modified_gmt":"2021-07-09T05:38:18","slug":"your-first-30-days-as-a-software-developer-at-a-tech-company","status":"publish","type":"post","link":"https:\/\/eisabainyo.net\/weblog\/2021\/07\/09\/your-first-30-days-as-a-software-developer-at-a-tech-company\/","title":{"rendered":"Your First 30 Days as a Software Developer at a Tech Company"},"content":{"rendered":"

How to onboard well as a software developer by knowing and nailing the expectation of your\u00a0role<\/h4>\n

Recently, Microsoft surveyed 30,000 workers in 31 countries about work, and according to the survey results, 41% of workers globally are thinking about quitting their current jobs. It doesn't require a genius to figure out that tech companies are going to be the ones most impacted by this as the tech industry is one of the fastest-growing industries amidst the global pandemic. So if you are a software developer, you will likely be joining a new company in the next 12\u201318 months.<\/p>\n

---<\/p>\n

Changing to a new job can be quite stressful\u200a-\u200abut it's also a good thing. It puts you outside of your comfort zone and stretches you. It makes you see and think about things that you wouldn't normally think twice about at your previous job\u200a-\u200asuch as making a commit to the company's repo, seeing your work live on production, joining your team stand up, and asking someone to review your pull request. When you are too comfortable at your workplace and you have gotten used to the process and tools, you tend to take things for granted and operate on an auto-pilot mode. Changing your environment, be it a new team within the same company or a new job altogether at a different company, makes you become more aware of yourself and what you do day to day as a developer.<\/p>\n

Besides generic new hire questions like What time should you start work? How friendly should you be in your first week?, this article aims to provide answers to all the software development-related questions that you, as a new developer, wanted to ask your fellow developers or your development manager but were too afraid to.<\/p>\n

---<\/p>\n

I am referring to the questions like:<\/p>\n

\nWhen should you add your code to the company\u00a0repo?
\nWhen should you expect to see your work live on production?
\nWhen should you share your view on a particular design\u00a0pattern?<\/p><\/blockquote>\n

As an engineering manager who has hired and onboarded many developers and tech leads, let me share with you some of the most commonly thought of (and sometimes asked) questions and my answers for them. I hope they will help you as you, as a new developer in a new job, make the best first impression and at the same time, let everyone know the real you and what you've got to offer.<\/p>\n

I will be providing two answers to each question: one for startups and small companies and one for medium to large enterprises. This is because, from my experience as a technology leader with almost 20 years working in the tech industry with startups to Fortune 500 tech companies, I know that the size of the company and the environment play a large role in expectation. Also, note that my answers are just guidelines as there may be some nuances that you might encounter. Regardless, I hope they are helpful in giving you a perspective on what you need to aim for as a newly hired software engineer at a company.<\/p>\n

Part I: It's All About the\u00a0Code<\/h3>\n

When should you set up your development instance on your machine?<\/strong>
\nSmall startup: On the first day
\nLarge enterprise: Within the first two weeks<\/p>\n

When should you make your first commit?<\/strong>
\nSmall startup: Within the first three days
\nLarge enterprise: In the first two weeks<\/p>\n

When should you expect to see your work live on production?<\/strong>
\nSmall startup: Within the first ten days
\nLarge enterprise: It depends. The next release cycle after your first month.<\/p>\n

When should you learn about best practices and coding standards?<\/strong>
\nSmall startup: Within the first week
\nLarge enterprise: Within the first two weeks<\/p>\n

When should you understand the architecture of the system(s) that you'll be contributing code to?<\/strong>
\nSmall startup: In the first week
\nLarge enterprise: In the first month<\/p>\n

When should you be independently picking up and completing a task from your team's backlog?<\/strong>
\nSmall startup: Within your first sprint.
\nLarge enterprise: Within the first month.<\/p>\n

Regardless of whether you're a junior software developer or a senior one, your tech lead or engineering manager should have some tasks that you should be able to pick up independently based on your seniority level. Make sure you communicate this with them.<\/em><\/p>\n

When should you start contributing to story estimation?<\/strong>
\nSmall startup: After your first sprint*.
\nLarge enterprise: After two sprints*.
\n*One sprint=Two weeks.<\/p>\n

Part II: It's About the\u00a0Process<\/h3>\n

When should you start being an on-call person for your team's services (especially if the company practices YBIYRI)?<\/strong>
\nSmall startup: Within the first month.
\nLarge enterprise: After you've shadowed an on-call rotation. Usually after a few months.<\/p>\n

When should you put your hands up to drive a team activity, e.g., running a retro?<\/strong>
\nSmall startup: After you've seen how it's done at least two times.
\nLarge enterprise: Same as above.<\/p>\n

When should you be comfortable being an Approver for someone else's Pull Request?<\/strong>
\nSmall startup: Within 15 days
\nLarge enterprise: Within 60 days<\/p>\n

When should you know about the build and release process?<\/strong>
\nSmall startup: Within the first week
\nLarge enterprise: Within the three weeks<\/p>\n

Part III: It's About the Big\u00a0Picture<\/h3>\n

When should you start being an active participant in various guilds and charters, e.g., Frontend Guild, Technical Architecture Guild, etc.<\/strong>
\nSmall startup: In one month
\nLarge enterprise: In three months<\/p>\n

When should you start contributing to technical discussions?<\/strong>
\nSmall startup: In three months
\nLarge enterprise: In six months<\/p>\n

When should you learn about the product (as an end user) especially its features and capabilities?<\/strong>
\nSmall startup: Within the first three days
\nLarge enterprise: Within the first seven days<\/p>\n

When should you have good knowledge of operational aspects of the engineering?<\/strong>
\nSmall startup: Within the first 20 days
\nLarge enterprise: Within the first 60 days<\/p>\n

When should you start talking about your career aspirations with your manager?<\/strong>
\nSmall startup: Within 30 days
\nLarge enterprise: Within 90 days<\/p>\n

Keep Your Own Onboarding Checklist<\/h3>\n

Your manager may provide you with an onboarding document, but it's also important to keep your own to make sure you're keeping track of your own progress and are meeting the minimum expectation for a software developer role in your first few weeks.<\/p>\n

Apart from coding and technical tasks, you should also add the following important items to your checklist:<\/p>\n