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 learned a few lessons.

Disclaimer: there will be no code in this message.
')

Question: What is the most important programming language?

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

Talking with people is much more important than with cars.

Programming is a team sport. Rarely there is a brilliant product created from scratch by one person ( CodeSandbox is a great example, although Ives recently hired a couple of employees), but in most cases a team is needed.

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

Professional and communication skills may be more important for project success than purely technical ones. Who cares if you hired the world's top five database experts 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 get 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 you are building / supporting, then you can make decisions outside of pure technology. Ask questions: Is this feature necessary at all? What problem does it solve? Can we solve this problem differently? Do we want to solve this problem first?

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

If the code review is stressful, then it is terrible, terribly wrongly organized

Oh my God. Check code.

We do not really think about it, but the act of publishing a work with its study by several other people is in some way unique to our profession. No wonder it causes stress.

I personally saw people sending 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 it's hard to sustain his code review. Fifty picky comments under the junior pool-request does not at all prove your superiority as a developer. This only proves your unkind nature.

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

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

Most people don't want to write bad code. And if they do, they are probably dealing with restrictions that you do not know about. They may also not be very good at programming (for now), and here you can show yourself as a mentor.

Anything MUST go wrong, be prepared

According to Wikipedia:

Murphy's Law is a proverb or epigram that usually says: “Anything 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 create a login form - assume that people copy and paste the text of the whole book into the password field.

If you create a WYSIWYG window, assume that someone will try to break it, and probably can do it.

If you have a database, at some point it will be disabled. 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 “senor” on the badge is finally the opportunity to answer:

I do not know, never tried. I will look and call you back.

Being a junior, I was terribly afraid: what if someone guesses that I am an impostor. After a couple of years as a developer - if I haven’t seen something, maybe it still hasn’t surfaced. Or just another cool technology that needs to be learned. Lifelong learning is not a fashionable phrase, it is a reality in IT.

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

Learn in public

As soon as you move from “I don't know” to “Well, it was interesting” - share with someone. Post to a blog, post a video, speak at a knowledge sharing event, or just ... tell someone. If you think something is obvious to everyone, it is not. 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.

And what lessons have you learned as a developer?