This article is about kick-starting your new developer job based on my experience gathered in multiple companies and projects. Read it, prepare well and you will do great!
Introduction
Kick-starting your new developer job is very important. Different teams will have different expectations, but essentially you will be expected to find your place in the company. Are there any essential tips for doing this?
I am sharing my experiences based on several different companies and projects I participated in so far. In each of these environments, I had to start from zero, without any significant knowledge of a project or team.
There are experiences from projects and companies such as TimeTac, Codeable, ApiLayer, and Eversign.
By following these important guidelines, I was successful every time. But more importantly, focusing on these things made me feel professional, pushing forward, motivated and I enjoyed working on each of these projects.
Read them through, and share them if you find them helpful. Good luck in your new job!
Steps to kick-start your new developer job
- Understand how your company work, how does it earn money, and why are you hired
- Learn about the company product
- Get used to company language and vocabulary
- Ask about company processes and understand them
- Set up your development environment, try being independent
- Set yourself clear goals with (MIT) Most Important Task on a daily basis
- Keep your code changes "diff size" small
- Aim to be a positive zero at the beginning, reduce risks
- Brush up on your social skills, understand company rituals and habits
Companies one on one, or how stuff works
Understand why you are hired
We are hired by a company or as a consultant for some project. Companies earn money by selling a product or service, or software as a service (SaaS) for that matter.
To make this happen the company hires different people to contribute to their teams. Everyone can contribute in their own way, but there is always some process to describe how things are done. Tasks are usually done in some specific way.
Understand company playground
Then there is the technical environment, which is a playground company set for a team. This environment can really be anything technical. Tools used for coding, debugging procedures, how to test, how to deploy code, who to ask, which tool to use for communication, etc.
Finally, there are open issues and challenges, things someone has to do. That is most likely why the company hired you.
Kick-starting Your New Developer Job, step by step guide
Learn about the product
The first thing you want to do is obvious, you want to read the product documentation. But, this can be tedious, because documentation can be overwhelming.
You should pretend you are a customer who wants to use product. There is no need to go into depths yet, there will be enough time and need for that later.
So, start small, find marketing and promo material, read through it. Then, find customer "how to get started" guides and go through them.
If your company is making software as a service, open a free account or ask someone to give you a user account. Play around, see what software does.
Finally, introduce yourself to sales and customer success teams, they are the closest you will get to customers.
In my experience so far, I was always meeting amazing people in these departments. They have knowledge of how stuff works and in most cases, they want to share it and make a good team.
Bonus tip: If your company has a backlog, read through it, actually skim through it. However, don't get scared or overwhelmed. Very likely 50 of the things in backlog will not be refined or over-scoped.
Understand company language
Companies use specific domain language to describe their products and needs. Very often you might fail to understand something only because vocabulary is not familiar to you. It might look like the team is much more knowledgeable than you, when in fact, they just have "the lingo".
There is no strict rule here, other than listening more than talking and asking whenever something is unclear.
Very important advice would be: Do not fake that you understand something if you don't, ask away.
There is an interesting article about Domain Driven Development, which is a beginner's guide to understanding Domain Driven Development. It is closely related to this topic and you might want to read up on it as well.
Learn about processes
Ask questions about anything you are not sure of, don't assume. If you will be working in a company, you need to know what to do, who to ask for help, and when.
Some things you might need straight away, how do you get tasks, is there a supervisor, who is your technical peer, how do you push code to production. Then, what chat tool do you use i.e. Slack), which channels are important, where can you ask for help?
Keep an open mind, some companies will not have ideally optimized processes for everything. You don't want to start suggesting process changes very early. Two reasons for this. Firstly, you don't know the reasons for these processes which might be very valid. Secondly, you don't know enough about the company to be able to suggest something useful at first.
In short, ask a lot of questions and, when it comes to processes, try to be the one who is listening, instead of talking.
The importance of the feedback
While you are learning about processes and trying to find your way around, you should ask your team to give you feedback on what you are doing.
This way you will know if you are going in the right direction. Asking for a feedback should be a common thing you are confident to do all the time.
As an example, when I wrote this article I asked few friends for a feedback. They shared many interesting insights, from technical to logical and cosmetic ones.
One friend told me that my LOTR (Lord Of The Rings) meme from previous section is outdated and that I should go with something more modern. This is funny, because I already got this comment once at work when I was using similar meme in a presentation.
Long story short, I took some time and make the best out of this comment. Here is a my LOTR meme updated for the 2020. :)
Setup your development environment
The most important thing for kick-starting Your New Developer Job is to, before starting with your first task, make sure your development environment up and running. This might sound easier than it is in reality. Here is a quick list of things you want to do:
- setup development environment in full, do not just make it work in any way possible
- ensure your debugging works, and that you can debug different things you need (i.e. frontend debugging, API debugging, console command debugging).
- your company probably have testing and staging environments, ask about them and setup access to them
- ask about different databases your product uses and set up access to them
- understand how to debug and where logs are
Once you do the steps above, you are well prepared to tackle with your first task.
You also already learned about the project because you had to think about lots of different things while setting a development environment.
The collaborative environment is important
I think it is worth mentioning that collaborative environment is very important. You should understand "rules of engagement" meaning what tools are used for communication, how is testing coordinated and communicated across the team and what procedures are involved.
As a practical example, many teams have dedicated testing servers. However these resources are usually limited and time sensitive and there is some way of coordinating who is using what and when. These are the things you want to understand.
If you don't ask and don't understand these things, that means that you don't need testing environment. Furthermore, that means that you are not testing your code, or at least not testing it in a way your teams finds appropriate.
You don't want to be the person who is not testing your changes properly. :)
Technical vs organizational rules
This is a huge topic which probably deserves its own article. However, we need to at least mention it here. Technical rules are rules defining how to code, check code quality, test, which tools to use, how to debug, deploy, monitor logs, etc. All these things are important.
However, you are not alone in the company. You are not alone in the team. It it wrong to act like you are single person band. In short, there are some organizational rules you want and need to understand. What are these rules? Well, that is the trick, it depends on organization you are working for.
One thing I can promise, these rules will be a bit, or a lot different to what you might assume or what you had in your previous company or in the school for that matter.
Best advice here is to keep an open mind and assume that every rule has a reason (I already mentioned this once or twice in this article). Do not try to change organizational rules. Understand them, work by them, notice strong and weak points. Once you get some "seniority" in the company, you can propose changes to whole team.
However, to be able to change something for better, first you need to live trough it. Or, in words of my colleague, you can not solve a problem. until you spend some time with that problem and understanding what difficulties and pains it is causing.
Consider using Most Important Task (MIT) approach
Most Important Task, or shorthand MIT, is a very simple but powerful approach, which suggests that you should, at the beginning of your day, focus on the task that is providing the biggest benefits.
This approach is based on the fact that first 1-2 hours at the beginning of your day you are at your "cognitive best". Cognitive best means that you have the best chance of solving problems.
Most of the people use this time to read through messages, respond to emails, cleanup stacked questions, and similar. This is not what you want to do.
You want to plan your day and understand what is the most important task for you. The task is providing you the most benefits and that will make the biggest impact on your team and company.
Once you know what this task is, you want to focus and work only on it. You can go a step further and dedicate time slots to read through Slack and Mail messages, instead of doing constant content switching.
Keep diff sizes small
There are two important things here.
First one, when making new features try doing it in phases, document, and explain each phase. This will help your reviewers to recognize problems early and when they point them out you will easily fix them. If you make long and undocumented diffs, everyone will have a hard time examining them and once they find the problem you will have to do everything all over again.
Be smart, plan your features, and bug fixes. It is ok to do something in phases, even if these are small commits. It is not about the size of the code change, but about the impact.
I was already writing about keeping diff sizes small in two other articles. One is about Clean Code Rules and how to improve the quality of your coding. The other article is about how code-reviewers review your code, what do they actually check. You can read up on these topics as well, it can be helpful for your own code.
Aim to be at the positive zero
There is a concept called "Being a positive zero", which means that you did not make any fascinating breakthroughs but you also did not break anything.
When you start working on a new project, the chances that you will break something are bigger than the chances you will make some major impact. Don't take unnecessary risks or try to prove with huge changes. Make a small but positive impact, without causing more harm than good.
Read the room, understand climate and rituals
Soft-skills for Kick-starting Your New Developer Job
Soft-skills are very important and often neglected. When you are part of a new team, you need to understand the climate and "the rituals". Have fun, talk, and hang out with everyone. If you are remote, at least do it online, or if possible visit your team from time to time.
You will not match with everyone of course, but you do need to give chance to anyone to talk about technologies, life, hobbies.
Finally, learn from your mistakes, because you will make them, others will as well. Don't be judgmental and try to keep an open mind.
Most importantly, do not try to compete with others, your competition is with yourself.
Try to improve on a weekly basis, and always be better than your previous self. Other team members and friends are not there to compete against you but to share experiences. Sometimes this experience sharing will look like criticism, but that is perfectly fine. Keep an open mind, be honest and friendly and you will do good.
I wish you all the best!
Bonus tip: I got very valuable feedback on this article from few friends which opinion I appreciate a lot. One comment was very interesting and I am adding it as a bonus tip.
Also, a good tip, try to solve every problem by yourself. If it is not possible to get it done, write down what you did, describe the problem, and then ask your mentor. This way he will already know what you tried and he doesn’t need to try it again for you.
If you don't have a mentor, supervisor, or peer, try finding or asking for one. It doesn't matter if you are a junior, senior, or any other skill level, it is always good to have some supervision and someone to talk to.
Top comments (3)
Love this, Milan! Thank you for sharing it - lots of great tips!!
ah, I see this now, thanks! :) Have you recognized some of your own experiences in these?
Thanks Milan, really good read!
It all sounds good and meaningful.