4 ошибки, которые я сделал как программист, но мне пришлось стать техническим директором, чтобы увидеть их

Я работал программистом более пяти лет. Это не впечатляет, поскольку у некоторых из вас, вероятно, в три раза больше опыта работы, но мне нравилось думать о себе как о senior-разработчике. Звучит серьезно и важно, не правда ли?

Однажды мне предложили поработать техническим директором (CTO) в стартапе, специализирующемся на медицинских технологиях. Проработав некоторое время на этой новой должности, я могу оглянуться назад и сказать, что тогда я не был никаким senior-ом. Не поймите меня неправильно — я все еще считаю, что обладаю отличными знаниями в программировании, особенно в веб-разработке, — но если это так, почему я говорю, что не был ведущим разработчиком?

Из-за этих четырех вещей.

1. Пользователи — идиоты

Нет, не идиоты.

Да, пользователи используют приложение неожиданным, часто странным образом.

Да, пользователи могут задавать вопросы, которые кажутся действительно глупыми.

Да, иногда пользователям требуются функции, которые кажутся бессмысленными.

Да, у пользователей возникают трудности с функциями, которые не требуют пояснений.

Пользователь не эксперт. Мой врач не требует, чтобы я знал разницу между липопротеинами низкой и высокой плотности. Почему же я предполагал, что пользователи должны знать, какой браузер они используют? Для меня и для вас это очевидно, но моя мама считает, что Google и Интернет — это синонимы. Она сказала бы, что не использует никаких браузеров, потому что использует Google 🙈.

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

2. Мой код — это искусство и должен быть идеальным

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

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

Это решение показалось мне недальновидным. Кроме того, он посоветовал нам прекратить писать документацию и преобразовать код в менее сложную архитектуру (мы могли бы это сделать, так как мы были в начале проекта).

Хорошо, я согласен, это ускорит разработку на некоторое время, но у нас будет много проблем в будущем. Мы потратим много времени на исправление ошибок в дальнейшем, и новая архитектура будет слишком простой, когда проект вырастет! А как мы будем вводить в проект новых программистов без хорошей документации?

Мы часами обсуждали, насколько это плохое решение — и сколько оно будет стоить нам в будущем.

Через несколько месяцев проект провалился из-за того, что он резко превысил бюджет.

Спустя годы должен признать правду: наша команда совершила огромную ошибку. Мы думали о будущем и забыли о настоящем. Мы полностью проигнорировали обстоятельства — небольшой бюджет и необходимость в короткие сроки создать MVP.

Приятно создавать код, который можно показывать другим и которым можно гордиться. Но еще лучше успешно доводить проекты до конца. В конце концов, программирование — это не искусство.

3. Я буду использовать «X» для этого проекта, потому что я это знаю

В моей предыдущей компании мы создавали каждый проект с одним и тем же стеком технологий: Symfony и Angular. Почему? Symfony — лучший серверный фреймворк? Неа. Может быть, Angular — единственный способ создать современный интерфейс? Неа. Мы всегда выбирали этот набор технологий, потому что мы не знали других так же хорошо, как эти. Это была наша зона комфорта, но разве не правильно выбирать знакомые технологии для новых проектов? По-разному.

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

Я помню проект, в котором самым важным требованием был хорошо работающий WebSocket. Что мы выбрали для создания нашего бэкенда? Конечно, Symfony. Может быть, сегодня создать WS на PHP проще, но тогда это был кошмар. Мы потратили много времени на то, чтобы это работало. Я имею в виду МНОГО. Мы знали, сколько времени (и денег) потребуется на создание WS на основе PHP, но мы отказались от идеи использовать Node. Почему? Я правда не знаю. В Node мы бы создавали API в 10 раз быстрее, но он не был технологическим стеком нашей команды.

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

4. Мой продукт оунер/менеджер ошибается, я бы сделал это лучше

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

Почему ты не можешь просто выполнить свою работу и определить скоуп, прежде чем я начну работать?! Неужели так сложно заранее решить, как эта функция должна работать?

Это было так наивно, но я действительно думал, что это легко. Теперь я полностью понимаю, насколько сложно спланировать каждую деталь проекта. Вы должны принять во внимание ограничения технологии и бюджета (что на самом деле одно и то же), вы должны подумать о пользователях, которые будут использовать ваш продукт, вы не можете забыть о бизнес-требованиях и маркетинге. Иногда некоторые требования изначально не известны. Иногда обстоятельства в бизнесе меняются, и иногда вам нужно сначала что-то сделать, чтобы понять, что можно было сделать лучше.

Другое дело — менеджеры по продукту могут ошибаться. Это так просто. Программисты производят баги, и PM тоже. Это так очевидно, когда я думаю об этом сейчас. Я был бы лучшим программистом, если бы понял это раньше. Вместо того, чтобы пытаться показать, насколько они неправы, я должен был сосредоточиться на поиске решений.

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

Итог

Для некоторых из вас эти четыре вещи могут быть очевидны. Если вы работаете в отличной организованной agile-команде с хорошим лидером и помните об основных законах UX — я очень рад. Я предполагаю, что вы можете быть гораздо лучшим программистом, чем я. Потому что «быть хорошим программистом» — это не только технические навыки. Еще важнее понять, какую ценность вы можете принести компании и как это сделать.

Вот как я сейчас понимаю термин «senior-разработчик»:

Senior-разработчик — это не тот, кто знает все аспекты технологии. Это человек, который поможет нашей компании создать отличный продукт, даже если для этого потребуется пересечь границу своей зоны комфорта. Решения выше проблем.

Источник