Перевод второй части статьи «11 Realpolitik Career Tips for Junior Developers».
Автор этой статьи, Эрик Дитрих, имеет большой опыт работы в разных компаниях, а в настоящее время занимается консультированием. Мы уже публиковали перевод первой части его статьи с «реалполитик»-советами начинающим разработчикам, а теперь представляем вторую часть.
6. Относитесь с большим (очень большим!) подозрением ко всяким показателям, которые тешат ваше тщеславие, и геймификации карьеры
Помните, как в первой части статьи я иронизировал насчет того, что всех программистов на Земле можно рассортировать, опираясь на их счет на Stack Overflow? Что ж, Stack Overflow в нашей индустрии — отличный пример очень острого (и при этом обоюдоострого) меча — геймификации.
У вас 150 тысяч очков на Stack Overflow? Прекрасно! Просто потрясающе! Добавьте еще два доллара, и сможете купить содовую на заправке!
Вот еще несколько вещей, к которым можно добавить 2 доллара и купить все ту же содовую:
- Ежедневное участие на GitHub в течение 365 дней и полученную за это метку «железный кодер».
- Выступления на 20 «пользовательских группах» и конференциях и заслуженную победу в конкурсе ораторского искусства им. Кеннеди в вашем регионе.
- Еженедельные публикации статей на сайте сообщества в течение 52 недель и бейджик Уолтера Кронкайта за это (Уолтер Кронкайт — популярный репортер и ведущий новостей в США, — прим. перев.).
- Искренняя и сердечная благодарность вашего работодателя за то, что отработали 50 часов в неделю вместо 40.
Когда ваши заслуги получают признание, это дает приятные ощущения, спору нет.
Но мы, разработчики, имеем уникальную и злосчастную склонность делать все эти награды и звания самоцелью, а не лишь средством для достижения какой-то цели.
В общем, если вы собираетесь заняться чем-то, что потребует от вас много времени, усилий, труда и самопожертвования, спросите себя, зачем это вам. Не участвуйте в бессмысленных состязаниях ради получения фантиков.
7. Мир разработки в целом и ваша компания в частности — не меритократия
Давайте обсудим идею того, что сфера разработки это меритократия.
Если корпорация-гигант нанимает кого-то и платит ему больше других, значит, этот человек талантлив. Если ему платят меньше или вообще не нанимают, значит, он менее талантлив.
Индустрия, где все любят определять свой ранг и оценивать себя по очкам, бейджикам и подобным вещам, естественно предполагает, что такое ранжирование является рациональным. Работайте над повышением своих оценок, изучайте алгоритмы и структуры данных, станьте асом в прохождении собеседований, работайте сверхурочно — и космический бог ранжирования программистов вознаградит вас за это. Верно?
Нет, не совсем.
Мы в нашей индустрии не можем даже прийти к единому мнению, что такое «хороший код», не говоря уже о том, чтобы определить способ его объективной оценки. Мы говорим себе, что вознаграждаем производительность, но в основном мы просто повышаем людей за то, что они продержались на работе достаточно долго и не дали себя уволить.
Разработчики спорят буквально обо всем на свете, но есть одно утверждение, с которым согласны все: система найма в нашей отрасли сломана.
Вы надеетесь, что, став «хорошим» программистом, в результате обязательно получите повышение и признание? Не слишком на это рассчитывайте.
8. Одни результаты лучше других, но что такое «хороший код», никто не знает
Давайте углубимся в тему, затронутую в предыдущем пункте. Пройдемся по статьям, где дается определение «хорошего кода», и посмотрим, что там говорится.
Первый результат поиска, на котором я остановился, был следующий:
«Первое, что приходит в голову, это поддерживаемость. Если другим разработчикам сложно разбираться в вашем коде, поддерживать его и расширять, это определенно не хорошо. Затем на ум приходят и другие вещи: эффективность, элегантность (простота, правильное использование конструкций языка и возможностей среды), модульность, правильный объектно-ориентированный дизайн, …»
Хорошая попытка. То есть, для определения хорошего кода можно использовать любой из кучи пунктов.
Давайте рассмотрим второй пример.
«Мы часто обсуждаем принципы, которыми руководствуемся при написании хорошего кода, — разработку через тестирование, объектно-ориентированное программирование, SOLID, DRY, закон Деметры — этот список можно продолжить».
Прекрасно! Теперь у нас совершенно новый набор терминов (по сравнению с первой статьей).
Обратимся к третьему примеру:
«Хороший код — это хорошо структурированный код. Человеку, который пытается в нем разобраться, должно быть очевидно, где блок кода начинается и где он заканчивается. Прослеживание логики в кодовой базе должно быть простым и явным».
О, прекрасно, наконец-то мы можем прийти к какому-то единому мнению!
Кто не понял — это был сарказм. Погуглите «хороший код» — и вы убедитесь, что его определения вообще не пересекаются.
Но это не значит, что «хороший код» — это какая-то нигилистическая трясина релятивизма.
Когда на обновления уходит меньше времени, а не больше, это хорошо. Код, в котором проявляется меньше дефектов, если его тронуть, — лучше кода, который вводит вас в заблуждение. И если для какого-то действия можно написать меньше кода, а не больше, лучше так и поступить.
Но при этом лучше сразу избавиться от иллюзий насчет того, что существует какое-то универсальное определение хорошего кода. В основном на вас просто орут другие люди, опирающиеся на свой большой опыт в какой-то анекдотичной сфере деятельности и небольшие эмпирические исследования.
9. Не учите технологии, «чтобы было». Действуйте по плану
О, вот это хороший совет! Вам случалось зайти на какой-нибудь сайт сообщества и прочесть там комментарии вроде «Я собираюсь изучить язык (фреймворк, парадигму), чтобы расширить кругозор»?
У меня такое было. Причем я и читал подобные комментарии, и сам писал их. Помню, как однажды затвитил что-то вроде «Буду изучать F# в эти выходные!».
Но вы поступайте, как я говорю, а не как я сам поступаю (поступал). Не изучайте стеки, технологии, языки и фреймворки только потому, что они есть.
Ой, да знаю я… Сразу думаешь: «Но индустрия развивается в этом направлении, и все вокруг уже знают эту технологию. Это же инвестиция в мое будущее».
Никакая это не инвестиция. Пожалуйста, поверьте мне.
Я писал код на 10 языках (на профессиональном уровне). А уж сколько всяких фреймворков и инструментов знаю, и передать не могу.
И что, мне это чем-то помогло? Конечно, я думаю, что в определенной мере помогло.
Но насколько лучшим программистом сделала меня каждая изученная технология? Моя мудрость и видение — результат того, что я программировал на Python (языке, где пробелы значат очень много) или на C / C++ / C# / Java / Perl / Assembly / Visual Basic / PHP / Ruby / JavaScript (языках без такого упора на пробелы)?
Безусловно, изучать новые технологии это не плохо. Но в этом нет и ничего безусловно хорошего.
По мере развития вашей карьеры вы станете замечать, что многие программисты систематически изучают все новейшие технологии и в результате делают свой набор навыков в милю шириной и в дюйм глубиной. Подавляйте такие позывы. Совершенствуйтесь в том, с чем работаете, а новые технологии изучайте тогда, когда у вас есть четкое понимание того, какую пользу это принесет вашей карьере.
10. Собеседования по алгоритмам и практика в собеседованиях это гонка по нисходящей
Если вы зайдете в Twitter и полистаете твиты программистов, вы очень быстро наткнетесь на какой-нибудь популярный твит на тему «система найма в сфере разработки сломана». При этом обязательно будут упомянуты хрестоматийные собеседования по алгоритмам и структурам данных, а также с применением белой доски. Но столь же несложно найти статьи и посты о том, как «взломать» эти собеседования.
Что это такое? Дихотомия?
Причина этого в том, что корпорации Кремниевой долины (так называемые компании FAANG) задают тон, а более мелкие компании хотят им подражать.
Многие люди смирились с этими собеседованиями, потому что, как бы это ни было тупо, но без них не пробьешься в престижную компанию.
Но есть и те, кто критикует эту процедуру собеседований, считая ее бессмысленным издевательством над новичками. Даже глава HR-отдела в Google однажды охарактеризовал процесс собеседования как «полный бардак». Критики этих собеседований просто указывают на то, что дедовщина это плохо и тупо — независимо от того, насколько сильно вы хотите вступить в братство, где она процветает.
Но я хочу предложить вам вообще другой взгляд на ситуацию. Несмотря на все достоинства и недостатки этих собеседований, они в любом случае ставят вас в положение просителя, а «ветерана» индустрии с 2-летним опытом работы — в позицию вашего начальника. И даже если вы пройдете собеседование, добровольно согласившись на унижение в этом ритуале дедовщины, вы все равно попадете в самый низ крупной организации.
Вы должны понимать, как обстоят дела. Профессионалы не позволяют издеваться над собой.
11. Любите свою работу, но боритесь с каждым, кто пытается использовать эту любовь против вас
Несколько лет назад я посмотрел видео, которое нашел довольно интересным. Оно называлось «Drive: The Surprising Truth about What Motivates Us» («Драйв: неожиданная правда о том, что нас мотивирует»). Там продвигалась идея, что мастерство, автономия и предназначение значат для нас куда больше, чем деньги (после достижения некоего минимального дохода). Мы хотим чувствовать, что становимся лучше, и чтобы хорошо работать, нам нужна свобода и ощущение, что мы участвуем в чем-то большом и важном.
Мне все это показалось довольно правдивым взглядом на вещи. Но вместе с тем я заметил, что организации часто склонны использовать эти наши желания против нас же. Не сложно заметить, что компании эксплуатируют стремление разработчиков к мастерству, предлагая им в качестве поощрения разные «плюшки» (типа «одобрительно похлопать по плечу») вместо повышения зарплаты (см. раздел о геймификации).
Так что в качестве последнего совета я умоляю вас проявлять осмотрительность.
Если наши с вами вкусы совпадают, вы найдете разработку программ очень интересным и благодарным делом. А если устроитесь на хорошую работу с достойной зарплатой, то и жизнь ваша будет довольно хороша.
Чего еще желать?
Ну, на самом деле есть, чего пожелать. Кому-то не хватает сущих мелочей, а кому-то — довольно много всего.
Вам может очень нравиться ваша работа, а ваша компания может хорошо вам платить. Но никогда не следует упускать из виду ценность, которую вы создаете. Так же, как и позволять кому бы то ни было убедить вас, что ваша любовь к работе каким-то образом снижает ее стоимость. Не соглашайтесь с утверждениями вроде «когда любишь работу, то она сама по себе награда». Не позволяйте работодателю подменять денежное вознаграждение бессмысленными плюшками и «культурой».
Это не значит, что нужно всегда и во всем быть меркантильным и выгрызать каждый доллар. Если работа вам нравится и зарплата устраивает — супер! Но следите за тем, чтобы это был ваш сознательный выбор, а не результат того, что вас надули и в переговорах о зарплате использовали против вас вашу же любовь к работе.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]