Елена Правдина - Говорят, в IT много платят. Как построить успешную карьеру разработчика, оставаться востребованным и не выгорать [litres]

Выбирайте некрупные проекты для результата. Зачастую в популярных фреймворках и библиотеках с сотнями звезд немалая очередь пул-реквестов. Вам придется отсмотреть, не предложил ли уже кто-то ту же правку. Либо не было ли это обсуждено в вопросах и признано ненужным. Помимо этого, инфраструктура крупных продуктов нередко весьма бюрократична для новичка. Требуется прочитать многостраничные инструкции, призванные стандартизировать оформление PR, гайды по кодстайлу с расстановкой табов или пробелов и принципам названия переменных. Серьезные проекты почти всегда содержат линтеры, инструменты сборки, а значит, вам придется изучить, установить еще и их. А также предполагают прогон или даже написание вами тестов – извольте освоить еще и этот стек, выбранный на вкус авторов. В итоге вы потратите 90 % времени на смежные задачи, чтобы только внести мелкую правку. Конечно, все эти знания: линтеров, инструментов тестирования – принесут вам пользу и вырастят вас профессионально. Однако, не зная рынка, вы можете потратить время на знакомство с редкими или нигде более не применимыми сборщиками, пакетами и решениями. Что, в свою очередь, может снизить ваш интерес и энтузиазм, потребуйся вам изучить действительно стоящий и более общеприменимый аналогичный инструмент.

Выбирайте массово используемые проекты для ревью. Логично, что аппруверы проектов, используемых миллионами, например React-а или jQuery, – представители IT, в профессионализме которых сомневаться не стоит. По крайне мере, они точно знают больше вашего. Пусть вам трудно будет предложить что-то стоящее поначалу и велика вероятность, что ваши усилия не войдут в продукт, однако здесь как нигде вы можете получить высококвалифицированный фидбек. Замечания, которым можно доверять, с учетом гибкости, надежности, жизнеспособности и расширяемости вашего решения. То, что всегда держат в голове профессионалы-разработчики крупных проектов. Как изменить архитектуру, какой граничный случай учесть или даже как понятнее для других назвать функцию – такие замечания от настоящих знатоков несут наибольшую ценность и формируют ваши правильные привычки и мастерство.

Проверьте живость проекта. Посмотрите дату последнего коммита, последнего вопроса и пул-реквеста. Если в этом репозитории больше полугода отсутствует активность, или же больше пары недель нет ответа на свежий вопрос либо реакции на PR, очевидно, что на месте следующего игнорируемого несчастливчика с большой долей вероятности окажетесь именно вы – с напрасно проделанной и никому не нужной работой.

Имея неосторожность уже написать код в продукт подобной стадии и наблюдая затяжную тишину в ответ, или же будучи убежденным в важности планируемых доработок на малоактивном проекте, не забудьте попытаться призвать аппруверов, выйти с ними на связь. Возможно, вам все же удастся получить заветное одобрение или хотя бы ценный фидбек.

Оцените полезность потенциально приобретаемых вами навыков. Сопутствующие инструменты должны быть нужны вам для изучения с целью последующего трудоустройства либо знакомства с общеприменимыми, свежими и перспективными технологиями.

Прислушайтесь к внутренним желаниям. Труд делает из обезьяны человека, а чужой кодстайл делает из программиста его последователя. Если вам не близки требования по оформлению кода проекта в ключевых вещах, вам не кажется разумной его архитектура, либо вы видите повсюду переменные a, b и item2 – подыщите себе другой репозиторий для контрибуции. Не привыкайте к плохому. Впитывать чужие практики и привычки на начальном этапе опасно для формирования верного вкуса, если вы не можете гарантировать мастерство их автора.Часто требования кодстайла – пережиток старых и далеко не самых лучших решений проекта, от которых сложно избавиться, или же специфика предпочтений его автора, а вовсе не образец для подражания. Новичку трудно отделить одно от другого и не забить себе голову сомнительными практиками.

Безусловно, участие в опенсорсе лучше, чем ничего. Проще всего отрицать полезность, прикрываясь аргументами, – сложнее заставить себя выйти из зоны комфорта и сделать хоть что-то. Однако не ставьте слишком многое на возможность внести свои правки в серьезный проект. Используйте как вишенку на торте, дабы придать новые нотки вашей профессиональной дисциплине, ответственности и мастерству. Но не берите опенсорс в качестве цемента, замешиваемого в основу вашего первичного становления как джуниор-разработчика.