Я проработал программистом более 5 лет. Конечно, у некоторых из вас, вероятно, гораздо больше опыта, но тогда я считал, что уже достиг уровня старшего разработчика.
В один прекрасный день я получил должность технического директора (Chief Technology Officer, CTO) в медтех-стартапе. Проработав некоторое время на новом месте и проанализировав свой прежний опыт, я понял, что еще не достиг уровня старшего разработчика.
Я по-прежнему считаю себя грамотным программистом, особенно в сфере веб-разработки. Но почему же я посчитал, что не дотягиваю до уровня старшего разработчика? На это есть четыре причины.
1. Пользователи не разбираются в тонкостях разработки
Часто они используют приложение нестандартным, странным образом. Иногда задают глупые, на первый взгляд, вопросы. Бывает так, что они просят ввести функции, которые кажутся бессмысленными. И порой они путаются в очевидных действиях.
Пользователь не является экспертом. На приеме у врача пациенту не нужно знать различие между липопротеинами низкой и высокой плотности. Так почему же я раньше предполагал, что пользователи должны знать название используемого ими браузера?
Чтобы угодить клиенту, мне порой приходилось конфигурировать компоненты фреймворка и изменять его поведение по умолчанию. Иногда я добавлял поддержку для браузеров, которым не симпатизирую. Сегодня это кажется нелепым, но раньше я винил клиента в том, что мне приходилось корректировать код по его требованиям.
2. Чистый код и другие требования проекта
Чистый код, модульные тесты и детальное документирование несомненно имеют важное значение. Будучи программистом, я старался писать чистый код, использовать современные шаблоны и часто проверял актуальность всех зависимостей в проекте. Ведь я намеревался стать классным программистом.
Когда продакт-менеджер попросил меня отказаться от модульных тестов, чтобы ускорить процесс разработки, я огорчился: неужели он не понимает, как они важны? Мы не использовали какие-либо другие автоматизированные проверки. Лишь модульное тестирование давало надежду на создание стабильного продукта.
Такое решение мне представлялось недальновидным. Кроме того, он посоветовал прекратить документирование и упростить архитектуру кода (это было возможно, так как проект находился на начальной стадии).
Конечно, это и правда ускоряет разработку на некоторое время, но в будущем добавляет целый ряд проблем. Мы потратим много времени на исправление регрессионных ошибок, а новая архитектура окажется слишком простой, когда проект начнет расти. К тому же без хорошего документирования новым программистам будет тяжело подключиться к работе.
Мы долго спорили о том, рационально ли это решение и какие проблемы оно вызовет в будущем. А через несколько месяцев проект провалился из-за серьезного превышения рамок бюджета.
Спустя несколько лет я понял, что наша команда совершила огромную ошибку. Мы планировали будущее без учета настоящего положения дел. Мы полностью игнорировали обстоятельства: небольшой бюджет и необходимость создать минимально-жизнеспособный продукт в короткие сроки.
Приятно создавать код, который можно с гордостью показать другим разработчикам. Но успешное завершение проектов будет еще приятнее. В конце концов, программирование — это не искусство.
3. Не все хорошо знакомые технологии применимы в новом проекте
В прежней компании мы создавали все проекты с использованием одного и того же набора технологий: Symfony и Angular. Возникает вопрос, почему? Ведь Symfony не считается лучшим серверным фреймворком. Может, Angular — это единственный способ создать современный пользовательский интерфейс? Тоже нет.
Мы всегда выбирали эти технологии, так как хорошо ими владели. Так нам было удобнее. Но правильно ли выбирать хорошо известные технологии для реализации новых проектов? Здесь все зависит от обстоятельств.
Новый проект часто более или менее похож на предыдущие. Поэтому нет смысла тратить массу времени на изучение новых технологий, когда уже есть проверенные решения. Однако это не всегда так.
Я помню проект, в котором самым важным требованием был хорошо работающий протокол WebSocket. И что мы выбрали для создания бэкенда? Конечно, Symfony. Возможно, сегодня легко создавать WS на PHP, но тогда это был настоящий кошмар, отнявший просто массу времени. И при этом, зная сколько времени (и средств) на это потребуется, мы отказались от использования Node. На первый взгляд непонятно, почему? Ведь в Node можно было бы создать API в 10 раз быстрее, но мы этой технологией не владели.
Я очень доволен тем, что сегодня программисты в моей команде более восприимчивы к новым идеям. Так, недавно мы решили полностью отказаться от технологии, используемой для создания одной из частей системы. И я уверен, что это решение позволит сэкономить немало времени, даже если кое-что придется изучить с нуля.
4. Конфликт интересов заказчика/менеджера продукта и программиста
Когда я работал программистом, у меня были сложные взаимоотношения с менеджером по продукту. Всякий раз, когда он сообщал о новых изменениях в проекте, у меня возникали мысли: “Почему он не может полностью выполнить свою работу, прежде чем я начну свою? Неужели так трудно заранее решить, как эта функция должна работать?”.
Я наивно полагал, что это было легко сделать. Теперь я понимаю, насколько сложным может быть планирование всех деталей проекта. Нужно учитывать ограничения технологии и бюджета (они могут быть взаимосвязаны), следует подумать об интересах пользователей этого продукта, нельзя забывать о требованиях со стороны бизнеса и маркетинга. Иногда в начале проекта известны не все требования. Временами меняются коммерческие обстоятельства, а иногда нужно сначала что-то сделать, чтобы обнаружить лучшее решение.
Кроме того, продакт-менеджеры тоже могут ошибаться. И в этом нет ничего особенного. Ошибаться могут не только программисты, но и менеджеры. Теперь это для меня очевидно. Но если бы это было понятно мне как программисту, то я бы мог добиться большего. Лучше сосредоточиться на поиске решений вместо того, чтобы думать об ошибках менеджеров.
Как это ни парадоксально и грустно, но в какой-то момент я забыл о том, что у нас с менеджером одна задача — сделать отличный продукт. Просто у него было гораздо больше информации о бюджете, коммерческих условиях, требованиях со стороны клиента, сроках и приоритетах. Вот почему я не понимал некоторых решений.
Заключение
Для кого-то эти четыре ошибки могут быть очевидными. Я очень рад за тех, кто работает в отлично организованной команде с хорошим руководителем. Полагаю, что такие программисты смогут добиться гораздо больших успехов, чем я. Потому что для этого нужно владеть не только техническими навыками. Еще важнее понять, какую ценность вы можете принести компании. Вот как я теперь понимаю термин старший разработчик.
Такой программист не просто знает все аспекты технологии. Этот человек поможет компании создать отличный продукт, даже если при этом для решения проблем ему придется выйти за рамки привычной среды.
Читайте также:
- Развенчание мифов о разработке программного обеспечения
- Как стать разработчиком проектов с открытым исходным кодом
- 5 советов для начинающих программистов
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Jakub Górowski: 4 Mistakes I Made as a Programmer, but I Had To Become a CTO To See Them
