Большой запрет для любого разработчика программного обеспечения

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

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

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

Эго

Что еще можно сказать об этом? У разработчиков программного обеспечения огромное эго. Может быть, это комплекс бога, который мы развили за годы, когда увидели себя творцами.

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

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

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

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

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

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

Влюбись в свой код

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

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

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

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

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

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

Пытаюсь сделать все самостоятельно

Хотя это тоже может попасть в категорию «Гордость», я думаю об этом с точки зрения «Жадности». В любом случае, это еще одно большое «нет-нет», которого нам нужно избегать как можно больше.

Ваш средний проект для платящего клиента должен включать:

  • Кодирование.
  • Автоматизированное тестирование.
  • Ручное тестирование.
  • Документация.
  • Развертывание.
  • Обслуживание.

А в разделе «Кодирование» у вас также есть такие вещи, как выбор правильного технического стека, понимание того, какие сторонние библиотеки вам придется использовать (то есть, с какой инфраструктурой пользовательского интерфейса вы будете работать, какой драйвер базы данных и т. Д.).

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

Сколько часов в день ты работаешь?

И даже если у вас есть рабочий день по 18 часов, и вы знаете, как все делать самостоятельно, позвольте мне задать вам простой вопрос: считаете ли вы, что вы лучший человек для тестирования собственного кода? Не думаете ли вы, что здесь может быть некоторая предвзятость создателя, которая мешает вам увидеть свои собственные ошибки?

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

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

Другой вариант - думать, что вам нужно кодировать все это, независимо от какой-либо сторонней библиотеки. Как будто тем самым вы внесете в систему какую-то нечистоту.

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

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

Сравнивая себя с разработчиками-знаменитостями и думая, что мы никогда этого не добьемся

Зависть - это сука, а социальные сети - ужасный ее источник. В моем случае я видел, как многие разработчики пострадали, сравнивая себя с другими в Твиттере (социальная сеть может измениться, но результат тот же).

Мы все видели Флорин Поп, Телмос и Джек Форджес сцены #TechTwitter. С их огромной аудиторией и успешной карьерой. И они абсолютно этого заслуживают, но вы не можете сравнивать себя с ними, на самом деле, поцарапать это можно, но не стоит.

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

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

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

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

Хорошие вещи приходят к тем, кто платит цену крови.

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

Оставить «ДЕЛАТЬ: исправить позже» во всем коде

Я имею в виду, что я могу сказать об этом, чтобы показать вам, что это настоящий грех?

Черт возьми, может быть, ОДИН из этих комментариев действительно потребовал достаточно больших усилий, чтобы заслужить немного подождать, чтобы исправить это. Однако я готов поспорить, что 90% этих комментариев можно было исправить прямо сейчас.

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

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

Есть два возможных способа избавиться от этого греха:

  1. Избегайте этого любой ценой. Каждый раз, когда вы пишете этот комментарий, устраните проблему. Не убегайте от работы, даже если вы думаете, что это займет у вас некоторое время, вы, вероятно, выйдете из нее, узнав что-то новое, и в следующий раз вы сделаете это быстрее.
  2. Превратите каждый комментарий в проблему в своей очереди. Какую бы систему вы ни использовали для отслеживания незавершенной работы, убедитесь, что вы превратили каждый из этих «ДОЛЖЕННЫХ» комментариев в реальную проблему, которую позже можно будет добавить в свою рабочую итерацию. Таким образом вы убедитесь, что требование не потеряно в море кода. Вам может потребоваться 3 дня или 3 месяца, чтобы разобраться с этим, но вы все сделаете.

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

Никогда не прекращайте читать учебные пособия

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

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

Это бесконечный цикл, вы всегда найдете то, чего никогда раньше не видели. Решение и единственный способ разорвать этот порочный круг - прыгнуть в воду.

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

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

Это, в свою очередь, предоставит вам информацию, необходимую для самостоятельной работы.

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

Обжаривание других разработчиков во время проверки кода

Рецензирование кода должно быть моментом обучения как для рецензента, так и для рецензента.

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

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

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

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

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

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

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

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