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!
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!
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.
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.
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.
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.
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.
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. 🙂
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:
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.
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. 🙂
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.
Sign up for my newsletter because you want to get some quality content served right into your mailbox. Give it a try, it is a great way to improve your development and business skills. Just like a warm cup of tea in the evening, it will do good for you. Even better, you will get the latest news, updates, and promotions. No tea included. 🙂
Note: Your information is protected and I never spam, ever. You can view my privacy policy here.
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.
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.
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.
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.
This article is about the code review best practices. It explains code review from the… Read More
API design is an important aspect of modern software development. It allows different systems to… Read More
This article sheds some light related to the question will ChatGPT or AIs in general… Read More
This article provides an overview of new features and deprecations in PHP 8.2. PHP 8.0… Read More
This article is about Automation and Artificial Intelligence in Software Engineering: Experiences, Challenges, and Opportunities.… Read More
PHP is getting more and more features. Enumerations in PHP are one of the latest… Read More