Чед Фаулер - Программист-фанатик
Окружающие тебя люди влияют на твой результат. Поэтому тщательно подходи к выбору коллектива.
Будучи худшим парнем в группе, я начинал вести себя так же, как и в музыкальной группе. Естественным образом подстраивался под игру остальных членов коллектива. Но есть фактор, который превращает данное свойство в проблему. Дело в том, что, играя в казино и в захолустных барах с не самыми лучшими музыкантами, я спускался на их уровень. Более того, подобно алкоголику, язык которого заплетается даже в трезвом состоянии, я демонстрировал ту же самую отвратительную манеру игры, выступая в более приличных местах.
В итоге я понял, что улучшить или, наоборот, ухудшить свои навыки можно в зависимости от того, с кем приходится работать. Ведь продолжительный опыт сотрудничества с одной группой оказывает сильное влияние на стиль твоих выступлений.
Позднее, после перехода в компьютерную индустрию, я обнаружил, что привычка искать самых лучших музыкантов сопровождает меня и как программиста. Возможно, неосознанно я искал работу среди лучших специалистов в области IT. Неудивительно, что тенденция сохранилась. Быть самым худшим парнем (или девушкой) в команде — все равно что быть худшим музыкантом в группе. Ты обнаружишь, что стал необъяснимо умнее. Ты даже начнешь грамотнее говорить и писать. Твой код и дизайн станут более элегантными, и вдруг окажется, что ты способен предлагать все более творческие решения сложных задач.
Вернемся к первому объяснению моей способности встраиваться в группу легче, чем ожидалось. Я и в самом деле не был настолько плох, как думал. Действительно, очень легко понять, как оценивают твой уровень другие музыканты. Если ты играешь хорошо, они пригласят тебя выступить с ними снова. В противном случае тебя начнут избегать. Это куда более надежный критерий, чем просьба высказать свое мнение, ведь хорошие музыканты не любят играть в одной группе с плохими. К моему изумлению, превосходные музыканты часто звали меня выступать с ними и даже предлагали организовать собственную группу.
На самом деле попытка быть худшим не дает тебе недооценить себя. Можно быть первоклассным музыкантом, но всю жизнь играть в заштатных коллективах просто потому, что ты боишься. Прямо признавая себя далеко не лучшим, мы избавляемся от страха, что на нашу недостаточную квалификацию укажет кто-то другой. На самом же деле, даже если ты попытаешься стать худшим, легко это не получится.
Действуй!1. Найди ситуацию, в которой ты можешь быть «худшим». Разумеется, далеко не у всех есть роскошная возможность менять команды и фирмы просто из-за появившегося вдруг желания работать с лучшими специалистами. Но можно найти некоммерческий проект, в рамках которого ты будешь сотрудничать с теми, кто способен постепенно повысить твой уровень. Найди информацию о встречах специалистов, живущих в твоем городе, и начни принимать в них участие. Разработчики часто ищут проекты, которыми можно заниматься в свободное время, используя новые приемы и оттачивая имеющиеся навыки.
Если в твоем городе нет организованного сообщества программистов, используй интернет. Найди привлекательный открытый проект с командой, которая находится на более высоком уровне, чем твой. Узнай чем они занимаются, просмотри архивные рассылки, выбери функциональность, над которой работают, или обнаруженную критическую ошибку, и приступай к написанию кода! Имитируй стиль готового кода по данному проекту. Преврати это в игру. Пусть твой код и дизайн будут так похожи на остальные материалы проекта, что даже отцы-основатели, стоявшие у истоков, не смогут вспомнить, кто это написал. Как только результаты твоих трудов тебя устроят, покажи их. Если все сделано на уровне, твой фрагмент кода будет включен в проект После этого можно приступать к написанию следующего фрагмента Если разработчики проекта не согласны с твоим решением, внеси исправления с учетом их отзывов и повторно отправь на рассмотрение или же возьми на заметку данные ими рекомендации. Работая над следующим дополнением к проекту, попытайся обойтись меньшим количеством переделок. В итоге ты станешь полноправным членом команды. Ты удивишься, чему можно дистанционно научиться у опытных разработчиков, даже если вы никогда не встретитесь лично.
Совет 5
Инвестируй в интеллект
При выборе поля будущей деятельности порой так и подмывает остановиться на технологиях, с которыми связано максимальное количество рабочих мест. Например, заняться изучением Java. Или программировать для .NET. Знание Java позволяет претендовать, а возможно, и получить работу, связанную с написанием Java-кода.
По такой логике не имеет смысла вкладываться в узкоспециализированные технологии, особенно если вы не планируете работать в этой области.
Компания TIOBE Software воспользовалась поисковыми службами интернета для определения относительной популярности языков программирования. За основу были взяты обсуждения различных языков.[4] На сайте написано, что «общемировой рейтинг составлен по информации о наличии квалифицированных инженеров, курсов и независимых производителей». Разумеется, речь не идет о научно обоснованной оценке, но тенденции говорят сами за себя.
На момент написания данной книги самым популярным был Java, затем следовал C. C# занимал почетное шестое место, но его популярность росла. ABAP — внутренний язык программирования компании SAP — оказался на семнадцатом месте, медленно утрачивая свои позиции. Мой любимый язык программирования Ruby (именно на нем написаны все мои наиболее серьезные проекты, кроме того, я принимаю участие в организации ежегодных международных конференций по этой теме) был на одиннадцатом месте. Впрочем, к моменту выхода первого издания этой книги он перестал входить даже в первую двадцатку. Он проиграл даже ABAP!
Я спятил, если все еще пользуюсь Ruby? Или попросту глуп? На ум первым делом приходят эти два объяснения, не так ли?
Поль Грэм в статье «Великие хакеры»[5] утверждал, что программисты, пишущие на Java, далеко не так умны, как приверженцы Python. Он взбесил множество глупых Java-программистов (неужели я это написал?), которые принялись писать на своих сайтах развернутые контраргументы. Бурная реакция показала, что он задел за живое. Я присутствовал при первой презентации этой статьи. И она заставила меня вспомнить один эпизод.
Я приехал в Индию, чтобы набрать сотрудников, и просматривал сотни кандидатов, претендующих на десяток рабочих мест. Наша команда, проводящая собеседования, страдала от нехватки сил и времени из-за низкого процента успешно пройденных собеседований. Несмотря на поздний вечер, головную боль и красные глаза, мы не расходились, пытаясь найти новый подход к отбору кандидатов. Требовалось оптимизировать процесс, увеличив число интервьюируемых или каким-то образом привлекая более толковых людей (а лучше и то и другое). Тем, что осталось от моего голоса после двенадцатичасовых попыток получения ответов от ошеломленных программистов, я предложил добавить к ключевым словам, по которым наши специалисты по поиску персонала отбирали резюме из базы данных, слово «Smalltalk». «В Индии никто не знает этого языка», — кричал заведующий отделом кадров. Но на это и был направлен мой расчет. Ведь программирование на Smalltalk коренным образом отличается от программирования на Java. Вариативный опыт даст нам новый уровень требований к кандидатам, а динамическая природа Smalltalk позволит Java-программистам подойти к решению задач с другой стороны. Я надеялся, что эти факторы дадут нам специалистов с высоким уровнем технической подготовки, которого не было у уже просмотренных соискателей.
Добавление к списку требований Smalltalk удивительным образом уменьшило кадровый пул. Но теперь к нам приходили более одаренные люди. Они действительно разбирались в объектно-ориентированном программировании. Они знали, что Java не является универсальным, как его порой пытаются представить. Многие из них обожали программировать! Нам оставалось недоумевать, где же вы все были в предыдущие две недели?
К сожалению, наши возможности по привлечению подобных разработчиков сильно ограничивал уровень зарплат, которые мы могли предложить. В данном случае они могли диктовать свои условия, и большинство из них предпочло остаться на прежней работе или продолжить поиски. Мы потерпели неудачу с наймом, но получили бесценный урок: искать лучше среди кандидатов с многообразным (и даже нетрадиционным) опытом, а не среди тех, кто посвятил себя решению однотипных задач. Я объясняю это тем, что хорошие специалисты сами стремятся к разнообразию, потому что им нравится изучать новое. Да и вынужденная работа в незнакомой сфере формирует более зрелых и всесторонне образованных разработчиков программного обеспечения. Впрочем, по какой бы причине подобная ситуация ни сложилась, мы поняли, что она работает. Я до сих пор пользуюсь этим приемом при поиске разработчиков.
