Soon the tenth year will come, as I professionally do programming. Ten years! And apart from formal work, almost two-thirds of my life I created something on the Internet. I can hardly remember the years when I didn’t know HTML: it’s even strange to think about it. Some children study music or ballet, and I instead created magic worlds, coding in my nursery.

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

Perhaps the current juniors will find here something of their convictions and look at them from the other side. Or they realize that they have already got rid of it, so they went much further than I was at your stage.
')
The current lords may also want to share funny (and slightly humiliating) stories about the lessons learned from their junior experience.

For clarity, I emphasize that juniors are awesome : it’s easy to appear at work to learn new things — this already requires a ton of courage. This is an article about my own experience and learning. I don’t generalize that all younger developers think or behave like this.

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

Thanks to Artem and Sarah for the feedback!

The absolute truths of the junior, which had to unlearn

1. I am a senior developer

When I first tried to get a job, I was 19 years old. Vacancy was called "student webmaster." This is quite an amazing job title, 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 more appropriate word for this craft. In any case, my job was to write PHP and MySQL and maintain our site on Drupal, as well as create some internal tools.

Since before that I had coded for several years in my bedroom, I was sure that these years are considered as “years of experience”. So when I was asked about my experience in writing in PHP, I confidently answered: “3 or 4 years!”

I thought I knew a lot about SQL, because I could do outer joines (outer joins).

And when I googled, I found out that three or four years of experience meant a big pile of money.

Let us turn to my last job, which I received after five years of “combined” student and professional experience (which I considered to be a common experience). At that time, my code almost never went through the code review. I ran ssh on the server and did git pull. I am sure that I have never seen a single pull request. Don't get me wrong, in the first two jobs I recognized 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 engineer of the frontend”, received the offer and accepted it.

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

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

Just like a boss.

What I finally understood

Not all experience is the same . My experience in coding in a bedroom, working as a computer programmer is different from research in computer science and working in a growing startup. This is a different experience. For a year of 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 goes much slower.

That is 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 the position of junior, where you will work alone! And do not choose the first job (or, frankly, any job) only on the basis of salary. Team is where real value is.

I also learned that job titles mean nothing by themselves. The position of the CTO 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 "Senora" did not at all make me the lead programmer. In addition, hierarchical titles are inherently flawed and difficult to compare. I realized that it is important not to dwell on the names and should not use them as some kind of external verification.

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 one and a half years at the university at 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 do not create applications. You are working on algorithms or analyzing data sets. Alternatively, if you create 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 high expectations.

Expectations regarding how the industry works. Automatic Deploy Pull Requests and Code Review. It will be great! Finally, the quality of the code I dreamed about! But besides a high-quality code with proper standards and best practices , I firmly believed that everyone in the software industry wrote tests .

Hmm ...

So imagine my surprise when I didn’t find any tests on the first working day in a startup. No tests in the interface. No tests in backend. No tests at all.

NDA Nothing. Zero. NaN. Tests are absent as a phenomenon.

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

But not because people can not write them.

They either have never experienced problems from the lack of tests, or experienced problems from the presence of old tests. Two things that I have never encountered.

What I finally understood

Many companies and startups have almost no tests . Fighting for the market or for survival, many companies neglect early stage testing. Even fashion companies that sponsor conferences or open source often make a big clumsy monolith with minimal tests. Just ask the developers about the status of the code base.

No company has a perfect technical setup . Every company has problems, every technical debt. The question is what they do with it. In employment, you need to clearly understand that there is not everything is in order - otherwise they would not open a vacancy.

Being overly confident in matters for which you lack real experience is rather arrogant . I acted SUCH know-it-all, insisting on the widespread introduction of tests, having almost no experience on how to actually implement it on a large scale. Do not repeat my mistakes. It is important to have principles, but it is also important to be open and truly interested in order to take in the experience and views of other people.

3. We are so far behind everyone else (aka technical version of the loss of profit syndrome )

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 speeches from conferences on YouTube. Damn it, I continuously read “that orange site” [probably referring to Hacker News - approx. trans.]. It seems that everyone is writing super-complex and high-quality applications with excellent performance and trendy animations, while I just make patches, trying to get to the deadline.

I literally idolized all the other companies I read about, and was disappointed by how far my company and the project were lagging behind them.

What I finally understood

Many conference presentations cover proof of concepts, not real scenarios . Just a story at a conference about some kind of technology does not mean that the company uses this technology in its daily work or that all their code is in perfect shape. Often, speakers at conferences present toy applications, not real applications: it is important to distinguish them.

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

4. The quality of the code is very important.

In the old days, I could make a very hard 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, but it matches my personal tastes. Things like indents, formatting, naming - God forbid you do it differently. It was absolutely impossible to pass the code review without a single comment from me: you would have to master the skills of reading thoughts and in addition to win the lottery.

Submit over 50 comments to your pull request listing all the semicolons you missed!

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

(Fortunately, after many years of work at the computer, the vision of an eagle has disappeared, so now you have nothing to worry about - joke)

What I finally understood

Good enough - that's enough . When approaching the ideal code, the law of reduced recoil acts. The code should not be perfect, but clean enough to work and not a complete disaster for support. Often, code that is too repetitive or too detailed 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 nagging . Although some line can be improved, but the main problems of the architectural order. It is better to focus immediately on the structure of the application, rather than on individual tiny code fragments.

The quality of the code is important , do not get me wrong. But the quality of the code is not what I thought. This is not lintting, formatting or some kind of style, which 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 across 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 find out what the hell is going on here. The only time that this happened was I rewrote all the code, instead of trying to figure out how it works.

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

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

Jsdoc EVERYWHERE.

I began to comment on everything to try to find meaning. Annotations for each function that I could get to.

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

What I finally understood

Documentation sometimes lies . It is easy to think that documentation solves all questions. “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 the wrong 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 the working code. Another example is to automate 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 item you thought I was neurotic, just read this one! For a while in my career, I considered any “dirty” code a technical duty . Technical debt is a funny term, because if you ask for an example, they will call very different things.

Since I considered any “unordered” code a technical duty, I immediately tried to eliminate it with maximum rigor!

Once I literally spent the weekend manually correcting 800 lint errors.

That's how neurotic I was.

(Disclaimer: it was before the automatic fixes appeared).

What I finally understood

A disorganized or disorderly code is not the same as technical debt . Just imperfect state does not mean that it is a technical debt. 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 confused, it's just a little confused. Cleaning may not be worth your time.

Having some technical debt is normal . Sometimes we shorten the way, because we need to do the work urgently, and for the sake of this we “borrow” some of the time in the future. Having code snippets that are a real “technical debt” is fine if you accept that you may have to return it. If your codebase, in your opinion, is free from technical debt, most likely you overestimate the appearance to the detriment of the delivery . And my God, how I overestimated him!

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

Having started programming at a rather young age, I became a true professional of for-cycles, honing them to automatism for 15 years. Programming itself is like a breath to me. When the solution is obvious, I can simply print the code non-stop, like text on a blog or email. I can code the solution faster than others and usually take on more complex projects.

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

It seems that everything fits? After all, the position is called “lead developer”, and not “lead communicator” or “lead project manager”. I really didn’t understand how many more skills needed to be developed in order to become truly “leading”.

What I finally understood

Senior engineers will have to learn a lot of skills besides programming . If you compare with the beginning of a career, I had to develop an astronomical amount of skills. Communication, dependency management, context sharing, project management, project timing, and collaboration with non-developer colleagues. 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 "senor" . This is the result of years of accumulated experience. And yet many years of experience - a necessary, but not sufficient condition for the senor. It must also be the right experience in which you learned the right lessons and are able to successfully apply this knowledge in the future. Sometimes important lessons will show up in a year or later - which is why years of experience still matter, even if you are a really good programmer.

In some areas, we are still Junior . 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 Lead Programmer . " Great thing if at what point you are wondering what this job means.