Знаете, меня вряд ли можно назвать сеньором. У меня всего 3 года опыта разработки и повидал я сравнительно мало. Но я помню те тяжелые дни, когда я оказался на своей первой работе и мне пришлось буквально заставлять себя делать хорошо. Когда не понимал зачем нужен git и закрывал задачи без проверки. Если бы я посоветовал себе несколько вещей, то, возможно, мой карьерный путь был бы менее тернист. Потому спешу поделиться этими советами, пока память свежа, и подискутировать над тем, что считаю хорошими рекомендациями начинающему специалисту!
Дисклеймер
Статья написана в призывно-агрессивном стиле, это лишь стилистический образ для более комфортного чтения. Я не претендую на звание "гуру" в мире IT и истинность озвученных тезисов может быть спорна. Приятного чтения!
Ваша компания и технологии не хуже других
В один момент жизнь программиста резко меняется. После того, когда та самая компания предложит первый оффер. Вчера вы были студентом или самоучкой, а сегодня уже полноценный программист. В вашей трудовой написано программист. В профиле любой социальной сети можно написать "Developer at %company_name%" и никто не сможет оспорить. Тогда эмоции просто бурлят внутри, чувствуется, что сотни часов за компьютером не были потрачены зря.
И вот вы вышли, ваш первый рабочий день. Вам показали ваше место, тимлид дал доступ ко всем ресурсам, рассказал что к чему, помог настроить проект. Рядом с задачей в жире появилось ваша фото. Так тянется день за днем. Задачи закрываются, ревью проходится (обычно не с первого раза) и вас хвалят.
В этот момент где-то там, на задворках сознания, начинает появляться мысль, что вы не дурак, раз у вас все так хорошо. А дураки-то все остальные. Вот у нас на проекте angular и java. А у моего одногруппника c# и vue. Вообще-то всем известно, что java лучше, чем c#, так почему у них на проекте не так? Наверное, у них в команде слабые спецы.
Скажу честно, я видел ребят, своих ровесников, которые попадали в компании, где HR-бренд сильнее многих в регионе. И я видел, как у них расправлялись плечи. Ведь они работают в компании %company_name%, там и офис круче, и приставка новее. И технологии тоже новее. Это первая ловушка, которая развращает некоторых программистов, превращает в снобов или просто малоприятных людей. Интересен факт, что если их уволят и они устроятся в %another_company_name%, то первая организация попадет в опалу, а новой единственно верной технологией станет та, которая прямо сейчас на проекте. И такое, увы, тоже приходилось видеть.
Нет плохих или хороших компаний за редким исключением. Нет плохих или хороших технологий. Те люди и инструменты, с которыми вы работаете прямо сейчас, являют уникальную связку, которую трудно оценить и сравнить. Не попадайтесь в эту ловушку, смотрите по сторонам, ищите плюсы и минусы и отмечайте их у себя в голове. Помните, даже в самой хорошей компании могут быть задержки в зарплате и у самой крутой технологии в ядре бывают баги.
Поймите что от вас хотят
До своей первой работы программистом я подрабатывал системным администратором. И однажды мой бывший начальник сказал фразу, которая отпечаталась в моей голове на всю жизнь:
Программирование само по себе никому не нужно. Если оно не решает каких-то задач, то это просто баловство
Я бы хотел немного объяснить. Я делю программирование на 2 вида - творческое и рабочее. Творческое - это когда ты пишешь для своего Github или просто для себя. Там никто не ограничивает, никто не говорит как правильно. Это хобби. Рабочее же выполняет задачи бизнеса. Все. Бизнесу плевать на количество паттернов в коде и количество слоев абстракции. Капиталисту с сигарой нужно, чтобы его сервис работал без сбоев и, желательно, уже вчера. В идеале эти 2 вида накладываются друг на друга, в самом плохом случае - не пересекаются вообще.
На проекте вы Junior. Не ваша зона ответственности продумывать сложную архитектуру и переделывать наиболее критичные задачи. И зачастую ваш лид - умный человек. И он дает задачи не по велению сомнительных голосов в его голове, а по плану, который он проработал заранее. Поэтому рекомендую заранее услышать что хочет от вас руководитель, осознать почему он это хочет и работать. И продолжать неустанно учиться, путь лишь начался.
Ваши грейды - химера
Я, как постоянный читатель хабра, видел много споров на тему Junior/Middle/Senior. К сожалению, никто не может точно определить грейд. У нас нет единого критерия и это надо признать. Однако сколько я не спрашивал, у всех в голове примерно такое деление по этим трем популярным уровням:
Junior - новичок, за которым приходится постоянно проверять. Он много спрашивает и много учится.
Middle - за ним стоит проверять лишь сложные, очень важные или спорные задачи. В его арсенале, помимо технологий и паттернов, появляется такая царь-пушка как осознанность. Он хорошо понимает что и для чего делает, на него можно положиться и выдавать задачу со знанием того, что он ее сделает. Это самостоятельная рабочая единица.
Senior - человек, который должен взять задачу сам. Помимо обширных технических навыков и высокого уровня ответственности, senior умеет общаться с командой и имеет свою точку зрения. Точку зрения, которая базируется на опыте и знаниях.
В компании могут быть различные roadmap-ы и внутренние экзамены, которые переведут вас на уровень выше, навесят новую лычку и дадут возможность зарабатывать больше. Однако никто не гарантирует, что если выучить все необходимое, вы действительно станете middle. Помните, что от вас хотят ответственности и чтобы вы решали задачи для улучшения продукта, а не для того, чтобы решить очередную задачу. Ваш лучший проверяющий - вы сам.
Во многих компаниях есть менторство и Code Review. Где-то это возводится в культ и HR поют хвалебные оды этим процессам. Все это, несомненно, круто, но не забывайте, что ваш ментор и ревьюер - тоже люди. Они могут устать, могут отвлекаться или просто банально лениться. Они могут не заметить ошибки, тесты могут быть написаны неверно (если они вообще есть) и ваш код попадет людям. И если он будет плохим или c багами, то в первую очередь ответственность на вас. Да, вас вряд ли будут ругать или уволят, сейчас такого не принято в отрасли. Однако в вашей голове отложится факт, что система упала именно из-за вас. Проверьте все лишние пару раз, это не займет много времени, но сделает вашу программу гораздо надежнее.
Помните про эффект Даннинга — Крюгера
Про данную психологическую особенность написано очень много статей. Проще всего продемонстрировать его следующей картинкой:
Картинка честно взята отсюда.
Да, на определенном начальном этапе вы почувствуете себя самым сеньорным из всех сеньоров. Вы будете думать, что горы по колено и что вы все можете. Я вот однозначно таким был и мне пришлось приложить усилия, чтобы подавить это жгучее чувство внутри. Это, увы, не так. У вас еще очень большой путь путь впереди, вам многое предстоит узнать и пощупать. Помните - вы не король разработки. Король разработки у нас один и имя его многим из нас хорошо знакомо. Старайтесь провести на пике уверенности как можно меньше времени.
Читайте уже наконец чужой код
Когда вы учитесь, то вы много смотрите и читаете. Лекторы различной степени подготовки и индусы с ютуба. Курсы на платформах. Книги и статьи. Но есть еще один способ обучаться программировать, про который незаслуженно забывают при обучении. Чужой программный код. На Github-е миллионы репозиториев из которых можно выбрать те, что подходят вашей специфике. На хабре чуть ли не ежемесячно появляются статьи с топом репозиториев на Github. Чтение чужого кода - это сам по себе очень важный навык, но так же этот навык позволяет научиться новому, подсмотреть различные способы написания и организации кода, технические решения. Не пренебрегайте этим самородком.
На вашем проекте уже есть код, вряд ли вы начали создавать систему с самого нуля. И если вас просят написать очередной controller или реакт-компонент, то в вашей кодовой базе их уже много. Посмотрите как они реализованы, поймите почему так. Если не понятно, то задайте вопрос. Я очень часто начинал изобретать велосипед, который, как выяснялось позже, уже давно сделан. Поверьте, чтение чужого кода дает очень сильный толчок вашим навыкам.
Говорите со своими коллегами
Ваши коллеги - это люди с багажом знаний. Не стоит его недооценивать, они уже видели много и многое умеют. Вас никто не осудит за лишние вопросы. На самом деле, как мне кажется, задавать вопросы - это одна из самых главных компетенций Junior-специалиста. Как я уже говорил, скорее всего, ваш лид - не дурак. Слушайте своих коллег, часто они рассказывают много интересного.
Помимо вашей команды и коллег по работе существует it-тусовка. Есть полно митапов, конференций, хакатонов и прочих мероприятий. Не стесняйтесь задавать там вопросы. Знания других людей, рано или поздно, получится взять, расплавить и отлить из них меч, которым можно будет рубить головы кровавой гидре энтерпрайза. Это гораздо эффективнее, чем ковать свой с нуля.
Прекратите смотреть на чужие зарплаты
Однажды мне наш HR рассказала историю, как она общалась с соискателем, у которого было чуть меньше года опыта. И он попросил заработную плату от 150 тысяч рублей. Я, откровенно говоря, был слегка шокирован соотношением цифр и релевантного опыта. Как правило, у начинающих специалистов разбегаются глаза от цифр в вакансиях. И начинается погоня не пойми за чем. Деньги, как правило, приходят с опытом. И зависимость тут прямая. Вряд ли вам предложат много денег, если вы на самом деле умеете мало.
Нужно стараться оценивать себя по отношению к другим соискателям. И расти в финансовом плане постепенно. Пятилетка в три года - это звучит громко, однако на практике маловероятно. Помните о том, что впереди много лет и все приходит со временем. Не торопите события, это может лишь привести к конфликтам и недопониманию со стороны коллег. Но и забывать о своих условиях тоже не стоит. Я по этому вопросу делаю так - постоянно смотрю какие вакансии предлагают компании и в голове примерно прикидываю как оценивается мой навык другими работодателями.
Будьте инженерами, а не макаками
Пожалуй, это самый главный пункт. Я часто встречаю на форумах и в беседах "Front-End разработчиков на React/Redux", которые на деле с трудом отличают javascript от микроволновки. Наша область труда - наукоемкая. Тут не бывает "просто взял и воткнул кнопочку". За всем кнопочками скрывается очень много сложных вещей, которые разрабатывались лучшими инженерами десятилетиями. Не просто так сейчас появился Computer Science.
Я не хочу вас призывать становиться учеными и начинать штудировать книги по дискретной математике и теории вероятностей. Я хочу лишь напомнить, что основным топливом для мотора вашего прогресса (а так же вашей зарплаты, вашей позиции в компании и вашего социального комфорта) будет являться ваше любопытство. Именно любопытство приводит к тому, что вы начинаете глубоко разбираться в вопросе.
Я бы разделил программистов на 3 большие группы. Представьте, если вам задать довольно специфичный вопрос (вроде "Ты слышал что-нибудь о кодах Рида - Соломона"). Программисты могут ответить на него следующими способами:
Нет, мне это не надо
Нет. Что это такое, расскажи?
Да, конечно, это...
Так вот, как правило, среди действительно крутых специалистов, на которых хочется равняться, по моим наблюдениям в большинстве своем ребята из категории 2 и 3.
Помните, вы - инженеры. Не кодеры, не программеры, а инженеры. Вы решаете проблемы при помощи программирования. Поэтому не скатывайтесь в нишу, где вы решаете проблемы одной единственной технологией. Мир меняется, инструменты рождаются и умирают, но подходы и мышление остается с вами навсегда.
Эпилог
Итак, я всего лишь поделился своим видением этого мира. Я уверен, что многим опытным специалистам есть что сказать, так что буду рад дискуссии в комментариях. А всем, кто только начинает свой путь в странном мире разработки ПО - желаю успеха и умопомрачительного карьерного роста!
