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

Платы за проделанную работу не предполагалось. То была деятельность на благотворительных началах. Однако то, что я смогла завершить ее, стало поворотной точкой в моем профессиональном самоопределении и сыграло огромную роль в дальнейшей карьере.

Итак, что ждет вас, попробуй вы подобную благотворительную деятельность как стартовый тренировочный полигон?

Входные данные

Работа без оплаты, зачастую по знакомству, предметная область и круг общения могут быть значительно удалены от IT.

Где?

Дома, в метро, на улице, в свое свободное, часто ночное, время.

Сроки

Как правило, довольно лояльные. Что важно для новичка и максимально безболезненно для учебы/подработки.

Ответственность

Минимизирована за счет благотворительного характера. Наименее стрессова. Максимум – вам будет неудобно перед знакомым. Однако, не получая ничего взамен, вы выглядите наименее проигрышно в случае неуспеха и максимально достойно и удобно для заказчика в случае приемлемого результата.

Источники знаний

К сожалению, зачастую только Google и итоги ваших собственных изысканий. Профессиональное наставничество отсутствует. И понять «что хорошо, что плохо» придется вам самим.

Уровень обратной связи

На пользовательском уровне, неквалифицированный фидбек. Ревью кода отсутствует, технические комментарии, советы от более опытных разработчиков тоже. Вы получаете комментарии характера «нравится/не нравится», сдвинуть левее, заменить шрифт от заказчика, далекого от сферы IT. С одной стороны, технически вы не узнаете ничего нового, с другой – получите опыт общения с непрофильной аудиторией. Что позволит вам учесть точки расширяемости вашего решения (потребовалось переделать полсайта из-за одного пункта меню? Значит, ваша архитектура никуда не годится), принять изменяемость мира (вы полдня делали эту ссылку, а вас попросили заменить ее на телефон) и выработать терпимость.

На выходе

Шишки, набитые самим собой, самые памятные. Пусть вам пришлось перерыть пол-интернета, не имея возможности спросить наставника, зато вы навсегда запомните решение. Реальный результат, попавший в пользование с минимальным стрессом и не в ущерб основной деятельности. Ваша уверенность и знакомство с настоящим миром заказов и разработки. Опыт общения с «нетехническими» людьми.

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

Рано или поздно вы сталкиваетесь с ним. Пользуясь ли щедро размещенными пакетами, разрабатывая ли и внося мешающие наслаждаться жизнью правки или ища точки роста и следуя советам обрести опыт участия.

Я никогда не любила опенсорс как средство повышения профессионализма и появления «галочек в резюме». Благо серьезно поучаствовать в нем мне довелось, уже имея за плечами лет пять рабочего стажа. Тогда в «Инвентосе» мы занялись переписыванием HTML5-плеера на новые технологии, взяв за основу популярный видеофреймворк. Тогда же нам пришлось столкнуться с пачкой багов либо же не реализованных, но крайне необходимых в хоть сколько-нибудь серьезной видеоразработке фич. Именно в тот период с чувством удовлетворения я впервые направила мелкий пул-реквест в адрес вышеупомянутого фреймворка. Безусловно, его конечное принятие и осознание вклада в продукт, используемый тысячами людей, вызывает эйфорию побед, знакомую всем айтишникам, растущим на своем пути. Но есть и другая сторона медали.

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

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