Я работал программистом более пяти лет. Не особо впечатляет, ведь кто-то из вас, вероятно, имеет в три раза больший опыт, но мне нравилось думать о себе как о сениор-разработчике. Звучит серьёзно и солидно, правда?
Однажды мне предложили стать Chief Technology Officer (CTO) в медтех-стартапе. Поработав некоторое время на этой новой должности, я могу обернуться назад и сказать, что не был сениор-разработчиком. Не поймите меня неправильно — я по-прежнему считаю, что обладаю отличными знаниями программирования, особенно веб-разработки; но если это так, почему я не думаю, что был сениором?
Всё это из-за четырёх заблуждений, которые у меня были.
Пользователь (?)
1. Пользователь — это идиот
Нет, он не идиот.
Да, пользователи работают с приложением неожиданными, часто странными способами.
Да, пользователи могут задавать вопросы, которые кажутся по-настоящему глупыми.
Да, иногда пользователи просят добавить функции, которые кажутся бессмысленными.
Да, пользователи испытывают трудности с функциями, которые кажутся понятными сами по себе.
Пользователь — не специалист. Мой врач не требует от меня, чтобы я знал отличия между липопротеинами низкой и высокой плотности. Так почему я привык предполагать, что пользователь знает, каким браузером он пользуется? Это очевидно вам и мне, но моя мама считает, что Google и Интернет — это синонимы. Она бы сказала, что не пользуется никаким браузером, потому что использует Google.
Иногда чтобы удовлетворить пользователя мне нужно было переопределять части фреймворков для изменения их стандартного поведения. Иногда мне приходилось добавлять поддержку браузеров, которые я поддерживать не хотел (привет, пользователи Safari). Сегодня это кажется мне глупым, но в то время я действительно думал, что если мне приходится создавать в своём коде обходные пути для удовлетворения требованиям клиента, то в этом виноват клиент.
Выбираем самое лучшее имя для переменной.
2. Мой код — это произведение искусства, и он должен быть идеальным
Чистый код, юнит-тесты, отличная документация — это, без сомнения, важно. Я как программист всегда стремился писать чистый код с использованием современных паттернов, часто проверял актуальность всех зависимостей в проекте и т.п. Я хотел быть Хорошим Программистом.
Когда мой менеджер по продукту попросил отказаться от юнит-тестов, чтобы увеличить скорость разработки, я испытал гнев — разве он не понимает, насколько важны юнит-тесты? У нас не было никакого автоматизированного тестирования, поэтому юнит-тесты оставались единственной надеждой на обеспечение стабильности и отсутствие регрессий в продукте.
Это решение показалось мне недальновидным. Кроме того, он рекомендовал перестать писать документацию и преобразовать код в менее сложную архитектуру (мы могли это сделать, потому что находились в самом начале проекта).
Да, я согласился, что это в какой-то степени ускорит разработку, но был уверен, что это грозит кучей проблем в будущем. Мы потратим кучу времени на устранение регрессионных ошибок, а новая архитектура окажется слишком простой, когда масштаб проекта начнёт расти! И как мы будем знакомить новых программистов с проектом без хорошего readme?
Мы часами обсуждали то, насколько плохо это решение, и сколько оно будет стоить нам в будущем.
Этот проект завершился провалом спустя несколько месяцев, потому что значительно превысил бюджет.
Годы спустя я вынужден признать правду: наша команда совершила огромную ошибку. Мы думали о будущем и позабыли о настоящем. Мы совершенно игнорировали обстоятельства — ограниченный бюджет и необходимость создания MVP за короткое время.
Разумеется, замечательно писать код, который ты можешь показывать другим и гордиться. Но ещё лучше успешно завершать проекты. В конце концов, программирование — это не искусство.
Отношение моей старой команды к пробованию чего-то нового.
3. Я буду использовать для этого проекта «X», потому что знаю его
В моей предыдущей компании мы создавали каждый проект с одинаковым технологическим стеком: Symfony и Angular. Почему? Является ли Symfony лучшим бэкенд-фреймворком? Нет. Может быть, Angular — единственный способ создания современного фронтенда? Нет. Мы всегда выбирали эту связку технологий, потому что не знали другие так же хорошо, как эти. Это была наша зона комфорта, но действительно ли неправильно выбирать хорошо известные технологии для новых проектов? Это зависит от разных факторов.
Во многих случаях ваш следующий проект будет более-менее похож на предыдущие. Было бы нелогично тратить много времени на изучение новой технологии, потому что у вас уже есть проверенные решения. Но иногда такой выбор будет ошибочным.
Помню проект, в котором самым важным требованием был хорошо работающий WebSocket. Что мы выбрали для создания бэкенда? Symfony, разумеется. Возможно, сегодня реализация WS на PHP будет выглядеть проще, но в то время это было кошмаром. Мы потратили много времени, чтобы заставить его работать. ОЧЕНЬ много. Мы знали, сколько времени (и денег) будет потрачено для создания WS на PHP, но мы отказались от идеи использования Node. Почему? Не могу сказать точно. На Node мы бы создали API в десять раз быстрее, но он не был в технологическом стеке нашей команды.
Я очень счастлив, что программисты в моей нынешней команде более открыты всему новому, чем был я. На прошлой неделе мы решили полностью заменить технологию, используемую для создания части нашей системы. Я уверен, что это решение сэкономит нам много времени, даже если придётся что-то учить с нуля.
Что я думал о решениях менеджера по продукту.
4. Владелец продукта/менеджер по продукту ошибается, я бы сделал лучше
Когда я работал программистом, мои отношения с менеджером по продукту были… натянутыми. Каждый раз когда он говорил мне о новых изменениях в содержании задачи, я думал: «Почему ты не можешь сразу сделать свою работу и определиться с задачей до того, как я начну работать? Разве так сложно решить заранее, как должна работать фича?»
Это было так наивно, но я действительно считал, что всё так просто. Теперь я полностью понимаю, как сложно спланировать каждую деталь проекта. Нужно учитывать ограничения технологий и бюджета (что на самом деле одно и то же), необходимо думать о пользователях, которые будут работать с твоим продуктом, нельзя забывать о требованиях бизнеса и маркетинга. Иногда некоторые требования неизвестны в начале; иногда меняются обстоятельства у бизнеса, а иногда нужно сначала что-то создать, чтобы понять, что это можно сделать лучше.
Ещё один аспект — менеджеры по продукту могут совершать ошибки. Да, всё так просто. Программисты создают баги и PM тоже. Сегодня это кажется мне настолько очевидным. Если бы я был программистом получше, то понял бы это раньше. Вместо того, чтобы пытаться доказать, насколько он ошибается, мне нужно было сосредоточиться на поиске решений.
Это иронично и печально, но в какой-то момент я забыл, что у меня и менеджера одна цель — создание отличного продукта. Просто у него гораздо больше знаний о бюджете, обстоятельствах у бизнеса, требованиях со стороны клиента, дедлайнах и приоритетах. Именно поэтому я не понимал некоторые его решения.
Подведём итог
Для кого-то из вас эти четыре пункта могут оказаться очевидными. Если вы работаете в отличной организованной agile-команде с хорошим руководителем и не забываете основные правила UX, то я искренне рад за вас. Наверно, вы можете быть гораздо лучшим программистом, чем был я. Ведь чтобы «быть хорошим программистом», недостаточно только технических навыков. Гораздо важнее понимать, какую ценность ты можешь принести компании, и как это сделать. Теперь я понимаю определение сениор-разработчика следующим образом:
Сениор-разработчик — это не тот, кто понимает каждый аспект технологии. Это человек, который поможет вашей компании создать качественный продукт, даже если это потребует от него выхода из зоны комфорта. Решения важнее, чем проблемы.
На правах рекламы
Подыскиваете VDS для отладки проектов, сервер для разработки и размещения? Вы точно наш клиент :) Посуточная тарификация серверов самых различных конфигураций, антиDDoS и лицензии Windows уже включены в стоимость.
Bellerogrim
> На Node мы бы создали API в десять раз быстрее
«Если бы знали его так же хорошо, как Symphony», почему-то автор забыл добавить.
TheSprightlyDuke
Это явно следует из контекста:
Почему «разумеется»?
Bellerogrim
Контекст там как раз «а вот на ноде это было бы легче и проще, и не надо держаться за зону комфорта, и забудьте что я говори в предыдущем пункте — сделать здесь и сейчас лишь бы-работало».
TheSprightlyDuke
Вербальный контекст — это законченный отрывок письменной или устной речи (текста), общий смысл которого позволяет уточнить значение входящих в него отдельных слов или предложений. Наличие вербального контекста всегда напрямую влияет на понимание любых сообщений, и отсюда часто встречающаяся в обществе ошибка цитирования, называемая «вырывание из контекста» (повторение некоторой усечённой части первоначального текста в ущерб его цельности, что может серьёзно искажать его исходное значение).
При том, что Вы говорите правду, Вы вырываете её (понимаю, что случайно) из контекста, что приводит к ложному выводу.
dreesh
Комментарий улетел в закладки) Однажды кто-то сказал что, даже то что, негласно и очевидно всем, все равно должен кто-то сказать.
TheSprightlyDuke
Маленько занимательной математика:
Когда я решил так сделать было три плюса у первого коммента. Уже восемь) А ниже, у DrPass так и намного больше)
Вот он пишет:
И это при том, что в статье ни слова не сказано, что они не знаю ноду. Там сказано:
«но он не был в технологическом стеке нашей команды.»
Более того. Там сказано:
*как эти, это про Симфони и Ангуляр
Лично мне эта фраза говорит о том, что, вероятнее всего, учитывая контекст, Ноду они знают, просто не сильно хорошо.
Стоит ли удивляться, что идиот у большинства разрабов клиент (я тоже так мыслил, одно время)? Про то, что это могла быть абстракция, пример, я вообще промолчу.
debagger
Все правильно, если знаешь яваскрипт, то в каком-то смысле знаешь ноду. А яваскрипт они судя по всему знали, раз у них в стеке был англяр.
TheSprightlyDuke
Ну вот drPass, походу, считает иначе, раз пишет:
Хотя автор, это явно, пишет о недостаточно хорошем знании. И вообще, он это пишет в РЕТРОСПЕКТИВЕ. То есть сравнивает потенциал не в уме, а наглядно. Вот он и высказывает предположениедополняя его фактологией
dreesh
Или у них микроскоп для забивания кудрявых гвоздей)
Как по мне, если создание "чудовища Франкенштейна" неизбежно, то пусть он будет красавицей хотя бы внешне (архитектура продумана)
Возможен вариант ультиматума от красавицы, но тогда встает вопрос о трудо-затратах на дипломатические решения. Одно большое чудовище сложнее победить, чем множество маленьких подружить друг с другом)
TheSprightlyDuke
Нормально Вы так завернули, пришлось поперечитывать, чтобы быть уверенным, что понял всё правильно) Таки классика жеж. Поэтому не надо делать голову себе и людям, надо писать на асме!))) Подумаешь, бочкой таблеток не обойдёшься)
Если серьёзно, то фиг его знает, как правильно. Настолько всё неоднозначно для каждого проекта. Куча обвязки не касающейся кода. Бюджет, сроки, психотип заказчика и его умение/готовность понимать и принимать собеседника, компромиссы, двигаться в хотелках, пользователи и их тараканы итд итп. Бррр, жутко становится, как начинаешь думать про внекодовые обвязки)
JordanoBruno
Работал с Symfony и нодой, в том числе с WS. Могу сказать, что для нужд стартапа backend API с поддержкой WS можно сваять очень быстро — есть множество готовых фреймворков куда проще того же Symfony.
P.S. Судя по тому, что Вы пишете с ошибкой — «Symphony», с ним Вы не знакомы явно :).
AndyPike
Да это же перевод на скорую руку, типа translate google. Смесь из англицизмов, которые совсем не соответствуют нормальным разговорным англицизмам, которые все понимают. У меня от «менеджер по продукту» слёзы текут. «PM» называется, Product Manager. Ну, или переводите нативно: «Главный по работам».
Это нормальная среда для разработчика UI с учётом UX. Причём всё постоянно меняется. Клиент никогда не виноват, мы для них или для себя это делаем? Золотое правило разработчика.