The tenth year will soon come, as I am professionally engaged in programming. Ten years! And besides formal work, almost two-thirds of my life I created something on the Internet. I hardly remember the years when I didn’t know HTML: it’s even strange if you think about it. Some children study music or ballet, and instead I created magical worlds, coding in my nursery.

Thinking about this first decade of regularly receiving money for entering strange characters into the terminal, I would like to share some observations on how my thinking has changed over the years of work .

Perhaps the current juniorsthey will find here some of their beliefs and look at them from the other side. Or they realize that they have already got rid of this, so they went much further than I was at your stage.

Current seniors may also want to share funny (and slightly humiliating) stories about what lessons have been learned from their junior experience.

For clarity, I emphasize that juniors are amazing : just appearing at work to learn new things - this already requires tons of courage. This article is about my own experience and training. I do not generalize at all that all junior developers think or behave this way.

I hope you enjoy the post and remind you of something from the past or the present.

Thanks to Artyom and Sarah for the feedback!

Absolute truths of the junior from which it was necessary to unlearn

1. I am a senior developer

When I first tried to get a job, I was 19 years old. The job was called a "student webmaster." This is a rather surprising name for the work, because you are considered both a “student” and a “master” at the same time. Nowadays, everyone wants to be “engineers,” because it sounds more fashionable, but for me, “master” is a better word for this craft. In any case, my job was to write PHP and MySQL and maintain our site in Drupal, as well as create some internal tools.

Since before that I had been coding for several years in my bedroom, I was sure that these years counted as “years of experience”. Therefore, when asked about how much experience I have written in PHP, I confidently answered: “3 or 4 years!”

I thought I knew a lot about SQL because I can do outer joins (outer joins).

And when I googled, I found out that three to four years of experience means a lot of money.

Let's move on to my last work, which I got after five years of “combined” student and professional experience (which I considered a normal experience). At that time, my code almost never went through a code review. I ran ssh on the server and did git pull. I’m sure I’ve never seen a single pull request. Do not get me wrong, in the first two works I learned a lot of amazing things, I just never worked with other developers in the same code base. Nevertheless, I applied for the position of “senior front-end engineer”, received an offer and accepted it.

So I became a senior developer at the mature age of 24 years.

After all, they would not give me this position if I really were not a senior developer, right ?! Of course, my impressive experience has led me to this peak, so people should listen to me !!! I am at the peak of my technical career, while the youngest in the office.

Just like a boss.

What did I finally understand

Not all experience is the same . My coding experience in the bedroom, the work of a student programmer is different from scientific research in computer science and work in a growing startup. This is a different experience. For a year of work in technical support at the beginning of your career, you can learn ten times more than five years in individual projects (or with minimal feedback). If your code is never viewed by colleagues, training is much slower.

That's why mentors are so important , and your team is much more important than the difference in a couple of dollars in salary. Do not settle for a junior position where you will work alone! And do not choose your first job (or, frankly, any job) only on a salary basis. Team is where the real value is.

I also learned that job titles do not mean anything on their own. The CTO position can be in a team of 5 people, 50 or 500 people. This is a completely different job, although the name is identical. So my title of "senior" did not at all make me a leading programmer. In addition, hierarchical titles are inherently flawed and difficult to compare. I realized that it’s important not to get stuck in the names and you should not use them as some kind of external check.

2. Everyone writes tests

The first half of my career I worked in the research field. In particular, three and a half years on one project with state funding, and then a year and a half at the university in the department of natural language processing. I can say one thing: programming in the scientific environment is completely different from programming in the commercial industry .

For the most part, you are not building applications. You work on algorithms or analyze data sets. Alternatively, if you are creating an application, most likely the work is funded by the state. This means that it is free for others and usually open source. And when something is free, it means that usually you are not responsible for ensuring that it is always available.

Because ... well, it's free.

You are also not responsible for financial income or specific results. However, the work of a programmer in a scientific institution is a topic for a completely different article.

In short, I left the institute with great expectations.

Expectations on how the industry works. Automatic deployments. Pull requests and code reviews. It will be great! Finally, the quality of the code that I dreamed about! But apart from high-quality code with the proper standards and best practices , I firmly believed that in the software industry everyone writes tests .

Hm ...

So imagine my surprise when on the first working day in the startup I did not find any tests. No tests in the interface. No tests in the backend. No tests at all.

Nda. Nothing. Zero. NaN. Tests are missing as a phenomenon.

Not only were there no tests , but no one seemed to have problems because of this! With some naivety, I suggested that the reason is because people simply did not know how to write tests for AngularJS. If I teach them, everything will work out - and we will begin to conduct tests. Error! In general, only a few years later we implemented automated tests in the code, and it was not as easy as I thought.

But not because people do not know how to write them.

They either never experienced problems from the lack of tests, or they experienced problems from the availability ofold tests. Two things that I have never encountered.

What did I finally understand

Many companies and startups have virtually no tests . When fighting for the market or for survival, many companies neglect testing in the early stages. Even trendy companies that sponsor conferences or open source often make a big clumsy monolith with minimal tests. Just ask the developers about the state of the code base.

No company has an ideal technical installation . Each company has problems, each has a technical debt. The question is what they do with it. When applying for a job, you need to clearly understand that everything is not in order there, otherwise they would not have opened a vacancy.

Being overly self-confident in matters where you lack real experience is rather arrogant. I acted SUCH a know-it-all, insisting on the widespread implementation of tests, with almost no experience how to really implement this on a large scale. Do not repeat my mistakes. It is important to have principles, but it is still important to be open and truly interested in order to perceive the experience and views of other people.

3. We are so behind the rest (aka the technical version of the syndrome of lost profit )

This is closely related to the topic of unit testing. My company did not conduct tests, but, of course, all other companies did them, right?

I read a bunch of blog posts. I watched a lot of conference speeches on YouTube. Damn it, I read “that orange site” all the time [probably referring to Hacker News - approx. trans.]. Everyone seems to be writing super-sophisticated and high-quality apps with great performance and trendy animations, while I'm just making patches trying to catch up to the deadline.

I literally idolized all the other companies that I read about, and was disappointed with how much my company and the project lagged behind them.

What did I finally understand

Many conference presentations cover proof of concept, rather than real-life scenarios . Just a story at a conference about a technology does not mean that the company uses this technology in its daily work or that all of their code is in perfect shape. Conference speakers often present toy applications rather than real applications: it is important to distinguish between them.

Working with Legacy is completely normal.. No, seriously, it's easy to imagine that some other company doesn't have a legacy. But after spending time at conferences, talking with people working in top companies, it becomes clear that we are all in the same boat. Try to find a company that does NOT have a huge monolith in PHP or Ruby that they are trying to tame (or should have tamed at some point)? Legacy code is commonplace, and working with it often teaches you more than creating applications from scratch, because you work more with concepts that you still don’t understand.

4. The quality of the code is very important.

In the old days, I could do a very tough code review .

At least I was very picky about style. My style turned out to be a modified version of the Airbnb JavaScript style guide style, but it fits my personal tastes. Things like indentation, formatting, naming - God forbid, you will do it differently. It was completely impossible to go through a code review without a single comment from me: you would have to learn the skills of reading thoughts and, in addition, win the lottery.

Submit more than 50 comments to your pull request that lists all the semicolons that you missed!

Because I have eyes like an eagle - and this eagle wants to get all its high-quality semicolons!

(Fortunately, after many years of working at the computer, the vision like that of an eagle has disappeared, so now you have nothing to worry about - #funny jokes)

What did I finally understand

Good enough - that's enough . When approaching the ideal code, the law of diminishing returns applies. The code should not be perfect, but clean enough to work and not a complete disaster for support. Often code that is too repeating or too verbose is easier for other people to understand. In addition, “good code” is not the same as “code that looks like I wrote it myself.”

Architecture is more important than nitpicking . Although some line can be improved, but the main problems are the architectural order. It’s better to focus immediately on the structure of the application, rather than on individual tiny pieces of code.

Code quality is important, Do not misunderstand me. But the quality of the code is not what I thought. This is not the linting, formatting, or any style that is described in the last article I read.

5. Everything must be documented !!!

When I came to my first real company, for the first time I came up against a strange code for the first time. Of course, I worked a little with someone else's code at the first job, but I never had to go into the existing code base and figure out what the hell was going on here. The only time this happened, I rewrote all the code, instead of trying to understand how it works.

In any case, the fact that it was AngularJS code written by the Ruby developers did not help the situation at all, and I was a junior who imagined himself a senior.

So, how did I deal with the fact that 300 lines of unfamiliar code made me feel like I'm drowning?

JSDOC. EVERYWHERE.

I started to comment on everythingto try to make sense. Annotations for every feature I could get to.

I learned all this fancy Angular-specific JSDoc syntax. My code was always twice as long because it had so much documentation and comments.

What did I finally understand

Documentation sometimes lies . It is easy to think that the documentation solves all the issues. “We need docks!” Although documentation is hard work, it needs to be done. You just have to document the right things in the right way. Excessive documentation of unnecessary things, as a rule, prevents people who are trying to solve a real problem.

Where appropriate, focus on automation instead of documentation . Tests or other forms of automation are less likely to lose relevance. Therefore, I try to focus on writing good tests with a clear language so that other developers can see how the project works with working code. Another example is automating the installation of an application with a few comments, rather than a long and detailed installation guide.

6. Technical debt is bad

If after the last point you considered me a neurotic, just read this one! For some time in my career, I considered any dirty code to be a technical duty . Technical debt is a funny term because if you ask for an example, they say very different things.

Since I considered any “disordered” code to be a technical duty, I immediately tried to eliminate it with the utmost severity!

Once I literally spent a weekend manually correcting 800 linting errors.

That's what a neurotic I was.

(Disclaimer: this was before automatic corrections appeared).

What did I finally understand

Unorganized or messy code is not the same as technical duty . Just imperfect condition does not mean that it is a technical duty. Technical debt actually slows you down in some way, or makes certain types of changes difficult or error prone. If the code is just a little messy, it's just a little messy. Cleaning may not be worth your time.

To have some technical debt is normal . Sometimes we shorten the path, because we need to do the work urgently, and for this we “lend” part of the time in the future. Having code snippets that are a real “technical debt” is normal if you acknowledge that you probably have to return it. If your code base, in your opinion, is free of technical debt, most likely you overestimateappearance to the detriment of delivery . And my God, how I overestimated him!

7. The higher the position of a programmer, the better he programs

Having started programming at a fairly young age, I became a true professional in for loops, honing them to automatism in 15 years. Programming in itself is like breathing to me. When the solution is obvious, I can just print the code non-stop, like text on a blog or email. I can encode the solution faster than others, and usually took on more complex projects.

For a long time, I thought that was the essence of the lead developer.

Does everything seem to fit together? After all, the position is called "lead developer", and not "lead communicator" or "lead project manager." I really did not understand how many more skills needed to be developed in order to become a truly “leader”.

What did I finally understand

Senior engineers will have to master many skills besides programming . Compared to the beginning of a career, I had to develop an astronomical amount of skills. Communication, dependency management, context sharing, project management, evaluating project lead times, and collaborating with colleagues who are not developers. These skills are difficult to quantify and require a lot of trial and error before they are properly learned.

Not every programmer will become a "senior". This is the result of many years of accumulated experience. Nevertheless, many years of experience is a necessary but not sufficient condition for the lord. It must also be the right experience in which you have learned the right lessons and are able to successfully apply this knowledge in the future. Sometimes important lessons will come out in a year or later - that is why years of experience still matter, even if you are a really good programmer.

In some areas we are still juniors . No matter how much experience you have, there are always places where you have little knowledge. Recognizing your incompetence in a particular area is the first step to filling this gap and getting help from more experienced comrades.

Bonus : I really liked the article “Being a Leading Programmer” . Great thing, if at what point you are wondering what this work means.