Просто о сложном
ОККАМ
13.06.2024
ADPASS рекомендует материал к прочтению
Falcon Space
Плохой, хороший программист. В чем ключевые качества программиста?
В этой статье разберем качества хорошего и плохого программистов. Я не претендую на истину последней инстанции. Я исхожу из ценности программиста для разрабатываемого продукта, а не от развития его карьеры, рисков увольнения и других смежных с чистой разработкой тем.
Введение
В этой статье разберем качества хорошего и плохого программистов. Я не претендую на истину последней инстанции. У каждого разработчика эти 2 списка будут уникальными. Также важный момент — я исхожу из ценности программиста для разрабатываемого продукта, а не от развития его карьеры, рисков увольнения и других смежных с чистой разработкой тем.
Качества программиста хорошего и плохого
Как программа будет меняться в будущем?
О чем задумывается хороший программист? Как это будет использоваться и меняться потом. Плохой программист не интересуется зачем это, как оно будет развиваться. Его задача — уложиться в рамки задачи, а что будет после — хоть трава не расти. Это ключевая штука, так как большая часть жизненного цикла продукта — это не разработка, а правки, доработки. От первичной реализации продукта сильно зависит, насколько сложно его потом поддерживать.
Если вы создаете код, который проблематично поддерживать или сложно развивать — это негативный сигнал.
Аккуратность
Если вы пишете неаккуратно, то вы не заботитесь о будущем чтении кода. Дело в том, что программисты читают код в общем случае больше, чем его пишут (особенно на этапе поддержки). Плохо написанный кривой код очень сложно понимать и требуется еще время на борьбу с небрежностью (малый рефакторинг).
Но аккуратность, это не только отступы, скобки. Это еще и дисциплина в именовании переменных, методов. Если вы каждый раз удивляете читателя кода своими уникальными именами — это плохо. Ваши названия должны быть прогнозируемыми и понятными без лишних комментариев. Вы можете назвать x1 количество заказов, но гораздо понятнее и проще, когда вы используете orderCount.
Избегание костылей. Результат работы программиста
Костыль — это не очень хорошее решение, которое программист внедряет в проект, чтобы решить задачу клиента. Клиент доволен, что его задача решена, программист доволен, что сделал это малыми усилиями.
Что тут плохого?
Костыли усложняют будущую поддержку и повышают риски сбоев. Хороший программист должен всеми силами противиться внедрению костылей в проект и задействовать их только в случае, когда выполняется 3 условия:
-
Заказчик не может жить без этой фичи.
-
Нет другого решения ее реализовать.
-
Костыль имеет ограниченные последствия.
Плохой программист вообще не задумывается об этом — он же нашел решение и имеет право его применить, тем более заказчик ничего не узнает про это, по крайней мере сейчас.
Активное заселение костылей в проект приводит к тому, что проект при изменениях и доработках может выдавать разные фокусы — поменял в одном месте, отвалилось в другом.
Также надо здесь сказать, что многое зависит от упрямости заказчика. Если он постоянно настаивает на внедрении сложных кастомных решений в проект, то в любом случае в нем появятся костыли. То есть заказчик должен принимать решения взвешенно, с учетом возможных проблем, а не в стиле «Хочу вот эту конфету, Хочу и все!».
Общение
Плохой программист совсем нелюдим и высокомерен. Конечно бывают исключения, но такая отгороженность от других обычно препятствует развитию.
Для продукта это нехорошая штука, когда ключевые программисты на проекте не идут на контакт. В итоге они просто могут уйти, а поддержка будет осложнена тем, что никто не знает, как это все работает.
Хороший программист делится информацией с командой и пытается помочь. Это не относится чисто к разработке, но это играет важную роль для развития продукта.
Создание продукта — это не написание гениального кода. Это взаимодействие и слаженная работа разных звеньев.
Вам не нужен гениальный программист, код которого никто кроме него не может поддерживать.
Обучение. Что нужно знать программисту?
Хороший программист постоянно учится. Это становится привычкой. Причем это необязательно должны быть языки программирования. Чем больше программист понимает в смежных областях, тем выше его ценность.
Я не сторонник бездумного внедрения всех подряд технологий (об этом в следующем разделе), но знать, изучать их требуется обязательно. Хороший программист должен черпать новые идеи и знания из появляющихся технологий.
Ответственность
Вышла новая интересная технология. Что делает беспечный программист? Он сразу пытается это внедрить в проект. И у этого есть свои личные плюсы: ты добавляешь строчку в резюме (увеличиваешь свою ценность) и за чужой счет можешь проработать технологию на практике (то есть получить реальный опыт).
Хороший программист должен задуматься: «А нужно ли это проекту?» Поможет ли это внедрение достичь целей проекта? Внедрение новой технологии — это всегда риск возможных проблем (баги, нет базы решений в сети по проблемам и так далее).
Также частая проблема в плане ответственности — это криво написанные запросы SQL (или LINQ или чего-то подобного), которые работают хорошо только на малом объеме. А когда база вырастает, то запросы начинают работать медленно.
Опытный хороший программист знает эти моменты и старается их учитывать при разработке. Опытный плохой программист плевать хотел на эти детали оптимизации, так как не ему потом поддерживать систему. Он просто сдает задачу и все. Тут мы говорим не об опыте программиста, а к тому, как он подходит к задаче.
Понимание бизнес-потребностей
Программа создается не для того, чтобы занять чем-то программистов. Она нужна для бизнеса. Чем лучше это понимает программист, тем более взвешенные решения он будет понимать. Знание предметной области напрямую влияет на структуру базы данных. Не понимания бизнес-логику в структуре БД могут быть серьезные ошибки.
Плохой программист хочет максимально локальную задачу, чтобы не думать ни о чем внешнем. Ему нужно прописать в идеале прямо алгоритм в задаче. В этом случае вы практически программируете опосредованно его руками. Это не очень хорошо. С другой стороны — это не повод ставить как попало задачу в стиле «тыжпрограммист».
Хороший программист принимает решения с учетом бизнес-ограничений и реалий потребностей пользователей.
Сильная техническая база
Если программист знает 20+ технологий — это еще не признак хорошего программиста. Лучше бы он имел хорошие базовые знания по 2–3 ключевым технологиям. Что такое хорошие базовые знания? Это умение выполнять быстро без запинок 80% типовых задач. То есть все основные базовые знания у него находятся в кеше.
Если он делает типовую задачу, он не гуглит по каждому поводу. Умение правильно гуглить, это очень хорошо, но если это делается для каждого чиха — это очень плохо. Это как если бы автор книги постоянно бы гуглил как пишется то или иное слово. Не получится написать что-то связное и стройное, если постоянно прерываться на простые вещи.
Если вы совсем новичок и хотите делать карьеру в IT, мой совет — работайте над базой. Выберите 2 технологии и вдоль и поперек проработайте базовые вопросы на практике.
Пусть вы не знаете каких-то тонкостей работы, но вы просто должны уметь быстро выполнять простые операции.
Программист любит программировать
Ключевое — программист должен просто любить это делать. Если этого нет, то скорее всего и навыки будут делаться чисто напоказ, то есть чтобы просто казаться хорошим программистом, а не быть им.
Программиста, в отличие от менеджера, довольно легко проверить по этому критерию — посмотреть проекты, которые он разработал сам для себя.
Если у человека нет pet проектов (то есть проекты, которые они делают для себя, чтобы что-то проработать или узнать), то скорее всего он ждет побыстрее пятницы и ненавидит понедельники, а в выходные занимается чем угодно, кроме программирования.
Если человек любит разработку просто как вид деятельности, то задача менеджмента — просто создать для этого идеальные условия и не мешать ненужными правилами (дресс-код, частые планерки и так далее).
Заключение
Список очень субъективный. Множество аспектов работы разработчика упущено. Фокус внимания в статье — на пользе для разрабатываемого продукта. Практически все рассматриваемые качества — личные. То есть они не поддаются простому нарабатыванию. Они обычно либо есть, либо их нет. Пробы переформатировать человека не сработают. Поэтому задача бизнеса — находить людей с нужными качествами, в первую очередь, личными качествами.
Лучшее в блогах
10.06.2024
Вам понравится
eLama
11.06.2024
Маркетинговое агентство «В точку»
31.05.2024
IT Test
20.05.2024
Что предпринять компании для защиты от киберугроз
![]()
Опубликован первый мировой рейтинг киберпреступности с основными угрозами и списком стран, откуда их исходит больше всего. Рассказываем, какие риски распространены сегодня в сфере информации, как на их развитие влияет ИИ и почему управление сторонними рисками может помочь обезопасить компании.
Неделя рекламы 
Новости 
Кейсы 
How to 
Интервью и дискуссии 
Маркетинговые исследования 
Проверено ADPASS 
Рекламные кампании 
