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

Итак, история о поврежденном мозге.

https://telegra.ph/Citata-o-povrezhdenii-mozga-12-22

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

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

2. Любая дискуссия о качестве кода должна быть о нарушении правил или о расширении набора правил. «Вот так вот лучше» с куском кода в комментариях к пулл реквесту писать нельзя.

3. Любую задачу можно решить несколькими способами.

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

Главное умение исполнителя
- умение задавать вопрос «зачем» в ответ на декларативно поставленную задачу.

Худшее, что может сделать разработчик
- сделать то, что его просят и не понимать зачем это нужно.

Худшее, что может сделать постановщик задачи
- ответить «просто сделай и всё».

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

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

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

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

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

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

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

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

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

- В формулировке вопроса есть вопросительное предложение, а не только повествовательные.

- В формулировке вопроса есть не только сам вопрос, а ещё и контекст в повествовательной форме.

- Фраза «я не могу» и «у меня не получается» идёт не первой.

- Отсутствует хронология ваших действий.

Не зря говорят, что правильно заданный вопрос
- это половина решения.

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

Главное правило написания таких вопросов
- начать с конца и думать какие наводящие вопросы собеседник задаст и отвечать сразу и на них.

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

Обратная сторона медали подхода
- некомпетентность. Её очень часто вменяют менеджерам, которые не разбираются в том, чем управляют. Типа, «нужно вот тут добавил дропдаун с вот такими значениями», вместо объяснения зачем это вообще надо и какую проблему оно пытается решить, чтобы найти самое

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

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

К слову, этот пост есть демонстрацией объединения этих подходов.

Недавняя переписка в чате домоуправления (осбб) натолкнула меня на один вывод. Дело было так.

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

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

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

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

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

Расскажите что думаете анонимным лайком или неанонимным текстом в чатике. Приятного чтения.

https://docs.google.com/document/d/1AGrvIggFFpCyzaUaW3vGO3umrO6e576Jsdt5Jk8vwqM/edit

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

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

И вывод наоборот. Если фичу пользователи очень сильно хотят и просят, то совершенно неправильным будет давать её в полном объёме со всеми возможными случаями использования. Начать надо с чего-то мелкого и целостного. Чтобы уже можно было бы пользоваться, но пользователи бы продолжали простить улучшения.

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

#dimoneverything

Помогает группе людей определиться со временем при организации ивента. Он не подходит для случаев, когда есть список четких опций. Но в ситуациях, когда надо просто собраться все равно когда и все равно во сколько, но главное
- чтобы вместе, инструмент подходит идеально:https://letmeknowwhen.space/

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

Вдруг кто-то из чатика захочет или знает кого-то, кто захочет сверстать лендос в качестве разового субподряда. Если что, мне в личку.

Спасибо, всех обнял.