10 законов техники Амира
Перевод Amir’s 10 Laws of Tech. Amir Shevat
Технология, созданная для хороших целей, в конечном итоге будет использоваться и для плохих.
В технологиях у нас есть понятие "счастливый путь" - ожидаемое поведение наших хороших пользователей, и мы склонны фокусироваться на полезных сценариях использования нашего продукта нашими клиентами. Это создает слабое место для эксплойтов и плохих воздействий, которые могут иметь наши технологии. Я был потрясен, когда некоторые пользователи впервые использовали наш API для сбора данных.
Технологический стек компании будет основан на опыте и предпочтениях первого технического специалиста в этой компании.
Когда компания только создается, первый технический специалист имеет практически неограниченные возможности для принятия решений относительно технологического стека, который компания будет использовать в обозримом будущем. Некоторые компании, в которых я работал, реализовывали все на PHP, потому что технический лидер был фанатом PHP.
Самыми болезненными и наименее полезными проектами являются проекты миграции, и тем не менее компании заменяют технологии каждые 4 года.
Миграционные проекты занимают в 10 раз больше времени, чем мы предполагаем. Они в основном бесполезны для бизнеса компании и заставляют разработчиков уходить из компании от скуки и разочарования. Тем не менее, вся технологическая индустрия всегда ищет следующую блестящую технологию, вместо того чтобы попытаться исправить текущий технологический стек.
За каждой крупной технологией последует движение за искоренение этой технологии, потому что она нас погубит.
Люди боятся перемен, и даже больше того - перемен, которых они не понимают. Каждая новая крупная технология провоцирует людей на ее искоренение, как будто она приведет к концу света. Все технологии - это инструмент, и они плохи только в том случае, если используются людьми не по назначению (см. "Технология, созданная для добра, в конечном итоге будет использована для зла").
Высококоммуникабельная и готовая к сотрудничеству команда средних инженеров превосходит необщительную и не способную к сотрудничеству команду великих инженеров.
Технологические компании слишком сильно ориентируются на возможности отдельных людей. Большинство продуктивных команд, в которых я работал, отличались тем, что были общительными и готовыми к сотрудничеству, а не гениальными примадоннами.
Если оставить продуктовую команду в покое, она будет добиваться ближайшей и самой простой цели.
В продуктовых командах работают умные, амбициозные и в целом хорошие люди. Однако они часто не видят общей картины и фокусируются на локальной цели использования продукта или функции, а не на общей цели компании или благе человечества. Концентрация на локальной цели, такой как привлечение или удержание пользователей, иногда заставляет команды разработчиков делать вещи, которые вредят компании и ее пользователям.
Некоторые стороны технологии являются псевдотеологическими - когда речь заходит о "табуляции против пробелов", вероятно, начнется священная война.
Люди, не связанные с техникой, думают, что инженеры - это очень умные и рациональные люди, которые оценивают вещи по их достоинствам и логическим преимуществам. Они не знают, что споры о том, какая кофейня лучше в Сиэтле или какая футбольная команда лучше в Аргентине, постоянно происходят и в технологиях. Разработчики могут часами яростно спорить о любимом текстовом редакторе, языке программирования и проекте с открытым исходным кодом.
Когда вы нанимаете кого-то из другой компании, вы переносите часть ДНК этой компании в свою собственную компанию.
Я видел это много раз. Наймите 5 человек из Salesforce, и внезапно ваша компания станет похожа на Salesforce, наймите 5 гуглеров, и вы получите часть Google в своей компании. Я частично Google, частично Microsoft, частично Slack, частично Amazon.
Это не проблема, если вы не нанимаете всех из одной компании. Вы же хотите создать свою собственную культуру, поэтому позаботьтесь о том, чтобы нанять самых разных кандидатов.
Все празднуют версию 1.0.0, но именно версия 1.0.3 действительно приносит ценность для клиентов.
Технологические компании привыкли праздновать запуск новых версий. Большинство таких запусков происходят в спешке, подчиняясь внешнему давлению, например, произвольному соблюдению сроков. И только к версии 1.0.3 происходит стабилизация продукта и он становится полезным для клиентов.
Через 10 лет кто-то назовет ваше новенькое сверкающее программное обеспечение "старым дерьмом" и будет удивляться, кто, черт возьми, разработал такой плохой продукт.
В технологиях мы склонны смотреть на программное обеспечение, разработанное 5-10 лет назад, как на что-то древнее. Мы обычно спрашиваем себя: "Кто, черт возьми, думал, что это хороший дизайн? Кто придумал эту ужасную архитектуру?" Помните, что кто-то через 10 лет, если вы будете очень удачливы и успешны, посмотрит на ваш продукт и скажет то же самое.