Я сів писати застосунок для пошуку по 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, якої ніхто не просив. Ця непотрібна стратегія виявилася найчеснішим інструментом кар'єрної самооцінки, яким я коли-небудь користувався.

Тож наступного разу, коли робитимеш щось для себе, запитай: про які частини ти дбав занадто сильно? Відповідь цілком може виявитися твоїм наступним десятиліттям.