Я сел писать приложение для поиска по GitHub — React на фронте, GitHub API на бэке. Обычный pet-проект для портфолио, не больше. Вводишь username, дёргаешь API, показываешь профиль, список репозиториев со звёздами и форками. Ничего особенного. Но где-то на середине я поймал себя на том, что вылизываю вещи, которые ни один ревьюер портфолио никогда не оценит, — и вот в этот момент проект перестал быть про React и стал про мою карьеру.
Проект, который выглядел совершенно обычным
На бумаге приложение было максимально банальным. Поле поиска, запрос к api.github.com/users/{username}, карточка профиля и список репозиториев под ней. Звёзды, форки, основной язык, дата последнего коммита. Я хотел, чтобы всё было чисто и работало — типичная штука, которую кладёшь в портфолио, чтобы показать: да, я умею связать фронтенд с живым API.
Ровно такое приложение я и написал. Чего я не ожидал — так это того, в какие именно части я влюблюсь.
Детали, которые я не мог перестать вылизывать
Вот тут стало странно. Меня затягивало в проблемы, которые для портфолио не значат вообще ничего:
- Debounce на поиске, чтобы быстрый набор не отправлял запрос на каждое нажатие клавиши и не сжигал rate limit GitHub API.
- Пагинация, потому что у некоторых людей сотни репозиториев, и грузить их все разом — лениво и медленно.
- Обработка rate limit — читать заголовки ответа и аккуратно отступать, а не вываливать пользователю невнятную ошибку.
- Подача данных для технарей — счётчики коммитов, разбивка по языкам, те самые цифры, которые инженер реально читает.
Ничего из этого не впечатлит человека, который смотрит твоё портфолио. Никто не ставит оценку за стратегию работы с rate limit на демо-приложении. Но я не мог остановиться. Мне было всё равно, красивый ли UI. Мне было важно, чтобы штука работала хорошо для технического человека.
Момент, когда всё сложилось
В какой-то момент я откинулся на спинку стула и задал себе очевидный вопрос: зачем я оптимизирую rate limiting для проекта, который никто никогда не запустит в проде?
Ответ был одновременно неудобным и отрезвляющим. Я не писал consumer-приложение, замаскированное под упражнение на React. Я писал инструмент для разработчиков — и делал вид, что это React-проект. Все мои инстинкты били в одну точку: сделай эффективно, сделай правильно, сделай полезно для других инженеров.
Я строил строку поиска для людей, которые читают счётчики коммитов ради удовольствия. И кайфовал от этого по-настоящему.
Pet-проекты — это карьерный компас
Я не проснулся однажды с решением стать DevOps-инженером. За меня это решили мои pet-проекты. Каждые свободные выходные, без всякого задания сверху, меня тянуло в одно и то же: API, автоматизация, тулинг, ускорение работы других инженеров. Этот паттерн звучал громче любого карьерного плана, который я мог бы придумать нарочно.
Потому что вот что я в итоге понял: DevOps — это тулинг для разработчиков, только в масштабе инфраструктуры. Та самая тяга, которую я чувствовал, собирая GitHub-поиск, — забота об эффективности, о rate limit, о чистых данных для технической аудитории — это ровно то же самое, что просыпается, когда ты строишь CI/CD-пайплайны, внутренние платформы и автоматизацию, от которой зависит вся инженерная команда. Строка поиска была маленькой версией. Инфраструктура — большой. Я просто ещё не соединил одно с другим.
Что я хочу тебе сказать
Если ты пилишь pet-проекты только чтобы «что-то лежало на GitHub», ты используешь их наполовину. Код — это тренировка. Настоящий результат — паттерн.
Обращай внимание на то, что ты строишь, когда никто не говорит тебе, что строить. Замечай, какие части ты оптимизируешь за гранью здравого смысла. Замечай, к чему ты возвращаешься в свободную субботу. Это не прокрастинация — это твой компас, и обычно он указывает на карьеру, которую ты ещё не назвал вслух.
У меня это было приложение для поиска по GitHub: React спереди, GitHub API сзади и стратегия работы с rate limit, которую никто не просил. Эта ненужная стратегия оказалась самым честным инструментом карьерной самооценки, которым я когда-либо пользовался.
Так что в следующий раз, когда будешь делать что-то для себя, спроси: о каких частях ты заботился слишком сильно? Ответ вполне может оказаться твоим следующим десятилетием.