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

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!

Comments

[Bob Walsh]

A few business things, Ori:

1. Find out and repeat back to them your manager's priorities. Is it coding vs. testing, elegance over readability, etc. And let them know you got their priorities straight. (and by manager, I mean the person that judges your performance, not some mythical VP somewhere)
2. **Start a log of what you've accomplished! **You'll need this for your resume/salary renegotiation. One liners, but start today. Roll them up too.
3. Have an Exit Plan. Know when and why you'll leave the position you're in a major psychic power - even without ever saying it, you get more respect, less bullshit and are valued more. Don't ever tell anyone that Exit Plan, but have it easily accessible.
4. Update your LinkedIn profile, your resume, and anywhere else you store your business life. Don't IG it until you know others at the same company are doing so now. Trust me on this one - some older people like myself are FREAKED OUT by mills IG-ing our workplace. It's a privacy thing.
5. Open Plan does not mean Open Plan. Since the first cave campfire people have been sitting around on rocks and woe to the newbie who takes the senior cave man's rock. Every work environment has a hierarchy, explicit and implicit. The implicit one is the more important.
6. Keep your mouth shut. **You don't know enough to offer informed opinions yet, and the code you may call garbage today might be your bosses' last commit he/she is inordinately proud of. Old saying: better to keep your mouth shut and be thought an idiot than open it and prove it. 7. Enjoy that new job smell!** But realize that while you are tucking into your new job, your co-workers are assessing your every move. Just saying!

[Ori Volfovitch]

I agree.
But I have to add that criteria 1 - 4 that you wrote are always true.
Not just on your first days!

Criteria 5 - 7 are correct and important. They are related to understanding the politics of the office, and are true to any job.
On the first days, at any job, you are a spectator (this comes to notion especially during lunch time!). you should take some time to understand the balance between the co-workers.
In short, as you said - keep your mouth shut!