Плохие программисты вовсе не глупы. Просто у них есть вредные привычки.
Некоторые программисты лучше других. Существует своего рода статистика: небольшая группа программистов — на уровне «великолепно», чуть меньшая группа — просто хороши, большая часть программистов, по крайней мере, компетентна, некоторые — едва дотягивают до предыдущего уровня, ну а кто-то совершенно ужасен.
Дело в том, что разница между хорошим и плохим программистом не обязательно кроется в умении писать код. Всё куда проще: вредные привычки. С ними сложно бороться и в жизни, и на работе.
В такого рода привычках легко увязнуть, пока бьёшься с кодом, а это в свою очередь мешает раскрыть весь потенциал. Если одни привычки помогают ускорить работу, то другие могут навредить бизнесу и личной жизни.
Часто мы их не замечаем, поэтому нужна помощь со стороны. Как и в жизни, в программировании нет строгих и однозначных правил. Чтобы чего-то достичь, нужно импровизировать.
Давайте обсудим вредные привычки, касающиеся программирования, от которых нужно избавиться как можно быстрее.
Мой код — ЛУЧШИЙ
Фридрих Ницше сказал:
На какую бы вершину я не взбирался, за мной всегда следует собака по имени «Эго».
Каждой команде нужны такие люди: скромные, голодные и сообразительные. У скромных менее выражено это эго, у них фокус смещен наружу, на команду, а не на себя. Голодных отличает серьёзное отношение к работе, они зациклены на результате, готовы ради него на что угодно. Под сообразительностью подразумевается смышленость, а не ум.
Не критикуйте сверх меры чужой код, ведь и ваш может оказаться под прицелом. Повторюсь, не осуждайте, но старайтесь анализировать объективно, с профессиональной точки зрения. Будьте скромны, старайтесь учиться везде и всюду.
Помните, что ваше эго может стать помехой для хорошей работы. Излишняя вера в собственное превосходство — смерть для креативности. Из-за уверенности, что вы уже всё освоили, вы теряете возможность научиться чему-то новому.
Я исправлю это за секунду
Психолог и автор книг Анжела Дакворт как-то сказала:
«Лёгкий путь не приведёт к истинному успеху.»
Сделайте себе одолжение: позвольте получить максимум от жизни. Если вы всё свободное время будете драить одни и те же углы зубной щеткой, то рискуете упустить главное. Короткий путь не всегда приводит к скорому и лучшему результату.
Поиск лёгких решений весьма соблазнителен, так или иначе к этому прибегает каждый. Действительно, иногда такой подход необходим, но в целом он опасен. Его следует осознанно избегать. Потенциально лёгкий путь сэкономит пару часов, но позднее могут всплыть проигнорированные проблемы, что так или иначе обернется месяцами мучений и потерей репутации.
Отнеситесь к моему совету серьёзно. Мне сложно далось осознание того, что короткие пути и жизнь за бесплатно — это совсем не свобода.
Я всё помню. Мне не нужна документация
Дик Брэндон весьма точно высказался на эту тему:
«Документация как секс: когда он хорош, это очень, очень хорошо, но когда он плох, то это лучше, чем ничего.»
Документация — своего рода касторовое масло программирования. Менеджеры уверены, что составление документации — панацея для программистов, а последние её откровенно ненавидят.
Так или иначе, документация — неотъемлемая часть жизни великих разработчиков.
Они понимают, что, как любой другой бизнес-процесс, взаимодействие внутри команды разработчиков происходит в потоке. Программист может сменить работу, переехать в другой отдел, уволиться. В худшем из сценариев: болезнь, увечье или смерть могут лишить команду участника в самый неожиданный момент.
Или же код может устареть. Разработчик горазд забыть, как именно работает код годовой давности, если не притрагивался к нему в течение этого времени.
В любом случае, доступ к документации, API спецификациям, мануалу или комментариям в коде может стать решающим при определении результата: либо продукт будет успешно реализован, либо сорвутся дедлайны.
Ответственное отношение — вот, что ценится в команде. Вы не станете «незаменимым» только потому, что не пишите документации. Всё закончится непоправимой потерей репутации в команде и дальнейшими проблемами.
Это не я!
Как верно отметил Брюс Ли:
« Ошибки всегда прощаются, если есть смелость признать их.»
Возможно, эту мысль не просто принять, но в ней выражена одна из ключевых характеристик действительно хорошего разработчика.
У нас всегда есть право на ошибку. Трудно поверить, что при всех прочих нормальных условиях, у нас нет ни малейшего шанса ошибиться.
Плохие разработчики обвиняют пользователей в том, что они “неправильно” используют продукт. Плохие разработчики не готовы брать ответственность за результат своей работы и баги. Они приложат все силы, чтобы убедить общественность в том, что причина ошибки — кто-то другой.
И что получается в результате такого перекладывания вины? Ничего.
Важно адекватно относиться к происходящему. Простое признание, вроде: «О, извините, тут действительно ошибка, сейчас исправим.» — позволит сохранить лицо и заполучить расположение аудитории.
Чем раньше вы признаете ошибку, тем больше времени у вас будет, чтобы её исправить. Всё просто!!!
Ваше «Готово» далеко от реальности
«Не заставляйте пользователя вводить информацию, которая уже известна системе.»
Если провести параллель между программированием и сексом, то на сегодняшний день найдётся немало неудовлетворенных компьютеров. Словно вы остановились на полпути и провалились в сон. Один из важнейших концептов, который я пытаюсь до вас донести, — это фактор «Готово».
Запомните, это означает протестированную, удовлетворяющую потребности пользователей и опробованную в действии программу. «Думаю, готово» и «Готово» — принципиально разные понятия.
Хороший разработчик стремится постоянно узнавать что-то новое. Он жаждет понять, как взаимодействуют кусочки архитектурной мозаики. Он пересматривает и перерабатывает дизайн, идеи, концепты фич, чтобы найти лучшее решение. Он понимает, что именно создаёт положительный пользовательский опыт.
С другой стороны, плохой разработчик придерживается одной технологии, своей любимой. Он уверен, что только такой путь «идеален» и что решение не должно исходить ни из обстоятельств конкретной ситуации, ни из пользовательского опыта. Он привносит в проект ненужные зависимости, лишь бы тот соответствовал его предпочтениям.
Плохого разработчика можно сравнить со слоном в посудной лавке. Он разрушителен, зря тратит силу и портит репутацию.
Подведение итогов
Итак, каким же словом можно объединить всё сказанное ранее?
Простой ответ —” подход”.
Ответственный подход к работе может компенсировать даже отсутствие многолетнего опыта.
Просто работать не достаточно, нужно придерживаться максимально ответственного подхода. И порой корректное отношение оказывается в разы ценнее прокачанных навыков.
Адекватное отношение вкупе с оптимистичным мышлением отразится на вашем стиле работы и значительно повысит продуктивность. Это определит и то, каких результатов вы добьётесь, и то, как к вам будут относиться другие люди. Хорошее отношение заразительно. Оно меняет сначала вас, а потом и ваше окружение.
Хочется завершить цитатой Зига Зиглара:
«Ваш подход, а не способности, определяют ваш уровень.»
Читайте также:
- Секрет быстрого обучения
- Почему люди проваливают собеседования по алгоритмам и структурам данных в крупных компаниях?
- Гибкие навыки для разработчика программного обеспечения
Перевод статьи Ravi Shankar Rajan: 5 Bad Habits of Absolutely Ineffective Programmers.
