Entering a new developer’s position: how to do it right?

Tags: beginners, career, productivity, howto
Published: 2019-10-03 06:04:39

# A developer's roadmap to a new job
Entering a new job, any job, is exciting. It could be a positive or a negative experience, depending on your personality, dynamics with the new colleagues, understanding your new responsibilities and many other factors.

> TL;DR – Try the pro-active approach. 
> Integration is faster for those who take initiative.

As a developer you also have the pressure to learn the product quickly, and know your whereabouts in the code, while learning your responsibilities.
Your employer is aware that while he is paying you a salary (high salary, you are a developer!), it will take a while before you actually **become productive and worth the pay you get**.

Your learning curve, and the time it will take you to become lucrative for the company, is crucial to your success in this company. Being an easy adapter can never be underestimated, and whether you are a good coder and an experienced developer, this skill is not granted.

Your team leader will probably have an agenda ready for your first week, or so. If he made plans for you, that’s great! follow them. But, I would suggest to go for the **pro-active approach** (with *no discrepancies to your team leader's agenda!*). 
If you want to prove yourself to your team leader, teammates and yourself, here are the actions that will help you fit in and deliver quickly:

## Getting to know the colleagues and your interactions with them 
On the first day, you are not going to write any code. In fact, it might take a few days. Developer’s mistakes are very expensive, and we don’t want to make any of those! We have to make sure we know what we are doing.
What you should do on your first days, is schedule 1 on 1 meetings with your new colleagues.
First and most important is to meet with you team leader and teammates. On that, I will expand in the next paragraph. But to get the bigger picture, you must go through a few more work mates.

Start the meetings with a short small talk to make the meeting pleasant and make a good first impression. Questions like - how long have they been working for this company, and how do they feel about it. Just to make the conversation flow. 
Before asking any professional questions, let them lead the conversation and let them have their own take on your job and responsibilities. They might add important issues that you haven’t thought of. Then, make sure you went over these topics according to your colleague’s position: 
* Project manager - work flow (Scrum, Agile, Kanban), project management technologies (like Jira, TFS, etc…) and how to use them, who assigns you with tasks and bugs, who gives time estimations, who prioritizes your tasks. If there is no project manager in your team, the responsibilities are split between your team leader and product manager.
* Product manager – The product (past, present and future plans), monetization (or better – how does the $money$ get in?), product pitfalls and work flow.
* QA engineer – work flow and pitfalls.
* CTO / R&D / Tech lead / any high ranking superior – the product, responsibilities, pitfalls, present and future challenges. Expectations.
* Team leader – this is your direct superior. It will take more than just one meeting, and this is crucial to your success, thus, I will expand more about this in the next step.

## Getting to know the team and work environment
First meeting with your TL, should start like the previous mentioned meetings (small talk, then let him lead). on your turn to ask questions, make sure you know the following:
* Project architecture (there might be more then one project)
* Frameworks in use (Angular/Vue/React for frontend, any CMS  like Wordpress/ Drupal / SharePoint or MVC in the backend like Laravel/ Symphony / Springboot )
* source-code management (GIT, SVN, etc…)
* DB (MySQL , MongoDB, etc…)

You can and you should do a retake on this meeting with your teammates.

## Getting to know the technologies
After talking to your TL, he might mention a technology you don’t know or don’t remember.
It’s very important to stop at this point and take a few days to learn it, before diving in to the actual code. If you are using a technology like Laravel, or Wordpress, take at least 3 – 6 days to learn the basics. Get your hands dirty and build a mini site with minimal functionality according to the guides you found on the web.
If it’s a frontend technology like React or Angular, take another 2 – 5 days to learn the basics and build a small project like a task manager. Again, try to apply the architecture you found in the web guides.

## Getting to know the project architecture 
Once you have acquired basic skills in the framework technologies, it’s time to dive into the projects files. Ask your TL and teammates to describe the architecture, and if you notice any differences from what you know about these technologies (ergo, how should a Laravel or React project look like), confront them in a professional manner. Ask why was it done this way, and not that way.
1. Ask for a description of the **work folders**. Approach this as if you are going into a library for the first time, and you are trying to learn its order.
If in a library you would have categories like: science fiction, adventures, comedy, miscellaneous and etc…, in a typical dev project you would have categories like: framework core files, templates, classes, UI functions, services, general files and etc...
You might also have files that are not where they belong, due to legacy issues.
Also, know the location of the configuration files. You hardly get to make any changes in them, but knowing their whereabouts is very important.
2. **Objects & Classes** – it will probably take you more than a while to learn ALL the objects & classes, there would be only a few that you will make constant changes in them. Try to focus on them.
3. **Routing** – how does it work? Very important to find your way around inside the project.
4. **Plugins** - 3rd party software that you use in the project.
5. Debug - Understand **where does the code starts**. Get your hands dirty and start debugging. 
Have a look at the product, find something that catches your eye, and find it in the code. Make changes and revert.

## Getting to know the coding style
One might say this is part of the architecture. I would like to give it an extra attention, this is the bits and bytes of your team’s work;
* Naming conventions - does the functions and variables use camel case or underscores? Do the functions name make sense to you?
* Design patterns  - getting to know the applied design patterns in the code. How are they applied? Are there any design patterns that you are not familiar with? Stop and learn them.
* Git messages convention.
* Documentation – hopefully for you, your new team documents the code. 


## Get your credentials
Another reason that developer’s first days of work are slow is lack of credentials.
Without them you will constantly get stuck. Make sure your TL and IT manager give you all the credentials you need: 
* Email
* Project management tool (Jira, TFS, etc…)
* Cloud, Servers, DB
* Server build tools
* Dashboards or CMS access
* Communication tools (Slack, Teams, etc…)

## Getting your first task
The moment you solve your first task is crucial for the primal impression you give your superiors. Push your team leader to have a “mini-task” ready for you, and try to solve on the first week.
Just to get things going. *Don’t make the “ignition” a long tedious process*.

## Summarize
Sitting on the fence, waiting to become an active and productive team member is a bad practice. Push yourself and show initiative. If it brings you joy, you are definitely on the right track!
Now, all that’s left is:
```
worker = new Worker();
worker.init();  
```
// Any comments? Please share!