Итак, вы - проснувшийся MBA, который выучил HTML на прошлых выходных, прошел курс SQL или даже прошел 6-недельный учебный курс по Rails. Это прекрасно! Изучение некоторых аспектов программирования - отличный способ завоевать доверие ваших инженеров, более эффективно общаться с ними и снизить нагрузку на вашу перегруженную работой команду инженеров. Я никогда не работал в технологической компании, где команда инженеров не является основным узким местом компании, поэтому все, что вы можете сделать, что избавит их от работы, увеличит количество времени, которое они могут потратить на то, что могут делать только они. . Мой последний генеральный директор изучил SQL самостоятельно, поэтому ей не пришлось беспокоить команду инженеров специальными запросами на анализ данных, и к тому времени, когда я ушел, она лучше меня писала сложные операторы SQL.

Но, как говорится, немного знаний - дело опасное. Во многом я не профессионал в области маркетинга только потому, что в том остроумном твите, который я написал, однажды получил 75 RT, вы не инженер, потому что вы отправили электронное письмо в формате HTML, которое отлично смотрится во всех почтовых клиентах, кроме Outlook.

Допустим, вы написали шаблон электронной почты, который уже разослали некоторым пользователям, и хотите добавить страницу с такой же информацией на свой веб-сайт. Или вы написали SQL-запрос, который используете для некоторых аналитических целей, и теперь хотите, чтобы ваш инженер добавил что-то похожее на продукт - может быть, как часть панели мониторинга или, может быть, как основная функция. Легко, правда? Вы уже сделали самое сложное!

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

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

(2) Краевые случаи. Возможно, вы выполнили свой SQL-запрос несколько раз, исправили возникшие ошибки, оценили результаты и закончили работу. Этого недостаточно для кода, интегрированного с продуктом. Работает ли это с неполными данными или данными в полете? Что должно произойти, если что-то пойдет не так - повторить попытку, отобразить ошибку для пользователя или вернуться к какому-либо другому поведению? Все эти досадно подробные вопросы, которые ваши инженеры задают вам, когда вы даете им спецификации продукта, связаны с тем, что их нужно так или иначе закодировать, даже если вам все равно, что (или если вы не думаете, что делаете). Вы хотите, чтобы было наоборот, если бы они выбрали путь самостоятельно).

(3) Несколько платформ. Вы знаете тот шаблон электронного письма, который вы написали, который выглядел великолепно? Он отлично смотрелся на всех почтовых платформах? А как насчет мобильных устройств? Пейзажный режим тоже? Режим доступности? Без их явной адаптации и тестирования они могут вообще не работать. Я говорю не только о том, что он выглядит немного странно - он может выглядеть ужасно сломанным на одном устройстве, даже если он выглядит идеально на другом.

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

(5) Тестирование. Большая часть времени инженера тратится на тестирование, даже если у вас есть отдельная команда QA или вы сами тестируете все, что они создают. Ничего не работает, как только инженер пишет код; это итеративный процесс. Обычно инженер напишет код, протестирует его, поймет, что он не совсем работает или сломает что-то несвязанное, и выполнит итерацию. Кроме того, считается хорошей практикой для инженерных групп поддерживать автоматизированный набор тестов, который необходимо обновлять или улучшать при изменении кода.

Скорее всего, я буду больше говорить об оценках в будущих публикациях, поскольку они часто являются источником напряженности между инженерами и не-инженерами. Это всего лишь несколько примеров того, как то, что кажется тривиальным, может быть не так быстро реализовано, как вы думаете.

Надеюсь, этот пост был вам полезен! Не забудьте подписаться на меня здесь, на Medium, в моем блоге О чем говорит мой инженер, Facebook, Twitter или LinkedIn. И присылайте отзывы и предложения по темам по электронной почте.