Предыдущие статьи вступительной части:
Введение.
В течении последних 2-х месяцев я принял, возможно, самые важные решения в жизни всех своих личных проектов: я разрешил себе халтурить.
Стремиться стать лучше, но в моменте, делать кое-как. Главное, чтобы был результат.
Это решение, помноженное на ещё два инсайта, привело к тому, что я не просто продолжаю кодить - я вижу прогресс каждый день.
Всё сводится к трём простым правилам, которые я для себя вывел:
1 - Создавать, используя идею вертикальных срезов.
Этот подход стал для меня первым открытием.
Когда я только начал создавать программу, от нейросети я узнал о такой вещи - как вертикальные срезы.
Я расспрашивал её о том, как можно проектировать отдельные части и их реализовывать. И в одном из ответов она дала совет, что нужно разрабатывать, используя идею вертикальных срезов.
Суть.
Реализовывать одну маленьку, но законченную функцию сразу на всех уровнях - от базы данных до интерфейса - за короткий срок.
Чем меньше функция, тем больше шансов её реализовать.
Проблема, которую это решает.
Этот метод борется с главным врагом проекта - "невидимым прогрессом".
Когда пытаешься делать систему "слоями" (сначала всю базу, потом всю логику, потом весь интерфейс), результата можно не видеть неделями, а то и месяцами.
Так постепенно угасала моя мотивация, и все прошлые попытки продвинуться в проекте заканчивались тем, что я бросал его даже не начав, так как не было видимого прогресса, который я мог пощупать.
Как я это применяю (конкретный пример из проекта).
Например, я ставлю себе задачу: "сделать функцию добавления тегов".
Затем я начинаю с самого необходимого:
- Определяю, какие данные нужны для тега.
- Описываю логику их сохранения.
- Прикручиваю к этому простой интерфейс.
(шагов чуть больше, но это основные)
И всё это - ради одной-единственной функции.
Не ради запуска целой системы тегов, а ради одного конкретного действия: чтобы кнопка "Добавить тег" - заработала.
С первого раза всегда получается примитивный вариант - но он работает. Это не даёт мотивации угаснуть.
Почему это работает?
Чтобы продолжать делать - важно видеть результат.
Этот принцип даёт мгновенную обратную связь и чувство движения. Маленькие, но ценные победы поддерживают мотивацию и создают ощущение, что проект не стоит на месте.
Это первая идея, из-за которой я пока ещё не бросил свой проект.
2 - Сначала каркас, потом детали.
Где-то пару недель назад я закончил базовый вариант самого важного упражнения - запоминание отдельного слова. И встал вопрос: что делать дальше?
С этим вопросом я снова пошёл к нейросети. И она дала совет, который изменил моё представление о планировании.
Суть.
Не углубляться в детали одного модуля, пока не создан каркас всей системы.
Сначала нужно реализовать основные части (модули) в минимальном виде и настроить их взаимодействие. Только после этого стоит возвращаться и прорабатывать каждую часть отдельно.
Проблема, которую это решает.
Мой первоначальный план был двигаться "в глубину": сделать все упражнения для слов, потом браться за теги и грамматику.
Это тупиковый путь. Можно потратить месяцы на одину часть системы, но так и не получить целостной программы.
Нет общей картины - нет и понимания, куда двигаться, а значит, легко потерять интерес и всё бросить.
Как я это применяю (конкретный пример)
Сейчас я откладываю реализацию 4-го этапа запоминания слов (припоминание отдельного слова). Вместо этого мои следующие задачи:
- Создать систему тегов в минимальном виде (как в первом принципе).
- Создать систему грамматики.
Цель - не детали и улучшения, а общая картина: чтобы понимать, куда двигаться дальше.
Почему это работает?
Это даёт стратегическое видение.
Когда у тебя есть каркас, ты видишь проект как единое целое, а не как набор разрозненных идей. Понимаешь, как всё должно соединяться, и получаешь больше точек для роста и новых осязаемых результатов.
Это не даёт застрять в бесконечной правке одной части и поддерживает общий импульс, превращая разработку из череды тупиков в поступательное движение вперёд.
3 - Работающий функционал важнее красивого кода.
Это самое важное открытие за последние несколько лет, которое позволяет мне двигаться вперёд.
Суть.
Позволить себе писать код "как угодно", с одним главным условием: программа должна работать так, как задумано.
Архитектура и "чистота" кода отходят на второй план.
Проблема, которую это решает
Я перфекционист. По крайней мере, был им. Хотя мы, перфекционисты, знаем: бывших не бывает.
Это значит, что я мог тратить часы и дни на полировку несущественной детали. Я переписывал функции по несколько раз просто потому, что внушал себе, что они реализованы как-то не так.
В разработке это приводило к параличу: я бесконечно правил, продумывал "идеальную" архитектуру, рефакторил код, который никто, кроме меня, никогда не увидит, и в итоге не переходил к реализации других частей.
Проекты забрасывались, потому что не было продвижения вперёд - только бесконечное "улучшение" того, что уже и так работало.
Этот принцип ломает этот порочный круг, переводя фокус с "как сделать идеально" на "как сделать, чтобы заработало".
Как я это применяю (конкретный пример)
Сейчас, создавая новую фичу (например, ту же систему тегов), я не пытаюсь сразу выстроить безупречную архитектуру по всем канонам.
Я сосредотачиваюсь на простом вопросе: "Что должно произойти, когда пользователь нажмёт эту кнопку?". И пишу код, который приводит к этому результату, даже если он получается "кривым" и неоптимальным.
Работающий прототип сейчас, важнее идеального решения когда-нибудь потом.
Почему это работает?
Это снимает внутренний блок перфекциониста и смещает фокус с процесса на результат.
Для меня, как для начинающего разработчика, который физически не может учесть всех лучших практик, это единственный способ продвигаться вперёд и не бросить проект в очередной раз.
Когда ты видишь, что твоя программа работает и делает то, что ты задумал, это даёт гораздо больше мотивации, чем идеальный, но несуществующий код в твоей голове.
Это основа, которая делает возможными и вертикальные срезы, и движение "вширь".
Стремление к профессионализму: важное уточнение.
При этом я искренне считаю, что нужно стремиться к профессионализму - особенно мне, как начинающему разработчику.
Сказать "пиши плохой код, лишь бы продолжать" - хороший совет. Он работает, потому что позволяет не бросить.
Но лучший совет такой: "Пиши плохой код, чтобы сохранять мотивацию и не останавливаться, но параллельно учись и развивайся, чтобы потом этот код улучшать".
Нужно осваивать язык, библиотеки, подходы к проектированию, архитектурные паттерны - и всё остальное, что делает разработчика сильнее.
Самое важное - найти баланс: с одной стороны, разрешить себе делать "хрень" и не париться, а с другой - постоянно учиться и постепенно превращать эту "хрень" в качественный продукт.
На мой взгляд, это единственный верный путь.
Итог.
За два месяца я понял главное: чтобы проект не умер, ему нужен не идеальный план, а постоянный импульс:
- Вертикальные срезы дают скорость: ты видишь результат сегодня, а не через месяц.
- Сначала каркас даёт стратегию: ты понимаешь, куда расти, и не закапываешься в одной детали.
- Приоритет работающего функционала даёт свободу: ты перестаёшь бороться с собой и просто делаешь.
Вместе они создают простую систему движения вперёд:
- Ставишь маленькую задачу (срез),
- Выбираешь для неё подходящее место в каркасе проекта,
- И реализуешь её хоть как, но чтобы работало.
Не обязательно делать всё сразу.
Можно начать с одного правила - того, что отзывается именно вам.
Попробуйте разрешить себе писать "кривой" код ради работающей кнопки или отложить детализацию ради общего каркаса. Прогресс, даже крошечный, - лучший мотиватор.
Я следую этому пути всего два месяца, но это первые два месяца, после которых я не хочу всё бросить. Возможно, этот подход поможет и вам не забрасывать свои проекты.
А что помогает вам продолжать, когда опускаются руки? Делитесь в комментариях - будет интересно собрать коллекцию лайфхаков и, возможно, дополнить этот список!
Присоединяйтесь.
Хотите следить за тем, как эти принципы воплощаются в жизнь?
- Подписывайтесь на мой Дзен-канал - тут будут выходить итоговые статьи и главные инсайты.
- А для наблюдения за процессом - добро пожаловать в Telegram! Там я делюсь кодом, сырыми идеями, планами на неделю и разбором полётов. Всё как есть: и победы, и шишки. Это самый живой способ следить за проектом почти в реальном времени.
P. S.
Помогите, пожалуйста, улучшить читаемость текстов! Как вы считаете: жирные выделения помогают быстро ухватить суть или, наоборот, мешают сосредоточиться? Стоит ли мне сократить их количество или вовсе отказаться?
Все статьи вступительной части:
- Основные инсайты - мои главные открытия (текущая статья).
- Планы на ближайшее будущее - на месяц - два (будущая статья).