January 19, 2018 at 12:25Letter to junior: what I would like to know at the beginning of the journey
- Transfer
- Recovery mode
Dear junior developer,
I hope you have fun! I am sure that you will overcome many difficulties, but do not hope that they will end soon: after 20 years in the field of software development, I still encounter difficult tasks. Whether you are a beginner or not, you have to study constantly in our work. In my career there have been victories and falls, so I share tips that would help me at the very beginning of the journey.
It's nice to listen to compliments for debugged code or a working script, but not all feedback should be positive. Take an interest in what is done poorly to improve performance.
Ask for honest feedback about your work from colleagues, team or mentor. And most importantly, be prepared and open to any criticism. It is difficult to share feedback with someone who does not want to perceive it. Of course, it can be difficult to perceive criticism when I tried and laid out to the fullest - it’s a shame anyway! Over time, you will learn how to easily take criticism, draw useful conclusions, and improve performance based on feedback.
I remember how often I returned to editing a task after it was completed. I constantly ask myself and my team why we are doing exactly this, what it will lead to and for what purpose.
The result is important to you and your team, but more importantly, your personal contribution to achieving the goal. The difference between these two achievements is the following: the input is your work: you write code, use libraries, create functions and products. And at the exit, you get a result that should help achieve goals. In short, the main thing is not a product, but how well it performs its functions. Even if your team consists of the coolest developers with an experience of 100,500 years, it will not matter if your product sucks.
The problem for developers is to focus on solving logical problems, not problems. Let’s figure out what the difference is.
For example, you are feverishly trying to optimize the application search feature to speed up the process by milliseconds. Ask yourself, is this really a critical problem (the one without which the service will not live) or just an exciting task? It is important! If the search function is the basis of the service, then you can save the company. But if you just discovered an unoptimized code, remembered an article with a new optimization technique and decided to give it a try - you're wasting time.
Software and product development is constantly evolving: new techniques, approaches and technologies are emerging. Therefore, you should not rely on the advice and experience of a single person. Find a few people who will become your mentors: each of them will have their own approach to solving problems, writing code and creating a product. So you learn the approach to work from different angles. In the future, for solving each problem you will use different approaches, which will greatly simplify your life.
Also, your mentors should not be gray-haired old people. Do not think that the development skill depends on many years of experience. Great programming experience is certainly a good sign, but I often rely on the advice of junior specialists myself, they can also become worthy teachers.
It is pleasant to work in a friendly team that rejoices at your success, praises your work and decisions. But it’s important to remain on an equal footing and not to lift one’s head. In my team, every developer is a star - not because he writes cool code, but because he makes the team stronger. To make your team better, stay on the same wave with your colleagues, no one wants to support the arrogant “king of all coding”.
Shock news: NO! The company and the project will not die if you decide to leave. Several times I gave up promising career opportunities because I thought that the team and the project would not survive my departure (oh, I was so important!). Yes, I was a valuable employee. But he was mistaken, believing that they would not be able to do without me.
Do not highlight the key figure in the project. If in your company it is accepted that the only person owns complete information about the project / task - change the approach. Expand the team, share information about what is happening in the work and delegate tasks. Do not lock everything on yourself, this is wrong.
These are just some of the lessons I learned from my work experience. Hope they will be helpful.
I hope you have fun! I am sure that you will overcome many difficulties, but do not hope that they will end soon: after 20 years in the field of software development, I still encounter difficult tasks. Whether you are a beginner or not, you have to study constantly in our work. In my career there have been victories and falls, so I share tips that would help me at the very beginning of the journey.
// Collect constructive feedback
It's nice to listen to compliments for debugged code or a working script, but not all feedback should be positive. Take an interest in what is done poorly to improve performance.
Ask for honest feedback about your work from colleagues, team or mentor. And most importantly, be prepared and open to any criticism. It is difficult to share feedback with someone who does not want to perceive it. Of course, it can be difficult to perceive criticism when I tried and laid out to the fullest - it’s a shame anyway! Over time, you will learn how to easily take criticism, draw useful conclusions, and improve performance based on feedback.
// More than coding
I remember how often I returned to editing a task after it was completed. I constantly ask myself and my team why we are doing exactly this, what it will lead to and for what purpose.
The result is important to you and your team, but more importantly, your personal contribution to achieving the goal. The difference between these two achievements is the following: the input is your work: you write code, use libraries, create functions and products. And at the exit, you get a result that should help achieve goals. In short, the main thing is not a product, but how well it performs its functions. Even if your team consists of the coolest developers with an experience of 100,500 years, it will not matter if your product sucks.
// Solve problems and do not waste time on puzzles
The problem for developers is to focus on solving logical problems, not problems. Let’s figure out what the difference is.
For example, you are feverishly trying to optimize the application search feature to speed up the process by milliseconds. Ask yourself, is this really a critical problem (the one without which the service will not live) or just an exciting task? It is important! If the search function is the basis of the service, then you can save the company. But if you just discovered an unoptimized code, remembered an article with a new optimization technique and decided to give it a try - you're wasting time.
Solve problems. Stop and ask yourself: “What am I doing? Does it really make a big difference? ”
// Find a few mentors
Software and product development is constantly evolving: new techniques, approaches and technologies are emerging. Therefore, you should not rely on the advice and experience of a single person. Find a few people who will become your mentors: each of them will have their own approach to solving problems, writing code and creating a product. So you learn the approach to work from different angles. In the future, for solving each problem you will use different approaches, which will greatly simplify your life.
Also, your mentors should not be gray-haired old people. Do not think that the development skill depends on many years of experience. Great programming experience is certainly a good sign, but I often rely on the advice of junior specialists myself, they can also become worthy teachers.
// Be moderately cool
It is pleasant to work in a friendly team that rejoices at your success, praises your work and decisions. But it’s important to remain on an equal footing and not to lift one’s head. In my team, every developer is a star - not because he writes cool code, but because he makes the team stronger. To make your team better, stay on the same wave with your colleagues, no one wants to support the arrogant “king of all coding”.
// Development is a team sport
Shock news: NO! The company and the project will not die if you decide to leave. Several times I gave up promising career opportunities because I thought that the team and the project would not survive my departure (oh, I was so important!). Yes, I was a valuable employee. But he was mistaken, believing that they would not be able to do without me.
Do not highlight the key figure in the project. If in your company it is accepted that the only person owns complete information about the project / task - change the approach. Expand the team, share information about what is happening in the work and delegate tasks. Do not lock everything on yourself, this is wrong.
Think about what will happen in the event of your departure or unexpected sick leave: will the project collapse or will the team be doomed to failure? Do not give yourself strong significance so that the team can continue to work without your presence.
These are just some of the lessons I learned from my work experience. Hope they will be helpful.