День 2739. #Карьера
21 Урок После 14 Лет в Google. Начало
Автор оригинала: Addy Osmani

Когда я пришел в Google около 14 лет назад, я думал, что работа заключается в написании отличного кода. Отчасти я был прав. Но чем дольше я там работал, тем больше понимал, что преуспевают не обязательно лучшие программисты, а те, кто научился ориентироваться во всём, что связано с кодом: в людях, в политике, в согласованности действий, в неопределённости. Эти советы о закономерностях, которые постоянно проявляются, проект за проектом, команда за командой.

1. Лучшие инженеры одержимы решением проблем пользователей.
Заманчиво влюбиться в технологию и искать места для её применения. Все это делали. Но инженеры, создающие наибольшую ценность, работают наоборот: они одержимы пониманием проблем пользователей и позволяют решениям возникать из этого понимания.
Это означает тратить время на обработку заявок в службу поддержки, на общение с пользователями, на наблюдение за их трудностями, на вопросы «почему», пока не доберёшься до сути. Инженер, который действительно понимает проблему, часто обнаруживает, что элегантное решение проще, чем кто-либо ожидал. Инженер, который начинает с готового решения, склонен к усложнению в поисках оправдания.

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

3. Ориентация на действие. Выпуск продукта. Вы можете отредактировать плохую страницу, но не можете отредактировать пустую.
Стремление к совершенству парализует. Я наблюдал, как инженеры неделями обсуждали идеальную архитектуру для чего-то, чего они никогда не создавали. Идеальное решение редко рождается из одних лишь размышлений — оно рождается из контакта с реальностью. ИИ во многом может помочь в этом.
Сначала сделайте как-нибудь, затем правильно, затем улучшайте. Покажите пользователям некрасивый прототип. Напишите неряшливый первый черновик проектной документации. Выпустите MVP, который немного вас смущает. Вы узнаете больше из одной недели реальной обратной связи, чем из месяца теоретических дебатов.

4. Опыт – это ясность. Умничание — это лишние затраты.
Инстинкт писать умный код почти универсален среди инженеров. Это воспринимается как доказательство компетентности. Но разработка ПО — это работа с дедлайнами и другими программистами. В такой среде ясность — это не споры о стиле, а снижение операционных рисков.
Ваш код — это руководство для незнакомцев, которые будут поддерживать его в 2 часа ночи во время сбоя. Оптимизируйте код для их понимания, а не для своего эго. Самые уважаемые сеньоры научились всегда жертвовать остроумием ради ясности.

5. Новизна — это кредит, который вы возвращаете сбоями, наймом персонала и когнитивными издержками.
Относитесь к выбору технологий как к организации с небольшим бюджетом на «инновационные токены». Тратьте один каждый раз, когда внедряете что-то существенно нестандартное. Вы не можете позволить себе много.
Это не значит «никогда не внедряйте новинки». Это значит «внедрять инновации только там, где вам платят именно за это». Всё остальное должно быть скучным, потому что у скучного есть известные причины неудач.
«Лучший инструмент для работы» часто оказывается «наименее худшим инструментом для большинства задач», потому что содержание зоопарка становится затратным.

6. За вас говорит не ваш код, а люди.
В начале своей карьеры я считал, что отличная работа говорит сама за себя. Нет. Код молча лежит в репозитории. Ваш менеджер упоминает вас на совещании, или нет. Коллега рекомендует для проекта вас или кого-то ещё.
В крупных организациях решения принимаются на совещаниях, на которые вас не приглашают, на основе отзывов, которые писали не вы, людьми, у которых есть пять минут и двенадцать приоритетов. Если никто не может рассказать за вас о вашем вкладе, ваш вклад по сути незначителен.
Речь не только о саморекламе, но и о том, чтобы сделать цепочку создания ценности понятной для всех, включая вас самих.

7. Лучший код — тот, который вам никогда не приходилось писать.
В инженерной культуре мы ценим созидание. Никто не получает повышения за удаление кода, хотя это улучшает систему больше, чем добавление. Каждая строка кода, которую вы не написали, — это строка, которую вам никогда не придётся отлаживать, поддерживать или объяснять.
Прежде чем начать разработку, задайте себе вопрос: «Что произойдет, если мы просто… не будем этого делать?» Иногда ответ — «ничего плохого», вот и решение.
Проблема не в том, что инженеры не умеют писать код или использовать для этого ИИ. Проблема в том, что мы настолько хорошо пишем код, что забываем спросить себя, стоит ли это делать.

Продолжение следует…

Источник: https://addyosmani.com/blog/21-lessons/