Заметки с тегом «Технологии»

Начинающие программисты часто спрашивают в личке — как правильно выбирать технологии? Что учить, чтобы не отставать от прогресса? Это — плохой вопрос, учить надо вовсе не технологии.

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

Пример хард-скилла — умение размахивать молотком. Само по себе это умение ничего ничего не стоит. Молоток нужен, чтобы забить гвоздь, а гвозди забивают, чтобы построить дом. Вот это и есть самое главное умение — строить дома. И это — софт-скилл.

Когда умной компании нужно построить дом, она ищет не людей, которые умеют работать с молотком, а людей, которые умеют строить дома. Чем вы построите этот дом: шуруповёртом, подъёмным краном или нанятой командой монтажников — не так уж и важно. Важно ваше умение решать задачи, при необходимости включая в арсенал неизвестные инструменты.

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

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

Их на самом деле всего три: ничего не делать, стать синьором или податься в управление.

Ничего не делать

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

Минус один — тебя скоро заменит робот. К примеру докер уже превратил сисадминов из гуру командной сроки во втыкателей кабелей. Битриксные ПХП-шники под страхом тильды учатся писать структурированный код, а нейросети превращают верстальщиков в тестировщиков.

Синьор

Если все-таки хочется расти дальше, то самый очевидный и понятный путь — синьор. Скорее всего ты сможешь его пройти прямо в той компании, в которой работаешь сейчас. Синьор — гуру: пишет понятный и быстрый код, решает задачи в срок, да еще и коллегам помогает.

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

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

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

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

Тимлид\Менеджер

Традиционный путь для выросших программистов — стать тимлидом. Через ступеньку синьора можно перешагнуть — достаточно иметь минимальную склонность к управлению: не избегать людей и отличать процесс от результата.

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

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

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

А там уже до CTO недалеко.

Итого

Если ты решил связать свою жизнь с программированием и успешно вылупился из джуниорской скорлупы, есть всего три направления — ничего не делать, расти как синьор, или идти в управление.

Самая большая карьерная опасность для программиста — роботы. Чтобы неожиданно тебя не заменили машиной, нужно расти вширь и учить параллельные технологии. Или делать то, что машина научится не скоро — принимать решения и нести ответственность за результат.

20 лет назад существовал такой класс софта — анализаторы логов. Это были развесистые скрипты на перле, которые парсили журналы веб-сервера и считали простейшие метрики, вроде глубины просмотра или популярности конкретных страниц. Чтобы их установить, нужен был Системный Администратор — чувак из центра затрат, который в добавок к синдрому вахтера обладал сакральными знаниями об установке модулей перла, настройке рейд-массивов и обновлении ядра.

Теперь анализаторы логов заменила Гугль-аналитика, сисадминов заменил докер, и появилось отдельное слово для обозначения невиртуальных серверов — bare metal. Однако я до сих пор встречаю компании, которые ставят себе «анализаторы логов» — корпоративный гитлаб вместо гитхаба, локальные версии дженкинса вместо серкла, свои хостинги, почтовые сервисы, трекеры задач и пр.

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

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

За 500$ в месяц можно накупить пачку корпоративных аккаунтов у всех нужных сервисов и, ни разу не заходя в консоль, построить инфраструктуру мечты для небольшой команды. В заемной инфраструктуре ничего не сломается, потому что она живет в облаке и обслуживается специальными (и дорогими) дядьками.

Неужели ваше время стоит дешевле?

Эта заметка — для менеджеров, которые принимают решение о выборе технологического стека. Если вы CTO, программист или просто готовы поговорить о различиях языков программирования — посмотрите версию для программистов.

За пару дней до Нового Года я решил выбрать робот-пылесос. На рынке есть десятки брендов — iClebo моет полы, iRobot лучше всех строит карту помещения, Дайсон — мощный, а Сяоми вроде бы самый крутой, и стоит в 5 раз дешевле. Объединяет всех производителей одно — нихуя не понятно, какую из характеристик нужно выбрать, чтобы конкретно в моей квартире стало всегда чисто.

Когда руководитель не может делегировать выбор технологий для нового проекта, он оказызывается в такой же ситуации, как я на Новый Год. Проект нужно было начать еще вчера, а чем Руби отличается от Питона и Раста, и как эти отличия отразятся на сроках и целях — непонятно.

Ответ про пылесос я в итоге нашел на вечнозеленом ixbt. Но с языками программирования так не получается — вменяемых материалов нет. Даже если вы неделю будете изучать реддит, то узнаете только как правильно троллить ПХПшников или что наследование в Го лучше чем в Джаве. Какое это имеет отношение к срокам и целям — непонятно.

А ответ простой — новый проект нужно начинать на стеке, с которым работает команда, способная гарантировать результат. Вы же не обсуждаете с дантистом диаметр бура, а с дворником виды метел? С дантистом вы договариваетесь о том, чтобы не болели зубы, с дворником — чтобы во дворе не валялся мусор.

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

Еще раз — подойдет любой язык программирования (кроме JS, конечно). Главное, чтобы те, кто на нем пишет, гарантировали результат. И у вас было, кем их заменить.