Многие уверены: чтобы работать в разы быстрее, нужны либо уникальные инструменты, либо десятилетия опыта, либо, на худой конец, сверхъестественная скорость печати. Мы привыкли считать, что производительность — это результат технологического вооружения и безупречного мастерства.
Но правда куда прозаичнее и, одновременно, парадоксальнее: всё дело в том, чтобы чётко понимать момент, когда «достаточно хорошо» действительно означает «достаточно». И в том, чтобы смело останавливать себя, пока желание «допилить до идеала» не превратило задачу в бесконечную эпопею.
Ещё несколько лет назад я, как и большинство разработчиков, всегда называл сроки с запасом. Думаю: «Две недели хватит», но озвучиваю «Три недели — на всякий случай». Казалось, это защитит меня от провалов по дедлайнам. Но даже так сроки уплывали — ведь я тратил часы, а порой и дни на полировку кода, который, в сущности, никто кроме меня не видел.
Когда скорость — не результат бессонных ночей и суперинструментов
В прошлом году я решил провести эксперимент: начал фиксировать свою скорость разработки и сравнивать её с темпом коллег.
Результаты удивили даже меня. Фичи я стабильно выпускал примерно в три раза быстрее, чем разработчики с сопоставимым опытом. При этом я не работал по 12 часов в день, не вёл двойную жизнь программиста-отшельника и не гонял на фоне «ИИ-ассистентов» в стиле «код за секунду».
Моя «магия» заключалась в том, что я нарушал почти все академические догмы, которые нам годами вбивают в головы на курсах, в университетах и в книгах по «чистому коду».
Проблема культа «идеального» кода
Когда я только начинал карьеру, мне казалось, что каждая строчка должна сиять совершенством. Имена переменных — как из учебников по английской стилистике. Архитектура — как храм, в котором ни один модуль не лишний. Каждая функция — идеальна, каждая зависимость — прозрачна, каждый тест — охватывает все возможные ветки логики.
На словах это звучит как рецепт мастерства. На практике — как медленный, мучительный способ закопать проект в ворох мелочей.
Ты можешь потратить три часа на название переменной, которая через неделю просто исчезнет при рефакторинге. Создать элегантную абстракцию, «с запасом» под будущие сценарии, которые никогда не появятся. Написать стопроцентное покрытие тестами — только чтобы узнать, что решал изначально не ту задачу.
Я прочувствовал это на собственной шкуре во время 24-часового хакатона. Наша команда 18 часов строила «красивое и правильное» решение. Победители же выкатили рабочую версию за 6 часов. Их код был кривоват, полон багов и TODO-комментариев, но он просто… работал. А в конкурсных условиях это — всё, что нужно.
Тогда до меня дошло: у каждого проекта своя шкала качества.
Медицинский софт или кардиостимулятор? Тут цена ошибки — человеческая жизнь, значит, нужен 100% перфекционизм. Быстрый пет-проект для проверки идеи? Тут хватит и 60% качества — главное, чтобы запускался и демонстрировал задумку. Большинство же задач лежат где-то между этими крайностями.
С тех пор я начинаю любую разработку с одного простого вопроса: «Что значит „достаточно хорошо“ для этой конкретной задачи?»
Черновики как инструмент разработчика
Писатели начинают с плохого текста — «черновика», который потом правят. Но среди программистов почему-то бытует странная иллюзия, что код должен быть чистым уже в момент первой компиляции. Это — перевёрнутая логика.
Мои черновики выглядят ужасно. В них баги, хардкод, копипаста, комментарии TODO, лишние print’ы для отладки. Я сознательно нарушаю принцип DRY, чтобы просто добраться до результата.
Почему это работает? Черновик мгновенно показывает то, чего ты ещё не знаешь.
Когда пытаешься выстроить «идеал» с первой попытки, ты принимаешь решения в тумане. Не знаешь, что окажется сложным, что изменится, что станет узким местом. Черновик же открывает эти зоны уже через пару часов.
Пример: недавно я разрабатывал пайплайн обработки данных. Первая мысль — спроектировать красивую, гибкую архитектуру, способную переварить любой формат. Но вместо этого я написал небольшой «грязный» скрипт под конкретные данные. Потратил два часа, а не два дня. Через неделю требования поменялись кардинально — и я был рад, что не угробил лишние часы на архитектуру, ставшую бы ненужной.
Мой процесс теперь такой:
- Написать самое уродливое решение, которое работает.
- Убедиться, что оно действительно решает задачу.
- Найти узкие места.
- Чистить и улучшать только то, что реально важно.
Спорьте с требованиями
Редко кто говорит новичкам, но это правда: многие требования можно менять и упрощать.
Часто менеджеры или заказчики формулируют их наобум — не подумав о том, что есть более простые варианты. Просят 10 экранов, хотя хватило бы двух. Требуют обрабатывать кейс, который встречается у 0,1% пользователей.
Раньше я просто выполнял запросы. Теперь я задаю вопросы:
— «Можно ли объединить эти экраны?»
— «А этот кейс вообще нужен?»
— «А если ограничиться 10 элементами вместо 1000?»
— «Может, выпустим упрощённую версию, а потом дополним?»
Очень часто ответ — «да».
Так, из задачи на 15 видов диаграмм мы пришли к одному простому линейному графику — и он полностью решил реальную потребность.
Фокус — главный ресурс
Люди думают, что главная беда — медленный набор текста или старые IDE. Но настоящий враг продуктивности — отвлечение.
Начинаешь чинить баг, замечаешь рядом «кривой» код, лезешь править, потом решаешь переименовать переменные, потом — переделать модуль. Часы проходят, а баг всё ещё живёт.
Я называю это «театром продуктивности» — ты занят, но не двигаешься вперёд.
Мой способ борьбы — таймеры и маленькие коммиты. Я ставлю 25 минут на задачу, и по сигналу коммичу, что есть, даже если не идеально. Это держит меня в рамках и заставляет сначала решать суть, а не детали.
Малые шаги — быстрые победы
Раньше я копил всё в один большой коммит. Думал: «Профессионалы так делают».
Ошибка.
Большие изменения тяжело ревьюить, опасно деплоить, и обратная связь приходит только в конце. Малые — проще, безопаснее и дают быстрые результаты. Психологически это мотивирует — каждое объединение в основную ветку даёт ощущение прогресса.
Мой принцип: если часть изменения уже даёт пользу — выкатывай, даже если фича ещё не завершена.
Навыки, которые ускоряют по-настоящему
- Чтение кода — умение быстро понять чужое решение экономит часы.
- Моделирование данных — правильная структура избавляет от множества проблем.
- Скрипты — автоматизация рутинных действий.
- Отладчики — вместо угадываний с print.
- Перерывы — свежий взгляд решает сложные задачи быстрее.
Главный вывод
Скорость приходит не от того, как быстро вы стучите по клавиатуре, а от того, сколько ненужных действий вы умеете отсекать.
Идеальный код, решающий неверную задачу, — мусор. Грязный код, решающий правильную задачу, — ценность.
Делайте черновики. Спрашивайте «зачем» у каждого требования. Работайте короткими шагами. Фокусируйтесь на важном. И помните: «достаточно хорошо» в 90% случаев — и есть правильно.
***✨ А что думаете вы? ✨
Делитесь мыслями в комментариях — ваше мнение вдохновляет нас и других!
Следите за новыми идеями и присоединяйтесь:
• Наш сайт — всё самое важное в одном месте
• Дзен — свежие статьи каждый день
• Телеграм — быстрые обновления и анонсы
• ВКонтакте — будьте в центре обсуждений
• Одноклассники — делитесь с близкими
Ваш отклик помогает нам создавать больше полезного контента. Спасибо, что вы с нами — давайте расти вместе! 🙌