О переводе

Это перевод 20 главы книги The Passionate Programmer: Creating a Remarkable Career in Software Development ^[1]. Её автор — Chad Fowler ^[2] — талантливый Ruby-разработчик, известный докладчик на конференциях, посвящённых Ruby и IT в целом. Бывший саксофонист, а сейчас — CTO 6Wunderkinder.

Краудсорсинговый перевод книги ведётся на github ^[22], присоединяйтесь.

Глава 20. Телепат

Я работал с парнем по имени Рао. Рао родом из южного штата Индии Andhra Pradesh, но он жил в США и работал вместе с нами. Рао мог написать любой код, о чем бы вы его ни попросили. Если вам было нужно низкоуровневое системное программирование — это к нему, если высокоуровневое прикладное, он мог сделать почти что угодно.

Однако, что делало Рао по-настоящему удивительным, так это то, что он делал это до того как вы его попросили. У него была эта сверхестественная способность предсказать то, что вы собирались попросить его сделать, еще до того как вы об этом подумали. Это было сродни магии. Мне кажется, я даже обвинил его однажды в обмане, но не было никакой возможности обмана. Я бы сказал: «Рао, я думал о смене способа инкапсуляции контроллера на нашем фреймворке приложений [1]. Если мы изменим его немного, то можно будет его использовать не только для веб-приложений. Что думаешь?». «Я сделал это на прошлой неделе», — ответил бы он — «Это есть в системе управления версиями. Посмотри.» С Рао постоянно так было. Настолько часто, что единственный способ, чтобы все это было совпадением, как если бы Рао делал все что можно представить с каждым участком кода, над которым работала наша команда.

В то время я возглавлял команду архитектуры приложений [2]. Среди прочего, мы разрабатывали и сопровождали фреймворки для использования в приложениях компании. Мои коллеги проводили много времени, обсуждая, как мы хотим видеть разработку ПО для улучшения компании. Мы также обсуждали роль ключевых инфраструктурных компонентов в этих улучшениях.

Вот где оказывались полезными фокусы Рао. Он не говорил много во время этих бесед, но и не отключался от них. Он слушал внимательно. И, раскрывая секрет, чего не делает ни один фокусник, он позднее рассказал мне, что он делал только то, о чем я уже сказал, что хочу это сделать. Просто я говорил об этом настолько тонко, что даже я не представлял, что сказал это. Мы могли ждать пока сварится кофе, и я мог рассказывать как здорово было бы если бы наш код имел дополнительную гибкость. Если я говорил об этом достаточно часто или произносил достаточно убедительно, даже если я не включал это в список дел, Рао мог заполнить перерывы в «настоящей работе», в поиске возможности внедрения одной из этих вещей. Если это было легко (и дешево) он мог сделать это на скорую руку и проверить.

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

Этот фокус с чтением мыслей не совсем безопасен. Это как натянутый канат, по которому вы избегаете ходить без страховочной сетки. Основные риски (с предполагаемыми смягчениями) следующие:

• вы тратите средства компании, делая работу, о которой вас никто не просил. Что, если вы ошибаетесь? Начните с малого. Делайте только предположения о заполнении пауз в вашей текущей работе, так что влияние изменений минимально. Если хотите, делайте это в свободное от работы время.
• каждый раз как вы добавляете код в систему, существует очень большой шанс того, что код станет менее гибким для изменений. Избегайте предположений, если это может привести к снижению или пределу того, что система может выполнять [3]. Когда влияние изменений достаточно велико, нужны бизнес решения. И в этом случае редко только разработчики влияют на решение.
• вы можете изменить функциональность системы, о чем просили вас заказчики, таким образом, что решение неожиданно для вас станет менее полезным или желательным для заказчика. Остерегайтесь угадывания, особенно если дело касается пользовательских интерфейсов.

Управление людьми и проектами — сложная работа. Люди, которые могут двигать проект в правильном направлении, без указки высоко ценятся их часто перегруженными работой менеджерами и заказчиками. Штука с чтением мыслей, если она сделана правильно, заставляет людей полагаться от вас — замечательный рецепт для развития карьеры. Этот навык стоит изучения и развития.

Действуйте!

1. Ранний рецензент этой книги Карл Брофи (Karl Brophey) предлагает для вашего следующего проекта или системы, которую вы разрабатываете, начать делать записи о том, что вы думаете, о чем хотят попросить менеджеры или заказчики. Будьте креативными. Попытайтесь посмотреть на систему с их точки зрения. После составления списка не-таких-уж-очевидных функций, подумайте о том как наиболее эффективно внедрить каждую.
2. Когда вы попали в проект или задачу по улучшению системы, следите за успехами. Как много ваших догадок действительно попросили разработать? Когда ваши функции были внедрены, была у вас возможность использовать эти идеи при мозговом штурме?[4]

---

[1] I would say, «Rao, I've been thinking about changing the way we're encapsulating the controller on our application framework»
[2] At the time, I was leading my company's application architecture team.
[3] Avoid mind-reading work that may force the system down a particular architectural path or limit what the system can do in some way.
[4] When your guessed features did come up, were you able to use the ideas you came up with in your brainstroming sessions?

---

Как лучше перевести слово feature?

И встречались ли кому-нибудь такие Рао?

Автор: urticazoku

Источник ^[23]