Экстраполяция IT

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

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

https://telegra.ph/Citata-o-povrezhdenii-mozga-12-22 Открыть/Комментировать

2020-12-22 12:01:00 Писать понятный код.

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

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

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

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

2020-12-21 13:33:10 Писать идеальный код можно только одному или максимум вдвоём. Когда разработчиков много, код пишется без контроля одного сверхразума, который определяет что хорошо и что плохо и поэтому код можно сделать только «приемлемым», а не «идеальным». И важны тут две вещи: научиться жить с приемлемым, а не идеальным кодом и определять приемлемость кода без человеческого фактора. Открыть/Комментировать

2020-12-18 13:07:55 Главное умение исполнителя — умение задавать вопрос «зачем» в ответ на декларативно поставленную задачу.

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

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

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

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

2020-12-10 15:42:35 За последние десять лет программирование, как отрасль, сделало качественный скачок. Теперь это не инструмент, который решает задачи. Теперь это ещё и способ поставить задачу.

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

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

2020-12-07 12:01:00 То, что умеешь не всегда совпадает с тем, что нравится делать.

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

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

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

2020-12-03 16:54:28 Второй критерий самостоятельности разработчика — умение задавать вопросы. И если в декларативно-императивном критерии были две стороны медали и надо было искать золотую середину, то тут всё сильно проще — вопросы надо уметь задавать.

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

— В формулировке вопроса есть вопросительное предложение, а не только повествовательные.
— В формулировке вопроса есть не только сам вопрос, а ещё и контекст в повествовательной форме.
— Фраза «я не могу» и «у меня не получается» идёт не первой.
— Отсутствует хронология ваших действий.

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

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

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

2020-11-30 13:00:35 Есть два очень хороших критерия определения самостоятельности разработчика.

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

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

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

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

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

2020-11-27 16:23:00 Недавняя переписка в чате домоуправления (осбб) натолкнула меня на один вывод. Дело было так.

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

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

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

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