Плохой, хороший программист. В чем ключевые качества программиста?

Введение

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

Качества программиста хорошего и плохого

Как программа будет меняться в будущем?

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

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

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

Аккуратность

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

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

Избегание костылей. Результат работы программиста

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

Что тут плохого? 

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

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

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

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

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

Общение

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

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

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

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

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

Обучение. Что нужно знать программисту? 

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

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

Ответственность

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

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

Также частая проблема в плане ответственности - это криво написанные запросы SQL (или LINQ или чего-то подобного), которые работают хорошо только на малом объеме. А когда база вырастает, то запросы начинают работать медленно. 

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

Понимание бизнес-потребностей

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

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

Хороший программист принимает решения с учетом бизнес-ограничений и реалий потребностей пользователей. 

Сильная техническая база

Если программист знает 20+ технологий - это еще не признак хорошего программиста. Лучше бы он имел хорошие базовые знания по 2-3 ключевым технологиям. Что такое хорошие базовые знания? Это умение выполнять быстро без запинок 80% типовых задач. Т.е. все основные базовые знания у него находятся в кеше. 

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

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

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

Программист любит программировать

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

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

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

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

Заключение 

Список очень субъективный. Множество аспектов работы разработчика упущено. Фокус внимания в статье - на пользе для разрабатываемого продукта. Практически все рассматриваемые качества - личные. Т.е. они не поддаются простому нарабатыванию. Они обычно либо есть, либо их нет. Пробы переформатировать человека не сработают. Поэтому задача бизнеса - находить людей с нужными качествами, в первую очередь, личными качествами. 

Источник: https://falconspace.ru/blog/khoroshiy-plokhoy-programmist

ИП Чакветадзе Валерий Гочаевич

ИНН:645055105204

erid:2SDnjeJzV5K

ИП Саркисов Юрий Леонидович

ИНН:780707506874

erid:2SDnjdqtVW9

ООО «ТК НИКЕС»

ИНН:2108003297

erid:2SDnjdLWEXj

Ищешь бизнес идею по твоим интересам и финансам?

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

Пройти тест