Несколько советов начинающим инженерам и не только
Меня зовут Женя, я главный разработчик в компании ITFB Group. По долгу службы я общаюсь с большим количеством разработчиков: собеседую, помогаю в развитии, выступаю наставником, иногда оказываю психологическую поддержку. Кому-то советую книги, предлагаю использовать те или иные популярные процессы или просто стараюсь подсказать что-то, что опытный инженер считает фундаментальным.
Пройдя путь от начинающего до немного продвинутого инженера, я выделил несколько важных советов и решил оформить их в пост. Не претендую на сакральность, но считаю, что вещи, описанные ниже, могут быть весьма полезны разработчикам любого уровня, особенно в неспокойные моменты карьерной жизни.
Работа на себя, а не на компанию/проект/технологию
Люди любят бренды. Потребность иметь отношение к чему-то большому, может быть, для некоторых из нас является чуть ли не одним из самых мотивирующих факторов при выборе своего пути. «Я работаю в знаменитой компании Х!», «Я занят популярным проектом Y!», «Я работаю с самой трушной технологией Z!». В начале карьеры, попадая в «брендовый» контекст, часто нет ничего лучше, чем красивый бейджик и рюкзак, и в этом нет ничего плохого. Но важно понимать, что «бренд» проекта/компании/технологии — это в первую очередь маркетинг. Инженеру при этом важно понимать, чему он потенциально может научиться, будь то проект или компания. Да, если это ваш первый в жизни проект, то вам должно быть, грубо говоря, все равно. Но если вы уже получили какой-то опыт, вам очень важно понимать перспективы вашего движения: что в компании Х вы занимаетесь именно инженерией, что на проекте Y вы действительно получаете целевой опыт в предметной области, что технология Z действительно классно решает ваши прикладные задачи и она будет востребована на рынке. Да, строчка в резюме о том, что вы проработали несколько лет в компании Y или работали с редкой технологией Z, конечно, выделит вас на первом этапе собеседования, но если в основном вы получали удовольствие от контекста, а не работали, то отсутствие компетенций быстро вскроется на техническом интервью. И если даже в 80% проектов вы подойдете, то в желаемые вами 20% — может быть, и нет. С опытом вам чаще все равно на обертку, и вы действительно понимаете, что вы тут делаете, куда вы идете и надо ли вам быть 10 лет в одной компании, на одном проекте, в одной технологии. Будьте осторожнее.
Всему свое время
Давайте поговорим о молодых по возрасту инженерах. Есть те, кто пришел в профессию из-за большого интереса к ней. Как правило, такие люди читают много книг по теме, смотрят различные выступления, пишут код, работают на себя в поте лица. В первую очередь потому, что им интересно, любопытно или они просто хотят быть крутыми специалистами в своей области. И вот нашему герою примерно 25 лет, у него уже 3 года опыта тяжелой работы, способствующей его росту.
И тут в компании обнаруживается техлид лет 20–25, который уже может подсказать по любому вопросу, у которого нет проваленных проектов, и вообще его все всячески любят. А еще у него может быть какой-нибудь дар в виде суперпамяти или прозрения. Причем так получается, что он приходит на проект инженера и тот каждый день понимает, что техлид действительно крутой. На бумаге это может показаться несправедливым, но на практике порой очень сложно принять, что мы все разные, у нас разная история, разные входные данные, которые определяют нас как людей и специалистов.
Можно впасть в уныние, можно начать работать усерднее, а можно искать подвохи в суперлиде. Ведь как так получается — я работаю, много читаю, иногда отдыхаю, пишу много кода, а все равно этот суперчеловек решает задачи быстрее меня? Несправедливо!
Обычно, когда я понимаю, что человек находится в такой ситуации, я спрашиваю его о 100-летних курильщиках: «Ведь курение вредит здоровью, но вот есть люди, которые курят и доживают до ста лет, а есть те, кому уже в 50 плохо даже без курения. Что нужно сделать, чтобы, так же куря, прожить 100+ лет?» Ответ можно дать любой, но следующий вопрос всегда один и тот же: «А при чем тут вы?» Ваше здоровье не зависит от того, как прожил жизнь другой человек. Ваше развитие не зависит от того, насколько круто человек за соседним столом решает задачи. Если вы как инженер работаете, делаете каждый день что-то, что делает вас лучше, ваше ментальное здоровье в порядке, у вас есть успехи на проектах, то зачем вам бежать за тем человеком?
Во-первых, почти наверняка он не так хорош, как вы себе его представляете. Во-вторых, вы не знаете его историю — может, у него, кроме работы, ничего другого и не было. Или он буквально своим упорством и трудолюбием заработал свои компетенции. Или у него просто особый набор навыков, наиболее эффективных для его работы. Может быть, он просто талант от природы. Что с этим делать?
Ничего делать не нужно. У вас есть вы и ваша жизнь. Вы живете в своем темпе и управляете им по своему усмотрению. Если рядом с вами успешный (в вашем понимании) или интересный человек, то есть смысл изучить его, пообщаться, поработать вместе, подсмотреть хорошие вещи и избегать плохих. Может быть, этот человек просто использует известные или специфические вещи и подходы, которые соответствуют его менталитету. В итоге, если без эмоций подойти к этому вопросу, может оказаться, что ничего не нужно исправлять. Или же вы сами решите множество проблем и получите удовольствие от этого.
Самое главное — жить в своем темпе. Стремитесь быть лучше каждый день хотя бы немного. И помните, что слишком быстрый темп в итоге может привести к выгоранию.
Зарплата — это наркотик
Хорошая зарплата — всегда хорошо. Не верьте людям, которые говорят, что деньги в какой-то момент не приносят удовлетворения, что надо жить только за интерес. Всегда приносят. Однако они бесполезны и не имеют ценности, если у вас нет удовлетворения от жизни. Всегда здорово, когда компания благодарит вас финансово. Это особенно важно в начале карьеры — через три года получать заработную плату, позволяющую, например, приобрести MacBook за одну неделю работы. Однако важно понимать, что ИТ-специалист — это сотрудник, удовлетворяющий потребности бизнеса. Вам платят либо потому, что вы приносите прибыль, либо потому, что вас сложно заменить.
Наступит момент, когда захочется перемен — другой проект, компанию или даже другую сферу деятельности. Например, инженер может решить уйти с довольно однотипного, но сложного проекта, на котором он является ключевым игроком. Данный проект приносит деньги, а инженер решает проблемы, удовлетворяет потребности проекта, создает прибыль. И бизнес, логично, будет пытаться этого инженера мотивировать остаться на однотипном, скучном, но нужном проекте. Самый популярный способ — деньги. Инженеру будут предложены еще большие вознаграждения, чтобы удержать его на проекте и выглядеть более конкурентоспособными на рынке труда. Более того, хорошие компании не доведут ситуацию до абсурда и будут стараться найти решение, которое будет выигрышным для всех.
Но что делать, если на соседнем проекте, где освободилось место, есть возможность заниматься тем, чем очень хочется. Или другая компания предлагает интересную должность, но уровень зарплаты там может быть меньше. И опять вопрос сводится к деньгам. Как сделать выбор правильно?
Сценарий может быть разным. Но мое мнение следующее: на начальных этапах карьеры особенно важно понимать, что любая экспертиза, которую хочется в себе развить, приобретается не за деньги, а за время. Если вы в одной из вышеописанных ситуаций, то задайте себе вопрос — готовы ли вы продать свое время за те задачи, которые вам предлагают, и за те компетенции, которые вы получите/не получите на старом/новом месте. Если есть такая возможность — кайфуйте от потраченного на себя времени, а не от заработанных на потере нулях.
(Может быть, поэтому автор так и не купил домик у реки…)
Доверие требует проверки
Не верьте на слово, все перепроверяйте, критикуйте, и мне тоже не верьте… Почаще задавайте вопросы.
Все люди лгут, чаще неосознанно. Людям свойственно ошибаться и видеть мир по-разному. Любой старший коллега — человек с определенным жизненным опытом. Предположим, вам сказали, что 2+2=4 (просто пример сложной задачи). Ваш авторитетный старший коллега с большим опытом и успешными проектами за спиной сообщает вам это. В вашем текущем проекте действительно 2+2=4, и вы это видите и принимаете, потому что это логично и работает в текущем проекте. Но проходит время, и к вам подходит другой коллега и спрашивает: «Чему равно 2+2?» Вы отвечаете:»4». А коллега возражает: «Почему?» Вы приводите пример из вашего проекта, где 2+2 было равно 4, и даете определенное логическое обоснование, которое работало в рамках вашего проекта.
Иногда предлагаемые решения имеют неочевидные недостатки. Часто это просто компромисс из-за отсутствия лучшей идеи. Люди просто прикрывают свою несостоятельность популярными решениями. В начале карьеры молодому специалисту это может быть неочевидно. Сложно определить заранее, является ли решение хорошим или нет, только на основе опыта. Да, в большинстве случаев вашим старшим коллегам можно доверять, они компетентны и не действуют из корыстных побуждений. Часто хочется верить им на слово и использовать их подходы повсюду — ведь они такие замечательные, они мне рассказали! Вне зависимости от того, насколько наивно вы все воспринимаете, ваш коллега не является университетским преподавателем. Скорее всего, он дал вам определенный контекст, описывающий, почему то или иное решение хорошо работает. Однако он может не описывать сам подход, причины его выбора, границы его применимости. Коллега не профессор — для него важно ответить на вопрос и помочь закрыть задачу.
Так что не верьте на слово коллегам, и мне тоже не верьте. Подвергайте все, что вы слышите, сомнению. Попробуйте провести мысленный эксперимент: напишите реализацию или просто пройдите Happy Path тестирование. Продумайте различные варианты и, вероятно, на 98% вы запомните и поймете, для чего нужен тот или иной подход, либо найдете пробелы, которые не сможете восполнить самостоятельно.
Спрашивайте правильно
Смело задавайте вопросы, если они у вас возникают. Это поможет значительно ускорить ваш профессиональный рост. По моим наблюдениям, у инженеров страх попросить помощи часто возникает из-за опасений, что коллеги могут посчитать их вопрос глупым или слишком простым. Если вы тоже так думаете, то проведите мысленный эксперимент: вы из раза в раз аффектите свои задачи (по времени или качеству), встречаясь с вопросом, который вы постеснялись задать из соображений того, что вас могли в моменте послать в документацию. Представьте, что, несмотря на то, что вы изучили документацию по вопросу, вы все равно сталкиваетесь с некоторыми сложностями, которые возникают из-за нехватки опыта.
Неприятно, верно? В начале карьеры нет гарантии, что, прочитав литературу по вопросу, вы все полностью поймете. Нет такого понятия, как «плохой вопрос». Даже если вы работаете со Spring, но не понимаете, как работает прокси, заполните этот пробел, используя литературу и коллег. Задайте вопрос тому, кому вы доверяете в этом. В начале пути стоит задавать вопросы как можно чаще. Однако если вы просто спрашиваете, почему 2+2=4, вас, вероятно, не поймут.
Как правильно задать вопрос? По моему мнению, хорошо заданный вопрос — это вопрос, который возник в процессе анализа и изучения исходного вопроса. Вам следует потратить какое-то время, чтобы самостоятельно проанализировать и понять логические связи, которые для вас неочевидны или вызывают вопросы, и попробовать самостоятельно ответить на исходный вопрос. Если у вас остались вопросы/пробелы/проблемы, то задайте вопрос, исходя из ваших выводов:
«Привет! Я пытаюсь разобраться в том, сколько будет 2+2. Из опыта предыдущих проектов я знаю, что это равно 4, потому что А, Б и еще С, и это логически следует из Б. Есть также правило Д, но оно не обязательно означает, что 2+2 это всегда 4, возможно, иногда это 5, но я не уверен, в каких случаях. Можешь подсказать?»
Для чего вы что-то учите?
У инженеров, особенно начинающих, горят глаза, когда они знакомятся с новой технологией или встречают новый паттерн проектирования. Выученная штука может быть настолько классной, что ее хочется применять буквально в каждом проекте для каждого подходящего кейса.
Но технологии не существуют в вакууме. Любая технология или паттерн придуманы для решения определенной задачи, каждая из них имеет границы применимости, и довольно сложная задача — понять эти границы. Это, прежде всего, требует опыта, чтения качественной литературы и общения с более опытными инженерами, а также проведения собственных экспериментов. Попробуйте понять, какая проблема стояла перед тем, кто разработал тот или иной подход или библиотеку. Может быть, не было бы лишним попробовать написать технологию самостоятельно или найти слабые стороны какого-нибудь паттерна, чтобы выяснить его пригодность.
Изучение всего подряд будет полезно только в том случае, если понимать границы применимости. Я бы рекомендовал избегать изучения вещей просто ради общего кругозора. Конечно, Kotlin гораздо лучше Java, а Rust — лучше обоих в два раза. NoSQL БД вообще не дает реляционным решениям никаких шансов, а классы Record на порядок практичнее классических POJO во всех случаях. В целом, все это неважно, потому что самое главное умение инженера — это умение решать задачи на алгоритмических платформах вроде LeetCode.
Выбирайте учебники, а не по справочники или гайды
Когда я столкнулся с тем, что часто люди изучают какую-то технологию только поверхностно, ограничиваясь изучением API или несколькими кейсами применения данной технологии или подхода, для меня это стало большой неожиданностью. Я заметил это, когда начал проводить собеседования. В основном это относится к молодым специалистам, так как более опытные инженеры, вероятно, не сталкиваются с такой проблемой из-за своего опыта. При изучении данной темы я заметил, что часто при встрече с новой технологией инженеры для экономии времени ограничиваются чтением гайдов, которые дают краткое описание и несколько примеров использования. Это допустимо, особенно когда необходимо быстро оценить возможности или реализовать небольшой функционал, но порой у меня складывается впечатление, что изучение останавливается на этом. Инженеры могут знать о том, что такое consumer/producer/topic/partition, но пытаться отправить файлы через Apache Kafka. Далеко не вся документация хорошо написана, но даже хорошую документацию нужно уметь читать. На раннем этапе пути необходимо уметь понять философию продукта и его цель, уяснить, какие проблемы он решает и какие ограничения есть. Существуют замечательные книги по различным технологиям, которые являются фундаментальными учебниками, и с их помощью можно получить определенный опыт.
Мыслите в масштабах системы, а не задачи
Решение сложных задач — это навык, который приходит далеко не сразу. Уверен, что у каждого инженера в начале пути были ситуации, когда ему давали сложную задачу, которую нужно было реализовать в уже существующей большой системе, и он уходил в нее, но в итоге решение задачи ломало другие функциональности.
Каждая функция зависит от других компонентов системы, которые также связаны с другими функциями. При глубокой работе над конкретной задачей некоторые взаимодействия могут быть случайно упущены, что может привести к проблемам в системе. Чтобы избежать этого, инженерам нужно всегда помнить о том, что функция делает в глобальном контексте, с чем она взаимодействует и какие имеет последствия. Если система слишком сложна, то стоит обратиться к документации.
Простые системы лучше
Вся суть изучения и практики алгоритмов заключается в развитии навыка разработки систем, которые работают эффективно и не выполняют лишнюю работу. Если упростить, то основная цель заключается в том, чтобы избежать создания кода, подобного приведенному примеру:
return getUsers ()
.stream ()
.filter (…)
.filter (…)
.map (…)
.filter (…)
.findFirst ()
.isPresent ();
Для такой реализации должна быть очень веская причина. Если вы хотите освоить эту тему более глубоко, вам лучше изучить классические работы по алгоритмам и структурам данных.
Это был технический аспект. Теперь перейдем к финансовой стороне вопроса. Очевидно, что в больших системах невозможно запомнить все. Тот код, который нужно запомнить, стоит денег. Тот код, который нужно отлаживать, требует поддержки, а это снова деньги. Время, затраченное на разработку новых функций или консультации по существующему коду, стоит денег. Внесение изменений в код также требует финансовых ресурсов. Если кратко — время стоит денег. Чем код или функциональность проще, тем легче их вычислить без необходимости запоминать (при отличном понимании аналитиком и разработчиком системы). Чем меньше неочевидных шагов и ограничений, не связанных с алгоритмом, тем меньше времени потребуется на разработку, тем быстрее система будет расти, и меньше времени потребуется на революцию системы, если такая потребуется. Разумеется, не всегда это возможно, но стоит стремиться к этому. И, конечно же, не стоит ограничиваться примитивными решениями.
Кроме того, есть и человеческий аспект. Если система простая, и вы хорошо понимаете, для чего она нужна, значительно легче стать экспертом в ней и удовлетворять потребности заказчика, что в итоге может приятно отразиться на ваших с ним трудовых взаимоотношениях.
Бизнес не оценивает красоту кода — бизнес оценивает быстрое и качественное решение проблем и задач с предсказуемым результатом.
Про гармонию
Любое настоящее развитие сопряжено с трудностями. Не всегда в жизни учеба или работа приносят нам удовольствие. Иногда для того, чтобы прогрессировать, нам нужно преодолеть себя. Даже на то, что нам нравится, требуются усилия, в первую очередь, моральные.
У вас есть вы, окружающий мир и результаты ваших решений. Вы уникальны, и никто и ничто не может быть важнее вас самих. Вашу жизнь можете изменить только вы сами (если вы находитесь в опасности, позвоните по номеру экстренной помощи). Не забывайте, что советы, описанные выше, бесполезны, если вы несчастны внутри себя (про временные случаи, когда негатив становится движителем, лучше не думать). Профессия инженера-программиста требует умения удерживать в голове огромное количество информации, и значительная часть успеха зависит от нашего отношения к себе самому. Вы не сможете творить, если потеряете себя. Стремитесь к внутренней гармонии. Наслаждайтесь каждым днем, печальтесь, когда это необходимо, не теряйте свою зону комфорта, но систематически из нее выходите.
Страсть к профессии — это энергия, которая может внезапно исчезнуть. Поймите, почему вы хотите заниматься этим, и не питайте завышенных ожиданий к себе, слушайте маму и чистите зубы минимум два раза в день.
Евгений, ведущий разработчик ITFB Group
