PJ Dev
480 subscribers
58 photos
1 video
1 file
67 links
История в прямом эфире о том, как я стал разработчиком, изменил свои привычки и улучшил качество жизни

https://pjdev.ru/
Download Telegram
Ну что друзья, всех с новым годом! Да по моему часовому поясу он настал именно сейчас.

Желаю всем счастья, успехов и здоровья. Сейчас самое время провести теплые моменты с друзьями, семьёй, а может быть и с самим собой, а на каникулах подведём итоги года.

Всех с новым годом 2026 годом!
118🎉15🥰6🍾5🦄1
Год эмоциональных потрясений — как очень хороших, так и очень плохих

Работа
———
Главное достижение в 2025 году — новая работа, которая из подработки переросла в основную деятельность. За этот год на работе я столкнулся с огромным количеством проблем, которые в какой-то момент казались нерешаемыми, но по итогу, какими бы сложными они ни были, всегда находились решения. Это и есть точка роста — когда ты делаешь то, что кажется невозможным.

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

У меня по-прежнему остаётся подработка педагогом по основам программирования для детей на выходных, однако совмещать её с основной работой становится всё сложнее. Один выходной в неделю на протяжении года заметно сказывается на уровне усталости. Возможно, доведу группы до выпуска и откажусь от неё. Хотя я так говорю уже несколько лет.

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

Сейчас становится всё тяжелее и тяжелее сохранять мотивацию, так как рост стал менее заметным, а занятия более тяжёлыми. Но когда я смотрю на играющих профессионалов, они вызывают у меня дикий восторг. Я понимаю, что до такого уровня мне не дорасти, но хочу быть к нему как можно ближе.

Бытовое
———
В 2025 году я планировал отпуск, однако в силу разных обстоятельств от него пришлось отказаться. Было грустно — я очень хотел хочу в отпуск, зато сэкономленные деньги позволили обновить технику: приобрёл новый компьютер и ноутбук.

В течение года я много читал — техническую, художественную и научно-популярную литературу. Чтение было скорее постоянным фоном, чем отдельной целью, за исключением нескольких технических книг, и помогало переключаться между разными типами задач и контекстов.

Также в этом году я выступал в роли эксперта на публичных и закрытых мероприятиях. Делился опытом получения новой профессии, обучения, разработки, поиска работы и другими темами, которые так или иначе связаны с моим каналом. Надеюсь, что этот опыт оказался полезным для аудитории, но он точно был полезен для меня самого — как способ структурировать собственные знания

#Мысливслух #Итогигода #2025
1🔥19👍1171
Так вышло, что на моей основной работе проводить ревью моего кода некому, и весь код, который я написал, прямиком отправляется в работу.

Я к этому уже привык, стараюсь его перечитывать по нескольку раз, потом даю себе паузу минут на 15, и снова перечитываю. Обязательно тестирую всё руками и делаю авто-тесты, чтобы убедиться, что всё в порядке.

Главное, что всё работает, но вот насколько оно оптимизированно и чисто написано — вопрос, который некому задать.

Так вот, я сейчас параллельно принимаю участие в крутом стартапе, где у меня есть "старший" наставник. Тут то я и вспомнил, насколько классно, когда твой код читает кто-то ещё кроме тебя, тем более кто-то более опытный. Коллега проводил ревью моего кода, и сказал, что в целом всё хорошо, но отметил несколько мелких недоработок, которые я не заметил. Если честно, то я немного удивился, что допустил эти ошибки.

Наверняка какие-то подобные мелки ошибки были и на основной работе, просто я их не замечал, а тут мне на них указали — и это очень хорошо. Буду набраться опыта у опытных товарищей

#Мысливслух
1🔥19👍11👏41
Небольшая тоска на меня напала: работы много, соответственно, свободного времени мало. Почти всё время работаю или тренируюсь, а в оставшиеся часы пытаюсь отдыхать.

Поэтому на бложек сейчас времени не хватает, хотя, я бы сказал, что скорее — не хватает сил. Иногда что-то пишу, но мысли какие-то незаконченные, и не проходят самоцензуру.

При этом на канале внезапно появляются новые люди, что для меня удивительно. Вроде в последнее время никакой медийной активности у меня не было, но это всё равно радует. Вроде так чуть-чуть осталось до круглой цифры в 500 подписчиков, но из низкой активности в последнее время циферки перестали расти.

В общем, к лету планирую пересматривать свою занятость. Надеюсь в ближайшее время разгребу основную долю задач, станет полегче и снова начну писать. Уже в каком-то смысле соскучился по каналу.

Вот такие у меня дела, если есть чем поделиться — пишите в комментариях, с радостью почитаю :)

#Мысливслух
116👍11
Я задумался о том, как оказался там, где нахожусь сейчас в профессиональном плане. Во многом это произошло потому, что я отказывался от гарантированно выгодных вариантов в пользу ещё более выгодных, но лишь потенциально.

Одним из первых предложений с высокой зарплатой была работа в местном профессиональном колледже: ставка преподавателя, потенциальная возможность разработки внутренних продуктов, плотный график, рабочее место далеко от дома и зарплата 90 тысяч рублей.

Учитывая, что тогда я зарабатывал около 40 тысяч, это было ощутимое увеличение дохода — более чем в два раза. Однако я отказался. Условия работы казались некомфортными, к тому же я всё больше хотел сосредоточиться на разработке.

Затем поступило отличное предложение от крупного местного банка: 15 минут пешком от дома, полный рабочий день, премии, льготы — всё официально, зарплата 130 тысяч рублей. Предложение звучало очень привлекательно, но и от него я отказался. Главной причиной стали скучные задачи (нужно было парсить тысячестраничные договоры и извлекать из них нужные данные) и очень жёсткий контроль за сотрудниками (вплоть до того, какого цвета галстук необходимо носить). Хотя это уже было ближе к разработке.

Было ещё несколько предложений стать разработчиком с условиями хуже, чем у меня на тот момент. О них я даже не задумывался. А вот отказаться от уровня оплаты труда в два, а то и в три раза выше моего — оказалось непросто.

Я переживал, что не смогу найти вариант лучше, но при этом боялся, что если соглашусь, то это «болото» затянет меня на несколько лет, и я перестану искать что-то лучшее, пока буду осваиваться на новом месте.

В итоге я сформировал для себя несколько требований к работе:

- Уровень зарплаты должен вырасти;
- Работа должна быть удалённой или с оплачиваемым переездом (даже было два таких предложения);
- Это обязательно должно быть моё профильное направление — backend-разработка;
- Желательно свободный график или плавающее начало дня.

Многие мне говорили, что надо браться за любую работу, расти и менять её. Говорили, что идеальных условий не будет, что я зря трачу время. Действительно, времени на поиск работы у меня ушло значительно больше, чем у других разработчиков из моего окружения, может быть мне просто повезло, но меня это полностью устраивало тогда, и я абсолютно доволен результатом сейчас.

#Мысливслух #ОРаботе
1👍20🔥134
Я периодически сталкиваюсь с вопросом от людей, далёких от разработки: «Зачем держать программистов в штате на постоянной основе? Разве нельзя один раз сделать продукт и просто пользоваться им годами?»

На первый взгляд вопрос может показаться логичным, но на практике такое почти никогда не работает. Я бы сравнил конечный продукт с живым организмом, который существует в постоянно изменяющейся среде.

Бизнес всегда требует изменений
Согласно известной шутке, просить внести правки в заранее оговоренный результат — это вообще самое любимое занятие заказчика. Хоть это и распространённая тема для шуток, но логика в этом есть: в бизнесе появляются новые направления, новые требования, новые законодательства, и всё это требует его адаптации к новым реалиям. Даже если сейчас продукт кажется «готовым», то требования к нему не зафиксированы навсегда. Они эволюционируют вместе с бизнесом. И каждый новый шаг — это доработка.

Зависимость от технологий и их версий
Любой продукт базируется на определённых технологиях, а они имеют тенденцию меняться:
- Выходят новые версии языков и фреймворков;
- Старые версии перестают поддерживаться;
- Закрываются критические уязвимости;
- Меняются требования к безопасности;
- Изменяются API-контракты;
- Вводятся новые ограничения.


Такие изменения происходят у ресурсов, которые для вас являются посредниками. Вы никак не можете на них повлиять, но вполне можете пострадать из-за этого. Даже если ваш код кажется идеальным, внешний мир может его разрушить.

Баги, которые сразу не удалось обнаружить
Я лично знаю о случаях, когда баг всплывал через несколько лет после того, как он появился: при тестировании просто не был задет краевой случай, который впоследствии всплыл и оказался болезненным для бизнеса.

Эти и другие баги нужно кому-то исправлять, а если нет постоянной команды разработки, то и исправить будет некому.

Попытка отдать задачу на аутсорс тоже может оказаться болезненной: опытные разработчики не готовы браться за мелкие заказы или запрашивают несопоставимую сумму из-за разовости сделки и потребности вникать в код legacy проекта.

Изменения в инфраструктуре
Продукт должен где-то размещается и зависит от инфраструктуры своего размещения. Могут измениться тарифы или условия размещения. Хостинг может закрыться или перестать работать. Рост аудитории может потребовать масштабирования, а оно, в свою очередь, потребует пересмотра архитектуры. Всё это приводит к тому, что продукт требует постоянных изменений — доработки.

В итоге разработка — это не разовая услуга по созданию продукта, а постоянный управляемый процесс сопровождения.

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

На определённом этапе изменения могут стать не нормальной эволюцией, а вынужденной и дорогостоящей реанимацией или вовсе привести к смерти продукта.

#Мысливслух
1👍8🔥5❤‍🔥3💯21
Наверняка вы играли в Sims или хотя бы знакомы с концепцией этой игры — симуляцией управления жизнью людей.

Одна из возможностей этой игры — ускорение времени. Обычно я пользовался ей, чтобы быстрее достичь результата в освоении навыков, карьере и финансовом благополучии персонажа, а также чтобы пропустить тяжёлую, изнурительную и бедную часть жизни. Далее цифровой человечек жил очень успешную, но очень короткую жизнь.

Ближе к сути:
недавно меня посетила мысль: «вот бы было здорово перемотать жизнь на 10 лет вперёд». В тот момент, где я уже успешный разработчик с большим опытом работы, скорее всего накопил какую-то приличную сумму денег, улучшил качество жизни и вообще чувствую себя прекрасно. И это желание на самом деле вполне естественно. Когда находишься в процессе роста, неопределённости и регулярных усилий, хочется быстрее оказаться в точке стабильности и результата. Выходить из зоны комфорта всегда сложно, но, вероятно, это один из немногих способов роста.

Тем не менее, мне очень быстро стало страшно от этих мыслей. Я задумался, а готов ли я потерять 10 лет своей жизни, даже если результат будет гарантирован? И почти сразу решил для себя, что не готов. В отличие от компьютерного человечка, жизнь у меня одна, а само течение жизни — главная ценность, и даже гарантированный успех не компенсирует утрату времени.

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

А если бы кнопка ускорения времени действительно существовала — вы бы её использовали?

#Мысливслух
👍1410🔥6🤔2
"Смерть" мессенджера telegram всё ближе. Проблемы дошли до бытового уровня, где многие пользователи начали жаловаться: "изображения не загружаются, связь пропадает, сообщения отправляются по 30 секунд". Примечательно, что десктопные версии работают хуже мобильных. У меня даже есть очевидное предположение, из-за чего смартфоны справляются лучше — их модифицировали.

Умрёт ли telegram полностью? Ну, что-то подобное прогнозировали и в отношении YouTube, который, по моим субъективным ощущениям, действительно в какой-то момент немного выпал из жизни, но сейчас вернулся и живее всех живых. Думаю, так будет и с telegram, если не придумают новых способов умерщвления.

Тем не менее я уверен, что многие пользователи не выдержат "сбоев" в виде отсутствия загрузки изображений и долгой реакции приложения, ничего не станут ремонтировать, и это приведёт к отказу от такого сервиса. А это значит, что я должен дать своим подписчикам альтернативный способ получения информации.

Выше я уже писал о том, что вижу два дополнительных альтернативных пути развития:
- Написать собственный блог;
- Дублировать посты в Max.

Так вот, я написал сервис блога, развернул инфраструктуру на облачном сервере, реализовал быстрый автоматический деплой всех изменений, прикрутил домен, и теперь меня можно читать на pjdev.ru.

У блога есть комментарии, но пока они будут скрыты. Надо разобраться с тем, как организовать модерацию и с вопросами законодательства. Соответственно, комментарии будут разрешены только после регистрации, а это сбор и хранение данных — вопрос, над которым тоже надо поработать с точки зрения ФЗ.

Кроме того, по ссылке можно присоединиться к моему новому каналу в Max.

P.S. Я начинал писать блог сначала около 3–4 раз из-за того, что очень сильно увлекался разными сторонами разработки и закапывался в них. Мои попытки довести один из аспектов до идеального состояния приводили к полному отказу от идеи. В итоге от попыток сделать идеально я перешёл к мысли: "сделать так, чтобы работало". Скорее всего, позже об этом расскажу более подробно, но если коротко, мысль такая: "идеальное — враг работающего".

P.s.s. я теперь не знаю где вы это читаете поэтому. Blog, Max, Telegram.
👍10👎43😁2🔥1
Почему я сделал собственный веб-сервис для блога после замедления Telegram в России

Я не ухожу с Telegram и не планирую этого делать в будущем. Telegram по-прежнему остаётся важной частью моего блога и основной платформой распространения, и так будет до тех пор пока это возможно, но теперь, в связи с "замедлениями", точно нужна альтернатива — и ей станет личный сервис-блог.

Однако web-сервис для меня — это не только способ распространения информации, но ещё и некое портфолио, а также инструмент, который позволит тестировать и изучать новые технологии. Уже сейчас, благодаря блогу, я знакомлюсь с frontend-разработкой, улучшаю CI/CD и DevOps-практики.

До текущей реализации я уже дважды пробовал сделать, в каком-то смысле, такой простой web-сервис, но каждый раз закапывался в какие-то узкие задачи и в итоге всё бросал.

— Первая попытка закончилась тем, что я создал очень жёсткие требования к коммитам: линтеры, форматтеры и, самое страшное, — очень строгая типизация. Любое, малейшее изменение сопровождалось тем, что было просто невозможно совершить коммит. Я явно переборщил и всё бросил.

— Вторая попытка закончилась тем, что я начал экспериментировать с архитектурой: пытался разбить всё на какие-то «молекулы», сервисы, модули, файлы, функции. Это было абсолютно необоснованно и бессмысленно. В итоге я получил огромное количество модулей и файлов — мне это не понравилось, и я снова всё забросил.

Это был интересный и ценный опыт. Как видите, третья попытка более успешная. Она точно не идеальная, мне многое ещё не нравится в текущем варианте, но он хотя бы рабочий.

Этот пост — первый в серии постов о том, как я решил создать собственный блог, дальше я постараюсь рассказать о поэтапном развитии сервиса. Буду последовательно разобрать все этапы: от идеи и архитектурных решений до реализации, инфраструктуры и планах дальнейшего развития проекта.

Если хотите посмотреть на блог или, может быть, даже добавить его в избранное.

#Мысливслух #Блог
🔥126👍6👏2
В прошлом посте я писал о том, почему вообще решил делать собственный web-сервис для блога, а теперь расскажу о технической реализации backend-части.

Недолго думая, я выбрал фреймворк Django по очень простой причине: это привычный для меня инструмент, который я хорошо понимаю. Был вариант ещё использовать FastAPI в академических целях, чтобы освежить его в памяти, но, так как впереди ещё стоял вопрос реализации frontend-части, я решил, что сосредоточу обучение на фронте.

После прошлых неудачных попыток мне совсем не хотелось уходить в архитектурные фантазии, и я решил, что буду делать всё просто и стабильно. Поэтому я сознательно придерживался минимализма во всём проекте. Решил, что пока обойдусь без регистрации/авторизации, ограничусь минимальными моделями Post и Tag, ну и дефолтным User для себя, чтобы управлять админкой. Скромный набор обязательных полей и связей, и всё было готово.

Отдельный плюс Django для такого проекта — это админка из коробки, которая на первых порах позволяла управлять данными без frontend-части. Да и в целом для блога это очень полезный инструмент, который с лёгкостью закрывает вопросы создания и редактирования постов, тем более если ты единственный автор. Django изначально создавался для журналистов с идеей быстрого создания контентных web-сервисов.

Я сразу принял решение, что буду развивать backend как API-приложение. Главная его задача: хранить и обрабатывать данные, реализовывать бизнес-логику и отдавать всё это наружу в понятном формате. Так что логичным продолжением стало дополнение в виде Django REST Framework, который дал сериализацию, пагинацию и разграничение прав доступа. В итоге backend получился API-only: опубликованные посты отдаются через публичные endpoint'ы, черновики доступны только из административного контура, а сам сервис сосредоточен именно на данных и логике публикации.

Когда backend начал обретать форму, стало понятно, что следующим шагом будут отдельный frontend и объединение этих двух сервисов в один рабочий продукт. Поэтому было принято решение создать три отдельных репозитория: backend, frontend, infra. Об этом и будут следующие посты.

#Backend #Django #Python #Блог
👍106🔥4
Почему не стоит держать всё в одном Django-приложении: разделение на backend, frontend и инфраструктуру

Продолжаю серию постов о том, как пишу собственный блог.

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

Идею держать всё в одном Django-приложении я сразу отверг. На старте это удобно: один репозиторий, один деплой, минимум инфраструктуры, есть инструменты, которые позволяют реализовать frontend на шаблонах. Но как только появляется полноценный frontend и нормальные CI/CD процессы — границы начинают размываться, и система становится сложнее, чем должна быть.

Проекты, с которыми я работал, обычно не выделяли инфраструктуру в отдельный репозиторий. Хотя в одном из них эти процессы всё-таки были обособлены, и мне это понравилось. Поэтому я решил в качестве эксперимента попробовать реализовать новую для себя схему:

- backend — отдельный сервис с API
- frontend — отдельное приложение, которое работает с этим API
- infra — отдельный слой, отвечающий за деплой, окружение и сборку

Это не попытка уйти в микросервисы, а разделение проекта на зоны ответственности. Каждая часть системы отвечает за свою область и не тянет на себя лишнего. Если бы я оставил всё в одном репозитории, то любое изменение тянуло бы за собой всё сразу — от API до деплоя. В какой-то момент это начинает замедлять разработку сильнее, чем кажется на старте.

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

Моя практика показывает, что плюсов больше, чем минусов — прежде всего за счёт контроля связности. Явные границы через API фиксируют точки взаимодействия: зависимости перестают быть скрытыми и становятся управляемыми. Любое изменение проходит через контракт, а значит становится предсказуемым — понятно, где и что может сломаться.

По сути, это перевод сложности из неявных связей внутри кода в явные интерфейсы между частями системы. Это упрощает развитие: можно менять отдельные компоненты, не затрагивая остальные, пока соблюдается контракт.

В итоге это не про сложную архитектуру, а про управляемость и предсказуемость системы.

#Архитектура #Блог #МыслиВСлух #Разработка
👍4🔥3🤝2
Обстоятельства изменились, нужна новая работа

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

Как говорил волшебник Ринсвинд:
«В интересные времена живём».


Вердикт был вынесен довольно неожиданно. На основном месте работы в один из обычных дней нам просто сообщили во время созвона, что мы дорабатываем до конца месяца и компания закрывается. Радует, что расходимся абсолютно мирным путём на основе заранее оговорённых договорённостей.

Информацию о том, что компания закрывается, я получил буквально за день до своего отпуска, так что он, по сути, стал бессрочным. Однако билеты куплены, отель оплачен — отпуску быть! Сейчас поеду, отдохну, вернусь и буду снова учиться проходить собеседования и искать работу. Так что открыт к предложениям, если у кого-то есть варианты, то с радостью обсужу с вами этот вопрос. Слышал, что рынок труда сейчас очень тяжёлый, так что теперь немного переживаю, но надеюсь, что всё пройдёт гладко.

P. S. Технические посты как-то не зашли, да и на свой блог времени совершенно не было из-за того, что делал большой рефакторинг всего проекта: написание тестов, документации, оптимизация кода, реструктуризация и формирование единого стиля, настройка CI\CD процессов и DevOps инструментов. Была потрачена уйма сил и времени, но теперь кажется, что это всё было впустую. Так что, наверное, пока техническую часть оставлю в стороне и буду дальше писать какие-то свои мысли.

P.s.s. ещё одни фактором отсутствия активности стала блокировка телеграмма из-за чего число просмотров упало почти в два раза. Я из-за этого расстроился и думал, что блог совсем умрёт, а я на него потратил больше трёх лет своей жизни, но кажется, что всё не так плохо.

#Мысливслух
💔159
Беда не приходит одна

Мой отпуск закончился тем, что я сильно заболел, и в итоге мне пришлось сутки с температурой 38+ шататься по аэропортам и перенести 11-часовой перелёт. Развлечение так себе.

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

Пока лежал, читал различные каналы о текущем рынке труда и, если честно, немного в шоке от того, что там пишут. Люди, которые попадают на технические собеседования, буквально заявляют, что им прямым текстом говорят, что их будут эксплуатировать и ни во что не ставить. И это я ещё мягко пересказал.

Естественно, это субъективное восприятие какой-то небольшой группы людей, на которых я случайно наткнулся в конкретный момент. Но люди опытные, и, кажется, врать им незачем. Пока не готов в такое верить. Когда появится личный опыт — поделюсь.

Есть и хорошие примеры. Некоторые знакомые говорят, что за минувшие полгода сменили работу, при этом увеличив доход. Так что тут всё, как всегда, зависит от человека, его навыков и в каком-то смысле от везения.

Плохое всегда воспринимается и передаётся ярче, чем хорошее. Посмотрим, что будет на самом деле.

#Мысливслух #поискработы
14