Страница-источник на сайте falconspace.ru
Вы когда-нибудь работали с программистом, после которого хотелось закрыть проект и уйти в лес? Я — да. И наоборот: встречал ребят, с которыми даже самая сложная задача превращалась в удовольствие. В чем разница? Не в количестве языков, которые они знают. И не в том, сколько лет опыта у них в резюме.
Эта статья — не про «идеального кодера». Она про то, как отличить человека, который реально двигает продукт вперед, от того, кто просто «отрабатывает часы». Я покажу вам качества, которые напрямую влияют на успех проекта. Вы сможете быстрее оценивать коллег, кандидатов или даже самого себя. И главное — поймете, на что реально обращать внимание, чтобы не попасть в ловушку «опытного, но бесполезного» специалиста.
Поехали.
Хороший программист думает на шаг вперед. Он спрашивает: «Как это будут использовать через полгода? А через год?». Ему важно, чтобы код было легко менять и допиливать.
Плохой программист не парится. Его задача — «закрыть таску» здесь и сейчас. «А что будет потом — не моя проблема». Он не думает о том, как его код повлияет на будущие доработки.
Это критично. Потому что 80% жизни продукта — это не первая разработка, а постоянные правки и улучшения. И то, как написан код изначально, определяет, будет ли поддержка адом или рутиной.
Важно: Если вы создаете код, который сложно поддерживать или развивать — это красный флаг. Вы не просто пишете программу, вы закладываете фундамент для будущих изменений.
Программисты читают код гораздо чаще, чем пишут. Особенно на этапе поддержки. Если вы пишете небрежно — вы усложняете жизнь всем, кто будет работать с вашим кодом после вас.
Аккуратность — это не только про отступы и скобки. Это про дисциплину в именовании. Если вы называете переменную x1, а могли бы назвать orderCount — вы заставляете читателя каждый раз гадать, что вы имели в виду. Хороший код должен быть предсказуемым и понятным без лишних комментариев.
Плохой код — это как плохой почерк врача. Разобрать можно, но нужно время и нервы.
Костыль — это «быстрое и грязное» решение. Клиент доволен, программист доволен, задача решена малыми усилиями. Но в чем подвох?
Костыли — это бомба замедленного действия. Они усложняют поддержку и повышают риск сбоев. Хороший программист борется с ними до последнего. Он использует костыль только в крайнем случае, когда выполняются все три условия:
Плохой программист не задумывается. Он нашел решение — значит, имеет право его применить. Заказчик все равно не узнает... пока.
Активное заселение костылей в проект приводит к тому, что при каждом изменении система начинает «фочить». Поменял в одном месте — отвалилось в другом.
Но тут есть и обратная сторона. Многое зависит от заказчика. Если он постоянно настаивает на сложных кастомных решениях в стиле «Хочу вот эту конфету и все!» — костылей не избежать. Заказчик тоже должен быть ответственным.
Плохой программист — часто нелюдим и высокомерен. Он «варится в собственном соку» и не делится информацией. Для продукта это катастрофа. Такой ключевой разработчик может просто уйти, и проект встанет. Никто не знает, как работает его код.
Хороший программист — открыт к общению. Он помогает коллегам, делится знаниями. Это не про «софт скиллы» ради галочки. Это про здоровье продукта. Создание продукта — это не написание гениального кода в одиночку. Это слаженная работа всей команды.
Вам не нужен гениальный программист, код которого никто, кроме него, не может поддерживать. Это обуза, а не актив.
Хороший программист учится постоянно. Это привычка. И речь не только о новых языках. Чем больше он понимает в смежных областях (бизнес, дизайн, тестирование), тем выше его ценность.
Я не сторонник бездумного внедрения всего нового. Но знать и изучать новые технологии — обязательно. Из них можно черпать свежие идеи и решения.
Вышла новая крутая технология. Что делает безответственный программист? Пытается запихнуть ее в проект. Ему это выгодно: в резюме появится новая строчка, а опыт он получит за чужой счет.
Хороший программист сначала спросит: «А нужно ли это проекту? Поможет ли это достичь целей?». Внедрение новинки — это всегда риск. Баги, отсутствие готовых решений в интернете — все это может затормозить разработку.
Другой пример безответственности — кривые SQL-запросы. На маленькой базе они летают. Но когда данных становится много — все падает. Хороший программист знает такие подводные камни и учитывает их заранее. Плохой — забивает. Ему же не поддерживать.
Программа пишется не для того, чтобы занять программиста. Она нужна бизнесу. Чем лучше разработчик понимает бизнес-логику, тем более взвешенные решения он принимает. Это напрямую влияет на структуру базы данных и на то, насколько система будет удобна пользователям.
Плохой программист хочет получить максимально локальную задачу. «Напишите мне алгоритм в ТЗ, я просто переведу его в код». Это практически программирование чужими руками. Неэффективно.
Хороший программист сам вникает в потребности пользователей и бизнес-ограничения. Он не ждет готовых решений, а предлагает свои.
Знать 20 технологий поверхностно — не признак крутости. Лучше иметь глубокие знания по 2-3 ключевым. Что это значит? Уметь быстро и без запинок делать 80% типовых задач. Базовые знания должны быть «в кеше».
Если программист гуглит каждый чих — это плохо. Это как если бы писатель постоянно проверял, как пишется слово «молоко». Связного текста не получится. Хороший программист гуглит сложные и нестандартные вещи, а не то, что должен знать наизусть.
Если вы новичок и хотите расти в IT — мой совет: работайте над базой. Выберите 2 технологии и проработайте основы на практике вдоль и поперек. Пусть вы не знаете всех тонкостей, но простые операции вы должны делать на автомате.
Это ключевой момент. Если человек не любит свое дело, он никогда не станет по-настоящему хорошим специалистом. Он будет делать вид, что учится, и имитировать бурную деятельность.
Как это проверить? Посмотрите на его pet-проекты. Проекты, которые он делает для себя, в свободное время. Если их нет — скорее всего, он считает дни до пятницы и ненавидит понедельники. Если есть — значит, программирование для него не просто работа, а образ жизни. Задача менеджмента в таком случае — просто не мешать и создать комфортные условия.
Чтобы вам было проще, вот список качеств, на которые я смотрю в первую очередь:
Этот список, конечно, субъективен. Многое упущено. Но фокус здесь — на пользе для продукта. И заметьте: почти все эти качества — личные. Их сложно «натренировать». Они либо есть, либо их нет. Перевоспитать человека в этом плане практически невозможно. Поэтому задача бизнеса — не переделывать людей, а находить тех, у кого эти качества уже есть.
Личные качества. Опыт нарабатывается, а вот ответственность, желание учиться и умение работать в команде — это база. Без нее даже самый опытный специалист может стать проблемой.
Спросите про его pet-проекты. Задайте вопрос: «Что ты думаешь о будущем этого кода?». Попросите привести пример, когда он отказался от использования новой технологии, потому что она не подходила проекту. Ответы покажут его ценности.
Постепенно их рефакторить. Начинать с самых критичных. Важно объяснить заказчику, что это инвестиция в стабильность и скорость будущих изменений.
Да, это сильно повышает его ценность. Понимание бизнес-логики позволяет принимать более правильные архитектурные решения и предлагать лучшие варианты реализации.
.jpg)
