Был ли прав в дискуссии

О дискуссиях и когда признавать ошибку

Отличный вопрос на софт-скиллы. Коротко: я часто был неправ, и это нормально. Главное — правильно реагировать на это.

Несколько примеров

Пример 1: Архитектурный спор

На одном проекте спорили используем ли микросервисы или monolith. Я отстаивал микросервисы потому что это модно и престижно. Мой коллега настаивал на monolith.

Я был неправ потому что:

• Команда из 5 человек, микросервисы это оверинжиниринг
• Сложность операционная (не 3 сервера, а 10+)
• DevOps и мониторинг для микросервисов требуют опыта
• Время на разработку увеличилось в 2 раза

Что я понял:

• YAGNI (You Aren't Gonna Need It) — не добавляй сложность на будущее
• Технология выбирается под задачу, не наоборот
• Мнение опытного коллеги важнее моих предположений

Пример 2: Технология базы данных

Умолял использовать MongoDB вместо PostgreSQL для проекта с аналитикой. Думал что JSON документы удобнее для гибкой схемы.

Я был неправ:

• Аналитика требует JOIN'ов и GROUP BY (SQL сильнее)
• MongoDB без индексов медленнее на 3-4 порядка
• Денормализованные документы вызвали аномалии обновления
• Откат на PostgreSQL занял месяц

Что я понял:

• Инструменты имеют сильные и слабые стороны
• "Подходит везде" обычно не подходит нигде
• Опыт в production важнее теории

Пример 3: Код ревью

На PR коллега написал асинхронный код с Promise.all вместо for loop. Я сказал что это обвязка и предложил простой для loop.

Я был неправ:

• Promise.all параллелизирует запросы
• For loop был бы в 10 раз медленнее
• Это критический path для API

Что я понял:

• Не всегда очевидное решение оптимальное
• Нужно мерить производительность
• Слушать аргументы коллег серьёзнее

Как я реагирую когда мне указывают на ошибку

// Фаза 1: Разочарование (первая реакция)
// "Но я же правильно рассуждал!"

// Фаза 2: Слушание (нужно пережить)
// Слушаю полностью без перебиваний
// Задаю уточняющие вопросы

// Фаза 3: Анализ (дома или после встречи)
// Проверяю аргументы
// Ищу метрики и доказательства
// Пересмотрю старые решения

// Фаза 4: Согласие (если правда)
// "Ты прав, я недооценил X фактор"
// "Спасибо что указал, будет опыт"

// Фаза 5: Применение (в будущем)
// Помню этот урок
// Применяю знание на новых проектах

Когда я был прав

Есть и такие моменты. Например:

Пример: Race condition в параллельных обновлениях

Остальная команда хотела использовать обычные UPDATE запросы. Я настаивал на SELECT FOR UPDATE.

-- Мой подход (правильный)
BEGIN;
SELECT * FROM accounts WHERE id = 1 FOR UPDATE;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
COMMIT;

-- Их подход (неправильный, может быть race condition)
UPDATE accounts SET balance = balance - 100 WHERE id = 1;

Я был прав:

• На нагрузке случился race condition (баланс минусовой)
• Потеря денег = критичный баг
• SELECT FOR UPDATE решил проблему

Реакция:

• Я не кричал "я же говорил!" а помогал с фиксом
• Объяснил почему это важно в production
• Добавили в чеклист code review

Как я даю feedback когда вижу ошибку

// Плохо (агрессивно)
"Это же неправильно! Ты не знаешь как работают индексы?"

// Хорошо (конструктивно)
"Интересное решение. Подумал, может быть лучше использовать индекс по этому полю?"
"Давай проверим на EXPLAIN ANALYZE, может быть я неправ?"

Признаки что я неправ в дискуссии

1. Аргументы заканчиваются — только повторяю одно и то же
2. Не слушаю контраргументы — перебиваю, не даю говорить
3. Опираюсь на "так всегда делали" — нет причины, только традиция
4. Не согласен не смотря на факты — есть метрики, но я упёрся
5. Личное на месте профессионального — делаю это о себе, а не о коде

Команда и здоровые дискуссии

// Культура которую я создаю

// 1. Код ревью — про код, не про человека
Плохо:  "Ты написал говно"
Хорошо: "Эту функцию можно упростить"

// 2. Уважение к мнению
Плохо:  "Только дурак будет спорить"
Хорошо: "Интересно твоё мнение, давай обсудим"

// 3. Опора на факты
Плохо:  "По моему опыту это правильно"
Хорошо: "В документации сказано, давай проверим с EXPLAIN"

// 4. Быстрое решение
Плохо:  "Спорим неделю, не переходим ни к чему"
Хорошо: "Давай попробуем вариант A неделю, потом оценим"

Итог

Я часто был неправ, и это нормально потому что:

• Опыт приходит через ошибки
• Новые технологии появляются быстро
• Каждый проект имеет особенности
• Я не знаю всё

Что важно:

• Быстро признавать когда неправ
• Слушать аргументы коллег
• Изучать почему решение не сработало
• Применять уроки в будущем
• Создавать культуру здоровых дискуссий

Мой девиз: Лучше быть неправым с хорошей командой, чем правым в одиночку.

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