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

1. Работать все время самостоятельно

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

2. Уверенность, что твой код самый лучший

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

3. Отказ писать плохой код

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

4. Обвинение других

Высокомерие – обычная черта среди технических специалистов, таких как разработчики. Умение признавать свои ошибки позволит вам выделиться из толпы. Не стесняйтесь извиняться, когда вы совершаете ошибки. После принятия данного факта, вы можете оценить ошибку, и проработать её, чтобы избежать в будущем. Неумение признавать ошибки делает невозможным дальнейшее обучение.

5. Переоцениваете собственный стиль

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

6. Романтизация своего инструмента разработки

Бывают случаи, когда ваш любимый редактор или инструмент командной строки не подходит для работы. К примеру, Visual Studio – хорошая IDE, Sublime – подходит для динамических языков, Eclipse – хороший инструмент для Java, и т.д. Vim или emacs могут быть вашими любимыми инструментами, но это не означает, что они подходят для любой ситуации.

7. Редкая обратная связь с менеджером/клиентом

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

8. Использование имен, которые не дают дополнительной информации

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

9. Недостаточно используете Google

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

10. Опускание рук

Стоит ли сдаваться так быстро? Несмотря на то, что они так близко к решению задач, слишком многие программисты сдаются раньше, чем найдут решение. Жизнь разработчиков полна испытаний, в этом нет сомнений. Наша повседневная жизнь полна новыми вызовами, и временами, когда застреваем над какой-то проблемой, мы хотим бросить её и перейти к другой. Однако, вы должны помнить, что “опускание рук” это не решение. Верно и то, что есть некоторые технические проблемы, которые мешают нам в разработке вещей. Тем не менее, это не означает, что задача не может быть решена, независимо от того, сколько времени займет процесс. Сдаться – это не то же самое что и остановиться, иногда нужно отложить задачу, и подойти к ней с чистым умом. Запомните, не позволяйте мысли о сдаче закрасться в ваш разум.


Привычки — это то, к чему мы привыкаем с возрастом. Выработка привычек, которым вы следуете, позволяет разгрузить наш мозг, и не думать над рутинными задачами. Когда вы привыкните к эффективным способам выполнения дел, они станут легкими, и не будут требовать усилий.

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

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

Комментарии (12)


  1. yesworldd
    11.04.2022 19:39
    +4

    Плохие привычка которая у меня была на самом начале - это учить все одновременно. Помню изучал java, python, sql, алгоритмы одновременно. Из за этого у меня была каша в голове. За двумя зайцами погонишься, ни одного не поймаешь, как говорится


    1. mayorovp
      11.04.2022 21:04

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


      Алгоритмы хочешь не хочешь — а придётся учить одновременно с другим ЯП, а изучение двух ЯП сразу позволяет лучше понять чем алгоритмы отличаются от их реализации.


      1. NeverIn
        13.04.2022 17:42

        Вот как раз SQL не лишний.


    1. alexshipin
      12.04.2022 01:46

      Согласен, когда изучал JS, Python (Django), PHP и C# (.net core и wpf), тоже была путаница, особенно, когда у тебя в Python пролезает camelCase, вместо рекомендуемого pep :-)

      В итоге, остановился на JS (основа) + C# (wpf, как хобби). И то, после JavaScript тяжело включиться сразу в C#, но, ничего, справляюсь :)


  1. ubx7b8
    11.04.2022 20:50
    +7

    У меня только одна вредная привычка - прокрастинация и завтра я с ней обязательно покончу!


    1. Schicout
      11.04.2022 21:05
      +2

      Послезавтра. Завтра прикину план - как с ней покончить.


      1. alexshipin
        12.04.2022 01:47
        +2

        После послезавтра. Завтра прикину план, а послезавтра будут думать над его реализацией и искать подвохи в исходном плане


      1. MrKirushko
        13.04.2022 14:30

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


        1. Schicout
          13.04.2022 14:47

          А как это осметить? Разработка технических предложений?


        1. dimti
          14.04.2022 13:33

          Чтобы составить, понадобиться планировщик. Нужно провести анализ рынка и попробовать разные платформы. Часть плана скорее всего придется разделить по разным CRM и баг-трекерам


  1. rubinstein
    12.04.2022 13:10

    Про goto забыли написать.


  1. ldss
    12.04.2022 17:07
    +3

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

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

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

    Имхо, конечно