5 привычек неэффективных программистов +1




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


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


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


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




Мой код ЛУЧШИЙ


Ницше как-то сказал.


“На пути вверх за мною по пятам следует мой пёс по имени «Эго».”

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


Не высмеивайте чужой код, однажды он может оказаться вашим. Делайте как можно более объективные и профессиональные наблюдения, но не осуждайте. Будьте скромны и старайтесь учиться у окружающих.


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




И так сойдёт


Анджела Дакворт как-то сказала.


“Нет лёгких путей достичь совершенства.”

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


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


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




Я всё запомню. Записывать ничего не буду


Дик Брэндон попал в яблочко, когда заметил


“Документация — как секс. Когда она хороша — это очень, очень хорошо. Когда она плоха — это лучше, чем ничего.”

Документация — рыбий жир программирования. Менеджеры думают, что она полезна для программистов, вот только программисты её ненавидят!


Тем не менее, хорошие разработчики делают ведение документации неотъемлемой частью работы.


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


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


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


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




Это не я!


Брюс ли как-то заметил.


“Ошибки всегда простительны, если достаёт мужества их признать”

У нас всегда есть оправдание… Мы ведём себя так, как если бы никогда совершали ошибок и не можем совершить их в будущем. Звучит, честно говоря, не очень правдоподобно.


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


Вот только какой результат достигается перекладыванием вины? Вообще никакого.


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


А чем раньше вы признаете ошибку, тем раньше её исправите.




Ваше «готово» не значит на самом деле готово


Рик Лемонс справедливо заметил.


“Не заставляйте юзера вводить информацию, которую система уже знает.”

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


Помните, что завершённый продукт — это продукт протестированный и одобренный заказчиком. Готовности лишь с вашей стороны недостаточно, чтобы что-то считалось завершённым.


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


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




Заключительные мысли


Каким словом можно описать то, о чём говорится выше?


Ответ — словом «Отношение».

Здравое отношение к работе важнее любого количества лет опыта.


Наряду с позитивным мышлением оно отразится на том, что и как вы делаете. От отношения к работе зависит её качество и восприятие вас коллегами.

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (5):