Letter to Junior: what I would like to know at the beginning

Dear junior developer,

I hope you have fun! I am sure that you are overcoming a lot of difficulties, but do not hope that they will soon end: 20 years later in the field of software development, I still face complex challenges. Whether you are new or not, we have to constantly learn in our work. In my career, there were victories and falls, so I share tips that would help me at the very beginning of my journey.

// Collect constructive feedback

It is pleasant to listen to compliments for the debugged code or the working script, but not all feedback should be positive. Be interested in what is done poorly to improve the work.
')
Ask for honest reviews about your work with colleagues, team or mentor. And most importantly, be prepared and open to any criticism. It is difficult to share feedback with those who do not want to perceive it. Of course, it can be difficult to take criticism when I tried and laid out to the fullest - it's a shame all the same! Over time, you will learn to easily perceive criticism, draw useful conclusions and improve performance based on feedback.

// More than coding

I remember how often I returned to editing a task after its completion. 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 as follows: input is your work: you write code, use libraries, create functions and products. And at the exit - you get a result that should contribute to the achievement of 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 of developers is to concentrate on solving logical problems, not problems. We will understand what the difference is.

For example, you are frantically trying to optimize the search function of an application 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 a non-optimized code, remembered an article with a new optimization technique and decided to try it - you are wasting time.

Solve problems. Stop and ask yourself: “What am I doing? Does it really matter? "

// Find a few mentors

Software and product development is constantly evolving: new techniques, approaches and technologies are emerging. Therefore, do 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 his 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 each task, you will use different approaches, which will greatly simplify life.

Your mentors should not be gray-haired. Do not think that the skill of development depends only on years of experience. A lot of programming experience is definitely a good sign, but I myself often rely on the advice of junior specialists, they can also become worthy teachers.

// Stay cool

It's nice to work in a friendly team that is happy with your success, praises your work and decisions. But it is important to remain on an equal footing and not to lift the 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 with your colleagues on the same wavelength, 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 refused 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 could not cope without me.

Do not select a key figure in the project. If it is accepted in your company that only one 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 close everything on yourself, this is wrong.

Think about what will happen if you leave or the hospital is unexpected: will the project collapse or will the team be doomed to failure? Do not give yourself a strong value that the team could continue to work without your presence.

These are just some of the lessons that I learned from my experience. I hope they will be useful.