Программист-фанатик
Шрифт:
Совет 11
Учимся ловить рыбу
Лао-цзы сказал: «Дай человеку рыбу, и он будет сыт целый день. Научи его ловить рыбу, и он будет сыт всю жизнь». При всей верности этой поговорки Лао-цзы не учел, что бывают люди, не желающие учиться ловить рыбу. Такой человек предпочтет на следующий день попросить еще одну рыбу. В процессе обучения задействованы как учитель, так и ученик. Но многие из нас зачастую не испытывают желания учиться.
Не жди, пока тебе расскажут. Спрашивай сам!
Что в индустрии ПО считать рыбой? Процесс работы с инструментом, некий аспект технологии или некую информацию из бизнес-отрасли, в которой ты работаешь. Умение проверить определенную часть системы управления исходным кодом, с которой работает твоя команда, или настроить сервер приложения. Многие из нас считают все эти мелочи само собой разумеющимися и считают, что с ними обязательно справится кто-то другой. В системе управления версиями
Кто хочет зависеть от милостей другого человека? Или поставим вопрос более жестко: ты бы согласился нанять на работу человека, зависящего от целой группы специалистов? Лично я отвечаю на этот вопрос отрицательно. И предпочитаю сотрудников, способных к самостоятельным действиям.
Очевидно, что первым делом следует изучить инструменты, необходимые для выполнения непосредственных обязанностей. Например, такой мощный инструмент, как система управления версиями. Он позволяет разработчикам повысить продуктивность своего труда. Это не просто место для кода, с которым ты закончил работать, ни в коем случае не следует воспринимать эту систему подобным образом. Она является неотъемлемой частью разработки. И столь важная вещь — надежное хранилище твоей работы — не должна быть для тебя загадкой. Самодостаточный разработчик легко обнаружит разницу между той версией проекта, над которой он работает, и последней корректной версией из хранилища. А представь, что тебе нужно взять последний выпущенный код и исправить там ошибку. Обнаружив существенную ошибку посреди ночи, ты вряд ли захочешь кому-то звонить и просить дать тебе корректную версию, чтобы приступить к устранению неполадок. Все то же самое можно сказать о средах разработки, операционных системах и практически каждом фрагменте инфраструктуры, на которой базируется твой код.
Не менее важной является используемая тобой технологическая платформа. Например, ты можешь разрабатывать приложения с помощью J2EE. Тебе приходится создавать различные классы, интерфейсы и дескрипторы развертывания. Можешь ответить на вопрос: зачем? Знаешь, как применяются все эти вещи? Что происходит при запуске J2EE-контейнера? Даже если ты не являешься разработчиком сервера приложений, знание всех этих вещей позволит тебе писать надежный код для этой платформы и устранять неисправности, когда что-то идет не так.
Особенно располагают к лени различные модули, генерирующие за тебя код. Они весьма распространены среди Windows-разработчиков, так как Microsoft создала множество инструментов, предельно упрощающих решение многих задач. Оборотной стороной этого удобства стало появление множества разработчиков, не имеющих понятия о принципах работы своего кода. Происходящее внутри того или иного модуля остается для них мистической тайной. Не пойми меня неправильно — генерация кода может быть весьма полезной. Ведь именно она позволяет перевести высокоуровневый код C# в байтовый код, запускаемый в среде исполнения .NET. Не думаю, что тебе понравилось бы писать такой код вручную. Но применение высокоуровневых мастеров и модулей не способствует углублению твоих знаний. В итоге твои навыки ограничиваются умением работать с имеющимся инструментарием.
В бизнесе, с которым связана наша деятельность, также можно легко проглядеть рыбу. Например, сотрудник ипотечной компании может попросить специалиста рассчитать процентную ставку для всех необходимых при тестировании сценариев, а может рассчитать ее самостоятельно. Хотя взаимодействие с клиентом приветствуется, как и согласование с ним бизнес-требований (в противовес недопониманию и самостоятельным попыткам нарисовать полную картину), только представь, насколько быстрее ты смог бы двигаться вперед, разбираясь в специфике бизнеса, на который работаешь. Разумеется, весь деловой регламент ты вряд ли выучишь, да это и не нужно. Но ничто не мешает разобраться в основах. Вспоминая лучших программистов, с которыми мне довелось поработать за прошедшие годы, могу сказать, что многие из них разбирались в бизнесе лучше, чем некоторые из их заказчиков. Это улучшило результаты их труда. Не знакомый с особенностями конкретного бизнеса человек легко допускает глупые ошибки, которых легко можно было бы избежать, обладая базовыми представлениями о том, в какой сфере ты работаешь. Более того, такой человек выполняет свои обязанности медленнее (и в конечном счете стоит компании дороже), чем аналогичный разработчик, разбирающийся в бизнесе.
Мы, разработчики программного обеспечения, можем перефразировать высказывание Лао-цзы так: «Попроси рыбу, и будешь сыт один день. Попроси кого-то научить тебя ловить рыбу, и будешь сыт всю жизнь». Но лучше не просить кого-то, а взять и научиться самостоятельно.
1. Как и почему? Прямо сейчас после прочтения данного раздела или в следующий раз на работе подумай о тех аспектах своей деятельности, которые ты не до конца понимаешь. Для погружения в непонятную сферу можно задать себе два крайне полезных вопроса: Как это работает? и Почему это происходит (или должно происходить)?
Возможно, ты даже не сможешь на них ответить, но сам факт постановки подобных вопросов приведет твой ум в новое состояние и поможет лучше осознать твое рабочее окружение. Как IIS-сервер передает запросы твоим ASPNET-страницам? Зачем генерировать все эти интерфейсы и дескрипторы развертывания для твоих EJB-приложений? В чем разница в работе компилятора при динамическом и статическом подключении? Почему для заказчиков из Монтаны сумма налога вычисляется по-другому?
Разумеется, ответ на любой из этих вопросов даст тебе потенциальную возможность снова задать подобный же вопрос. Как только вопросы как и почему иссякнут, можно считать, что ты достаточно углубился в тему.
2. Немного времени. Выбери в своем инструментарии важный, но игнорируемый инструмент и сосредоточься на нем. Это может быть твоя система управления версиями, библиотека, которой ты активно пользуешься, но не имеешь представления о том, как она устроена, или даже редактор, применяемый при написании кода.
Ежедневно выделяй немного времени, чтобы изучить очередной аспект выбранного инструмента, позволяющий повысить продуктивность твоей деятельности или лучше контролировать среду разработки. Например, ты можешь выбрать для изучения командную оболочку Bourne Again Shell операционной системы GNU. Когда в очередной раз твой ум начнет уходить в сторону от рабочих задач, вместо загрузки привычного новостного сайта поищи в интернете советы по bash. В течение минуты-другой ты обязательно найдешь новую для себя полезную информацию по работе с этой оболочкой. А узнав новый прием, начинай препарировать его с помощью вопросов как и почему.
Совет 12
Разберись, как работает бизнес
В предыдущей теме мы обсудили важность осознанного выбора бизнес-отрасли для будущей работы. К этому аспекту следует относиться серьезно, так как знание специфики работы в определенной отрасли является фактором, способным серьезно повлиять на возможность твоего трудоустройства. Но перед тем, как вкладываться в изучение деталей бизнеса, следует убедиться, что ты делаешь правильную с собственной точки зрения и с точки зрения состояния рынка инвестицию.
Однако всегда существует актуальный комплекс знаний, не относящийся ни к технике, ни к определенной отрасли — это основы финансирования бизнеса. В какой бы сфере ты ни работал, будь это производство, здравоохранение, некоммерческая деятельность или образовательное учреждение, эта сфера все равно относится к бизнесу. А бизнес сам по себе является областью, которую можно и нужно изучать.
Помню, как я, будучи молодым программистом, приходил на корпоративные встречи, и мои глаза стекленели, когда важный руководитель, с которым я никогда напрямую не работал, начинал демонстрировать какие-то диаграммы с огромным количеством цифр. Мне казалось, что все это не имеет ко мне совершенно никакого отношения. Я маялся и жаждал вернуться к себе, чтобы закончить работу над очередной подсистемой приложения. Коллеги из моей группы вертелись, как дети, истомленные долгой автомобильной прогулкой. Никто из нас не понимал смысла презентации и никого она не интересовала. Вину за эту, как нам казалось, пустую трату времени мы возлагали на некомпетентных менеджеров, организовавших данную встречу.
Оглядываясь назад, я понимаю, как глубоко мы заблуждались. Мы работали для бизнеса, и наша деятельность должна была помогать зарабатывать или экономить деньги. При этом мы даже не представляли, что делает бизнес доходным. И даже хуже — это казалось нам не важным. Мы были программистами и системными администраторами. Мы считали, что наша работа связана исключительно с темами, которым мы себя посвятили. Но разве может творчески помогать процветанию бизнеса человек, не понимающий, как этот бизнес функционирует?
Ключевым в предыдущем абзаце является слово творчески. Проще всего считать, что мы специалисты в IT и нам платят именно за это. Корректно поставленные задачи и правильное руководство позволяют сосредоточиться на вопросах, которые способствуют развитию бизнеса. И нам не нужно понимать, как работает бизнес, чтобы приносить ему пользу.
Ты не сможешь помогать бизнесу творчески, если не знаешь, как он устроен.
Но творчески приносить пользу можно, только имея представление о бизнесе, с которым связана твоя деятельность. В деловом мире то и дело звучат слова «чистая прибыль». Многие ли из нас действительно понимают, что такое чистая прибыль и от каких факторов она зависит? И, что более важно, многие ли из нас действительно понимают, какие их действия дают вклад в чистую прибыль? Является ли твое подразделение центром затрат или центром формирования прибыли (уменьшают или увеличивают твои действия чистую прибыль)?