[2/2] Говорят, что почти каждый инженер с этим в какой-то момент сталкивается. Обычно, на первой работе, но я знаю людей, которые переживают это и в статусе lead dev:/ В своё время с этим сталкивался и я, правда, это достаточно быстро закончилось. Пишу набор рекомендаций, которые помогут пройти этот этап побыстрее:

1. Самый действенный пункт и его явно не посоветовал бы вам ваш психотерапевт, но мы же ведь хотим результат? Совет - наблюдайте за историей гита коллег, смотрите их код, сравнивайте его со своим. Особенно важно обращать внимание на их недочеты (им не говорите!) и понять, что и они далеко не во всем превосходят вас. Можно обратить внимание банально на стиль. Возможно, они не знакомы даже с базовыми стандартами сферы и тупо вырубают все линтеры, или создают много вложенностей и ставят по 10 табов? Можно обратить внимание на архитектуру кода. Быть может, они вместо SOLID и грамотно внедренных паттернов, пишут god-классы с кривой инкапсуляцией? Быть может, они пишут множество замыканий без надобности и даже не зная этого термина? Докапаться можно до многого. В такой ситуации воля - не воля задаешь себе вопрос: и кто тут еще самозванец?

2. Самые высокие стандарты качества кода у популярных open source проектов. Возьмите и прочитайте исходные коды фреймворков и библиотек, которые используете. Это лишь звучит сложно, но читать код куда проще, чем писать. Учиться нужно у лучших и такой подход позволяет цеплять множество полезных приемов и сильно поднимать планку. Если ваши стандарты становятся столь высоки и вы уже не просто пишете код, а творите и получаете комплименты от коллег, то вы явно тут не самозванец.

3. В английском языке есть такой афоризм “Fake it till you make it”. Он советует притворяться, пока не получится. Это допустимая стратегия в ИТ. Если вы чего-то не умеете, то вы можете научиться этому в процессе работы, и это нормально;)

4. Обращайтесь за обратной связью к более старшим коллегам касательно своей работы, хоть даже она будет совсем неприятной. В программировании есть даже отдельный термин для этого - Code review. Запрашивайте его у коллег как можно чаще! Это позволяет учиться куда быстрее на первых этапах и непрерывно поднимать планку разработки. Таким образом, даже если вы и были в начале немного “самозванцем”, то вы быстро перестанете им быть.

#dev