🧠 Разработчик vs исполнитель кода: почему думающий специалист ценнее
Недавно наткнулся на интересный спор в комментариях под статьёй о профессионализме. Два противоположных подхода к работе:
Позиция А: "Если ТЗ составлено нечётко — не буду делать задачу, пока не уточнят все детали"
Позиция Б: "Это низкая квалификация. Чем такой разработчик отличается от GPT, которой дай чёткое ТЗ — и она всё сделает?"
Звучит как холивар, но давай копнём глубже.
Проблема обеих крайностей
Представь: к работяге приходит мастер и говорит "сделай балку".
Он молча берётся за работу. Через два часа мастер возвращается: — Ну что? — Вот, сделал.
А он просто металл с двух сторон обрезал. Технически — всё по ТЗ. Но балка не выдержит нагрузку и рухнет.
Работяга не уточнил: - Какая нагрузка? - Где будет использоваться? - Какие требования к прочности?
Голову не включил. Зато формально ТЗ выполнено ✅
А теперь обратная ситуация
Разработчик получает задачу: "Добавь кнопку для экспорта данных"
И говорит: "ТЗ неполное, не буду делать. Напишите мне: - В каком формате экспорт - Какие поля выгружать - Какой дизайн кнопки - Где она должна быть - Как должна называться"
Формально — профессионально. Но на практике — он просто перекладывает свою работу на менеджера.
Потому что ты эксперт. Ты видишь систему, знаешь контекст, можешь предложить решение.
Что делает инженер?
Получает задачу "добавь экспорт" и:
1. Анализирует контекст: какие данные уже есть, как организована таблица, что экспортируют конкуренты 2. Задаёт правильные вопросы: "Я вижу три варианта — CSV, Excel и JSON. Для отчётности лучше Excel, предлагаю его. Окей?" 3. Предлагает решение: "Кнопку логичнее разместить над таблицей справа, рядом с фильтрами. Так делают в админках" 4. Думает о крайних случаях: "А если данных 100к строк? Добавить асинхронную выгрузку?"
Видишь разницу?
Ты не просто ждёшь идеального ТЗ. Ты включаешь голову, предлагаешь, уточняешь. Истина посередине
Менеджер не всегда технически подкован. Он может не знать про лимиты браузера, производительность, паттерны UX.
Ты как эксперт можешь и должен: - Видеть проблемы, о которых менеджер не подумал - Предлагать улучшения на основе технического опыта - Говорить "нет", когда сроки нереальные (да, это тяжело 😄)
Но делать это нужно конструктивно: - Не "ТЗ хуёвое, переделывай" - А "Вижу три риска в этом подходе. Предлагаю альтернативу..."
В итоге
Разработчик высокой квалификации — это не тот, кто слепо выполняет ТЗ. И не тот, кто отказывается работать без идеальной спецификации.
Это тот, кто думает системно, задаёт вопросы, предлагает решения.
Как говорят бизнесмены — win-win. Все в плюсе: - Продукт получается лучше - Менеджер видит твою ценность - Ты растёшь как специалист
Не будь камнем. Идти на контакт, видеть проблемы, говорить о них — вот что отличает инженера от исполнителя кода.
А как ты подходишь к задачам? Делишься мыслями в комментариях 💬
· 17.12
В примере с заводом виноват 1 человек - мастер. Мастер это связующее звено между проектировщиками и рабочими. Именно он получает всю полноту рабочей документации, планирует сроки и распределяет рабочую нагрузку.
А получив от инженеров задачу "сделай балку", он должен уклончиво послать их за чертежом.
Если же ситуация складывается так что балка нужна срочно, и на проектирование времени нет, то мастер (зачастую вместе с инженером которому эта балка нужна) спускаются в цех и рисует схему/натурно показывают как балка должна выглядеть.
Кроме этого, рабочий объективно не может уточнить нагрузку и прочее в силу отсутствия понимания где эта балка будет использоватся и сопутствующих этому инженерных расчётов. И мастер тоже к этой информации доступа не имеет
ответить
коммент удалён