Когда в руках микроскоп, всё вокруг кажется гвоздями.

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

Человек не в состоянии понять какой инструмент подходит лучше, пока он о нём не узнает. У разработчиков это явно прослеживается, но это касается вообще всех. Менеджер проблемы разработки будет решать, добавляя новые отчеты и метрики. Тестировщик вспомнит о новом виде тестирования. Эйчар начнёт искать супер-пупер сеньора. Директора начнут добавлять еще одного Хэд-Оф-Что-то-там. Разработчики будут автоматизировать еще не автоматизированное.

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

Особо страшно становится, когда появляются инструменты, которые одинаково плохо решают вообще все задачи, вроде Экселя. Более-менее освоив эксель (или гугловы спредшит), все проблемы начинают казаться просто набором табличек с формулами.

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

И вот, в процессе написания такого письма, к каждому критерию приходится мысленно придумывать контраргументы. Их в общем и целом только три.

Первый — это когда «твоя работа в этом и заключается»:

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

Второй контраргумент — «это не твоё дело».

— Я тут инициативно сделал вон то, теперь соседний отдел доволен.
— Это была не твоя работа.
— Я организовал митап и теперь все коллеги стали образованнее.
— Компании это вообще не интересно.

Третий — «этого не достаточно». Понятно без примеров.

Примечательно, что эти контраргументы не оспариваются вообще. Хуже этого письма может быть только письмо о том, что ты увольняешься.

———
Эксперимент: тема зарплат продолжится другими постами, если наберется суммарно 100 любых реакций под этим постом.

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

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

Из вышесказанного естественным образом вытекает простое следствие.

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

Скажем, ваша зарплата $1000 и вы хотите 10% повышения. Работодатель знает, что найти вам замену можно за месяц и еще месяц уйдет, чтобы освоиться новому сотруднику. Отказав вам, вы начнёте искать работу и будете её искать где-то месяц. Получается, уволить вас будет стоить $2000, а повысить вам зарплату будет стоить $1200 в год. Значит руководству выгоднее повысить зарплату, чем лишиться вас.

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

Продолжаем про зарплаты и повышения.

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

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

У этого «честного» поминутно тарифицируемого подхода лишь одна проблема — критерием успешно проведённого дня будет считаться количество отработанных часов. Типа, «я сегодня молодец, отработал 8 часов».

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

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

Привет, ребята.

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

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

Тут знакомые зарелизили один полезный инструмент. Помогает группе людей определиться со временем при организации ивента.

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

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

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

#dimoneverything

Закончить ремонт нельзя, ремонт можно только остановить.

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

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

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

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

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

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

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

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

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

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

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

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

Есть два очень хороших критерия определения самостоятельности разработчика.

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

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

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

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

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

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

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

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

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

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

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

То, что умеешь не всегда совпадает с тем, что нравится делать.

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

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

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

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

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

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

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

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

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

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

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

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

Писать понятный код.

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

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

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

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

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

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

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