Self Improvement

Плохие программисты вовсе не глупы. Просто у них есть вредные привычки.

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

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

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

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

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

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

Фридрих Ницше сказал:

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

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

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

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

Я исправлю это за секунду

Психолог и автор книг Анжела Дакворт как-то сказала:

 «Лёгкий путь не приведёт к истинному успеху.»

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

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

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

Я всё помню. Мне не нужна документация

Дик Брэндон весьма точно высказался на эту тему:

«Документация как секс: когда он хорош, это очень, очень хорошо, но когда он плох, то это лучше, чем ничего.»

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

Так или иначе, документация — неотъемлемая часть жизни великих разработчиков.

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

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

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

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

Это не я!

Как верно отметил Брюс Ли: 

« Ошибки всегда прощаются, если есть смелость признать их.»

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

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

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

И что получается в результате такого перекладывания вины? Ничего.

Важно адекватно относиться к происходящему. Простое признание, вроде: «О, извините, тут действительно ошибка, сейчас исправим.» — позволит сохранить лицо и заполучить расположение аудитории.

Чем раньше вы признаете ошибку, тем больше времени у вас будет, чтобы её исправить. Всё просто!!!

Ваше «Готово» далеко от реальности

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

Если провести параллель между программированием и сексом, то на сегодняшний день найдётся немало неудовлетворенных компьютеров. Словно вы остановились на полпути и провалились в сон. Один из важнейших концептов, который я пытаюсь до вас донести, — это фактор «Готово».

Запомните, это означает протестированную, удовлетворяющую потребности пользователей и опробованную в действии программу. «Думаю, готово» и «Готово» — принципиально разные понятия.

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

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

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

Подведение итогов

Итак, каким же словом можно объединить всё сказанное ранее?

Простой ответ —” подход”.

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

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

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

Хочется завершить цитатой Зига Зиглара:

«Ваш подход, а не способности, определяют ваш уровень.»

Читайте также:


Перевод статьи Ravi Shankar Rajan: 5 Bad Habits of Absolutely Ineffective Programmers.