Курси дали мені базу, але розробником мене зробили власні помилки

💡 Усі статті, обговорення, новини для початківців — в одному місці. Приєднуйтесь до Junior спільноти!

Мене звати Денис Івшин, я Python розробник який шукав роботу 3 місяці в чому знайшов велику проблему і реалізував її рішення створив свій власний SaaS і хочу поділитися своїм досвідом

Мій шлях у програмування почався у грудні 2023 року. Тоді мені було 15 років.

Я не мав чіткого плану, ким саме хочу стати: backend-розробником, спеціалістом з автоматизації, засновником власного продукту чи просто людиною, яка вміє вирішувати свої проблеми за допомогою коду.

Мотивація була доволі простою: Python здавався інструментом, за допомогою якого можна зробити майже що завгодно.

Автоматизувати рутинну роботу, обробити дані, написати скрипт, створити вебзастосунок або навіть повноцінний продукт. Саме ця універсальність мене й зачепила.

Зараз у моєму стеку є Python, Django, FastAPI, Django REST Framework, PostgreSQL, Redis, Celery, Docker, Git та інші інструменти backend-розробки. Але на початку я, звичайно, не розумів навіть половини цих слів.

І майже всі важливі речі я зрозумів не під час перегляду курсів, а тоді, коли власний код починав ламатися.

Як усе почалося

Мій перший серйозний контакт із програмуванням був досить стандартним: Coursera, YouTube, документація, допомога батька та родичів, які вже розумілися на розробці.

А далі — спроби, помилки, ще спроби й нові помилки.

Першим курсом, який справді дав мені хорошу базу, став Crash Course on Python від Google. Пізніше я пройшов інші програми:

Automating Real-World Tasks with Python;
Configuration Management and the Cloud;
Introduction to Git and GitHub;
Using Python to Interact with the Operating System;
Troubleshooting and Debugging Techniques;
Google IT Automation with Python Specialization.

У моєму резюме ці курси займають окремий блок, разом із практичними проєктами на Python, Django, PostgreSQL, Redis, Celery та Docker.

Але зараз я чітко розумію: сам сертифікат майже нічого не означає, якщо після завершення курсу ти не можеш відкрити порожній файл і самостійно почати щось створювати.

Тому я не просто дивився відео.

Я писав код паралельно з навчанням, робив вправи, переробляв приклади під свої потреби й поступово переходив до власних невеликих програм.

Спочатку міг займатися днями безперервно — переважно на мотивації. Але мотивація швидко закінчується. Потім довелося переходити на дисципліну.

Це, напевно, один із перших важливих уроків, який я отримав: навчатися програмуванню лише тоді, коли є настрій, майже неможливо.

Перші два місяці я майже нічого не вмів

На початку прогрес здається дуже швидким.

Спочатку ти не знаєш, що таке змінна. Через кілька днів уже пишеш умови й цикли. Потім вивчаєш функції, словники, списки, файли та винятки.

Через це легко отримати відчуття, що ще трохи — і ти вже розробник.

У мене відчуття, що я можу написати щось самостійно, з’явилося приблизно через два місяці.

До цього я переважно спирався на приклади, документацію та допомогу інших людей. Після цього почав хоча б приблизно розуміти, як розкласти задачу на частини та знайти необхідне рішення.

Серед перших автоматизацій були прості речі на кшталт сортування електронної пошти та роботи з файлами.

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

Саме з автоматизації власних потреб і почався мій інтерес до більш серйозної розробки.

Мій перший великий проєкт — облік комунальних послуг

Першим проєктом, який я вже сприймав не просто як вправу, став застосунок для обліку комунальних послуг.

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

У проєкті було багато функцій, і поступово він став значно більшим за початкову ідею простого калькулятора.

Над ним працювали двоє: я займався backend, а мій друг, який тоді жив у Польщі, — frontend.

Так я вперше нормально відчув, що таке розділення відповідальності між клієнтською та серверною частинами.

Раніше я міг написати функцію та вважати, що все готово. Але коли з твоїм API працює інша людина, з’являються нові питання:

чи зрозуміло названі endpoints;
чи стабільно вони повертають дані;
чи однаково обробляються помилки;
чи не змінюється формат відповіді без попередження;
чи може frontend нормально використати твою логіку.

У цьому проєкті я працював із Python, Django, FastAPI, PostgreSQL, REST API та Docker. Також уперше отримав досвід командного Git-workflow: окремі гілки, pull requests, об’єднання змін і ситуації, коли різні частини системи переставали працювати разом.

Для мене цей проєкт став переходом від «я вивчаю Python» до «я намагаюся створити систему».

Там було багато неідеальних рішень. Частину коду я зараз точно написав би інакше. Але саме тому цей досвід був важливим.

Можливо, окремо варто було б розповісти про цей проєкт детальніше: як ми будували його удвох, які функції додавали та що в результаті довелося переробляти.

Чому я обрав Django

Коли я почав робити перші вебзастосунки, мені потрібен був фреймворк, який дозволяв би швидко перейти від ідеї до робочої системи.

Django здався простим і зручним.

У ньому вже є багато готових речей: ORM, система користувачів, адміністративна панель, міграції, маршрутизація та зрозуміла структура проєкту.

Для початківця це важливо. Замість того щоб одразу збирати все з окремих бібліотек, можна зосередитися на логіці застосунку.

PostgreSQL я почав використовувати майже від самого початку навчання, тому що родичі, які мені допомагали, працювали зі схожим стеком.

Спочатку я не до кінця розумів, чим реальна база даних відрізняється від звичайного збереження інформації у файлі. Потім почали з’являтися зв’язки між моделями, індекси, міграції, запити, проблеми продуктивності — і стало зрозуміло, що база даних є окремою великою частиною розробки.

Моделі також доводилося змінювати.

І саме тоді я вперше зрозумів, що рішення, яке здається нормальним на початку, може стати проблемою через кілька місяців.

Від простого CRUD до складнішої логіки

Після першого проєкту я працював над системою для моніторингу ризику професійного вигорання.

Це був уже значно складніший backend.

У системі були різні ролі:

працівник;
менеджер;
HR.

Кожна роль мала власний рівень доступу. Працівник міг проходити регулярні опитування, а менеджери й HR отримували агреговану аналітику без доступу до даних, які мали залишатися приватними.

Ми реалізовували:

JWT-автентифікацію;
role-based access control;
версійовані шаблони опитувань;
розрахунок показників стресу, навантаження, мотивації та енергії;
загальний Burnout Index;
автоматичні сповіщення про різке збільшення ризику;
кешування аналітичних даних через Redis;
фонові задачі через Celery;
unit-тести;
документацію API через Swagger;
контейнеризацію за допомогою Docker.

Цей проєкт навчив мене, що backend — це не лише створення, читання, оновлення та видалення записів.

Найскладніше починається тоді, коли з’являються правила.

Хто може бачити конкретні дані? Що станеться, якщо користувач пропустить опитування? Як правильно розрахувати показник, якщо даних недостатньо? Коли потрібно відправити попередження? Як не показати менеджеру інформацію, яка може ідентифікувати конкретного працівника?

У резюме все це можна вмістити в кілька рядків про Django, Redis, Celery, RBAC та аналітику. Але за кожним таким рядком стоять десятки невеликих рішень і помилок.

Я навчався за кордоном, але душею залишався в Україні

У 2025 році я поїхав навчатися до Словаччини.

Моя спеціальність була пов’язана з менеджментом у туризмі, а не з Computer Science.

Це дало мені певний досвід у менеджменті, роботі над командними проєктами, дослідженні ринку, економіці, плануванні та роботі з даними. Але водночас я розумів, що найбільше мене цікавить саме технічний напрям.

Я хотів навчатися на комп’ютерних науках.

Навчання за кордоном стало корисним життєвим досвідом, але душею я все одно залишався в Україні. З часом я зрозумів, що хочу повернутися, продовжити розвиток саме тут і здобувати освіту, яка відповідає моїм справжнім інтересам.

Тому я повернувся в Україну й зараз вступаю далі на спеціальність, пов’язану з комп’ютерними науками.

Я не вважаю попередній вибір повністю помилковим. Менеджмент теж допоміг мені краще розуміти продукт, користувачів, процеси та бізнесову сторону розробки.

Але технічну базу мені весь цей час доводилося будувати самостійно.

І саме тут я бачу різницю між самоосвітою та системним навчанням.

Самостійно можна вивчити Python, Django чи Docker. Але набагато важче самостійно скласти правильну послідовність фундаментальних тем: алгоритми, структури даних, операційні системи, мережі, архітектура комп’ютерів, математика та безпека.

Тому зараз я не відмовляюся від самоосвіти, а хочу доповнити її більш системним навчанням.

Ідея власного продукту

У березні 2026 року я разом із партнером почав працювати над власним SaaS-продуктом.

Ми хотіли вирішити проблему людей, які довго шукають роботу, отримують мало відповідей і часто не розуміють, що саме не так із їхніми документами або підходом до пошуку.

Я повністю відповідав за backend.

Приблизно за два місяці ми пройшли шлях від ідеї до першої робочої версії.

Але важливо розуміти: два місяці до релізу не означають, що продукт став завершеним.

Навпаки, після запуску почалася значно складніша частина.

До цього ти працюєш зі своїми припущеннями. Після запуску з’являються реальні люди, реальні дані, нестандартні сценарії та речі, про які ти не подумав.

Backend був написаний на Python і Django з використанням Django REST Framework та PostgreSQL. Також потрібно було побудувати API, систему користувачів, аналітичні процеси та інтегрувати моделі машинного навчання в загальну логіку продукту.

Найскладнішою технічною частиною для мене стала саме інтеграція машинного навчання.

Потрібно було не просто надіслати дані в модель та отримати відповідь. Треба було побудувати цілий процес:

підготувати дані;
перевірити формат;
обробити можливу помилку;
правильно зберегти результат;
повернути його клієнту;
не заблокувати роботу всього застосунку;
зробити поведінку передбачуваною для користувача.

Коли працюєш із зовнішньою моделлю, ти не контролюєш її так само, як звичайну Python-функцію. Відповідь може зайняти більше часу, змінитися за форматом або взагалі не прийти.

Саме такі речі й перетворюють красиву ідею на реальну інженерну задачу.

Одна міграція — і PostgreSQL раптом став SQLite

Однією з найбільш неприємних проблем була ситуація з базою даних.

У проєкті використовувався PostgreSQL, але через неправильну конфігурацію під час одного з етапів система фактично починала працювати через SQLite.

На папері це здається дрібницею: просто неправильно вказані налаштування.

Насправді наслідки можуть бути значно серйознішими.

Різні бази даних мають відмінності у типах, обмеженнях, транзакціях і поведінці запитів. Те, що працює в SQLite, не завжди однаково працює в PostgreSQL — і навпаки.

Ця помилка навчила мене не довіряти тому, що «конфігурація начебто правильна».

Потрібно перевіряти:

до якої бази реально під’єднався застосунок;
які змінні середовища він отримав;
де саме виконуються міграції;
чи однакові конфігурації в локальному та production-середовищах;
чи не використовується fallback-значення.

На щастя, production у нас жодного разу повністю не падав через оновлення. Але ця історія добре показала, наскільки небезпечним може бути маленьке припущення.

Власний продукт не дорівнює комерційному досвіду. Але й не є просто пет-проєктом

Навколо власних продуктів часто є дві крайні позиції.

Перша:

Якщо ти створив SaaS, то вже майже senior.

Це неправда.

Друга:

Якщо тобі не платив роботодавець, це взагалі не досвід.

І це теж не зовсім правда.

Власний продукт не дає всього, що можна отримати в сильній команді.

У тебе може не бути досвідченого архітектора, який зупинить неправильне рішення. Може не бути системного code review, складної інфраструктури, великого навантаження та процесів, які існують у зрілих компаніях.

Через це легко зробити помилку й навіть не зрозуміти, що вона була.

Але водночас продукт змушує відповідати за всю систему.

Не лише написати endpoint, а й подумати:

чи потрібна ця функція користувачу;
як вона взаємодіє з іншими частинами;
як її розгорнути;
що станеться після оновлення;
як знайти помилку;
як підтримувати старі дані;
як пояснити її людині, яка нічого не знає про внутрішню архітектуру.

У моєму випадку продукт перетворився на спільну екосистему з backend, вебчастиною та мобільним застосунком.

І тут я зрозумів важливу річ: backend не існує окремо.

Можна зробити технічно правильний API, але якщо frontend не може з ним нормально працювати, результат усе одно поганий.

Найскладніше виявилося не програмування

До запуску я думав, що головною складністю буде написати систему.

Після запуску виявилося, що найскладніше — знайти перших користувачів.

Технічну проблему зазвичай можна розкласти на частини:

відтворити помилку;
перевірити логи;
знайти причину;
протестувати рішення;
виправити.

У маркетингу такої передбачуваності немає.

Можна зробити хорошу функцію — і вона не буде цікава людям.

Можна витратити кілька днів на сторінку — і майже ніхто її не побачить.

Можна запустити рекламу, отримати трафік, але не отримати користувачів, які готові платити.

Одного дня завдяки таргетованій рекламі продукт відвідала 761 людина. Але сам по собі трафік ще нічого не означає.

Він не відповідає на запитання:

чи зрозуміли люди продукт;
чи побачили цінність;
чи повернуться вони;
чи готові вони платити;
чи вирішує продукт їхню реальну проблему.

Перші два місяці продукт не заробив нічого.

Потім з’явилися перші клієнти, які загалом принесли приблизно $1000.

На запуск, інфраструктуру, сервіси та інші витрати пішло близько $500.

Я не сприймаю це як доказ великого бізнесового успіху. Це радше підтвердження того, що принаймні кілька людей побачили в продукті цінність і були готові за неї заплатити.

Але між першими $1000 і стабільним бізнесом — величезна відстань.

Я думав, що буде простіше

Не можу сказати, що очікував легкого успіху.

Я приблизно розумів, що буде складно. Але все одно думав, що після запуску процес піде швидше.

Ти кілька місяців створюєш продукт і мимоволі починаєш дивитися на нього зсередини.

Ти знаєш, скільки логіки стоїть за кожною кнопкою. Знаєш, скільки разів переписував певний модуль. Пам’ятаєш усі баги та складні рішення.

А користувач цього не бачить.

Він відкриває сторінку й за кілька секунд вирішує, чи варто залишитися.

Йому байдуже, наскільки складною була архітектура. Він хоче зрозуміти, чи вирішує продукт його проблему.

Це іноді неприємно, але дуже корисно.

Технічна складність не дорівнює користувацькій цінності.

Як я використовую AI в розробці

Я почав використовувати Codex ще на етапі проєктування продукту.

Переважно він допомагав подумати над концепцією, структурою нових функцій і можливими варіантами реалізації.

Зараз я намагаюся використовувати AI менше.

Не тому, що він не допомагає. Навпаки, він значно підвищує продуктивність.

Але є ризик, що швидкість написання коду почне випереджати розуміння.

Зараз приблизно 10% коду в моїй роботі створюється за допомогою AI. Але я завжди переписую або адаптую результат під власну логіку.

Я не вставляю згенероване рішення, не розібравшись, як воно працює.

AI може допомогти:

запропонувати структуру;
знайти потенційну помилку;
показати альтернативний підхід;
створити чернетку функції;
швидше прочитати незнайомий код;
продумати edge cases.

Але головну роботу я не хочу повністю йому передавати.

Згенерований код уже створював баги, які потім доводилося шукати й виправляти. І це нормально: AI не знає всього контексту системи, навіть якщо здається, що знає.

Тому я вважаю, що AI особливо небезпечний саме для junior-розробників.

Не тому, що їм не можна ним користуватися.

Проблема починається тоді, коли людина повністю на нього покладається.

Можна дуже швидко отримати великий обсяг робочого на перший погляд коду. Але якщо ти не можеш пояснити:

чому вибрано саме це рішення;
які в нього обмеження;
що станеться на нестандартних даних;
як його протестувати;
наскільки воно безпечне;

то фактично цей код тобі не належить.

Без AI я зміг би підтримувати свій проєкт. Просто це займало б більше часу.

Для мене AI — це прискорювач, а не заміна інженерного мислення.

Чого мені досі не вистачає

Власний продукт, кілька проєктів і завершені курси не зробили мене досвідченим інженером.

Найбільша моя слабкість зараз — саме недостатня кількість досвіду.

Я вже працював із різними технологіями, але не вважаю, що знаю кожну з них на глибокому рівні.

Є велика різниця між:

«Я використовував Redis у проєкті»

та:

«Я добре розумію всі сценарії кешування, інвалідацію, конкурентний доступ і поведінку системи під навантаженням».

Те саме стосується Docker, Celery, PostgreSQL, архітектури та безпеки.

Я можу побудувати робочу систему. Але ще не завжди можу одразу сказати, як вона поводитиметься при різкому зростанні навантаження, великій кількості паралельних задач або складній помилці в інфраструктурі.

І саме це я хочу розвивати далі.

Мені не хочеться просто додавати нові технології до резюме.

Хочеться глибше розуміти ті, з якими вже працюю.

Що насправді дало мені навчання

Курси дали мені базову структуру.

Вони пояснили синтаксис Python, роботу з операційною системою, Git, автоматизацію, хмарні сервіси та debugging.

Документація навчила шукати точну інформацію.

YouTube допомагав швидше знайомитися з новими темами.

Родичі та батько допомагали не зупинитися в моменти, коли я взагалі не розумів, що відбувається.

Але головне дали проєкти.

Саме вони навчили мене:

працювати без готової відповіді;
самостійно розкладати задачу;
читати чужий код;
переписувати власні рішення;
шукати причину помилки, а не лише її повідомлення;
думати про дані та користувачів;
працювати з іншою людиною;
не боятися незнайомих технологій;
доводити систему до робочого стану.

Коли вчишся на курсі, завжди знаєш, що правильне рішення існує.

У реальному проєкті часто немає одного правильного рішення.

Є кілька варіантів із різними компромісами, а тобі потрібно вибрати один, не маючи повної інформації.

Найбільша пастка початківця

На мою думку, найбільша пастка — постійно готуватися почати.

Ще один курс.

Ще одна бібліотека.

Ще одне відео про правильну архітектуру.

Ще один місяць на алгоритми.

І тільки потім — власний проєкт.

Проблема в тому, що момент повної готовності не настане.

Майже всі важливі речі я вивчив тоді, коли вони стали потрібні для конкретної задачі.

Я не вважаю, що теорія непотрібна. Навпаки, зараз я хочу отримати більш системну освіту в Computer Science саме тому, що бачу прогалини у фундаментальних знаннях.

Але теорія засвоюється зовсім інакше, коли ти вже стикався з проблемою на практиці.

Після реальної помилки транзакції вже не здаються абстрактною темою.

Після невдалої міграції починаєш уважніше ставитися до бази даних.

Після складного бага краще розумієш цінність логування та тестів.

Після першого користувача перестаєш думати, що достатньо лише написати код.

Чи шкодую я про витрачений час

Ні. Жодної хвилини.

Навіть якщо окремі рішення були неправильними, а частину коду довелося переписувати, сам процес дав мені більше, ніж будь-який окремий курс.

Я побачив увесь шлях продукту:

від ідеї
до першої архітектури,
від backend-логіки
до запуску,
від перших користувачів
до перших грошей.

І водночас зрозумів, що запуск — це не фінал.

Це лише момент, коли твої припущення вперше зустрічаються з реальністю.

Що б я порадив собі у 15 років

Я б не радив проходити більше курсів.

Я б сказав:

Починай робити власний проєкт раніше.

Не обов’язково великий SaaS.

Це може бути:

скрипт для сортування пошти;
сервіс для особистих витрат;
калькулятор комунальних послуг;
Telegram-бот;
невелика система обліку;
API для власної ідеї.

Важливо, щоб проєкт вирішував проблему, яку ти сам розумієш.

Тоді з’являється причина не просто вивчити технологію, а розібратися, навіщо вона потрібна.

Я також сказав би не боятися поганого коду.

Перший код майже завжди буде поганим.

Проблема не в тому, що початківець пише неідеально. Проблема — коли він ніколи не повертається до старих рішень і не намагається зрозуміти, що можна зробити краще.

Замість висновку

Я не вважаю себе людиною, яка вже все зрозуміла в розробці.

Навпаки, чим більше я працюю над реальними системами, тим краще бачу, скільки всього ще не знаю.

Але зараз я вже не боюся ситуації, коли переді мною незнайома технічна проблема.

Я знаю, що можу:

розкласти її на частини;
знайти необхідну інформацію;
перевірити кілька рішень;
зробити помилку;
виправити її;
довести результат до робочого стану.

Курси дали мені початок.

Документація дала інструменти.

Допомога близьких дала підтримку.

Але розробником мене поступово зробили саме власні проєкти, невдалі рішення та помилки, які ніхто не міг виправити замість мене.

І, мабуть, це головне, що я зрозумів за цей час:

програмування починається не тоді, коли ти знаєш достатньо, а тоді, коли береш відповідальність за результат власного коду.

Теми: Django, Junior, Python, навчання, освіта