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

Введение

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

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

Поехали.

Хороший vs плохой программист: 10 ключевых отличий

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

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

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

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

2. Аккуратность и дисциплина в коде

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

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

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

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

Костыль — это «быстрое и грязное» решение. Клиент доволен, программист доволен, задача решена малыми усилиями. Но в чем подвох?

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

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

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

Активное заселение костылей в проект приводит к тому, что при каждом изменении система начинает «фочить». Поменял в одном месте — отвалилось в другом.

Но тут есть и обратная сторона. Многое зависит от заказчика. Если он постоянно настаивает на сложных кастомных решениях в стиле «Хочу вот эту конфету и все!» — костылей не избежать. Заказчик тоже должен быть ответственным.

4. Общение и работа в команде

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

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

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

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

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

Я не сторонник бездумного внедрения всего нового. Но знать и изучать новые технологии — обязательно. Из них можно черпать свежие идеи и решения.

6. Ответственность за проект

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

Хороший программист сначала спросит: «А нужно ли это проекту? Поможет ли это достичь целей?». Внедрение новинки — это всегда риск. Баги, отсутствие готовых решений в интернете — все это может затормозить разработку.

Другой пример безответственности — кривые SQL-запросы. На маленькой базе они летают. Но когда данных становится много — все падает. Хороший программист знает такие подводные камни и учитывает их заранее. Плохой — забивает. Ему же не поддерживать.

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

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

Плохой программист хочет получить максимально локальную задачу. «Напишите мне алгоритм в ТЗ, я просто переведу его в код». Это практически программирование чужими руками. Неэффективно.

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

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

Знать 20 технологий поверхностно — не признак крутости. Лучше иметь глубокие знания по 2-3 ключевым. Что это значит? Уметь быстро и без запинок делать 80% типовых задач. Базовые знания должны быть «в кеше».

Если программист гуглит каждый чих — это плохо. Это как если бы писатель постоянно проверял, как пишется слово «молоко». Связного текста не получится. Хороший программист гуглит сложные и нестандартные вещи, а не то, что должен знать наизусть.

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

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

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

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

10. Качества хорошего программиста: итоговый чек-лист

Чтобы вам было проще, вот список качеств, на которые я смотрю в первую очередь:

• Думает о будущем: его код легко поддерживать и развивать.
• Аккуратен: пишет понятный, предсказуемый код.
• Избегает костылей: использует их только в крайнем случае.
• Коммуникабелен: делится знаниями и помогает команде.
• Постоянно учится: развивается и в профильных, и в смежных областях.
• Ответственен: думает о последствиях своих решений для проекта.
• Понимает бизнес: вникает в потребности пользователей и задачи бизнеса.
• Имеет сильную базу: быстро и качественно делает типовые задачи.
• Любит свое дело: у него есть pet-проекты и горящие глаза.

Заключение

Этот список, конечно, субъективен. Многое упущено. Но фокус здесь — на пользе для продукта. И заметьте: почти все эти качества — личные. Их сложно «натренировать». Они либо есть, либо их нет. Перевоспитать человека в этом плане практически невозможно. Поэтому задача бизнеса — не переделывать людей, а находить тех, у кого эти качества уже есть.

Часто задаваемые вопросы (FAQ)

Что важнее: опыт или личные качества программиста?

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

Как отличить хорошего программиста от плохого на собеседовании?

Спросите про его pet-проекты. Задайте вопрос: «Что ты думаешь о будущем этого кода?». Попросите привести пример, когда он отказался от использования новой технологии, потому что она не подходила проекту. Ответы покажут его ценности.

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

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

Нужно ли программисту знать бизнес?

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

Насколько полезной была статья?

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

Как программисты могут обманывать. Уловки программистов-мошенников

Как найти программиста и не пожалеть потом об этом

Взаимодействие с подрядчиками - как улучшить работу с программистом

Постановка задачи программисту. Как ставить задачу разработчику

Заказать сайт: цена вопроса. Как не переплатить и получить результат?

Как писать ТЗ программисту?