Советы по карьере и навыкам

Перевод статьи Jon Skeet, Career and skills advice

Немного странно даже писать этот пост, но я получаю множество писем с просьбами советов о том, как стать лучше в программировании, как проходить интервью, кем лучше быть: универсалом или специалистом и т.д. Хочу, чтобы сразу было понятно: я не эксперт по профориентации. У меня очень мало оснований того, что эти советы стоящие; они могут и не быть дельными советами для Вас, даже если это хорошие советы в целом. Да, и не стоит ожидать нечто шокирующе-проницательного или оригинального. Вы также могли уже слышать все или часть этих советов.

Итак, с такими странными предостережениями, мои случайные мысли...

Общение, общение, общение

В программном обеспечении все дело в общении, пишете ли Вы проектную документацию, отвечаете на вопросы на Stack Overflow, ведете беседу на конференции пользователей, проходите интервью или просто пишете код. На самом деле, написание кода - это общение двух различных аудиторий одновременно: компьютера (компилятора, интерпретатора и др.) и того, кто будет читать и поддерживать код в будущем.

На самом деле, я вижу улучшение общения одним из основных преимуществ Stack Overflow. Каждый раз, когда вы спрашиваете или отвечаете на вопрос - это возможность практиковать общение с другими разработчиками. Является ли Ваш пост четким, насколько это возможно? Дает ли только правильный объем информации: ничего лишнего, в соответствующем и последовательном виде? Попадает ли в правильный тон с читателем, сдерживая любое разочарование из-за проблемы, с которой Вы столкнулись, или осознанных недостатков в тех, кому Вы отвечаете?

Stack Overflow является лишь одним из путей улучшения коммуникативных навыков. Существует много других:

• Написать блог, даже если Вы думаете, что никто не станет читать. Вы можете быть удивлены. Если Вы тратите время на написание о том, что находите интересным, очень вероятно, что кто-то еще заинтересуется этим. Если Вы вполне этим увлечены, подумайте о написании книги, - сейчас есть много вариантов для публикации, от традиционных издателей до онлайн-подходов.
• Найти возможность для создания презентаций, будь то в пользовательских группах, на конференциях или на работе. Понимаю, что не всем нравится представлять что-то большим группам людей, даже если убеждаюсь, что настроением трудно проникаться. (Кто бы не хотел бы быть в центре внимания? Я что, такой мелкий?
• Гордитесь своим общением в коде. Уделите больше времени документации и комментариям, чем обычно; старайтесь думать о том, что читая код, кто-то, возможно, пытается что-то выяснить. (Кроме того, думайте о том, что они должны знать об этом, даже если они не в курсе, что им нужно было это знать.)
• Много читайте и размышляйте о прочитанном. В то время, как мы привыкли комментировать качество и домыслы в сообщениях блога, мы не уделяем внимание сознательному обсуждению качества другой письменной работы. В следующий раз, читая документацию по какой-то библиотеке, которую используете, найдите время, чтобы спросить себя, насколько она эффективна и что способствует повышению качества (или влечет за собой отсутствие такового).

    Вы также можете убедиться, что улучшения Вашего общения также улучшает Ваши мыслительные процессы. Ясность идей и четкость выражений часто идут рука об руку.

Кодирование и отражение

Написав код, просмотрите его - в идеале в значительных промежутках времени. Код, который выглядит "круто" сегодня, может показаться незрелым шесть месяцев спустя.

Есть, конечно, различные виды кода, написанные под разными ограничениями. Вы можете обнаружить, что если Вы уже профессиональный инженер-программист, Вам не дают достаточно времени для критической оценки, но у Вас может быть преимущество в отзывах о коде от ваших коллег. (Отзывы о коде часто могут расцениваться как рутинная работа, но при подходе к ним в правильном расположении духа можно много узнать.) Если Вы сотрудничаете в проекте с открытым исходным кодом (open source project) - или, возможно, создаете такой проект с нуля, то можете убедиться, что у Вас есть больше возможностей, чтобы попробовать несколько подходов и оглянуться на код, написанный ранее

Чтение чужого кода может быть также полезным, хотя я считаю, что это один из тех видов деятельности, о которых больше сказано, чем на самом деле сделано.

Специалист или универсал?

Эрик Липперт написал о том, как ему дали совет, чтобы выбрать тему и стать по ней экспертом мирового уровня, и я думаю, что в этом заложен большой смысл. С другой стороны, Вы не хотите быть настолько ограниченным узкой областью знаний, чтобы развиваться в более широком мире. Здесь подводится баланс: "я универсал" с точки зрения наличия относительно малого количества навыков в конкретных областях дела, но я "специалист" с точки зрения языка: значительного объема отведенного времени на изучение C# и Java. Также я очень ограничен в плане того, в каких аспектах программного обеспечения я компетентен: я хотел бы думать, что я имею достаточную базу по разработке библиотек или серверного кода, но мой опыт разработки пользовательского интерфейса (будь то Интернет или клиентское приложение) сильно ограничен. Я также знаю меньше языков, чем хотел бы знать.

Вы должны решать то, что предпочтительно для Вас, - но это стоит делать сознательно, а не просто плыть по течению. Конечно, принимать продуманные решения - не то же самое, что выполнять их: несколько месяцев назад я решил, что было бы интересно сосредоточиться детально на разработке приложений на некоторое время (WPF , Windows Store, Android и IOS через Xamarin), но до сих пор достиг только небольших результатов.

Иногда меня спрашивают, какие технологии хороши с точки зрения трудоустройства. Это может быть очень локальным вопросом, но мой опыт показывает, что это действительно не имеет слишком  большого значения. Если Вы нашли то, во что увлечены, то все, что в этом узнаете, будет полезно в более обычной, но прибыльной среде. Технологии меняются достаточно быстро, так что Вам почти наверняка придется выучить несколько языков и платформ в Вашей карьере, так что Вы можете сделать увлекательными, по крайней мере, некоторые из этих вариантов.

Интервью

Об интервью было написано много советов людьми с намного большим опытом, чем у меня. На самом деле, я нечасто проходил интервью, хотя сейчас провожу их довольно много. Несколько общих советов:

• Не делайте слишком много преувеличений в своем резюме. Если Вы утверждаете, что являетесь экспертом в языке, а потом забываете, как написать объявление метода, это оставляет плохое впечатление.
• Узнайте заранее, что нужно компании и то, из чего, скорее всего, будет состоять интервью. Возможно, Вам будет предложено написать код на доске или в текстовом редакторе? Если это так, было бы неплохо попрактиковаться, - ведь это существенно отличается от написания кода в IDE. Если Вам, скорее всего, зададут вопросы об алгоритмической сложности, а знания с университета ощущаются как давным-давно забытые, следует их немного освежить.
• Будьте интересными! Это часто сводится к пристрастию в чем-либо. Если единственной мотивацией у Вас является: "Мне скучно на нынешней работе", не упоминая интересных сторон, интервью пройдет неудачно.
• Внимательно слушайте, о чем Вас спрашивают. Если конкретно просят игнорировать один аспект кодирования (проверку, производительность, какой бы она ни была), то не оправдывайте свой ответ, используя один из этих аспектов. Всеми средствами ссылайтесь на этот аспект, но руководствуйтесь данными Вам уточнениями, определенными как важные. (Баланс в интервью может перемещаться, так как Вас пытаются оценить по нескольким критериям.)
• Общайтесь ясно, насколько можете, даже пока размышляете. Я люблю, когда кандидаты объясняют свою точку зрения, как они справляются со сложной проблемой. Сразу видно, где ими управляет разум, насколько они интуитивны или методичны, где у них могут быть слабые стороны, - и я могу направлять их намеками. Это может стоить нескольких секунд, чтобы выработать наилучший способ озвучивания своих мыслей. Да, и если Вы пишете на доске, постарайтесь сделать это разборчиво.

Итог

Это полностью субъективное руководство Джона по интересной и прибыльной карьере в сфере разработки программного обеспечения. Если Вы решите действовать по некоторым из этих советов, я искренне надеюсь, что это скажется для Вас хорошо, но не гарантирую этого. Желаю удачи в любом случае!