Притча про Программиста и Калькулятор

Все, что написано здесь, было опубликовано раньше в Телеграм-канале “Продуктивный Игнат”.

Если вы на него подписаны, то скорее всего нет большого смысла читать дальше: я пока не понял, что тут в Медиуме с форматированием текста, а еще в статье нет ни одной картинки

Притча

Много-много лет назад пришел молодой программист к Мастеру и говорит:

Мастер, этот калькулятор, который я написал, работает неправильно. Если число поделить на ноль, он покажет в результате -1. Это известная проблема, ее уже чинят другие программисты.
Но после деления на ноль появляется несколько других багов. Например, умножение любого числа на 7 дает 184, а отрицательные числа вообще перестают отображаться.
У меня есть пара идей, что может быть не так с семерками, плюс я собрал логи с пользовательских компьютеров, чтоб воспроизвести и подебажить, что если мы …

Тут Мастер перебил его и говорит: “а баг с делением на ноль еще не починили, да?”
“Еще нет”, — отвечает программист.

Тогда Мастер снова отвернулся к монитору и больше не отвечал. А в Слаке у программиста (ну или чем там все пользовались в то время) появилось сообщение: “вот когда починят, тогда и приходи, а сейчас займись чем-нибудь полезным”.

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

Мораль №1

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

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

Пример:
Программисту изменила жена и ушла от него. Он в депрессии, работает плохо, допускает очевидные ошибки.

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

Хорошее решение: узнать причину проблемы, если это возможно. Собрать выездной тимбилдинг в подъезде в Текстильщиках, написать всем вместе в лифте “Катя — шлюха”

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

Мораль №2

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

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

На это можно возразить: “чем писать письмо, быстрее дойти до человека ногами, в одном опен-спейсе сидим”. Если как раз эта мысль сейчас у кого-то в голове, знайте — это был квик-тест на уровень эгоцентризма.

Можно продолжить:
1. Прибавьте один балл, если аудиосообщения лучше текста, потому что “так быстрее и зачем я вообще что-то руками набирать буду, пусть в метро без наушников динамик к уху приложит и слушает, вдруг там что-то важное”
2. Прибавьте еще три, если наушники в ушах человека это индикатор того, что нужно громче кричать, ведь он может что-то не услышать

Да, я знаю что все люди разные и что
1. кто-то думает, когда говорит
2. кто-то думает, когда слушает
3. кто-то заряжается энергией от общения с другими людьми
4. кто-то не умеет читать
5. и когда эти четверо встречаются вместе, происходит химическая реакция и к концу первых пятнадцати минут им не хватает стены чтобы записать все новые идеи, которые им пришли в голову

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

— Слушай, а ты не задумывался, почему кузнечик называется кузнечиком? Это же как кузнец, только маленький да? В песне вообще поется “И съела кузнеца”. Какого нафиг кузнеца?

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

Скорее всего он скажет “не знаю” и отвернется.
А потом полезет в гугл искать этого кузнечика, потому что какая уж тут теперь задача.

Мораль №3

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

Называется он “Работа над задачами с неопределенной спецификацией”.

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

В общем, критерии такие:
1. Велика вероятность того, что результат будет никому не нужен и пойдет на свалку.
Это означает, что можно строить какие угодно воздушные замки, пробовать миллион новых архитектурных решений, все равно до проверки дело не дойдет, а времени может уйти ого-го сколько, задача-то сложная
2. Велика (100%) вероятность того, что все очень резко поменяется в процессе и добавятся новые детали
Это означает, что можно строить какие угодно воздушные замки, пробовать миллион новых архитектурных решений, все равно можно потом сказать: “ну что же вы сразу не сказали, что кнопки синие, а не красные, теперь всю архитектуру переделывать надо, спецификация поменялась, сами понимаете”
3. В начале проекта ставится задача на исследование чего-нибудь
Это означает, что можно 80% времени планировать это исследование, 20% времени поднимать окружение (если проект новый, то и технологии новые, а эту библиотеку ты попробуй еще установи), а потом удвоить эстимацию, потому что “ну это же исследование, как его вообще можно эстимировать”.
Результатом такого исследования чаще всего бывает ответ: “ну вроде все сделать можно, эстимировать пока нельзя, так как окончательное ТЗ еще не готово, как будет готово надо будет еще поисследовать

Однажды кто-то из моих коллег сказал: “Если долго сидеть на берегу реки, можно увидеть, менеджера, который закрывает задачу как неактуальную”.

Это применимо как к борьбе со внутренним пинателем болта на работе, так и к притче выше — перед решением задачи неплохо бы убедиться, что:
1. Ее надо решать
2. Ее надо решать сейчас
3. Сейчас надо решать именно её

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