Transcription
How seniors write code and why you should start doing the same is what I will discuss in this video.
First, we need to agree on who senior programmers are. There are many different opinions on how to define a senior. The most common criterion is years of experience. If you have worked for 10 years as a developer, you can be considered a senior programmer. If you have worked for only one year, you are just a junior.
However, if you spent all 10 years just painting buttons or writing CRUD endpoints, you might be a senior in CRUD or in painting buttons. But whether you are a senior or not is a big question. It probably depends on the tasks you have solved. Some say that if you have tackled complex technological challenges, you are a senior programmer.
In one comment, someone wrote that if a developer cannot independently deploy clusters and Hadoop, then there is nothing to discuss with them. They wouldn't consider that person a senior. But if, at your workplace, there is no such technology and you haven't used it, then saying you are not a senior programmer is also not possible. If such a developer goes to another company where they can deploy those clusters, but it is not needed there, then their seniority won't be useful.
Thus, specific tasks cannot be classified as the extensive and complex experience that makes you a senior. There is also a widespread belief that seniority can be measured by salary. If you receive a senior salary— for example, for a Java backend developer, a senior's salary starts at around 35,000 rubles per month—then we will measure by this criterion. If you earn that salary, then you are a senior programmer.
Personally, in my career, I have worked on about 20 different projects, and I earned between 150,000 and 500,000 rubles per month. I want to say that there is practically no difference in the tasks I performed for 150,000 versus 500,000 rubles. I wouldn't say that for 150,000 rubles, I was doing tasks that were purely junior-level, and seniors were given different tasks. No, there were very complex tasks, including memory leaks and optimizations.
For example, at Sberbank, I worked on CRUD, doing some elementary things. Those tasks were not something that a mid-level or junior could easily handle. Therefore, money is not a reliable indicator of whether you are a senior or not. Complex tasks and extensive experience are not necessarily linked to salary.
You can prepare for interviews, negotiate well, and if you can sell yourself effectively, you might land a high salary without being a senior. There is also the criterion of what is written in your employment record. When I got my first job at Sberbank, they immediately wrote "senior developer" in my employment record. So, was I a senior? Of course not. I was a junior, or at most, a junior-minus.
So, there is clearly no single criterion for determining seniority. I would say that a senior developer combines all these factors. If they dominate in most areas, then they are a senior. A specific factor might lag behind; they might earn less than the market average, but they have extensive experience and have solved great tasks at a high level.
They might just not sell themselves well and earn less, but they are still a senior developer. Conversely, there might be other criteria where you have less experience but are solving complex tasks, earning a lot, and holding a high position, dealing with architectural challenges. But having little experience in your employment record doesn't say much. You can still be a senior developer.
Therefore, considering all these factors, to advance in your career and achieve new heights in both your career and salary, you need to understand the principles that senior developers follow to move in the right direction.
The first principle that a senior developer follows is to ask a lot of questions before starting any assigned task. They analyze it, go to the business, the client, or the analyst who set the task. They ask a million questions: what problem are we solving, what do we want to see as a result? Sometimes, the task is not clearly written, and the client might want something different.
To avoid ending up with a result that doesn't match the business's expectations, you should first ask all the questions and clarify any nuances. Maybe the client doesn't even need this task. Perhaps there are already ready-made solutions or functionalities. This way, a senior saves their own time and saves money for the business.
Even if the task is set and needs to be solved, they don't start writing code immediately. They look for ready-made solutions, maybe Google something instead of reinventing the wheel. This is important not only in development but also during the interview stages.
I often see in recordings of mock interviews with juniors or real interviews that there is a coding section where the junior is given a task, and they immediately start coding without asking questions. No, you should first ask what inputs we have, whether the array is sorted, if there can be empty values, or discuss corner cases in advance.
Before starting any task, you should discuss a lot of different questions with the task setter and not waste time, money, or effort on unnecessary things.
The next principle that a senior developer adheres to is to complete their task 100%. Not 80%, and not leaving stubs, but fully completing the assigned task. You should write the code yourself, test it manually, cover it with tests, and not leave any stubs for later.
You should write tests for your code immediately, completing the entire functionality. This way, if a senior sets a task for you, they know it will be completed fully, not just 80%. It won't turn out that the tests weren't covered or that documentation is missing.
If you finish all your tasks completely and keep track of execution and code coverage with tests and documentation, it raises your prestige in the eyes of the team lead. They know they can assign you a task without worrying about any issues that will need to be fixed later.
The next principle that a true senior programmer follows is adherence to coding standards. There are two types of coding standards: widely accepted standards and internal company standards. To understand the widely accepted standards, you should study the SOLID principles and perhaps read Martin Kleppmann's book.
I wouldn't recommend strictly adhering to these principles in every situation, as they are not universally applicable. For example, in Spring, they are often violated. There are cases where you can break them, but that doesn't mean you shouldn't study and apply them.
SOLID principles are needed to ensure that the code you write is easy to read, extend, and maintain. It should be simple and understandable for everyone. Additionally, there is the DRY principle—Don't Repeat Yourself. You shouldn't write a lot of duplicated code or copy-paste.
If you see that you have two places where you are copy-pasting, that's okay, but by the third instance, you should definitely extract that method into abstract classes or methods. Don't forget to format your code. It's very simple in an IDE; it's Ctrl + Alt + L. In some other environments, look up the keyboard shortcuts.
Install the SonarLint plugin in your IDE; it will help you avoid the most primitive mistakes in terms of writing complexity or basic pointer errors. Use it, follow its advice, and try to fix the issues it points out.
Senior programmers also remember to document their code because the code itself is not always clear about what it does. It needs to be studied, and comments and documentation help to immediately understand what it does, what arguments it takes, and what output you will get.
This is also very important: proper naming of variables, methods, and classes. Don't abbreviate; don't be afraid that your variable names will be too long. It's better than abbreviating and making it unclear what they mean or what they do.
There are several advantages to this. First, reviewing code with clear, understandable variable names, classes, and methods is much easier. Second, someone who will use your code later will understand what is happening based on the proper names.
And third, when you look at your code a year later, you might not remember what it does. If you wrote it clearly from the start, it will be easier for you to understand it later.
I also want to give advice for interviews. It doesn't matter if you are a junior, mid-level, or senior; if there is a live coding section, you should name your variables properly. Don't think, "This is just a test task; why should I care?" This is an abstract task, so I can name variables randomly.
No, interviewers look at how you name variables. If you use abstract letters or words, that's nonsense. You will do the same in your code. At least that's how they evaluate it. If you are given a code review task, pay attention to these points.
If they tell you to review a piece of code, pay attention to the names of classes and variables. If it just says "My CL" or "My Test," point out that we pay attention to such things. If they say, "It's just a test task; don't look at that," then okay, but you should definitely pay attention to it.
This greatly increases the readability of your code at all stages. It's very important for the team, for yourself, and for interviews.
I have examples of how I go through interviews on my Boost page. You can check it out; I do the same thing. Yes, I pay attention to these variable names. You can also find integrations with Telegram channels there. You can join the Telegram channel and ask questions.
If that's not enough, you can join group calls where we discuss these questions. You can also come for free consultations, but time is limited. There are paid consultations through the same Boost platform, where you will receive all the same bonuses: Telegram channels, group recordings, the opportunity to join group calls, and also personal consultations with me, which take priority.
If you want to get into development as quickly as possible, I can help answer any questions you have, any fears or beliefs related to job searching, resumes, interviews, what you need to learn, what you don't need to learn, and what to pay attention to.
Everything that concerns you, please come and ask questions. Join the consultations; I will help you. Links will be in the description.
The next very important principle of a senior developer is proper task estimation. All senior developers typically estimate tasks with a much larger buffer than it seems at first glance. It may seem that a task can be completed in one day, but there might be hidden challenges, and it ends up taking two or three days.
To avoid having to justify why a task took longer than expected, it's better to estimate with a buffer from the start. Generally, the business wants you to complete the task predictably and on time. They don't need you to say the shortest possible time to complete the task because you might not finish it in that time.
Then, your team lead will have to go to the business and explain why a task estimated for a week is taking two weeks. A senior developer understands that, in addition to hidden challenges, they will need to consult with the analyst, ask questions, and so on.
They allocate time for the task itself, for writing tests, for manual testing, for debugging, for writing documentation, for code review, and for fixing any possible comments.
In total, a task may look like it can be done in one day, but in reality, it might require two days of work. This is very important because team leads love predictability. If you estimate a task for two days, you should complete it in that time, not come back later and say, "Well, it took two days, and I still need to write tests, so I need another two days."
No, you should estimate with the maximum amount of time from the start. Juniors often have this problem, and I had it too. You are afraid to estimate too much time because you think others will think it's an elementary task. If you say it will take a week, the team lead might say, "What? A week? What could possibly take that long?"
So, estimate with a maximum amount of time from the start. For example, when I estimate too little, I often get told to add more time because I need to write tests and consult with the analyst. So, it's better to estimate more time to ensure you can complete it within that timeframe.
The fifth principle of a senior developer is KISS: Keep It Simple, Stupid. A senior developer should strive not to complicate the code they write. They shouldn't overdo it with architecture or create abstract classes or overly complex code.
They understand that a junior will come along and need to work with that code, and they won't understand the complexity. If a mid-level or junior-mid-level developer starts writing overly complex code, thinking that the more complex it is, the cooler it is, a senior understands that it's better to write as simply as possible.
They shouldn't introduce unnecessary patterns if you have a simple MVP application. Instead, you should make it as simple as possible. You don't need to try to refactor everything that seems off along the way.
If there is a piece of code that looks bad, you can tell the team lead about it and ask if they want to refactor it. Most likely, the team lead will say that there is no task for that right now. Complete the current task first, and we can add it to the technical debt later.
If you introduce bugs while trying to refactor, no one will be happy about that. So, I highly recommend juniors: if it's not your task, don't touch it.
That's all I wanted to say today. If you want to develop in IT, subscribe to the channel. See you in the next videos. Goodbye!