Time flies, right?

My career began in 2012, with the first internship in C ++. Honestly, I had no idea what I was doing (in fact, nothing has changed). However, I have learned a few lessons.

Disclaimer: There will be no code in this message.

Question: What is the most important language in programming?

This is English. Or Spanish, Chinese, Polish. Anyone you use to communicate with colleagues.

Talking to people is much more important than talking to cars.

Programming is a team sport. There is rarely a brilliant product created from scratch by one person ( CodeSandbox  is a great example, although Ives has recently hired a couple of employees), but in the vast majority of cases a team is needed.

Communication skills can save or bury a project. Do not worry, the problem is not only yours, even NASA suffers because of this .

Professional and communication skills may be more important for project success than purely technical ones. Who cares that you have hired the five best database experts in the world if they refuse to talk to each other, and you end up with five different instances of MySQL, Aurora and MongoDB.

You need to deeply understand what you are developing and why

Most people become happier when they have a goal. This also applies to work.

Your goal as a developer is not to translate JIRA to JavaScript, Trello to C #, etc. Your goal is to solve problems .

If you have a deep understanding of the system that you are building / maintaining, then you can make decisions outside of pure technology. Ask questions: is this feature even necessary? What problem does it solve? Can we solve this problem differently? We want to solve this problem in the first place?

Such thinking is sometimes called a business context, but if you want to do your job well, you need to not only understand the context, but be able to shape and influence it. To influence a product, it is not necessary to occupy a managerial position in an organization. At the very least, this is not necessary for understanding the product.

If a code review is stressful, then it is terribly, terribly incorrectly organized.

Oh my God. Code verification.

We really don’t think about it, but the act of publishing the work with its study by several other people is somewhat unique to our profession. No wonder this causes stress.

I personally saw people sending a code review specifically at a time when X was not in the office or Y was on a business trip. X is a brilliant programmer, but hard to sustain his code review. Hundreds of picky comments under the junior pool request do not at all prove your superiority as a developer. This proves only your bad nature.

OK, but what should I do when this function is completely broken?

Get up. Contact this person, talk in person . Talk to him, find out why he implemented the code in this way.

Most people do not want to write bad code. And if they do, they are probably dealing with constraints that you are not aware of. They may also not be very good at programming (yet), and here you can prove yourself as a mentor.

Something MUST go wrong, get ready

According to Wikipedia:

Murphy's Law is a proverb or epigram that usually reads: "Everything that can go wrong will go wrong."

This is one of those things that are too true. When designing a system, always assume some kind of failure.

If you are creating a login form, assume that people will copy and paste the text of the whole book into the password field.

If you create a WYSIWYG window, suppose someone tries to break it, and is likely to be able to do it.

If you have a database, it will be disconnected at some point. If you have not tested restoring a database from a backup, this is not a backup.

If you are preparing a demonstration in front of an audience, make sure that the demo works online, offline, upside down and under water.

Do not be afraid to say "I do not know"

The most pleasant privilege of the title "Senior" on the badge is, finally , the opportunity to answer:

I don’t know, I have never tried it. I will look and call you back.

As a junior I was terribly afraid: suddenly someone will guess that I an impostor. After a couple of years as a developer - if I haven’t seen something, maybe it still hasn’t surfaced. Or another cool technology just appeared that needs to be explored. Lifelong learning is not a buzzword, it is a reality in IT.

Or I'm just an incredible scammer who managed to deceive everyone that I really can do my job. You never know.

Learn in public

As soon as you switch from “I don’t know” to “Well, that was interesting” - share it with someone. Write a blog, record a video, talk at a knowledge-sharing event, or just ... tell someone. If you think something is obvious to everyone, this is not so. Even the best professionals have something to learn from beginners, and vice versa.

Teaching is an incredibly effective way to make sure that you really understand the subject in question.

As someone damn smart said:

When one teaches, two learn.

What lessons did you learn as a developer?