На ковчеге были динозавры?

Сегодня ютьюб показал пару видосов. Вот интересно, если бы я пришел на зачет к преподавателю и сказал бы, что конъюнкции не существует, я верю то, что ее нет. Так как в священном писании сказано, что бы мне он ответил? Вот тут например Ты либо за научный подход и критичский способ мышления либо за веру в священное писание и авторитет тех, кто дольше чем ты его толкует. Какие общие подходы вырабатывать, если фундаментальные аксиомы противоречат друг другу. А еще стоит вспомнить, что религия делала с наукой, когда у нее было больше власти. Это печально лишь только.

Почему инженер делает что-то? Потому что может!

В одном из чатов меня спросили, а почему мы делаем CodingDojo ивенты для инженеров. 

Почему, по вашему мнению, взрослым людям интересно заниматься такой достаточно детской забавой? (лично авторам в том числе 🙂 ) Что мотивирует?

Инженер это такой подвид Homo Sapiens, который делает что-то казалось бы совсем не нужное потому что может.


Я вот вчера пол ночи ковырял эмулятор старого бытового компьютера ЛИК, который был придуман в 1988 году. Просто потому что могу. Это не нужно для прогресса человечества сегодня. Но моими наработками будут пользовался некоторые инженеры, которые так же как я ценят ретро компьютеры. А возможно кого-то из них мои наработки вдохновят на какие-то другие свершения. Или их свершения вдохновят других инженеров, которые вдохновят других инженеров, которые... Быть может какие-то из свершений будут уже в области, которая поможет человечеству сегодня.

Мы в контексте CodingDojo делаем то, что заряжает инженеров, а потом они возвращаются на свои проекты и творят там чудеса.


или что-то вообще на другой планете

По сути это все инженерные задачи, огромные (типа полета на Марс робота made in Earth) - складываются из больших, большие из множества маленьких, маленькие решаются за пару вечеров. Какая разница на чем качать свой инженерный ум? Он прокачивается серии "это не возможно", которые он сделал возможным этой ночью. А начал это путешествие без уверенности в успех, но со знанием что путешествие будет увлекательным.

Делая музыку на старых дисководах, откапывая проект 25 летней давности или играя в Coding Challenge

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

Думаешь это все "войти в IT" и большие зарплаты двигает нас в будущее? Нет. Это делают такие люди, как инженер в видео ниже

Почему он cделал то, что сделал? Потому что мог.

Как улучшить себе жизнь со скриптами bash/btach

Сегодня я хотел написать этот пост, но краткое вступление раздулось до огроменного ставшего в результате самодостаточным поста. Тут же я поделюсь серией подобных практик в одной узкой области - сборка и поставка приложения. А пост этот был написан с использование другой практики - make manual from chat log. Когда ты с коллегой в чате уже обсудили какой-то вопрос, ты настрочил много текста и теперь хочешь его как-то повторно использовать. Так что этот пост, как и многие другие - во многом вдохновлен обсуждением вопроса в чате, скопипащенный оттуда и немного отредактированный. 

Итак погнали. Я ленив, а потому если команду в консоли bash/batch я ранаю второй раз за сегодня, тут же останавливаюсь и начинаю писать bash/batch скрипт: bash для linux, batch для windows. За последние пару лет эта практика меня сильно прокачала в этих сприктовых языках программирования. Если раньше мне приходилось гуглить как делается в OS так или иная операция или выполняется та или иная команда, то сейчас я гуглю особенности различных языковых конструкций: if/else/while/function/ect, как делаются те или иные expression и так далее. Этот язык программирования (вообще правильно command language) весьма специфический и более того их два диалекта - для windows и для linux. Почему диалекта, потому что очень многое слизано (как мне кажется) у windows с linux. Отличия все же приходится гуглить. 

Раньше я писал скрипты для обоих OS. Но в последнее время склоняюсь в сторону linux, а для тех, кто работает под windows предлагаю для запуска моих bash скориптов использовать что-то типа cygwin или mingw. Очень в немногих местах приходится проверять OS и менять поведение скрипта в зависимости от OS. Но это куда лучше чем писать две версии скриптов, либо лишать windows пользователя инструмента автоматизации. 

Идем дальше. Загнать тот скрипт, который ты обычно ранаешь в консоли в текстовый файл и назвать с расширение bat/sh это первый шаг, но этого недостаточно. Часто новички в DevOps часто используют команду cd для того, чтобы направиться в определенную папку, и там уже выполняют команду. Я же пришел к тому, что каждую команду стоит выполнять в абсолюте.
Все что выполняется относительно, всегда потом дает повод поиграться с ним в самый неподходящий момент.

cd ./some/place/in/project
ls -la
cd ../../..
cat file.txt

В суппорте такой подход требует от меня всегда помнить "где я?". То есть для каждой строчки надо помнить 2 вещи - ЧТО делаем, ГДЕ делаем. А если ты юзаешь всегда только абсолютный путь, тогда все чисто.

ls -la /srv/app/some/place/in/project
cat /srv/app/some/file.txt 

Более того, рекомендовано использовать такие команды даже когда ты работаешь в консоли руками. Если говорить про linux то там в папке твоего юзера есть ~/bash_history файл и в нем все команды когда-либо выполняемые тобой на этой машине. Очень информативно видеть там самодостаточные команды, выполнив которые из любого места системы будет один и тот же эффект.

Но как быть с дублированием? Допустим я не хочу постоянно вбивать /srv/app/some

ls -la /srv/app/some/place/in/project
cat /srv/app/some/file.txt

В скрипте (bash) сделать так

root=$(pwd)
ls -la $root/place/in/project
cat $root/file.txt

В batch вот так 

set root=%cd%
dir %root%\place\in\project
type %root%\file.txt

Следующим шагом я бы улучшил информирование в консоли (bash). 

BLUE=94
GRAY=89
YELLOW=93

color() {
    message=$1
    [[ "$2" == "" ]] && color=$YELLOW || color=$2
    echo "[${color}m${message}"
}

eval_echo() {
    command=$1
    [[ "$2" == "" ]] && color=$BLUE || color=$2
    color "${command}" $color
    echo
    eval $command
}

eval_echo "set root=%cd%"
eval_echo "dir %root%\place\in\project"
eval_echo "type %root%\file.txt"

echo
color "Press Enter to continue"
read

И тогда вывод будет намного более приятным. Перед выполнением лога работы каждой команды будет напечатана другим цветом сама команда. А в самом конце скрипта подождем нажатие Enter с тем, чтобы убедиться что оператор все осознал и возражений не имеет.

 

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

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

А если не хочется копипастить из скрипта много кода, то напомню, что самый минималистичный вариант eval_echo это

eval_echo() {
    echo "$1"
    eval $1
}

Обрати внимание, что в этом коде есть ESC символ. 

 

Благодаря этому символу в linux консоли можно рисовать цветом. Под bacth есть подобный подход.

Все это сильно позволяет ускориться во время выполнения обычных рутинных действий: залить ветку на github со всеми subrepo, pull всех subrepo, автоматическая генерация каких-то ресурсов, создание snapshot для всех артефактов, создание запускного jar для каждого компонента с автоматически сгенерированными скриптами запуска, запуск сервера в целях отладки в определенной конфигурации, дамп базы и так далее. Все это делалось вручную раньше, а сейчас на это не тратится время. Время (сильно меньше) тратится на поддержание скриптов. Это экономически выгодно, иначе небыло бы DevOps с CI/CD и мы собирали war вручную или с Ant, заливали бы его в папку Tomcat на сервере, разбирались бы с конфликтом jar, как делали это 10 лет назад. Деплой бы занимал не 1 клик и 10 минут, а 1 час и много ручной работы.

Инженерные практики могут ускорить тебя в 100х раз

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

Почему я коллекционирую различные ускорялки? Математика проста. Пусть это конкретное решение мне даст +15% в производительности. Какое-то другое решение даст +15%. Еще где-то что-то прочитаю и попробую, снова +15%. Складываем вместе 10 подобных решений и получаем 1.15 ^ 10 = 4.04. То есть 10 подходов ускоряющих тебя всего лишь на 15% в сумме дают + 404%, а это 4х в скорости! Подходов за 10 летний опыт может собраться на порядок больше. И для 50 штук прирост будет уже 1083%, 10x. А и это 15% роста продуктивности это так, самый минимум из того, что новая практика тебе может дать. Часто введение нового подхода сама по себе в разы тебя ускоряет. 

Внимательний читатель заметит, что любой новый подход в разработке облагает автора налогом. Естественно надо закладывать время на суппорт. Часто разработчик принимает решение сам, буду ли заморачиваться с новым кодом и его суппортом или по старинке сделаю, и делает это на основе критерия. Если я скажу, что новый подход даст тебе прирост в производительности в 10 раз, а при этом потребует от тебя всего лишь по 5 минут в день больше времени - дурак не согласится. Но обычно все не так. Времени на реализацию решения надо потратить сегодня 2-3 часа, а потом еще на суппорт решения раз в неделю по 0.5 часа. А прирост будет 10-20%, что уже не так леко прочувствовать, как 2,5 часа. На одной чаше весов - вклад в часах единоразовый с небольшим вниманием, а на другой % прироста производительности. % складываются иначе, чем часы. Копить % выгоднее, чем экономить время. Не всегда, но часто.

Правда, далеко не все дивиденды от инженерных полдходов можно "складывать" как описано выше. Есть независящие инструменты. Ну например я кодирую в Idea (она удобнее), а на сервере у меня все в docker (легче чем инсталить все на host машину). Там на X% ускорился, тут на Y%. Но так как работаю я ИЛИ в идее ИЛИ с докером на сервере, то % берется не от 168 рабочих часах в месяце, а от всего времени в IDE и отдельно всего времени во время обслуживания сервера. Результат складываем и "X% + Y%" дает ((1+X/100)*develop_time + (1+Y/100)*deploy_time). И в этом случае время проинвестированное в разработку и поддержание инструмента стоит оценивать критичнее. Но есть и фундаментальные подходы, скажем как следование принципам BabyStepsRefactoring, CleanCode, UnitTesting, TestFirst. Выгода от использования этих принципов ощущается одновременно и влияет друг на друга, потому формула суммирования будет более вкусной. Возможно не (1+X/100)*(1+Y/100) - это крайность. Но чем более влияния подходов друг на друга, чем чаще они используются, тем ближе мы к пермножению процентов, а не суммированию.

Надеюсь никтон не будет спорить в наше время с тем фактом, что рефакторить код необходимо, если ты хочешь хоть как-то влиять на энтропию системы. Держать код в чистоте - значит помогать себе и другим читателям понимать, что тут происходит. Делать рефакторинг можно грубо зарывшись по уши в код и потом тратя время на исправление всех ошибок компиляции, отловку багов, а можно элегантно - вооружившись компилятором ide и юнит тестами быстро привести код в рабочий вид. Но параллельно с этим всем можно производить рефакторинг маленькими шажками, что позволит исключить дебаг из процесса. А если нужна новая функциональность, то использования подхода TestFirst и сключит дебаг так же из процесса разработки. Привет TDD! Каждая из практик ценна сама по себе, но вмсте они дают возможность избавиться от Debug вообще. 

Debug - самая сложная и неуправляемая, а потому и дорогостоящая часть в разработке. Во время Debug ты мало что понимаешь - только тыцаешь 2-3 клавиши и смотришь в стек в ожидании инсайта. А без юнит тестов рефакторинг опасен, но если ты и осмелишься - много багов уйдет на прод. А без рефакторинга сложно и за CleanCode следить. Так вскоре техдолг не даст менять сисему как того нужно бизнесу. В какой-то момент исправление 1 баги будет порождать 2 новых. Тогда лучшее, что можно сделать - заморозить его. Ну или покрыть модуля автогенерируемыми юнит тестами, затем взяться за рефакторинг модулей с целью навести порядок в модели и сделать код чуть более clean. Затем выкинуть старые автогенерируемые тесты и написать нормальные, читабельные. Этот долг придется выплатить, если хочется продлить жизнь проекту. И лучше тут пользовать подходом ПрицнипСкаута. Сделать место стоянки после себя чище, чем оно было до тебя. Каждый день плати чуть-чуть времени уделяя этим инструментам: CleanCode + Refactoring + UnitTesting. И проект проживет дольше. 

Это один из примеров связки практик. Есть и другие практики. И тот из нас, кто научится использовать их по максимуму будет производительнее чем тот, кто не будет в 100 раз, в 1000 раз, а может и в 10000 раз. Возьмем студента новичка без опыта разработки - сложная задача может просто его застопорить на недели (если вообще задача будет решена), тогда как опытный миддл сделает ее за два дня. Вот и решай на сколько более производительный тот, кто сделал работу в сравнении с тем, кто не сделал ее. Я же верю в то, что хоть в среднем по индустрии Middle не сильно отличается от Senior (так просто устоялось), их производительность может отличаться в весятки, а то и сотню раз. Вопрос в том, остановился ли Senior в развитии на уровне инструментария Middle и дальше качает только SoftSkills или продолжает поиск инструментов его ускоряющих.

Нейросети уже кодят вместе с нами

Ждал эту фичу от StackOverflow но ее предложил Github.  Программирование с этой технологией становится еще более высокоуровневым.

Какие трудности. Ну кроме того, что еще больше информации будет собирать о нас большая компания добра (этим в наше время уже никого не напугать) больше волнует общественность нарушение авторских прав. Во-первых копайлот учится на открытом исходном коде, а некоторые лицензии могут запрещать использование этого кода в проприетарном приложении (привет GNU GPL). Во-вторых код из окружения разработчика утекает на сервера Microsoft и вероятно на них тоже обучается нейросеть, что может нарушать авторские права проекта. Но прогресс не остановить, я уверен что у ребят найдутся ресурсы, чтобы порешать все и технология увидит своего покупателя. Кстати да, я более чем уверен что подписка будет платной. 

Слышу ворнинги разработчиков порталов с коллекцией алгоритмов типа HackerRank, ведь теперь любому участнику в разы проще вырваться из низов используя только Copy-Past Driven Development. Но я уверен, что и они решат этот вопрос.

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

Мне видится потенциал этой технологии в области TDD и Refactoring. Уже сейчас такие чудные инструменты как Intellij Idea очень классно подсказвают в рефакторинге что можно упростить. И те из нас, кто очень крут в рефакторинге просто потому что он его изучал глубоко постепенно сдает свои позиции тем, кто только вошел в индустрию. Два клика мышкой и смотришь - было стало. А теперь представь, что сможет Copilot глядя на все Diiff во всех репозиториях - там закодированы бесчисленные рефакторинги. 

Другой килер фичей может стать подключение TDD методологии разработки в Copilot. То есть если сделать возможным задавать запрос на написание метода через тесты, тогда и отладку можно отдать нейросети. Пусть перебирает код, пока не пройдут тесты. Вот это будет здорово! Это еще сильнее снизит порог вхождения и уберет из процесса разработки Debug - самую сложную часть, которая пока еще остается нашим козырем. 

Будущее уже наступило. Пристенитесь, мы продолжаем ускоряться.

Мое отношение к поиску кандидата его интервью и найму

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

Собеседования не эффективны по своей природе. Я как интервьюер в первые пару минут разговора уже знаю (чувствую) беру ли этого человека к себе на проекте или нет. Все остальное время - "тыкание палочкой" и поиск оправданий для своего изначального чувства. Даже если все идет по процессу - быть субъективным 1 человеку разумному сложно. Первое впечатление задает весь тон собеседования. А еще многое зависит от совместимости психотипов, что ты ел сегодня утром, болит ли у тебя голова, выспался ли, ругался ли ты сегодня утром с представителем ЖЕКа по поводу протекающей канализации под домом, получил ли ты ожидаемый бонус на прошлой неделе и массы других факторов, которыми наполнен каждый день каждого из нас. Разговор будет не про твой опыт - так точно. Скорее про обмен веществ. Но всем будет казаться, что про опыт.

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

Если да - отлично! Давайте пообщаемся по существу - как мы (и наш опыт) можем быть полезны друг другу. Если нет - то нет. Все равно, даже если мы проведем классическое интервью - фидбек будет приблизительно такой "спасибо, мы выбрали другого кандидата", "спасибо, мы вам еще напишем (ложь)", "спасибо, вы нам не подходите". Любые попытки разузнать что не так - очень модерируются и в результате ты не получаешь подробного (хоть и неприятного, но потому и полезного) фидбека. Банальные отписки. Или тишина. Да я понимаю почему - тебе как менеджеру проект надо застафить. Вакансий 5. Кандидатов 25. Попробуй всем отписывать подробную обратную связь. А если ты рекрутер - твоя зона внимания уже не 25, а 250 кандидатов. К тому же кандидат может и не услышать (понять) фидбек, обидеться, отпишется и через год, когда станет более опытным не захочет иметь дело с компанией. Сложно тут. Я все же стараюсь давать емкие фидбеки даже когда освобождаю (увольняю) ребят из команды. Но всегда это трогает такие слои, которые не очень приятно поднимать и осознавать коллеге. Но так у него есть шанс. Он получил обратную связь. Ее, эту связь, кстати, хорошо бы получить и для проекта от него. Такую же не удобную. А потом превратить в план работы над ошибками. 

Про резюме я сказал. Оно вообще ни о чем не говорит. Написать его любым мне как кандидату ничего не мешает. Масса сататей и видосов на эту тему написаны. Целые разделы IT тренингов этому посвящены. Как высосать коммерческий опыт из пальца. Другое дело отзывы коллег, с которыми трудился. Потому я лично их всегда для себя запрашиваю и сам делюсь. Если не спрашивать - никто и не оставит. Все спешат. Надо спросить и напомнить. И еще раз напомнить. Вот мой профиль, я им горжусь. Я уже не может быть всего над чем трудился с коллегами, но в любой момент смогу прочитать их отзывы. Надеюсь мои отзывы им так же греют. И я никогда не писал того, во что не верил сам, иначе теряется весь смысл.

Но вернемся к резюме. Само по себе резюме в наше время - с точки зрения интервьюера почти ноль. Потому на собеседовании скорее всего разговор будет не на равных, а с подозрением - мол ты обманщик и мы сейчас тебя будем уличать. Вот зачем так неэффективно расходовать свою жизнь? Сколько таких интервью было у меня. Акт самоутверждения через унижения кандидата. Причем попробуй как-нибудь сам взять на собеседовании подобный тон, перехватить инициативу (у вас же СО-беседование) и спросить что-то впроде. А вы сами-то используете на проекте то о чем меня спрашиваете или я буду писать бекенд ендпоинты методом copy past в системе которую нельзя рефакторить потому как тестов вообще нет, а тесты писать нельзя потому, что заказчик не хочет за это платить? Так работы не получить. А если она сейчас не очень то и нужна, то зачем тогда ходить на собеседования? Редкость, когда это делается для поддержания тонуса, но и не честно я считаю по отношению к тем, кому ты не сказал заранее что новой работы не ищешь, а на собеседование идешь из любопытства. Так что чаще всего на собеседовании именно кандидат сидит в неудобной позе. Палочкой в него тычут.

На самом собеседовании это выливается в вопросы типа "а чем отличается интерфейс от абстрактного класса". Не ну вы серьезно? Это ж как надо не доверять резюме кандидата, чтобы начинать с подобного вопроса. Ну или "а давайте по-программируем на листочке A4 и посмотрим как вы соображаете". Очень полезный навык, раскрывающий всю суть инженера. Программирование на листочке. Лет 30-40 назад так и было, но не сегодня.

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

Когда я работал в офисе то порой наблюдал за тем, как все окружающие вставали и синхронно шли к кофепоинту. Интернет отключился. Google driven development больше не работает. Работа стала. И с таким настроем ребята принимают решение про трудоустройство на основе написанного кандидатом в блокноте. А ты попробуй выключи интернет и сам попрограммируй хоть два часа к ряду. А ведь в опыте кандидата могли быть и такие показательные моменты, когда в целях пожаротушения без IDE по SSH на удаленном linux prod сервере в консоли в jar (что внутри war, что внутри докера) подменить 1 перекомпилированный вручную класс чтобы NPE исправить не пересобирая всего приложения (допустим, это не возможно). Его ж не спросят. А про давайте двусвязный список напишем в блокноте... Ну такое. 

Хочешь посмотреть как кодит кандидат? Запроси его гитхаб. Коллега должен уже что-то сделать до того как предложить свою кандидатуру. Его github аккаунт должен быть живой и показывать что помимо работы и зарабатывания о постоянно в тонусе инженерии. Что-то делает. Его это интересует, он живой. И в коде видно насколько. Как он относится к тестированию. Как он работает с техдолгом. Как у него с документацией и CI/CD. Как у него с алгоритмами. А ты и есть этот инженер и у тебя нет до сих пор гитхаба - опубликуй в нем все свои домашние проектики (я не верю что у тебя их нет). As is. И потом веди их уже так, как если бы за тобой подглядывает весь мир. Мне повезло, у меня проект opensource. Роль на проекте у меня больше менеджерская, но свой вклад в опенсорс я успел сделать.

Имея базу гитхаб + резюме + продающее видео ты как инженер становишься привлекательнее. Я как менеджер быстро могу понять хочу ли продолжить общение или нет? Может просто опыт не подходит нашему проекту - это можно понять уже через 5 минут. Или по темпераменту человек не впишешься в коллектив - так же 5 минут. Зачем суммарно тратить N часов времени, ведь 2 часа только самого интервью суммарно всех участников, а сколько для подготовки к нему, сколько ментальных сил кандидата. Если мы ускоряемся, а мы ускоряемся, то я хочу иметь возможность общаться за тот же 1 час с 10ю кандидатами. Не меняя в корне подхода интервью, это не возможно. 

Идем дальше. Что бы не происходило на интервью, как бы вы друг другу не понравились - все тайное станет явным в процессе триал периода. Инженер пришел помогать бизнесу или зарабатывать не сильно напрягаясь. А раз так, почему бы не проверить это заранее? У меня проект опенсорсный, я могу привлекать контрибьюторов. А тем из них, кто показал лучшие результаты - предлагать место в команде. Мне бы хотелось, чтобы в любом проекте, каким бы он ни был закрытым - нашлась часть работы, ТЗ которой можно было бы опубликовать в интернете без нарушения контрактов. Результат полезен всем. Кандидат имеет шанс показать себя, прокачать свой гитхаб, а может даже и получить плюшку от компании (как фрилансер). Команда получает дополнительную возможность решать свои вопросы, заметить на рынке талантливых ребят, сделать им предложение. Но это ж надо заморочиться. Да и проект у нас закрытый. Собеседования ж привычнее. 

Это все про мир, каким бы он мог быть, если бы я переизобретал его с нуля. 

К слову про переизобретения. Раньше (на заре моей профессиональной карьеры) все менеджеры твердили, что удаленная работа не возможна. Что мы скажем другим, если тебе разрешим? Как мы проверим вы там шаритесь, а работаете? Как организовать рабочее место? Как быть с безопасностью? И тому подобные вопросы-отговорки без желания (скорее потребности) искать на них ответы. Но меня волновало другое - 2,5 часа на дорогу с/на работу в сутки дают 3 полных рабочих месяца по 8 часов в году или 22 сутки из 365 доступных в дороге. Не с семьей, не за проектом, не за книгой, а в дороге, нюхая выхлоп или потную подмышку соседа в метро. Но я добился удаленной работы за 6 лет до карантинных ограничений и доказал, что офис для работы лично мне не нужен, более того он мешает. А работая из дому проблемы совсем другие возникают, не те, о которых менеджеры переживали - как делать перерывы и не перерабатывать. Сейчас моя команда работает по всему миру. И нам всегда было достаточно для решения любых вопросов чата и созвонов. Это про IT. А офис с печеньками и тенисным столом... Хорошо, что это отходит. Отойдут и собеседования. 

Еще момент, называется синдром самозванца. Если кандидат им страдает, у него шансов в моем проекте в разы больше, даже если опыта у него недостаточно. По моему важно не то, сколько опыта ты перелопатил в прошлом, а как ты готов ускоряться в будущем. Если в карьере кандидата все уже было и цель заработать на ипотеку не сильно напрягаясь - продуктивности не будет. Еще год назад студент, который только только стал мидлом будет больше драйва и энергии проекту давать, чем ленивый гуру. При чем тут синдром самозванца? А все просто - в тот момент, когда кто-то решает, что более чем заслужил быть сдесь - начинается его незаметная деградация. Зачем напрягаться, если все и так ок. Зачем делать больше, если это ни на что не повлияет. А я скажу. Есть инженеры которые делают свою работу в 100 раз быстрее других. При чем правда, что зарплаты у них могут и не отличаться заметно. Но не в этом дело. Дело в том, чтобы успеть сделать больше. Успеть оставить след. И шансов больше у того, кто не уверен в своих силах. И все потому, что ему некомфортно если ничего не происходит, он ищет пути. И находит. А есть опытный уверенный в себе, но как окажется поже ленивый синьйор-помидор, он уже все умеет и знает. Я возьму молодного и неуверенного. 

Камушек в сторону устоявшегося процесса рекрутинга. Создавая тренинг школу с коллегами мы сталкивались с проблемой наших выпускников - рекрутеру не интересны студенты выпускники. Опытных надо. И отношение к ним не очень. Получается студенты бегают за рекрутерами до получения первого комерческого опыта. А после первого проекта картина разворачивается на 180 градусов - за инженерами бегают уже рекрутеры. Вопрос к рекрутерам - как будут относиться к вам инженеры которым пол года назад на любой их запрос вы отвечали отказом или игнором? И как мне быть с вашими 100500 запросами по всем каналам связи о том, что мне бесконечно надо рассмотреть вашу компанию для нового места работы. Причем все из них мимо. А если вдруг интервью я не пройду по причине какого-то несварения с интервьюером стоит ли включать игнор? Эта игра не в долгосрочную. Ясное дело, что завтра придут другие. Но те, кому вы сказали нет вчера - завтра больше не придут. Я точно не приду.

А к кому придут? К тому, кто интересовался их настроением, их карьерой их жизнью и профессиональной деятельностью тогда, когда не надо было стафить чей-то проект. Где-то так, наблюдая за работами тех немногих рекрутеров, у меня родилась идея назвать их роль не рекрутер для компании, а продюсер для инженера. Как с рок звездами. Пока инженер делает магию на сцене - мы качаем его, помогаем вырасти по карьере, помогаем найти работу или поддерживаем нетворкингом и связями. Инженеру, который сейчас не у дел (выгорел, устарели технологии, болеет, проблемы) очень важна поддержка и кастомные условия, даже если это не выгодно рекрутеру сейчас. Тогда как потом, когда он приведет все дела в порядок - его можно будет выгодно устроить.

Было бы здорово, чтобы между инженером и продюсером были и другие взаиморассчеты, а не прсото бонус рекрутеру за трудоустройство от компании. Но тут уже камень в огород инженера пост советского пространства - он не готов за платить за развитие своей карьеры. Жаль. Это считаю большим упущением. Не все деньги, что инженер заработал - по настоящему его. Часть денег - это инвестиции от работодателя в его будущее. Если деньги были спущены инженером не на самообразование, не на расширение компетенций, а исключительно на жизнь-потребление, в будущем в кризис инженеру будет не просто. А кризис придет.

А пока все ж работает. А значит не трогай! Так жеж?