Сергей Седов – успешный разработчик. Вот уже 15 лет он делает проекты на Java для крупнейших российских и зарубежных компаний. За это время из начинающего программиста он вырос в серьезного руководителя и системного архитектора программных продуктов в модели SaaS.
Терпеливо изучать то, что нравится
Java я изучил самостоятельно, во время своей первой стажировки. Но интерес к программированию появился еще в школе. В седьмом классе родители купили мне самый простой компьютер - в нем можно было писать только на бейсике. Но мне и этого хватило, чтобы увлечься. Я писал на нем простенькие игры, вроде крестиков-ноликов. Позже сделал маме программу, которая помогала ей считать что-то связанное с бухгалтерским учетом. Она даже пользовалась ей для работы.
Когда я начинал, не было форумов и нормального интернета. Только бумажные книжки с плохим переводом. Но к ним прилагался диск с примерами кода. Покупаешь такой диск, книжку, садишься и разбираешься. А дальше я просто программировал и программировал.
На третьем курсе я устроился стажером в компанию NetCracker. У них тогда был один продукт, построенный на Java. С его помощью можно было моделировать поведение компьютерных сетей, рассчитывать их пропускную способность. Университетское образование в работе никак не пригодилось, думаю, оно и сейчас не нужно, чтобы стать хорошим разработчиком.
Участвовать в реальных проектах
Свою первую стажировку в NetCracker я нашел и организовал самостоятельно - просто попросился на собеседование. Взяли меня скрепя сердце, но это было важным шагом - у меня появился ориентир. Во-первых, я определился, что изучать. Во-вторых, я видел перед глазами примеры людей, к квалификации которых хотел стремиться.
У меня был некий испытательный срок и набор задач, выполняя которые, я получал новые знания. Если ты их выполнял, получал более серьезные задачи – например, фиксить какие-то баги на проекте.
Не было ни лекций, ни справочных материалов - можно было только книги на английском из шкафа брать. Никто никого не учил - новичкам давались задания, которые со временем усложнялись.
Например, код, который рассчитывает IP-адреса в определённом диапазоне, нужно было портировать на Java. Следующее задание – сделать такой IP-калькулятор, оформить интерфейс в виде апплета к этому коду. Дальше - сделать так, чтобы была JSP-страница, которая этот интерфейс показывает. Вот так потихонечку я эти технологи осваивал.
Изучать теорию по мере необходимости
После прохождения испытательного срока я получил работу в Netckraker и стал получать 100 долларов в месяц. Огромная зарплата для студента по тем временам.
Это был отличный опыт. Именно практический. Барьер вхождения в эти технологии очень высокий. Даже если представить, что в те времена нам бы читали лекции или давали дополнительные материалы, мы бы не освоили этот объем в теории. Изучать технологии важно было ровно в том объёме, который позволяет решить конкретную небольшую задачу.
Для меня такая форма обучения была оптимальной – тебя бросили в воду, а дальше – либо плыви, либо пошёл вон.
Не думать о грейдах, а брать ответственность за своей проект
Когда я начинал работать, не было таких градаций, как сегодня: джуниор – не джуниор. Не было «фронтэндеров» и «бэкэндеров». Все программисты были, условно говоря, фулстек. Просто опытные ребята могли взять любую задачу и запилить. А те, кто послабее, пилили задачу попроще, но пару раз обратившись к матёрым инженерам.
Ну и джуниор джуниору рознь. Успех в работе зависит от зрелости человека. Если он раньше изучал один язык, а сейчас учит с нуля новый, но понимает, какие задачи будет решать, он сразу переходит на другой уровень. Конечный результат для него должен быть выражен в каком-то конкретном продукте, которым хотя бы 1000 человек воспользуется, а не в том, какой он получит от этого грейд.
Если говорить о своем опыте, после работы в Netckracker я пришел в компанию CBOSS. В составе небольшой группе я писал проект на Java. Мне просто поставили задачи и контролировали по минимуму. Была отличная возможность проявить самостоятельность, самоорганизованность и расти.
Именно в тот момент я осознал практическую пользу паттернов в проектировании. Самостоятельная работа подтолкнула меня изучать не только программирование, но организацию архитектуры программного обеспечения.
Бросать себе вызовы
Когда я работал в компании Luxoft, мои коллеги стали готовиться к экзамену Sun. Действительно сложный экзамен в несколько этапов, каждый из которых тогда стоил долларов по 100.
Для того чтобы его сдать, нужно купить ваучер, который действует ограниченное время – около полугода. То есть купил, пол года готовишься и нужно обязательно сдать. Я все-таки рискнул, очень усиленно занимался и это сильно систематизировало мои знания.
Так я получил сертификат системного архитектора и стал хорошо понимать разницу между разработкой проекта и его подготовкой к промышленной эксплуатации - то есть к реальной жизни, где проект можно будет комфортно развивать и сопровождать.
Системный архитектор – это программист, который в состоянии понять, как с нуля сделать сложный программный продукт. Следующий шаг после него - руководитель проекта.
Иметь представление о проекте в целом
Когда продукт попадает к реальным пользователям, они часто сталкиваются с проблемами. Это происходит, даже если продукт протестировали и функциональные дефекты были устранены.
Разработчики обычно разводят руками: «На нашей стороне ошибки нет. Это проблема системного администратора». Системный администратор говорит: «А у меня тоже в линуксе всё нормально, процессоры не загружены». Вроде никто не виноват, а продукт получается некачественным.
При этом есть простые инструменты, которые просто заранее нужно настроить, а потом использовать для отладки продукта на этапе эксплуатации. Конфигурирование, журналирование, миграция схемы данных, мониторинг – все это облегчит жизнь разработчика на этапе эксплуатации. Если мы делаем интернет-проект для массового использования, этот набор навыков - must-have.
Я считаю, что именно разработчики должны отвечать за эту часть. Поэтому и мой вебинар – во многом для разработчиков. Конечно, они должны работать в тандеме с системными администраторами при выпуске продукта. Но есть большое количество вещей, которые системный администратор просто не знает, он не так погружен в логику работы приложения.
Представьте приложение, которое раз в неделю по расписанию выполняет операцию, которая требует большого количества оперативной памяти. Если разработчики об этом не предупредили системного администратора, он может просто не предусмотреть нужный размер оперативной памяти на сервере. И в течение 5 дней это приложение будет хорошо работать, но в выходной шлепнется. Это только самый простой пример, в реальной жизни их гораздо больше.
Сегодня программисты все чаще работают над крошечным кусочком продукта и не задумываются о том, что происходит вокруг. Кому-то так комфортнее работать. Но для людей с амбициями, которые планируют свой карьерный рост в сторону старших разработчиков, системных архитекторов, тимлидов или даже основателей стартапа – важно смотреть дальше своих непосредственных задач.
Если вам понравилась статья ставьте лайк и подписывайтесь на канал. Будет много интересного!
Если вы хотите почитать статьи и материалы в нашем блоге, переходите на наш сайт.