Как программисту вырасти в руководителя проекта

Преподаватель Сергей Седов рассказал, что помогло ему выстроить успешную карьеру в IT.
17 ноября 2017B1ddf94768b759d6ddbe44dc38826b5ab8367f3aГульнара Гарафиева3914317

 

Сергей Седов – успешный разработчик. Вот уже 15 лет он делает проекты на Java для крупнейших российских и зарубежных компаний. За это время из начинающего программиста он вырос в серьезного руководителя и системного архитектора программных продуктов в модели SaaS.

18 ноября на конференции Geek Week Сергей проведет вебинар о том, как подготовить web-приложения к успешной промышленной эксплуатации. А пока наш докладчик рассказал, что помогло ему выстроить успешную карьеру в IT.

Терпеливо изучать то, что нравится

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

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

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

Участвовать в реальных проектах     

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

У меня был некий испытательный срок и набор задач, выполняя которые, я получал новые знания. Если ты их выполнял, получал более серьезные задачи – например, фиксить какие-то баги на проекте.

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

Например, код, который рассчитывает IP-адреса в определённом диапазоне, нужно было портировать на Java. Следующее задание – сделать такой IP-калькулятор, оформить интерфейс в виде апплета к этому коду. Дальше - сделать так, чтобы была JSP-страница, которая этот интерфейс показывает. Вот так потихонечку я эти технологи осваивал.

Изучать теорию по мере необходимости

После прохождения испытательного срока я получил работу в Netckraker и стал получать 100 долларов в месяц. Огромная зарплата для студента по тем временам.

Это был отличный опыт. Именно практический. Барьер вхождения в эти технологии очень высокий. Даже если представить, что в те времена нам бы читали лекции или давали дополнительные материалы, мы бы не освоили этот объем в теории.  Изучать технологии важно было ровно в том объёме, который позволяет решить конкретную небольшую задачу.

Для меня такая форма обучения была оптимальной – тебя бросили в воду, а дальше – либо плыви, либо пошёл вон.

Не думать о грейдах, а брать ответственность за своей проект

Когда я начинал работать, не было таких градаций, как сегодня: джуниор – не джуниор. Не было «фронтэндеров» и «бэкэндеров». Все программисты были, условно говоря, фулстек. Просто опытные ребята могли взять любую задачу и запилить. А те, кто послабее, пилили задачу попроще, но пару раз обратившись к матёрым инженерам.

Ну и джуниор джуниору рознь. Успех в работе зависит от зрелости человека. Если он раньше изучал один язык, а сейчас учит с нуля новый, но понимает, какие задачи будет решать, он сразу переходит на другой уровень. Конечный результат для него должен быть выражен в каком-то конкретном продукте, которым хотя бы 1000 человек воспользуется, а не в том, какой он получит от этого грейд.

Если говорить о своем опыте, после работы в Netckracker я пришел в компанию CBOSS. В составе небольшой группе я писал проект на Java. Мне просто поставили задачи и контролировали по минимуму. Была отличная возможность проявить самостоятельность, самоорганизованность и расти.

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

Бросать себе вызовы

Когда я работал в компании Luxoft, мои коллеги стали готовиться к экзамену Sun. Действительно сложный экзамен в несколько этапов, каждый из которых тогда стоил долларов по 100.

Для того чтобы его сдать, нужно купить ваучер, который действует ограниченное время – около полугода. То есть купил, пол года готовишься и нужно обязательно сдать. Я все-таки рискнул, очень усиленно занимался и это сильно систематизировало мои знания.

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

Системный архитектор – это программист, который в состоянии понять, как с нуля сделать сложный программный продукт. Следующий шаг после него - руководитель проекта.

Иметь представление о проекте в целом

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

Разработчики обычно разводят руками: «На нашей стороне ошибки нет. Это проблема системного администратора». Системный администратор говорит: «А у меня тоже в линуксе всё нормально, процессоры не загружены». Вроде никто не виноват, а продукт получается некачественным. 

При этом есть простые инструменты, которые просто заранее нужно настроить, а потом использовать для отладки продукта на этапе эксплуатации. Конфигурирование, журналирование, миграция схемы данных, мониторинг – все это облегчит жизнь разработчика на этапе эксплуатации. Если мы делаем интернет-проект для массового использования, этот набор навыков - must-have.

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

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

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

Новые комментарии