Другими программистами - и ими самими

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

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

Я надеюсь, что эта статья, основанная в основном на моем собственном опыте, дает некоторые полезные идеи. Давайте нырнем!

Ниже приведены некоторые утверждения, которые многие из нас слышали или предполагали, которые являются ложью. Конечно, осознание того, что что-то является ложью, не означает автоматически истину, поэтому я здесь, чтобы отдать вам два цента за эти утверждения (которые являются ложью).

1. Если это работает, не трогайте его

Или более распространенная поговорка: «Если не сломалось, не чини».

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

Как вам, вероятно, говорят на работе, предлагать улучшения - это хорошо. Если все сделано правильно, то это - мы вернемся к этому позже. Но на практике чаще всего ваш вклад сначала не принимается. Более того, вы часто можете чувствовать, что вас наказывают за хорошие идеи. Не позволяйте этому разочаровывать вас!

Он не сломан. Это ложь или довольно слабое оправдание. По большому счету, нет неприкосновенного кода. Как указывает Джефф Этвуд, хотя есть много метафор для процесса разработки программного обеспечения, все они описывают процесс. Как бы хорошо ни была спланирована программа, в реальной жизни она развивается и меняется. От рефакторинга плохого дизайна до удаления мертвого кода и добавления или обновления комментариев. Это часть его здоровой жизни, иначе сад станет нездоровым, уродливым и, в конце концов, мертвым.

В отличие от университетских проектов, на самом деле ничего не делается.

Так что нет, тот факт, что код работает, не может служить оправданием для отказа от внесения изменений, даже если они бесполезны с точки зрения функциональности. Однако может быть что-то еще.

Спросите почему!

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

2. Информация, которой не делятся, - это безопасность работы

Или: Сложный код - гарантия работы.

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

Итак, во-первых, это ложь. Гарантия занятости - это ложь, как часто говорят, с самого начала, и ее не обязательно преследовать. Но что касается знаний, то в большинстве случаев компании не оставляют кого-то рядом только потому, что являются экспертами в каком-то сомнительном проекте наследия вуду, которого все боятся. Проще говоря, незаменимого человека нет, и если уж на то пошло, то нет и модуля.

Но даже если бы это было правдой, это не значит, что вы не расплачиваетесь за свою «безопасность», если идете по этому пути. На самом деле, вы сильно упускаете. Если у вас есть какое-либо намерение расти и продвигаться в своей компании и в профессиональном плане в целом, одним из наиболее продуктивных (и увлекательных) элементов вашей работы будет обмен знаниями. Это то, что делает вашу команду эффективной, часто это то, как вы получаете ценный вклад в свою работу, вдохновляете и вдохновляетесь, и это часть того, что в конечном итоге может сделать вас самым популярным человеком. Кроме того, чтобы придумать фразу, когда вы что-то объясняете, вы также объясняете это себе.

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

Кроме того, ваш работодатель всегда будет ценить вашу инициативу по обмену знаниями, поскольку заставить людей делать это больше (не только в мире программного обеспечения) - заведомо сложная проблема. Скажем так: действительно стоит задать вопрос: «Но если я передам все, что знаю, почему бы не продвинуть меня по службе?»

3. Вы не можете оспаривать X

«Вы» как новичок, а «X» - это личность, идея, политика, решение о продукте и так далее. Другими словами: «Не создавай смутьянов». Спойлер: Это ложь.

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

Важно отметить, что уровень и характер этого сопротивления сильно различаются между организациями и командами. Но он всегда есть и всегда будет. Примите это и научитесь с этим работать. Как я уже говорил ранее, не позволяйте этому разочаровывать вас. Даже если это кажется личным (что, вероятно, не так).

Мысль о том, что вы не можете оспаривать, ставить под сомнение, предлагать или вести изменения, - это ложь в вашей голове. Кто-то мог положить это туда, но принимаете вы это или нет - решать вам. Обычно среда разработки программного обеспечения в любом случае довольно открыта для обмена идеями. Если ваш вклад ценный и конструктивный, недостаток опыта должен быть второстепенным.

Конечно, все мы должны проявлять здоровое количество смирения, как красиво подчеркивается в этом посте. Изменение, большое или маленькое, - это прежде всего общение с людьми. Люди всегда знают или видят что-то по-другому, поэтому есть что сказать о том, как это сделать. Но если есть одно правило, которое у меня всегда было в отношении высказывания своего мнения, так это следующее: Будь бесстрашным.

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

4. Технология не имеет значения

Мир программного обеспечения стремительно развивается, поэтому повсюду очень ценится наличие разнообразных навыков - платформ, языков и фреймворков. Однако легко запутаться в таких утверждениях, как «Если ты хороший разработчик, технология второстепенна» или «Языки программирования, которые нужно изучать в 20ХХ».

Я на самом деле пытался продать себя на собеседовании (давным-давно…), как будто мне было все равно, какие технологии использует фирма. И какая-то часть меня действительно в это верила, считая это «правильным» отношением.

Я не могу диктовать чей-либо карьерный путь, однако предлагаю вам учесть следующие моменты:

  • Технология, с которой вы начинаете профессионально, влияет на направление вашей карьеры. Вы хотите сосредоточиться на серверной части? Тогда Angular (пример) в данный момент для вас не актуален. Говорит ли с вами мир больших данных? Тогда Python (пример) - отличный выбор. Суть в следующем: проводите исследование.
  • Тот факт, что Swift в какой-то момент опередил Ruby в некоторых опросах, не означает, что вам следует перейти на него сегодня. Кроме того, слишком много учиться сразу - это сложно и непрактично. Вам нужно сосредоточиться на чем-то и овладеть этим. Обширный опыт работы с конкретной технологией, вероятно, станет важной частью вашей компетенции - и для многих должностей, которые вам понадобятся в будущем, это обязательно. Это здорово и необходимо исследовать, но избегайте ловушки «Мастер на все руки, ничего не умеющий».
  • Однако не все технологии равны с точки зрения возможностей. Давайте рассмотрим языки программирования в качестве простого примера: у вас есть старые гиганты, такие как Java и C ++, восходящие звезды, такие как Rust и Go, и некоторые умирающие звезды, такие как Perl и Objective C. Имейте в виду, это очень динамично и в некоторой степени субъективно. Но выбирайте с умом. Когда вы ищете компании, которые смогут произвести впечатление благодаря семилетнему опыту работы с Object Pascal в 2020 году, технология не вторична, а вы. Что будет в ближайшие несколько лет?

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

5. Рабочий день - это день работы.

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

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

Возьмите эту тривиальную особенность: вам нужно предоставить функцию, выполняющую скрипт. Вот и все. Если вы думаете, что это однодневка (то, что мы называем «быстрой победой»), скажем, без встреч и перерывов, потерпите меня:

  • 10:00: начните считать пробелы в этом «требовании». Что делать с ошибками? Или выходное значение? А если мы застрянем - есть ли тайм-аут? Настраиваемый? Вам нужно перехватить выход? Что, если он огромный? Вы уловили мою мысль: первая проблема будет связана с актуальными требованиями. Для этого вам, наверное, нужны люди - так что иди поищи их. Прошло полдня. Обед.
  • 14:00: Обсуждая требования, выясняется, что другой проект должен использовать вашу функцию, поэтому вы не можете просто поместить ее в свой проект. Еще час политических дебатов о том, куда и как поставить, а затем на самом деле. Плюс перерыв на кофе.
  • 16:00: Наконец-то пишу код. И знаете что, вы закончили к 18:00! Так что, на самом деле это был двухчасовой репортаж, не так ли? Однако теперь вам нужна тестовая среда. День закончился.
  • На следующий день: у вас есть тестовая среда к 10:00, вы пишете несколько скриптов для тестирования к 12:00, обрабатываете и тестируете некоторые сценарии к 14:00, модульные тесты (не TDD, просто меняйте порядок) к концу дня . Завтра: запрос на извлечение, рецензирование, слияние и небольшой документ.

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

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

Бонус: вас оценивают по вашим навыкам программирования

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

«Решение проблем» как термин в школе (где вы учились пять минут назад) является отчасти частичным. Это скорее «обучение решению проблем» - оно вроде как предсказуемо. В реальной жизни, с другой стороны, решать одни и те же проблемы снова и снова - это последнее, чем вы хотите заниматься, и это не ваша работа.

Ваша задача решить их раз и навсегда - большая разница. И для этого вам необходимо идентифицировать их, оценивать, задавать вопросы, планировать, сотрудничать, инициировать, исследовать, общаться, адаптироваться. И все это с позитивным настроем, с использованием опыта, здравого смысла, ловкости и энтузиазма.

Наиболее важные навыки, которыми вы оцениваете, выходят далеко за рамки технических. Единственное выражение, которое я могу придумать, которое описывает их sort-of, - это одно слово: Профессионализм. Но это еще не все, поскольку цель - решить проблему. Формула может выглядеть великолепно и по-прежнему не работать по причинам, которые никого не волнуют, потому что цель - это результат.

Итак, скажем так: Вас оценивают по вашему профессионализму и по тому, как вы преобразуете его в результаты.

Не знаю, как вы, но для меня это звучит как освобождение. Вместо того, чтобы гоняться за собственным хвостом с техническими деталями, которые вас не всегда волнуют, от вас на самом деле ожидается, что вы будете использовать свои навыки для достижения реальной цели. Это похоже на то, что тебя вообще не измеряют.

Заключение

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

Спасибо за прочтение!