Плюсовики токсично шутят )

https://twitter.com/0xfe0d/status/1370990926198411264?s=09

"Знание некоторых закономерностей освобождает от необходимости знать некоторые факты"

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

Коль скоро вы можете схватить суть кода и фреймворка, который вы используете - вы можете схватить суть и своего проекта. На практике это поможет осознать что, скажем, в данном конкретном случае можно обойтись одним php-файликом, а не городить конфиг вебпака на 50 экранов и поднимать кубокластер.

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

Как-то так.

(С) Pavel Novikov ( https://twitter.com/reinforced_sc )

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

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

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

Самый плохой эффект, который я видел - это эффект "срезания" премий. Т.е. если ты получил премию в этом месяце, и не получил в следующем, то это воспринимается ровно как штраф. Штраф выбивает из колеи и демотивирует так, что дальше некуда.

Всякие там звания "сотрудник месяца" - это вообще смешно в 99% случаев. Не видел, чтобы это работало.

Единственное, что можно сделать, чтобы сотрудник начал хорошо работать - это поработать с внутренней мотивацией. Убрать режим концлагеря: бессмысленные требования, премии/штрафы, навязанные сверху технологии (например, "пишем только на php и не ебёт"), жесткий график работы, токсичных коллег, говнокод.

Надо прислушиваться к мнению, относиться с уважением, дать максимальное количество полномочий (доступ к проду, принятие более менее ключевых решений без особого апрува), короче, чтобы проект воспринимался, как что-то личное.
Программисты идут в программирование, потому что им нравится программировать. Да блин, невозможно изучить (и продолжать изучать) СТОЛЬКО информации из под палки. А значит, надо лишь не мешать, убрать всё плохое. Построить процесс без стрессов.

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

В Chrome 90, который выйдет уже вот-вот, сделают автоматическое добавление https к адресу сайта, если не был указан протокол (при ручном вводе в строке браузера).

Это приведет к тому, что куча сайтов покажет 404 страницу. По разным оценкам больше 15% сайтов не настраивали себе https и не собирались.

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

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

Т.е. понятно, что letsencrypt настроить не так уж сложно, однако насильственные действия корпорации напрягают.

Прикольный сайт. Рассмотрены категории проблемных людей в разработке софта (там и разработчики, и qa, и менеджмент), и описано как с ними взаимодействовать.

Полезно примерить некоторые роли на себя и сделать выводы

https://www.howtodeal.dev/

Есть один канал, называется "Тимлид Очевидность", его ведет Женя Антонов (известная личность в узких тимлидских кругах). Там рассказывается о вещах, которые по идее должны быть очевидны любому тимлиду, но в этом и есть свообразная хитрость. Очевидное становится невероятным, когда его четче вырисовываешь в мозгу и обдумываешь.

К примеру, его пост про прозрачность и доверие: https://news.1rj.ru/str/general_it_talks/78

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

В общем, всем тимлидам и интересущимся крайне рекомендую канал. И надеюсь, что Женя еще раз придет к нам в подкаст, и расскажет что-нибудь интересное )

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

Обещал когда-то написать про системный подход.

Ну так вот, давайте поговорим про kpi рядового программиста. Ооочень часто пытаются определить работоспособность сотрудника по каким-то показателям типа "Петя закрыл 20 задач в месяц, а Вася 10", значит Петя хороший, а Вася плохой. Или интуитивно: "Петя херачит как не в себя, а Вася, по-моему, последнюю неделю хуи пинал".

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

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

Допустим у бизнеса есть суперважная задача1 и неважная задача2. Если суперинтенсивно работать над задачей2, то системе возможно станет только хуже. Потому что человек, интенсивно работающий над этой ерундой, с некоторой вероятностью будет дергать других людей: тимлида, админов, тестировщиков, дизайнеров и т.д. (зависит от проекта). Тем самым отвлекая их от важной, прибыльной задачи, перегружая всем мозг, забивая календарь ненужными митингами.

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

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

И вот только если Вася взял суперважную задачу, понимает её важность и при этом нихрена не делает, только тогда Вася мудак, не раньше. Скорее всего такого надо тупо увольнять.

Всё это настолько контринтуитивно (что ничегонеделание может помогать приносить ценность), что почти никогда не принимается в расчет. Да и сложно это нормально оценить. Один совет в курилке может быть более ценным, чем неделя программирования - как ты это увидишь на перформанс ревью?

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

Вчера в репозиторий php попало сразу 2 бекдора, причем от имени создателя PHP Расмуса Лердорфа и небезызвестного core-разработчика Никиты Попова.

Подозревают, что сервер git.php.net скомпроментирован.

В итоге решили отказаться от собственного гит-репозитория, и перейти полностью на Github (раньше гитхаб был лишь зеркалом)

Самый большой список источников для изучения языка Rust (книги, статьи, видео, подкасты, блоги, стримы, упражнения и тд)

https://loige.co/where-to-go-to-learn-rust-in-2021/

У меня есть одни слова от автора @ZeroBias эффектора на тему почему появился effector и какие его плюсы.

Децентрализованность, декларативность, эффективность. Требовался инструмент, позволяющий управлять данными в сложных приложениях без опасности раздуть монолитный центральный стор, с явным control flow, нормальной типизацией и емким апи.

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

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

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

Возможность, место, и способ вынести любую требуемую бизнес-логику из view, максимально упрощая компоненты.

Независимость от спорных концепций — никаких декораторов, никаких зависимостей от реакта/rxjs либо необходимости юзать классы или прокси — ничего из этого не требуется для управления состоянием приложения и поэтому api библиотеки использует только функции и простые js объекты.

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

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

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

Благодаря дженерикам в Go наконец-то можно будет написать универсальную для всех типов (ну, почти) функцию поиска элемента в списке. Что-то типа такого:

func find[T comparable](s []T, w T) int {
for i, v := range s {
if v == w {
return i
}
}
return -1
}

Мелочь, а приятно

Андроид делает ставку на Rust

https://9to5google.com/2021/04/06/android-rust-language-support/

Ночью не спалось что-то, в голову лезли мысли про тестирование.

Вот есть, например, код (допустим микросервис с http-эндпоинтами), и к нему написаны какие-то тесты. Уверен ли я, что тестов достаточно? Могу ли я серьёзно отрефакторить код и быть уверенным, что ничего не поломал?

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

Но с другой стороны, покрывать всё тестами на 100.0% (например, анализируя через мутационное тестирование) - слишком дорого. Действительно, зачем покрывать ветки кода, где, например, в случае ошибки при отправке тела ответа сервера, в лог пишется какой-то текст. Ну пишется и пишется, что там тестировать. Особенно, если это некритичная часть системы.

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

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

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

Таким образом, всякая херня не будет тестироватсья никогда - и слава богу. А сверхважные денежные куски кода будут покрыты тестами на 146%

Вот такие у меня эротические фантазии по ночам

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

«Эффект велосипедного сарая» — bike-shed.

«Эффект велосипедного сарая» или «закон тривиальности Паркинсона» был сформулирован Сирилом Норткотом Паркинсоном в 1957 году. Он привел в пример совещание на атомной электростанции, на котором большую часть времени участники потратили на обсуждение мелких и простых для понимания вопросов, таких как цвет велосипедного сарая, а не конструкции самой электростанции. Как объяснил инженер Карл Фогель, «время, потраченное на обсуждение пункта, обратно пропорционально его сложности и важности».

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

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

Вот и получается, что люди интуитивно или по своей лени идут по более простому пути. Хоть это и контрпродуктивно

Что с этим делать?
Знать об этом явлении. Всегда об этом помнить. Стараться вовремя возвращать на путь важных и продуктивных обсуждений себя и помогать вернуться другим.

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

Однако сознательность и дисциплина помогут сначала конкретному человеку, а педагогика и просвещение со стороны этого человека помогут всему коллективу.

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

Покажите этот пост коллегам, которые страдают байкшеддингом.

Полное (даже слишком) описание фич Postgresql 14.

Никакой революции нет, но возможно какие-то отдельные вещи, связанные например с партициями или рекурсивными CTE вам могут пригодиться

https://m.habr.com/ru/company/postgrespro/blog/550632/

Кратко о канбан-методе, сумбурный набор тезисов.

1) Канбан-метод и канбан, который в Тойоте - это два разных канбана.

2) Канбан-метод, в отличие от скрама, не является набором конкретных жестких правил и инструментов. Это скорее набор принципов и рекомендуемых практик

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

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

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

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

5) поэтому вторая обязательная практика - это ограничение количества задач, одновременно взятых в работу (wip-лимит). У десяти программистов всего десять голов, они не могут делать 100 задач одновременно. Стоит поставить разумный лимит на количество одновременно выполняемых работ, это существено уменьшит lead time, существенно увеличит предсказуемость поставки и даже улучшит самочувствие разработчиков и лидов. Программисты не будут переключаться с задачи на задачу, лид будет полностью понимать, что происходит в его отделе.

6) Когда количество задач ограничено, придется построить процесс, который позволяет понять, какую задачу брать следующей, когда освободилось место. Заказчики (product-менеджеры) должны между собой договориться, какая задача сейчас важнее.

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

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

9) WIP- лимиты вообще не зависят от размера задач. Это количество одновременно разрабатываемых задач, только и всего. Не путать со скрамом и списком задач на спринт.

10) идеально использовать "вытягивание". Т.е. только когда освободилось место (задач в работе меньше, чем WIP-лимит), брать новую задачу у продактов. Но в реальности продакты не могут работать "по вызову" и собираются время от времени, чтобы сформировать небольшой список актуальных задач, из которых разработчики будут брать задачи, когда освободятся руки. Размер этого буфера зависит лишь от частоты, с которой продакты собираются и изменчивости рынка

Написал тред-ответ на твит, что микросервисный подход - говно.

https://twitter.com/AntonOkolelov/status/1385528227687510018