Barba non facit philosophum
В начале десятых был такой популярный сайт, «Девелопер ответит» с типичными фразочками разработчиков, было забавно почитать. Можете посмотреть скриншоты в этом альбоме ВКонтакте.
В этой статье я тоже займусь стереотипными фразочками программистов, постаравшись объяснить, что же они на самом деле означают. Возможно, эта статья, как про замуж за айтишника, полна стереотипов и проекций личного опыта, но она может помочь вам избежать проблем на проекте.
Ну, не знаю, у меня на машине всё работает
Во-первых, скорее всего, врёт. Если не врёт, он настроил некое специфическое окружение, в котором софтина, действительно, работает. Раньше вокруг этой фразы часто возникали конфликты разработчиков и тестировщиков, но после появления Докера, возникла возможность передавать на тестирование сконфигурированный образ с настроенным окружением и проблема решилась.
Ещё может быть, что у разработчика ноут мощнее некоторых серверов и он прям не экономил на использовании ресурсов. На стандартных же восьми гигах оперативы, это всё не работает вообще или тормозит.
* * *
Да у них просто «Винды» кривые
Сейчас распределение операционных систем выглядит так:
Windows — 68,15 %
macOS (OS X) — 21,38 %
Chrome OS — 4,15 %
Неизвестно — 3,23 %
Linux — 3,08 %
FreeBSD — 0,01 %
Как видите, у большей части мира либо кривая винда, либо кривой макос. При этом системное и прикладное ПО других производителей как-то работает. Как говорили в СССР, дело было не в бобине.
* * *
Попробуйте перезапуститься. Думаю, всё заработает
Это больше любит техподдержка. Классическая депрессивная триада:
- Попробуйте почистить кэш браузера1.
- Попробуйте перезагрузить компьютер. И роутер. И пробки в квартире выключите и включите.
- Попробуйте вставить интернет-кабель напрямую в сетевую карту. На макбуках уже лет десять, как нет сетевых карт? Ну, тогда я не могу вам помочь2.
Техподдержка макоси ещё любит потребовать создать новую чистую учётную запись и попробовать повторить баг на ней.
В целом, да, перезагрузка часто помогает. Хуже точно не будет. Но разрабатываемый софт должен уметь самовосстанавливать сессии без глюков и перезагрузок не требовать.
* * *
Как дела в проекте? Работа ведется!
Видел пост чувака, который где-то в эмиграции снимает квартиру с четырьмя разрабами, работающими в разных конторах, которые с утра, в разное время, отчитываются о своей работе абсолютно одинаковыми словами. Выглядит и звучит как лагающая «Матрица».
В целом, да, устойчивые выражения есть не только у всех школьных учителей, но и у разработчиков. Писал модуль, отлаживал, правил баги, пояснительную записку ещё не писал.
В целом, да, бывают ситуации, когда надо покодить без отрыва и без промежуточных результатов несколько дней3. Но в целом, надо бить на подзадачи, чтобы был виден прогресс. Ещё может быть такое, что разраб (характерно для джунов) упёрся в техническую сложность, но не хочет или боится сообщить об этом, чтобы его не посчитали дураком и бьётся в стену. Лечится политикой декриминализации эскалаций.
* * *
Я уже неделю ночами работаю, а вы меня укоряете за срыв срока
Скорее всего, он работает не сутками, у него просто сбился режим, а на деле кодит всё те же 4-6 часов. Решайте сами, критично ли вам присутствие программиста в утреннее время или пусть лучше разрабатывает, когда ему удобно, а с утра отсыпается. Не работает, если группа разрабов пишет код с зависимостями и им надо синхронизироваться.
Ну и при грамотной организации оценки и работ, переработки должны быть исключением, а не правилом4.
* * *
Маркетологи задолбали
Запросы от техподдержки — голос существующих пользователей. Запросы от маркетинга и сейлзов — запросы пользователей потенциальных. Да, они не понимают в технологиях и не ценят красоту инженерных решений, им нужны приземлённые фичи, которые можно продать пользователям.
Здесь можно напомнить разрабам, что их, весьма приличная зарплата, берётся не из воздуха, а из продаж и игнорировать их запросы нельзя.
* * *
Совещания задолбали
Увы, такова судьба тимлида, техлида и большинства сеньоров — к сожалению, изрядную часть дня на их экранах будет не IDE (c тёмной темой), а окошко видеозвонка. Мидлов и джунов лучше от совещаний оградить, пусть занимаются любимым делом.
Кроме того, как писал выше, если люди создают связный код с зависимостями, им необходимо единое информационное поле, поэтому хотя бы разок в день лучше созвон с дейли таки провести.
* * *
Чего там планировать, я быстрее сделаю и всё уже будет работать
Скорее всего, не будет, а если будет, то не так как надо и с кучей багов, которые придётся долго и нудно править. В нормальном универе будущего разработчика учат сначала вдумчиво проектировать, рисовать схемы, планировать и только потом садиться бомбить код.
Проектирование — наше всё.
* * *
Планировать сроки бесполезно. Наша работа больше похожа на НИОКР, предсказать сроки невозможно
Нет, на НИОКР похож ничтожно малый процент работы. Для большинства айти-проектов, всё прекрасно планируется и предсказывается. Нужно только не забывать этой оценкой управлять, своевременно пересогласовывать и вносить правки в планы.
А вот на стадии планирования, действительно, может быть изрядное количество исследовательской работы. У меня был проект по маркировке, в котором сначала нужно было убрать неопределённость — выяснить, как устроены процессы сейчас. Но даже в нём мы планировали, предсказывали и соблюдали дедлайны.
* * *
Если решить не только конкретную задачу, но и весь класс подобных задач, мы получим продукт, который можно будет продавать
Почитайте мою старую статью про тьюрингову трясину. В общем, тоже нет. Любая проблема является представителем класса более общего класса проблем. Любой класс проблем является подклассом более общего класса проблем, предела, вершины нет. На деле, разработка такого универсального продукта выйдет сильно дороже решения конкретной, существующей задачи.
Кроме того, нет ничего хуже, чем выпустить отличный, но ненужный рынку продукт. Тут нужны маркетинговые исследования от маркетологов, которые задолбали и ничего не понимают в технологиях.
* * *
К пятнице готово не будет, но в понедельник — точно. Или во вторник
Скорее всего, во вторник не будет. А если и будет, то только ограниченный набор сценариев и только на машине разработчика, без юнит-тестов и документации. Разработчикам свойственно недооценивать сроки. Бороться с этим можно при помощи настойчивости и буферизации.
Вообще, оценка сроков — отдельная дисциплина в проектном менеджменте.
* * *
К сроку не будет готово, потому что жёсткий диск съела собака. И сгорела
Опять школьные отмазки. Пункт потерял актуальность после внедрения гита. Требуйте регулярно коммитить небольшие порции кода и проходить код ревью, тогда с этим не столкнётесь.
* * *
Код самодокументирован и самоочевиден
Нет, это тоже враньё, девелопер ленится. Уже через пару месяцев никто не поймёт, что этот код делает, включая самого автора5. Комментарии в коде должны быть, но и техническая пояснительная записка — обязательная часть документации проекта. Писать доку не менее важно, чем код, иначе поддерживать этот код будет невозможно.
- Кстати, в изрядной доли проблем с веб-приложениями, трабл связан с тем, что некий элемент криво закэшировался и очистка кэша реально может помочь. ↩︎
- Кстати, если вам не нравится оператор техподдержки, вполне рабочий лайфхак — тупо положите трубку и дозвонитесь ещё раз. Скорее всего, попадёте на другого оператора, если компания не совсем днищенская. ↩︎
- Помните, как в «Кремниевой долине» герои наняли хакера по кличке «Резчик», чтобы он им сделал важную фичу за ночь, а тот, оставшись без аддералла, всё запорол? Чаще всего, этим ночные бдения и заканчиваются. ↩︎
- Написал человек, набирающий статью в половине четвёртого ночи из-за бессонницы. ↩︎
- Я ненастоящий программист, но время от времени вношу правки в стили этого сайта при помощи вордпрессовского инструмента внешнего CSS. Всегда комментирую каждую инструкцию, потому что реально не могу вспомнить, что они делают, несмотря на то, что код предельно простой. ↩︎
