Как я изучаю технологии или Критика программистов
Когда работаешь в такой большой компании,как SimbirSoft (сотрудники из котлов ада вроде EPAM или Luxoft похихикали), начинаешь приобретать и очень быстро развивать некоторые профессиональные качества.
В моём случае - очень сильно развилось умение консультировать людей. И слово “консультант” в этой статье визуализируется не так
или на крайний случай так
В SimbirSoft одновременно разрабатывается 60-70 проектов. Общий стек технологий компании - десятки языков, сотник фреймворков, тысячи практик реализации. Компания с такими нагрузками может быстро превратиться в монстра, который разучился делать качественные продукты, где клиенты не получают ожидаемого дохода от разработок, а сотрудники мечтают сбежать из-под натиска неорганизованности.
К счастью, в СимбирСофте давно нашли способ не скатиться в пучину. Выход, на самом деле, очевидный. Так делают многие. В нашей компании эта идея просто отлично перевоплощена в чёткие процессы.
Что за идея, я раскрывать здесь не буду. Как-нибудь потом. Не об этом статья. Суть в том, что благодаря моему участию в этих процессах, очень часто приходится фактически консультировать клиентов, а также настраивать взаимодействие между сотрудниками разных отделов (я не говорю здесь об отделах backend + frontend, мой маленький программист-задрот, эти сами прекрасно общий язык найдут). Пример такого взаимодействия - совместная работа над проектом сотрудников отдела работы с клиентами и отдела backend.
Наши специалисты по работе с клиентами разбираются в ИТ лучше любого джуниор-разработчика. Они имеют широкий кругозор и могут самостоятельно понять, что нужно клиенту. К счастью (для разработчиков), эти ребята недостаточно глубоко погружены, чтобы выгнать всех программистов :) (хотя будь моя воля всех программистов в мире выгнал бы с работы, в том числе и себя. Мы жрём слишком много, а результата выдаём слишком мало). Именно поэтому специалисты по работе с клиентами обращаются к консультантам в нашей компании, одним из которых являюсь я. Как проходит это взаимодействие - это вот как раз те процессы, о которых я писал выше.
Моя официальная должность в компании: ведущий разработчик-консультант. Примерно раз в неделю я занимаюсь тем, что помогаю нашим клиентам понять, что им нужно, и как наилучшим образом реализовать их задачи. А последние 3 месяца активно работаю ещё и с отделом маркетинга в том же контексте. Помогаю найти контакт нашим пиарщикам и сммщикам, которые по понятным причинам не имеют технического бекграунда, с разработчиками из других отделов. При этом продолжаю постоянно программировать на проектах.
На первый взгляд кажется, что работа-то несложная. Просто болтай и всё. Эх... Если бы всё было так просто. Кроме навыков в коммуникации надо ещё обладать широкими знаниями в разработке любого программного обеспечения на всех уровнях. Ведь сегодня ты общаешься с клиентом, который делает ICO, завтра надо общаться на одном языке со специалистами по разработке стриминговых сервисов, а послезавтра мы прокачиваем телеком с мегатонным легаси. При всё этом я простой бекенд-разработчик, который может АПИшку развернуть, запросик в базёнку написать, сервачок настроить.
Как качественно выполнять свою работу в таких условиях? Ответ простой: надо постоянно развиваться. Развиваться не в контексте глубины знания всех технологий, а их применимости. Полноценный практический опыт разработки я имею только с Ruby, Rails на backend и ReactJS и компанией на фронте. Обо всём остальном я знаю по общению с коллегами, чтению статей, подкастам, конференциям и т.д. Я постоянно изучаю таким образом новые технологии. Потому что перед тем, как проконсультировать участников процесса, надо самому провести аналитику. И полученных знаний достаточно, чтобы решать поставленные передо мной задачи. В СимбирСофт моя работа, как консультанта, приносит компании профит. Клиент всегда доволен, его пользователь после использования продукта - счастлив.
Но такой подход не всегда нравится программистам. Почему? А потому что я всё меньше отстаиваю их принципы. Что за принципы?
И здесь мы переходим к критике программистов. К сожалению, подавляющее большинство программистов сегодня оценивают новые технологии по нескольким критериям, и часто бывает, что все эти критерии не имеют никакого отношения к конечному пользователю продукта, максимум проскользнёт сквозь пальцы забота о стекхолдере - но это далеко не всегда. Программисты сегодня оценивают новые технологии по критериям, связанным с базовыми концепциями разработки, операций и математики. Считая, что коли уж мы строим абстрактные замки, то можно содержать абстракцию в идеальном состоянии. Как бы не так. Чем больше ИТ проникает в нашу жизнь, тем меньше разработка ПО остаётся одним лишь созданием абстракций - надо как-то уживаться с реальным неидеальным миром.
Выбирая тот или иной фреймворк разработчик прежде всего изучает, какое у него окружение, какие есть тулзы для разработки, поддержка, обратная совместимость и т.д. Вопросов о том, как это поможет реальному потребителю не бывает. Вместо того, чтобы подумать о том, как функционал (увидел ошибку - иди в жопу) решит задачу пользователя, разработчик тратит тучу времени на настройку CI.
Я не говорю, что CI не нужны. Нужны, конечно, же! Главная задача программиста - находить золотую середину между идеальным техническим решением и задачами бизнеса. Очень часто происходит сильное смещение в сторону технических аспектов. Задай себе вопрос, программист: когда ты в последний раз переживал за пользователя?!
Эта проблема тянет за собой ещё одну: ЗАДРОТСТВО! При том, бесполезное ЗАДРОТСТВО! Как я это вижу? Да очень просто. Приведу пример.
Я почти всегда соглашаюсь проходить собеседования. Моё руководство об этом знает. Проходить собеседования - это не преступление. Тем более, что у меня уговор с руководством, что, если я решу уйти, то заблаговременно предупрежу об этом всех заинтересованных. Меня сейчас устраивает работа в SimbirSoft, и едва ли в ближайшее время что-то поменяется. Так что, просто прохожу собеседования. Но!! Я не соглашаюсь проходить собеседования или заканчиваю их раньше времени, если замечаю, что собеседование задротское. Совсем недавно общался с представителем очень известной компании. Там в названии есть буква “Я”. Так вот я отключился сразу после того, как меня попросили перечислить 7 типов индексов в PostgreSQL и описать их. Чувак!!! Год назад, я бы с лёгкостью назвал тебе 8, а может и 10 индексов PostgreSQL со всеми описаниями и весёлыми историями. Потому что я тогда работал на проекте, где это нужно было постоянно. Я могу завтра всё это вспомнить и так же хорошо их использовать. Сейчас этой информации в моей голове нет. Но это уже неважно, потому что мне неинтересно проходить дальше собеседование. Почему? Первая причина описана выше. А вторая: в случаях, когда тебя спрашивают конкретные знания в конкретных реализациях - это говорит о том, что ты будешь выполнять по сути конвейерную работу. Использовать полтора инструмента, по которым тебя прособедовали, быть винтиком в огромном механизме какого-то там продакшна. Меня это не устраивает.
ИТОГ: есть путь развития винтика в большом энтерпрайзе, который помнит все индексы pg, отлично знает все возможности ansible и т.д., а есть путь развития аналитического мышления в ИТ и приобретения навыков, которые позволят тебе не париться о периоде полураспада знаний. Что за период полураспада знаний (погуглите)? и почему поможет? Напишу как-нибудь в другой раз.
theartofmadeline
germansingergirl
s-u-f-j-a-n-s-t-e-v-e-n-s