Страсть к программированию. Глава 20. Телепат

    image
    О переводе

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

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

    Глава 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?

    И встречались ли кому-нибудь такие Рао?
    Оцените, пожалуйста, качество перевода

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Метки:
    • +15
    • 13,2k
    • 7
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 7
    • 0
      Как лучше перевести слово feature?

      ИМХО, в данном контексте — «особенность», «фишка».

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

      Ага. Правда чаще такие Рао делятся информацией в процессе выполнения такой вот «сторонней» задачи и она не становится сюрпризом для тимлида и команды(что полезнее, на мой взгляд). Но в чем они действительно круты — они в самом деле подмечают подобные «жемчужины» в ходе обычного разговора и способны, как минимум, начать их реализацию.
      • 0
        > ИМХО, в данном контексте — «особенность», «фишка».

        Тогда уж лучше «фича». Если речь идёт о
        > When your guessed features did come up, were you able to use the ideas you came up with in your brainstroming sessions?

        То особенности точно не в тему.
      • 0
        Мне всегда говорили, не добавляйте отсебятину. Спросят зачем нам, этого не надо или как сказано в самой статье тратите время.
        Да и вообще если сами добавили то добавьте ка и вот это, без дополнительных затрат.
        • 0
          После того, как переведут всю книгу, кто то соберёт её в распространенные форматы для читалок(epub и т.д.)?
          Я думаю, многие будут рады целой книжке.
          • 0
            почему бы это не сделать тебе? (-:
          • +1
            Как лучше перевести слово feature?

            Лучше не переводить.
            • 0
              Как лучше перевести слово feature?
              «Штрих»?

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.