Удержать нельзя отпустить

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

Почему считается, что удерживать не нужно? Почти все рассуждения примерно такие: дескать, человек, получивший оффер, уже мысленно уволился, “изменил”, “укусил”, поэтому остается только пристрелить. Даже если удержишь - все равно ненадолго, человек все равно уйдет.

Ребят, да, есть такой шанс, но вообще это ерунда. Любой мало-мальски талантливый сотрудник, особенно в начале карьеры, постоянно в сомнениях и соблазнах, и нет вообще ничего страшного, если вдруг на него “накатило”, и он собрался увольняться. Есть миллион ситуаций, в которых люди не нашли в себе сил поговорить о карьере до момента, когда на руках уже оффер. Либо не было создано для этого условий. Короче, вины “компании” в этой ситуации может быть не меньше, чем сотрудника. Это я не говорю о таких случаях, когда принести оффер в другую контору - это вообще единственный вариант заявить о своих целях и получить повышение (таких компаний становится меньше, но их до сир пор полно, уверен, что каждый из вас уж одну-две такие компании точно вспомнит).

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

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

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

Исследование показало, что 52 процента ответов ChatGPT на вопросы по программированию неверны

Исследователи просмотрели более 517 вопросов в Stack Overflow и проанализировали попытки ChatGPT ответить на них.

«Мы обнаружили, что 52 процента ответов ChatGPT содержат дезинформацию, 77 процентов ответов более многословны, чем человеческие ответы, а 78 процентов ответов страдают от различной степени несоответствия человеческим ответам», — написали они.

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

Исследователи Purdue опросили 12 программистов (по общему признанию, это небольшой размер выборки) и обнаружили, что они не обнаруживают ошибок, сгенерированных ИИ, в 39 процентах случаев.

Почему это происходит? Возможно, ChatGPT более вежлив, чем люди в сети.

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

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

Тут надо понимать, что обычный программист тоже не ответил бы 100% правильно на все вопросы stackoverflow. Если посмотреть ответы, там иногда такая дичь попадается, что диву даёшься.

Stackoverflow выруливает потому, что много людей вычитывают код. Т.е. бажный код + код ревью = правильный ответ (и то не всегда, мягко говоря)

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

Написал статью на Хабр

https://habr.com/ru/companies/karuna/articles/816677/

Новость не новая, но интересная.

Любопытное заявление сделал гугл. Они утверждают, что на Rust писать код в 2 раза быстрее, чем на C++

А команды, перешедшие с Go на Rust, пишут примерно с той же скоростью.

В последнее трудновато поверить, честно говоря

Точняк

Человеки
Бич любой более или менее большой корпоративной системы – канцелярщина. По звонку люди перевоплощаются в должности. В роботов с бейджиками «специальный специалист». И всё: коммуникация в этот момент превращается в полосу препятствий.

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

Специалист по всему говорит абстракциями, многословен и витиеват: он скрывает свою бестолковость. Ситуация критическая. Всем срочно нужна инъекция человечности.

Однажды, мне в команду упала задача с невнятным описанием. Заказчик оказался как раз таким энтерпрайзным (и ненужным) винтиком. Мы обсуждали и обсуждали, много часов. Столько текста. Столько слов было сказано и всё ради того, чтобы выяснить, что никто ничего не понимает и не знает, а заказчик вообще не автор, а просто рупор чужого потока сознания. Не тот, с кем надо говорить, просто он мастерски это скрывал. Это бессмысленная трата времени, так же известная под кодовым названием «работа».

Не знаешь – не знаешь. Не можешь – не можешь. Хватит казаться, достаточно просто быть, желательно быть человеком.

Чувака бомбит от того, как Uncle Bob в книге "Чистый код" рефачит программы. Боб взял несложную чистую функцию и раздербанил это на огромный класс, с мутированием полей и запутанными названиями.

Было:

private void printGuessStatistics(char candidate, int count) {
    String number;
    String verb;
    String pluralModifier;
    if (count == 0) {
        number = "no";
        verb = "are";
        pluralModifier = "s";
    } else if (count == 1) {
        number = "1";
        verb = "is";
        pluralModifier = "";
    } else {
        number = Integer.toString(count);
        verb = "are";
        pluralModifier = "s";
    }
    String guessMessage = String.format(
        "There %s %s %s%s", verb, number, candidate, pluralModifier
    );
    print(guessMessage);
}

стало:

public class GuessStatisticsMessage {
    private String number;
    private String verb;
    private String pluralModifier;
 
    public String make(char candidate, int count) {
        createPluralDependentMessageParts(count);
        return String.format(
            "There %s %s %s%s", 
            verb, number, candidate, pluralModifier );
    }
 
    private void createPluralDependentMessageParts(int count) {
        if (count == 0) {
            thereAreNoLetters();
        } else if (count == 1) {
            thereIsOneLetter();
        } else {
           thereAreManyLetters(count);
        }
    }
 
    private void thereAreManyLetters(int count) {
        number = Integer.toString(count);
        verb = "are";
        pluralModifier = "s";
    }
 
    private void thereIsOneLetter() {
        number = "1";
        verb = "is";
        pluralModifier = "";
    }
 
    private void thereAreNoLetters() {
        number = "no";
        verb = "are";
        pluralModifier = "s";
    }
}

Понятное дело, что если фанатично упарываться по какой-то идеологии, то попадёшь в ад.

https://theaxolot.wordpress.com/2024/05/08/dont-refactor-like-uncle-bob-please/

Пишете ли вы комментарии в коде?

Когда-то (100 лет назад) я писал много комментариев, пока не прочитал, что нужно просто писать нормальный код, а не объяснять его сбоку. А комментарии всё равно устареют.

Окей.

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

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

Беда лишь в том, что задачи не всегда нормально это объясняют.

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

Было бы круто, чтобы можно было писать такие специальные коменты, чтобы при каждом коммите приходилось явно подтверждать их актуальность (если код рядом с ними менялся). Вот тогда бы было идеально)

Сейчас буду набрасывать, я предупредил.

Все обсуждают статью "Go развивается в неверном направлении".
TLDR: дженерики усложнили код, но никто ими не пользуется, итераторы, которые ввели в 1.23 усложнили код, но это просто сахар для того, чтобы чуть по-другому перебирать коллекции.

Короче, я ваще не согласен )

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

Всякие там sql.Null[T] в 3d-party библиотеках тоже облегчают жизнь. Т.е. реальных проблем от дженериков на практике я не вижу, а реальная польза есть 100%.

А итераторы - это не просто синтаксический сахар, блин. Это же команда yield, временно прерывающая исполнение, и всё такое. Другой флоу вообще.

Я уверен, что будет куча мест, где можно будет заменить елдой каналы, и код станет намного проще и быстрее (потому что не надо дёргать планировщик).

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

Единственное, что плохо - это то, что надо изучить что-то новое. Ну т.е. Go хорош тем, что один раз выучил за условные выходные и потом ничего делать не надо 20 лет, не меняется ничего. Можно до пенсии спокойно писать свои микросервисы.

Короч, теперь это не так, теперь надо напрячься и раз в 5 лет изучить что-то типа дженериков или итераторов. Ну капец прям. Go всё равно в 5 раз быстрее учится, чем современный PHP, например.

Наброс закончен 🙂

Табы vs пробелы

Ни то, ни другое имхо не нужно, это всё костыли и анахронизм. Все пишут код в IDE/редакторах, ревьювят в системах с подсветкой и т.д. Никто не пишет код в чистых .txt

Давно пора сделать бинарный формат для кода.

Тогда

1) компиляция будет быстрее, можно хранить код сразу в виде AST дерева, которое целиком грузишь в память и поехали.

2) IDE с AST деревом будет работать быстрее, плюс для упрощения жизни IDE можно делать какие-то особые пометки, невидимые пользователю в редакторе

3) можно менять шрифты хоть в каждом слове, например, самые важные части программы выделить жирным красным и подчеркнутым. VeryImportantFunction()

4) юзеру не надо будет вручную вводить табы или пробелы - ide и так прекрасно знает, где отступ нарисовать.

Исключением будет только питон, так как там от отступов зависит вообще всё.

Репостну еще раз Программистику. Важная тема.

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

Не учи меня как жить

Как работать с мотивацией команды? Я знаю. А вы знаете? Руководители, которые упарываются в мотивацию, как по мне, не шарят за жизь. Я понимаю, как [пере]собрать мотивированную команду, но не имею ни малейшего представления, как мотивировать команду. Какую из задач все решают, а какую из них целесообразно решать?

Мотивация
Исходит из личных потребностей, желаний, целей и ценностей. Долговременная и устойчивая, она связанна с внутренними убеждениями и стремлениями человека. Поэтому, как правило, не требует внешних стимулов. Как и внешние стимулы, мотивация – это фактор, влияющий на поведение человека.

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

Почитать на тему:
Punished by Rewards
Why We Work

Способности
Принято разделять способности и навыки. Если упростить, можно сказать и софты с хардами, но способности точнее отражают суть. А суть в том, что ценность человека в способностях, а не в навыках. С первыми работать практически невозможно, а вторые развиваются на раз-два. Ну то есть работать то, конечно, можно, чем (чуть не сказал «успешно») тщетно и занимаются руководители, естественно, занятие это бестолковое.

Мотивация как раз относится к способностям человека. Это характеристика – мотивированный, как любопытный, интересный, токсичный, циничный или сумасшедший (тут желательна справка).

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

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

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

Короче
Будьте классным, здоровым и богатым. Как это сделать разберётесь, иначе вы не такой уж и классный, чтоб кого-то там ещё и учить. Возвращаясь к вопросу – никак. Никак работать с мотивацией.

Пост для закрепа.

В этом канале я пишу про то, что мне интересно. Чаще всего это Go, Postgres, тимлидские вопросы, общие мысли про программирование, управление проектами и всё такое.

Некоторые последние посты:

Мой плагин для редактирования OpenAPI (плагин для jetbrains IDE)

Неявное приведение типов - говно

Вся правда об IT

Перестаньте молиться на S.O.L.I.D

ИИ точно заменит программистов: один, два, три

Поставить deepseek на макбук парой команд

Возврат в офисы не окупается

Интерфейсы в Go позволяют отложить выбор

Обработка ошибок в Go - это большая ошибка

Go развивается в неверном направлении

Structured Concurrency в языке Go

Вышел Postgres 17

Большая часть ответов chatGPT неверны

Popover API работает в основных браузерах

Семантический поиск с помощью Postgres

Влияние каннабиса на способность программировать

Про фокус внимания разработчиков и тимлидов

ORM для реальных приложений не окупается


Подписывайтесь на канал Cross Join!

В продолжение темы про код и хранение AST. Я написал на Хабр статью, и там мне в панамку накидали нехило.

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

Вот еще пара вещей на подумать:

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

2) мат формулы можно было рисовать как матформулы, многоэтажно, если ввести спец конструкцию языка/IDE для этого.

3) тесты часто прогоняют по табличным данным, чтобы проверить разные кейсы. Эти данные зачастую выглядят как массив массивов или типа того. Почему бы не сделать конструкцию "таблица" и не рисовать это юзеру в виде, собственно, таблицы

3) комментарии вида javadoc/phpdoc тоже можно прибивать к самому классу/методу и показывать только при наведении курсора, чтобы не засирать экран хернёй.

4) если упороться, то можно отказаться от файлов совсем, и приложение рисовать как некую miro-диаграмму, кружочки-стрелочки и всё такое

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

6) картинки можно эмбедить прямо в исходник и там же видеть привьюшку

7) кстати, можно комментарии снабжать рисунками, а не ссылками на доку или псевдографикой

Вот такие мысли.

Кстати, вот панамка для новой порции х%ёв:

\ /
----

Дотягивать слабые стороны или усиливать сильные?

Мне всегда казалось, что должен быть определенный баланс в жизни. Что не должно быть чего-то такого, что сильно отстает.

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

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

Есть даже такая известная поговорка «Jack of all trades, master of none». Мастер на все руки – ни в чем не мастер.

Что говорят мудрецы?
Питер Друкер в одной из своих мудрых книг говорил, что сильные стороны сотрудников важнее слабых. Приводил такой пример:
«Генерал Грант был неординарной личностью и вёл не самый здоровый образ жизни. И хотя президент Линкольн знал об этих его особенностях, он всё равно назначил этого генерала главнокомандующим, потому что из всех генералов только Грант умел спланировать и успешно реализовать военные операции. Это было удачное назначение, ставшее переломным моментом Гражданской войны. Так, Линкольн выбрал главнокомандующего за сильные качества, а не за отсутствие недостатков».

В жизни и работе
У каждого из нас есть свои сильные и слабые стороны. И я не уверен, что баланс тут вообще достижим.
А еще я не уверен, что нам нужно достигать этот баланс. Что нам нужно постоянно выравнивать все свои недостатки и корить себя, что это всё никак почему-то не получается.

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

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

И прям морально стало легче.

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

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

Если бы всё было легко, то все бы уже были счастливые, довольные, эффективные и румяные.

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

Шел медведь, видит проект горит.
Влез в него, и выгорел