5 типов программистов, которые есть в каждом IT-отделе

Разработчики бывают разные, но в любой команде есть любители Stack Overflow и другие узнаваемые персонажи. Мы решили взглянуть на это с юмором и пользой — собрали пять ярких типажей программистов, добавили немного мемов и практичных советов, как им стать еще круче. Возможно, вы узнаете в них своих коллег или даже себя. 

Гуру-кодер: начал кодить раньше, чем научился читать

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

Узнать гуру-кодера нетрудно. Его сила — в технической подкованности: он знает тонкости многопоточности, наизусть помнит документацию любимого фреймворка и может объяснить, чем отличается REST от GraphQL, даже во сне. Способен за вечер поднять сложную DevOps-инфраструктуру, если вдруг решил, что так «правильнее».

Слабое место гуру-кодера — невнимательность к остальным членам команды. Он создает мощные и оптимизированные решения, которые отлично работают. Но забывает, что код должен быть простым и понятным, даже если иногда противоречит «общепринятым» практикам. Коллегам очень сложно поддерживать и дорабатывать его детище. Чтобы командная работа была более устойчивой и продуктивной, гуру-кодеру стоит освоить несколько приемов: 

• Создавать документацию к проектам. Поможет избежать ситуации, когда сотрудник пишет фичу, затем уходит в отпуск или увольняется, а коллегам приходится разбираться с его творением. Когда все задокументировано, остальным специалистам будет проще понимать и работать с кодом.
• Оставлять комментарии. Автору 800 запутанных строк могут быть очевидны собственные решения, а вот команде — не всегда. Комментарии помогут коллегам разобраться в коде, а также заранее решить спорные моменты. Например, если в комментариях объяснить, почему переменная названа именно так или использована эта функция, а не другая.
• Организовывать ретроспективы. Они помогут синхронизировать понимание задачи с другими, делиться своим опытом и не забыть про общие цели на проекте. Так гуру-кодер сможет применять знания на благо коллектива.

Сенсей-копипастер: «Как я это сделал? Ладно, главное, что работает!»

Получил звание сенсея, когда перенял технику Ctrl+C / Ctrl+V от мастеров с форумов. Даже если дать ему невыполнимую задачу, он справится, потому что не поймет, что она невыполнимая. Не произносите при нем слово «рефакторинг»: случится приступ.

Сенсей-копипастер отличается упорством и интуицией, которых нет даже у самых техничных специалистов, — для него в порядке вещей починить баг, не взглянув на функцию. Легко работает с кучей источников: читает форумы, гайды, треды в Reddit и комментарии к ответам на Stack Overflow. Умеет быстро искать похожие кейсы и комбинировать куски кода, пока тот не заработает.

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

• Найти ментора для регулярной обратной связи. Это может быть более опытный коллега, который поможет разобраться в сложных концепциях и объяснит, почему решение работает (или нет). Такой формат полезен, чтобы развивать понимание кода системно и отслеживать результаты через обратную связь от наставника.
• Смотреть практикумы по разбору кода. Подойдут форматы ”live coding”, где разработчики объясняют, почему принимают те или иные решения. Поможет понять логику мышления и структуру кода у разных специалистов, чтобы найти свои приемы.
• Участвовать в парном программировании. Вдвоем с коллегой решать общую задачу: копипастер будет писать код, а напарник — направлять и задавать вопросы, предлагать улучшения. Это позволит отрабатывать навыки прямо в процессе работы, а не ждать обратной связи, когда кусок кода уже готов.

Перфекционист-архитектор: 7 раз отмерит и еще 7 раз отмерит

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

Перфекционист способен продумывать невероятную архитектуру. Но только продумывать. Благодаря ему в команде всегда есть шикарный проект в Figma, расписанная доска в Miro или упорядоченный таск-трекер. Но в Git по-прежнему один коммит — init.

Главная слабость перфекциониста — он много думает, но недостаточно делает. Великие планы для него стоят на первом месте и загораживают сроки и работоспособность проекта. Не стоит обвинять его, а лучше научить бороться с перфекционизмом. Вот что может помочь:

• Сконцентрироваться на важных деталях. Выделить, какие из задач действительно повлияют на стабильность, скорость или удобство продукта, а какие стоит отложить. Это поможет не тратить силы на идеальную структуру каждого модуля.
• Обратная связь от коллег. Показывать черновики и архитектурные решения раньше, чем они станут шедевром. Так получится избежать ситуаций, когда перфекционист две недели продумывал сложную структуру, а команде нужно было просто добавить одну новую функцию.
• Фокус на опыте пользователя. Чтобы не тратить время на техническое «совершенство» кода, лучше работать над юзабилити. Ведь изящная архитектура сервиса скрыта от глаз обычных людей, а неработающую кнопку заметят все. 

Хакер-самоучка: слабые знания, отличная интуиция

Говорят, что его воспитывали не родители, а форумы и индийские туториалы на YouTube. Любит нестандартные решения, даже если они опасны: починит баг через костыль из CSS — и все заработает. Да и зачем разбираться в причинах, если можно накинуть !important?

Отличительная черта хакера-самоучки — энтузиазм и изобретательность. Он не всегда знает, как «правильно», зато знает, как «сработает». Его решения иногда граничат с магией: обходит баг в библиотеке с помощью багов в другой библиотеке, и все запускается.

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

• Пройти хорошие курсы или гайды. Необязательно браться за академические учебники — достаточно выбрать структурированные обучающие материалы по темам, где не хватает базы. Например, если есть трудности с асинхронностью в JavaScript, можно пройти курс, где объясняются Promise, async/await.
• Создать свою базу знаний. Записывать, какие решения сработали и почему. Это поможет быстрее ориентироваться в сложных ситуациях и не изобретать велосипед каждый раз. Формат может быть любым: от Notion до Markdown-файлов в репозитории.
• Вести список технического долга. Вместо жизни в мире вечных костылей полезно осознанно их замечать. Самоучке стоит фиксировать свои временные решения и возвращаться к ним позже, чтобы заменить на более устойчивые. Так код станет не только рабочим, но и удобным в поддержке.

Человек-фреймворк: 10 задач — 10 зависимостей

Считает, что нет задачи, которую нельзя решить с применением любимого фреймворка. Если же задача не решается — просто добавляет еще больше новых библиотек. Проекты такого специалиста тянут на пару мегабайт бизнес-логики и полгигабайта зависимостей, даже если он пишет скрипт для автоматизации Excel.

Человек-фреймворк горит идеей, находит самый современный инструмент, легко оформляет фронтенд на модных UI-библиотеках. Но при этом тратит больше времени на выбор стека, чем на реализацию самой задачи.

Слабая сторона такого программиста — зависимость от одного фреймворка. Чтобы делать свою работу лучше, ему стоит понимать, как устроены готовые решения. А также учиться выбирать инструмент, который подойдет под конкретную задачу. Для этого будет полезно:

• Разбираться в основах. Изучать, как устроены ключевые компоненты: например, маршрутизация и работа с базами данных. Это поможет лучше понимать разные фреймворки, увидеть сильные стороны и ограничения каждого. 
• Чаще использовать стандартные возможности языка. Вместо того чтобы сразу ставить очередную библиотеку, посмотреть: а можно ли обойтись без нее? Это поможет писать более чистый, понятный код, который не сломается после обновления зависимостей.
• Расширять свой выбор фреймворков. Каждый из них предлагает десятки паттернов, но не все они пригодятся под задачу. Даже если инструмент нравится, важно спрашивать себя: может быть, другой подойдет здесь лучше?