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

К сожалению, на определённом этапе я начал выгорать. Мне не нравились мои рабочие часы и я не мог с этим разобраться, потому что у меня был часовой пояс UTC+7, а у некоторых заказчиков просто UTC. Я устал работать из дома, начал искать себе офис. Когда я его нашёл, я понял, что проблема ещё и в том, что я хочу не столько работать в офисе, сколько ищу живого профессионального общения, командную работу. Более того, мне захотелось больших, амбициозных задач, работы над продуктами, которые позволяют своим владельцам зарабатывать миллиарды. Фриланс же предлагал быть одиночкой и работать над небольшими интернет-магазинами, малопонятными мне стартапами и т.п.

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

Мой переезд в Москву отчасти, связан с тем, что я хотел нормальной офисной работы и я её тут получил. Мне в целом стало спокойнее за своё будущее, я начал лучше контролировать своё профессиональное развитие, у меня появилось время думать о себе, о своём здоровье и душевном благополучии. Выросли и доходы, потому что компании в Москве готовы платить профессионалам гораздо больше, чем заказчики на фрилансе (например, на сайте fl.ru максимальная сумма желаемого месячного дохода ограничена 250000 рублей). Собственно, заказчики идут на фриланс чаще всего за экономией, потому что содержать своего разработчика фуллтайм накладно.

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

P.S. Задать мне вопрос или проголосовать за уже добавленные вопросы можно на qst.it-monk.ru.

Для меня Телеграм уже давно превратился из простого мессенджера в главный инструмент взаимодействия с людьми, в том числе и по рабочим вопросам. Это также основной источник новостей. Раньше таким инструментом был Вконтакте, но сейчас ВК я не пользуюсь вообще.

Из-за работы в GeekBrains у меня стало так много рабочих чатов в Телеграме, что я стал путаться, пропускать не только рабочие сообщения, но и сообщения от друзей. И вообще Телеграм стал источником стресса. А потом я узнал, что в Телеграме есть папки, которые смогли частично решить мою проблему. Делюсь этим открытием с вами, вдруг кому-то окажется полезным.

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

Обычно, когда я начинаю чувствовать, что вот-вот выгорю, я меняю работодателя. Это привносит в жизнь новые задачи, новый вызов и смену обстановки. Но я не хотел уходить с позиции разработчика в GeekBrains. Мне нравилось работать в GeekBrains, это крутой проект и крутая команда. И мне нравится работать в Mail.Ru Group, тут создают настолько комфортные условия труда, что добровольно отказаться от них достаточно трудно: это и заботливое отношение к сотрудникам и зарплата не ниже рыночной и крупной офис (фотки из офиса можно посмотреть в моей инсте).

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

В итоге из ГикБрейнса я уволился, но остался там на позиции декана. Теперь я работаю в Mail.Ru Group над DonationAlerts Studio. Нагрузка стала комфортной, процесс разработки мне нравится, но вот приобретённое чувство, что я работаю меньше остальных, у меня осталось. Масла в огонь подливает то, что я стал чаще прокрастинировать, видимо, не хватает хотя бы двухнедельного отпуска. Поэтому, отвечая на вопрос, да у меня есть синдром самозванца, мне субъективно кажется что я работаю хуже других.

Что с этим делать пока не знаю, но если найду решение, обязательно с вами поделюсь.

Самый лучший обучающий материал по куберу находится на официальном сайте Kubernetes. Ребята не поленились и сделали на базе katacoda интерактивную консоль с пошаговым руководством, объясняющим «какую команду выполнять, для чего и что вообще происходит». Вот ссылка на первый модуль этого туториала: https://kubernetes.io/ru/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive/.

Сам я знакомился с k8s именно по нему. Один минус: туториал на английском, но английский в нашей професcии итак нужно знать, это мастхэв, в отличие от той же математики (знание которой, опять же, не будет лишним).

В этом туториале используется minikube. Это утилита, которая призвана упростить работу с кубером в локальной среде разработки. Однако, есть инструмент куда проще, который даже не требует предустановленных Docker и Kubernetes.

Это MicroK8s. У меня, к сожалению, отсутствует серьёзная практика его использования, поскольку большинство моих задач хорошо решается простым docker-compose. Но того опыта, что у меня есть, достаточно, чтобы сказать, что микрокубернетс реально упрощает разворачивание локального кубера настолько, насколько это вообще возможно. Нашёл хорошую статейку на Хабре для тех, кто хочет попробовать: https://habr.com/ru/post/439734/. На Ubuntu работает отлично, устанавливается через snap.

Стоит отметить, что microK8s, как и minicube, совсем уж не рассчитан для продакшина. Это именно утилита для локального использования для разработки или из исследовательского интереса.

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

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

Если вам кажется, что я с этим печеньем затрагиваю какую-то малообсуждаемую несущественную тему, то скажу что это не так. Офисным печенькам посвящены многочисленные обсуждения и даже целые Instagram-аккаунты. Вот, например, канал @cookies_mailru.

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

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

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

Сейчас развитие ИИ находится на примитивном уровне. Единственное преимущество современных моделей в том, что они делают свою работу быстро: там, где люди потратят на раскрашивание чёрно-белого фильма месяцы или даже годы, натренированная модель справится за день. При этом у ИИ напрочь отсутствует абстрактное и критическое мышление, без которых существование полноценного интеллекта невозможно. То есть, ИИ на текущий момент может превосходить нас только в скорости принятия решений и осуществления этих решений (для того же раскрашивания чёрно-белых кадров фильма ему не нужно двигать рукой), в то время как об осознанности этих решений говорить не приходится, да и качество часто оставляет желать лучшего. Скажем, распознавание речи до сих пор глючит, хотя над ним активно бьются не меньше 10 лет.

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

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

И не нужно упускать из виду работу с заказчиком. Если бы у нас была система, которая может написать программу по формализованному, чётко сформулированному по определённым правилам техническому заданию, то написание такого задания, учитывая, что требования исходят от людей, по сложности было сродни написанию самой программы. Современная же разработка вообще обходится без технических заданий (кто составлял, тот знает, насколько это тяжкий труд), а задачи ставит от спринта к спринту, ориентируясь на дорожную карту.

В конце предлагаю к прочтению занятный материал по теме: https://habr.com/ru/post/507420/.

Скорость набора текста (особенно англоязычного, если говорить про жителей СНГ) является косвенным показателем профессионализма в IT.

Понятно, что если человек печатает быстро, это вовсе не значит, что он программист, тестировщик, devops, менеджер проекта и т.п. С другой стороны, если он заявляет себя, например, программистом, то медленная скорость набора говорит как минимум о скромном опыте.

В целом, работа за компьютером связана с набором большого количества символов. Что важно, большая часть набранной информации не получит отражения в конечном результате. То есть, на 1000 строк в репозитории может приходиться 2000 фактически набранных, а затем удалённых строк.

Я сталкивался и в работе, и на собеседованиях со специалистами, демонстрировавшими низкую скорость набора. Это может не сказываться на конечном качестве кода, но я заметил, что это сказывается на скорости решения задачи и на том, насколько тяжело это решение даётся. Можно предположить, что медленно набирающий код программист испытывает меньше комфорта во время разработки, особенно если за ним наблюдают. Он избегает написания кода для проверки теорий, старается копировать участки кода, допуская синтаксические и логические ошибки.

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

Отмечу, что речь идёт не о скорости программирования в частности, а о скорости набора текста вообще, о способности печатать «вслепую».

Тем, кто входит в IT или уже вошёл, можно посоветовать прокачать скорость набора. Так будет проще учиться, проще получить хороший оффер и проще будет работать.

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

Году в 2007 друг попросил меня переустановить Windows на компьютере его мамы. Я как-то невнимательно отнёсся к тому, из каких папок нужно сохранить информацию и забыл перенести, в частности, незаконченную научную работу.

Позже, в 2010 году, когда я осваивал Linux, допустил классическую опечатку, набрал под рутом rm -Rf . / вместо rm -Rf ./ и удивлённо наблюдал, как с экрана исчезают значки, виджеты, система начинает сбоить. Когда понял в чём же дело, было уже поздно: директория /home оказалась удалённой вместе с архивами моих старых pet-проектов, которые я поленился забэкапить, документами, фотками... И, главное, текущей работой по проекту: это был какой-то сайт на Drupal для заказчика, а мои оправдания по поводу того, что я случайно всё удалил, наверняка показались заказчику выдуманными.

Следующим на память приходит эпизод, когда я грохнул корпоративный сайт oncloud.ru. Мне нужно было на уже существующую тестовую виртуалку вместо старого проекта залить новый, чем я и занимался в окне терминала через ssh. Меня отвлекли каким-то срочным хотфиксом на корпоративном сайте, я его сделал и задеплоил (тоже через ssh, но в другом окне терминала), после чего вернулся к текущей задаче. Выполнив удаление с диска старого проекта, я понял, что сделал это не в том окне терминала, в котором нужно. Всё бы ничего, код сайта хранился в репозитории, а базу я не трогал, но удалился весь загруженный на сайт контент. На этот раз спасли бэкапы: виртуалка бэкапилась через veeam, так что сайт находился в неприглядном виде всего час, что, впрочем, для облачного провайдера немало.

Ну и из прошлогоднего. Решил на выходных сделать простое в использовании dev-окружение для системы, которую мы пилили. Там порядка 30 docker-контейнеров. Код микросервисов и фронтендов из репозиториев я решил скачивать в директории backend и frontend соответственно (и добавил их в .gitignore: backend и frontend без слеша вначале). А Docker-файлы я хранил в директориях docker/backend и docker/frontend. Разумеется, команда git add -A их не добавляла в коммиты (и в глаза не бросилось то, что не все файлы добавлены), о чём я узнал не сразу, а только когда грохнул директорию проекта и попытался проинициализировать его заново, чтобы убедиться что всё скачивается и работает как надо. Я тогда даже безуспешно пытался восстановить удалённые файлы, настолько мне не хотелось заново писать 30 docker-файлов и проверять нормально ли работает каждый контейнер. Часов 6 работы было тогда потеряно.

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

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

Самый эпичный случай был, когда коллега-программист хранил, в частности, админский пароль от VMware vCenter, с доступом ко всей облачной инфраструктуре компании и её заказчиков, в текстовом файле, а сам файл для удобства хранил на Яндекс-Диске, то есть у конкурентов. А на моё замечание о том, не кажется ли ему такая схема даже не столько безответственной, сколько саботирующей, махнул рукой. Вместо того чтобы настучать в службу безопасности (полагаю, за такое бы просто уволили), я уговорил его использовать более безопасный способ. Он стал использовать шифрованный блокнот, который хранил всё там же на Яндекс-Диске. Скомпрометированные пароли мы поменяли. Не идеально, но хоть что-то.

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

За годы я выработал идеальный для себя способ обращения с паролями: это программа KeePass (раньше использовал KeePassX из-за более приятного интерфейса, но программа не обновляется с 2016 года), которая хранит пароли в файле *.kdbx, зашифрованном мастер-паролем. Мастер-пароль я храню, разумеется, только в голове. При этом сам файл *.kdbx уже можно хранить где угодно, без мастер-пароля он бесполезен. Я храню его вместе с остальным барахлом локально в директории, которая синхронизируется на Яндекс-Диск, благо Яндекс не ленится обновлять клиент для Linux. Таким образом, в облаке у меня всегда актуальная версия файла с паролями. Если мне нужно, например, на смартфоне получить какой-либо пароль, я просто скачиваю файл из облака и открываю его в Keepass2Android.

Я присматривался к облачным сервисам для хранения паролей, пожалуй, самый известный — это 1password.com. Кроме необходимости ежемесячно платить по 5 баксов, это облачный сервис, к которому можно потерять доступ во время очередной борьбы РКН с ветряными мельницами.

Просто факт: в моём менеджере паролей сейчас насчитывается 224 записи.

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

В 2000-х популярность программирования набирала обороты, а самым популярным направлением изначально была десктоп-разработка. Самыми ходовыми решениями для десктоп-разработки были Java, Delphi, C++ Builder, .NET Framework. Все они подразумевали разработку в парадигме объектно-ориентированного программирования, поэтому в моде тогда было знать паттерны (шаблоны) ООП, чтобы писать красивые решения, не изобретать велосипеды и не городить костыли. Я старался применять популярные паттерны в уместных местах, не потому, что это правильно (что, в зависимости от задачи, бывает спорным), а потому, что это экономило время.

А ещё в то время было модным обсуждать и пробовать «экстремальное программирование». Кроме автотестов, парного программирования и прочего, оно подразумевает непрерывный процесс улучшения качества кода (рефакторинг). То есть, если сейчас код написан плохо, например, имеется дублирование, но задача решена, в этом нет ничего плохого, но этот код обязательно должен быть улучшен в ближайшее время. Таким образом, не так важно какая архитектура у только что написанного кода, важно чтобы этот код стал лучше через месяц и ещё лучше через два. Я с удовольствием взял тогда на вооружение этот принцип и применяю его в своей работе. Это позволяет, не выделяя отдельных дней на рефакторинг, поддерживать код в хорошем состоянии: видишь код, который можно улучшить, улучшаешь его прямо сейчас, не откладывая «на потом». У такого подхода есть и ещё один плюс: ты не забываешь кодовую базу и хорошо в ней ориентируешься, как паук в своей паутине.

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

Мне принципы SOLID нравятся, но я понимаю, что их применение приводит к увеличению кодовой базы и, главное, увеличению времени на разработку. Поэтому я применяю их в зависимости от условий задачи: если от меня требуется сделать что-то быстро или это вообще MVP, я предпочту антипаттерны, суперклассы и тому подобное. В дальнейшем, если продукт не умрёт и будет развиваться, за счёт непрерывного рефакторинга архитектура кода будет приведена в порядок.

Мне просто использовать на практике эту свободу следования, частичного следования или неследования каким-либо принципам, потому что опыт помогает сделать правильный выбор. К сожалению, часто такой свободы выбора нет у джунов: они либо не умеют применять паттерны и принципы, либо, наоборот, умеют и стараются писать идеальный код даже тогда, когда этого не требуется. У меня есть яркий пример, когда джун с хорошей алгоритмической и архитектурной подготовкой писал MVP месяц вместо недели: уговоры на него не действовали, потому что он не мог принять тот факт, что иногда SOLID несёт только вред.

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

Задать вопрос, предложить тему для заметки, а так же проголосовать за понравившиеся темы вы можете на странице qst.it-monk.ru.

Когда кто-то вас спрашивает, какой язык ему стоит выучить, не стоит просто называть язык, который вам нравится. Лучше спросите, в какой области он собирается работать, например:

Фронтенд — JavaScript;
Бэкэнд — JavaScript;
Мобильные приложения — JavaScript;
Игры — JavaScript;
Искуственный интеллект — JavaScript.

Как это ни странно, ноги сегодняшней кроссплатформенной популярности JavaScript растут из его, некогда, тормознутости: когда Google решил создать самый быстрый браузер, им пришлось столкнуться с необходимостью разработки быстрого движка для выполнения JavaScript. В нулевых шло активное состязание между браузерами за скорость выполнения JavaScript кода. Поскольку веб-приложения стали использовать JS очень широко, а jQuery встраивался чуть ли не в каждый сайт, то самый быстрый браузер должен был быть, в первую очередь, самым быстрым в части выполнения кода, а не загрузки HTML, стилей и картинок.

Поэтому в 2008 году вместе с первой версией Chrome вышла и первая версия используемого в нём JS-движка V8. V8 был и остаётся самым быстрым, с тех пор в нём появилось ещё больше оптимизаций. Скорость и асинхронная природа JS подтолкнули программиста Райана Даля к идее использования JavaScript на бэкэнде для разработки высоконагруженных приложений, и в 2009 году он выпустил среду Node.js, которая использовала V8 и позволяла выполнять JavaScript вне браузера. В 2010 году появился менеджер пакетов NPM, тогда началось победоносное шествие JavaScript по всем направлениям.

Node.js и NPM позволили появиться таким технологиям как Babel и Webpack, TypeScript, Angular, React и всему тому, без чего современная фронтенд-разработка не может обойтись. Node.js широко используется в бэкэнд-разработке в качестве основной и вспомогательной среды. Когда сообщество увидело в языке большой потенциал, стандарт языка стал активно развиваться, приобретая мощные синтаксические инструменты.

На основе Chromium был создан Electron, позволяющий разрабатывать десктоп-решения, на основе которого созданы Visual Studio Code, Skype, Discord, Slack, Streamlabs OBS, WhatsApp Desktop и другие. Но для десктопа используется не только Electron: например, клиент Spotify использует Chromium Embedded Framework для отображения интерфейса.

React Native, появившись в 2015-м году, быстро занял прочные позиции в качестве инструмента для мобильной разработки, став основой для таких приложений, как Facebook, Instagram, Skype, Tesla, Airbnb, Discord, Pinterest и многих других.

Нашлось место JavaScript и в разработке AAA-игр. Благодаря технологии Coherent Gameface, разработчики таких игр как Battlefield 1, Godfall, Control, PUBG, BlackDesert Online используют JavaScript для разработки игровых интерфейсов.

Разумеется, у JavaScript есть недостатки, но, как однажды сказал Страуструп, «есть всего два типа языков программирования: те, на которые люди всё время ругаются, и те, которые никто не использует».

На этой неделе принял решение уйти из Mail.Ru Group, в котором я занимал позицию разработчика DonationAlerts Studio. Если раньше причины моих уходов из проектов лежали в плоскости неудовлетворённости проектом, организацией процессов или просто усталостью, то теперь я дорос до более простой причины — неудовлетворённостью доходом. Настало время поговорить о волнующей всех теме, о зарплатах программистов.

И чтобы разговаривать предметно, я начну с цифр. Полтора года я работаю в мейле и всё это время получал 240 тысяч рублей на руки (или, как принято говорить, нетто). Это чуть выше, чем средняя зарплата по СНГ для разработчика моего уровня. Тут уместно задать два вопроса: а какая же максимальная зарплата и неужели работодателю не было выгоднее удовлетворить мои ожидания, нежели проходить через процедуру поиска нового разработчика и вытекающими из этого задержками в процессе разработки?

Всё объясняется простыми рыночными отношениями: зачем компании платить кому-то 300к, если есть очередь из желающих работать за меньшую сумму? Тем более, если это компания крупная, с тысячами разработчиков в штате, экономия на зарплате которым способна принести существенную прибыль в абсолютном выражении. Можно было бы возразить, что программист за 300к будет делать больше программиста за 200к, но нередко оказывается, что это не только не так, но и наоборот. Не слишком уверенный в себе программист способен создавать ценность не хуже «рок-звезды», но получать в три-четыре раза меньше денег, просто потому, что не знает, что можно по-другому. А по-другому можно и я считаю своим долгом об этом говорить.

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

Через неделю после того, как я получил долгожданное «повышение», ко мне начало приходить озарение такой силы, что мне пришлось срочно взять отпуск и провести полторы недели в размышлениях о том, почему я оцениваю свой труд так низко и что пора бы перестать вестись на крутые HR-бренды, а уделять внимание компаниям, которым ты нужнее (раз они готовы платить больше).

И вот мы подходим к ответу на вопрос о максимальных зарплатах в айти. Например, сегодня я получил предложение пройти собеседование на вакансию с вилкой з.п. 420-600к, с комментарием, что можно и больше, всё зависит от скиллов. Вилки зарплат 400-500к — это вообще обычное дело. Но вы, как программист, никогда не увидите таких предложений от рекрутёров из Тинькофф, Яндекса, Авито, Мейла и прочих известных компаний. Айти-гиганты доминируют на рынке труда, предлагая вместо высоких зарплат нематериальную компенсацию в виде массажа, фреш-баров и, главное, сопричастности к «великому». Остальным компаниям приходится просто больше платить.

За довольно долгий перерыв в ведении канала (в процессе смены работы решил устроить себе отпуск) было время подумать над вопросом отчего сейчас в основном зависит моя зарплата. Тем более что сам процесс поиска новой работы заставил задуматься о своём ценообразовании.

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

В процессе перехода по условным шагам «junior-middle-senior» работодатель начинает уделять софт-скиллам всё больше внимания. Для middle-разработчика важными становятся умение работать в команде, память и внимание.

У senior список навыков пополняется гибкостью (пригождается в процессе выбора подходящей для решения задачи технологии), навыками тайм-менеджмента, коммуникации, умением доводить начатое до конца. А требования к умению работы в команде увеличиваются.

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

Зависимость размера зарплаты от hard-soft навыков я бы субъективно описал так:

- У junior 90% суммы зависит от hard-скиллов, а 10% от soft-скиллов;
- У middle это 80%-20%;
- У senior — 60%-40%;
- У team lead — 40%-60%.

Отвечаю на вопрос, отчего сейчас зависит моя зарплата: я устраиваюсь на позицию team lead и думаю, что в моём случае половину зарплаты мне будут платить за hard-скиллы, а половину за soft-скиллы.

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