Сын маминой подруги? Нет. Просто с 12 лет фанатею от Python. Часть 1 — первые шаги

На самом деле, это не гайд, а личный опыт — хочу рассказать, как начал свой путь в IT. Я недавно на платформе и решил первым делом поделиться историей старта в айти-сфере. Возможно, мой опыт окажется интересным для новичков, а кто-то узнает в нём отражение своих первых шагов.

Интерес к программированию появился у меня ещё в начальных классах. Помню, когда дома появилась Sega Mega Drive, я захотел создать свою игру. Отец принёс книгу по ассемблеру со словами «Изучай!». Но, открыв её, я разочарованно подумал: «Тут даже картинок нет…» — и энтузиазм угас на несколько лет. Тогда я ещё не знал, что это лишь первая попытка — и не последняя.

Интерес к программированию вернулся, когда на уроках информатики мы начали изучать Паскаль. Особыми успехами я не блистал, но в моменты, когда удавалось написать функцию сложения двух переменных, ловил себя на мысли: «Е###ть, это работает! Что может быть проще?» На этом мой школьный этап погружения в программирование временно прервался. Из-за низких баллов ЕГЭ, собственной прокрастинации и бесконечных игровых сессий в Dota поступление на IT-направление сорвалось. Тогда казалось, что дорога в программирование для меня закрыта навсегда.

В итоге я поступил на физический факультет (название универа скрыто от лишних глаз) — и неожиданно обнаружил, что в программе обучения есть Fortran. Этот «динозавр» среди языков, который, казалось, остался в учебниках прошлого века (как я думал), стал моим первым серьёзным инструментом для расчётов. В тот период я активно публиковал исследования на ResearchGate и всерьёз планировал связать жизнь с наукой.

Однако у сотрудников научно-производственной компании (название компании скрыто от лишних глаз), с которыми меня познакомил научный руководитель, имелись другие планы на меня. Во время стажировки в НПК впервые познакомился MATLAB, С++. Строго говоря, моя работа с C++ не была классической разработкой — я фокусировался на создании алгоритмов для инженерных расчётов. Это напоминало сборку конструктора: брал готовые блоки кода, адаптировал их под физические модели, но до полноценных проектов «с нуля» дело не доходило.

Мой переход в разработку оказался неожиданным: друг предложил открыть магазин по продаже грилей, и первым шагом стал запуск сайта. Несмотря на нулевой опыт в веб-разработке и полное отсутствие знаний о дизайне, я решил создать платформу самостоятельно — без бюджета на фрилансеров и веры в «это смогут только профессионалы». Тогда я даже не понимал базовой архитектуры веб-сервисов: для меня не существовало разделения на клиентскую и серверную части, а аббревиатура CI/CD звучала как случайный набор букв. Тем не менее, мне предстояло выбрать инструмент для создания сайта. Почти случайно мой выбор пал на Python — не из-за глубокого анализа его преимуществ, а потому, что коллега из НПК как-то обмолвился: «С ним проще стартануть». После рабочего дня я задерживался в офисе до позднего вечера, изучая Python по книгам, которые тогда считал «библией разработчика»: «Изучаем Python» Марка Лутца, «Погружение в Python 3» Марка Пилгрима и «Грокаем алгоритмы» Бхаргавы Адитьи. Казалось, эти труды закрыли все пробелы: к концу третьего месяца я был уверен, что освоил язык от синтаксиса до скрытых возможностей. Ошибка новичка — принимать теорию за абсолют, не зная, что промышленная разработка потребует куда большего, чем знание декораторов и list comprehensions. Несмотря на то, что сайт для грильного магазина так и остался незавершённым, полученных знаний хватило для неожиданного поворота: я прошёл собеседование в компанию, разрабатывающую SaaS-платформу для логистики.

Придя в компанию, я представлял собой классический пример «зелёного» разработчика: за плечами — лишь прочитанные книги по Python и наивная уверенность, что синтаксис языка равен профессионализму. О софт-скилах вроде работы в Agile, коммуникации с командой или презентации решений я тогда имел смутное представление. Мои технические навыки тоже ограничивались базовыми скриптами — ни знания фреймворков, ни опыта с базами данных, ни понимания, как устроен CI/CD в продакшене. Первые дни напоминали прыжок в океан без умения плавать: задачи в Jira казались шифровками, а в митингах я молчал, боясь задать «дурацкий» вопрос. Jira для меня тогда казалась космическим кораблём с панелью управления на неизвестном языке. Каждый тикет, спринт и бэклог вызывали замешательство — я путал статусы задач, не понимал, зачем нужны метки, а в комментариях к багам искал скрытые подвохи. Это был мир, где даже просто «взять задачу в работу» требовало навыка, которому не учат в книгах по Python. Так я подошёл к главному, о чём редко говорят в учебниках по программированию: IT — это не только код, но и «софт» между людьми. Умение задавать вопросы, принимать критику и работать в команде оказалось сложнее любого алгоритма. Но эта тема — как legacy-код в большом проекте требует отдельного глубокого разбора. Если вам интересно, как я прокачивал коммуникацию вместо классов Python и учился не путать митапы с митингами — расскажу в следующем посте. Пока же запомните продолжу описывать свой путь.

Спустя несколько месяцев я принял решение уйти из компании. Причин было несколько: во-первых, высокая текучка кадров — коллеги менялись так часто, что я едва успевал запомнить их имена. Тогда я ещё не понимал, что ротация команд — не всегда зло, а иногда возможность перенять опыт разных специалистов. Во-вторых, проблемы с выплатами — зарплата приходила с задержками, а порой и в урезанном виде, что подрывало доверие к работодателю.

Следующим этапом стал переход в компанию, специализирующуюся на разработке решений для бизнес-аналитики с использованием Qlik. Что интересно, собеседование прошло нестандартно: его провели спонтанно, прямо в вагоне метро по дороге домой. Мои обязанности на новом месте включали работу с данными заказчиков: необходимо было извлекать сырые данные из БД, проводить их очистку и трансформацию, чтобы подготовить для визуализации в Qlik. Сама платформа не удовлетворяла требования по скорости обработки данных. После недель экспериментов и анализа альтернатив я наткнулся на Apache Airflow — инструмент для оркестрации ETL-процессов. В этой компании царила редкая для IT-среды свобода: не было жёстких требований к стеку технологий. Главное правило — «используй любой инструмент, если он решает задачу и не нарушает лицензии»

Со временем рутина с Airflow перестала приносить удовлетворение. Автоматизация ETL-процессов, которую я когда-то воспринимал как вызов, превратилась в шаблонные действия: настройка DAG, мониторинг пайплайнов, правка тривиальных багов. Мне хотелось выхода за рамки «просто рабочих задач» В тот момент я ощутил, что перерос текущие задачи. Мои навыки работы с данными, Airflow и базовым веб-разработчиком достигли уровня, когда хотелось более сложных вызовов. На совещании я предложил руководству радикальный шаг: отказаться от Qlik(ради эксперимента у одного заказчика) в пользу кастомных веб-дашбордов с обновлением данных в реальном времени.

Признаюсь честно: мои аргументы в пользу перехода на кастомные дашборды были скорее авантюрными, чем взвешенными. Жажда новых знаний перевесилa рациональность — я завысил свои навыки, заявив, что могу самостоятельно реализовать бэкенд на Django и фронтенд на Vue. На тот момент мой опыт с Django ограничивался базовыми туториалами, а Vue я вообще не касался.

Работа по 10–12 часов стала нормой — я пытался одновременно закрывать пробелы в клиентской и серверной разработке. По ночам учил Vue, днём правил баги в Djnago, а в перерывах гуглил, «как сделать адаптивную вёрстку». Иногда я ловил себя на мысли: «Зачем я ввязался в это? Может, проще было остаться в ETL?». Но назад пути не было — обещал «полный цикл».

Миф о «универсальном разработчике»

Руководство считало, что навыки в клиентской части автоматически означают умение делать дизайн. Мои попытки создать интерфейс в Figma выглядели как детские каракули. После недели мучений мы подключили дизайнера, но тут возникла новая проблема: Коммуникационный коллапс в работе с дизайнером, мы никак не коммуницировали во время разработки дизайна, я получал только готовый макет без возможности обсуждения (Стоит сказать, что такое есть во многих компаниях)

Если статья наберёт отклик — продолжу во второй: о команде, коммуникации и росте после первых провалов.