[Translation] Seven years of working as a developer: what lessons have I learned

[Translation] Seven years of working as a developer: what lessons have I learned


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 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 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 need a team.

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 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? 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 it is not necessary to understand the product.

If the revision code is stressful, then it’s terrible, terribly wrongly organized


Oh my God. Code check.

We really do not think, but the act of publishing of working 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. It only proves your unkind nature.

Good, but what should 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.

Something 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.

Don't be afraid to say "I don't know"


The most pleasant privilege of the title “senor” on the badge is finally , the opportunity to answer:

I don’t know, never tried. I'll look and call you back.

Being a junior, I was terribly afraid: what if someone had guessed that I was 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 buzzword, 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 you what lessons did you learn as a developer?

Source text: [Translation] Seven years of working as a developer: what lessons have I learned