Пластмассовый мир победил? Металл кажется прочным. Весит, блестит, звучит. Но если ты когда-нибудь держал в руках незакалённый кусок металла — ты знаешь, насколько он хрупок. Металл становится прочным только после того, как его обожгли, согнули, остудили. Только после того, как он прошёл через деформацию, согласование внешнего и внутреннего, он способен не треснуть от первого удара. Пластик — другой. Он не требует ковки. Он гибкий, но не слабый. У него длинные молекулярные цепи. Он может быть мягким, может быть твёрдым. Его форма — не про силу, а про адаптивность. Он не ломается — он гнётся. Вот почему пластмассовый мир победил. Потому что реальность стала быстрее, жёстче, подвижнее. И в этом мире выигрывает не тот, кто несокрушим, а тот, кто гибок, но не теряет себя. Мы часто в себе культивируем "металл": быть непрогибаемым, сильным, не поддаваться. Но внутреннее напряжение растёт. Ты вроде держишь форму, а потом — бах, надлом. И ты не понимаешь, откуда это. Почему я срываюсь, почему я устал, почему не могу справиться с задачей, которая ещё вчера казалась простой. Это происходит, когда форма не соответствует внутренней структуре. Ты играешь роль, но не прожил эту форму. Не прогрелся. Не остыл. Не согласовал себя с собой. Когда кузнец кует меч, он не просто придаёт форму. Он закаливает металл, чтобы внутреннее соответствовало внешнему. Иначе — меч сломается при первом бою. Человек — тот же металл. Только не закаливаешься автоматически. Тебя никто не опустит в воду после раскалённого пламени. Тебе самому нужно проходить эти циклы. Стресс — не враг. Он — твой огонь. Он раскрывает, где ты слаб, где у тебя внутренние конфликты. Не убегай от него — используй. Если ты боишься любой нагрузки, защищаешься от любой боли — ты так и останешься мягким сырьём. Хрупким, даже если внешне выглядишь сильно. А потом — выгорание, срыв, тревожность, ощущение, что ты не в себе. Надо не просто делать больше. Надо жить глубже. Согласовывать форму и структуру. Внешнее и внутреннее. Только так ты становишься прочным. Настоящим. Закалённым не «мотивацией», а опытом.
Android [Kotlin] для начинающих – Иван Ветров
Зачем нужны проблемы? Давайте начистоту: как вы обычно учитесь? Наверняка сначала теория, “введение в курс” и только потом добираетесь до практики. Но что, если я скажу, что можно учиться быстрее, интереснее и реально эффективнее, просто... начав с проблемы? Представьте, вам говорят: “Вот приложение, у него проблемы с производительностью, разберись”. И что делать? Поначалу паника. Но потом начинаете собирать информацию: гуглинг, ищем похожие кейсы, тестируем варианты. В этот момент вы учитесь по-настоящему. Не просто запоминаете инфу, а начинаете понимать, как она работает на практике. А если что-то не идет — можно спросить у ментора или другого близкого из сферы вашего обучения. Такой подход называется проблемно-ориентированным обучением (Problem-Based Learning или PBL) В данной педагогической модели главным является развитие способности самостоятельного обучения и креативного подхода в решении проблем, а не разрешение конкретной проблемы как таковой. В связи со спецификой задач, технология PBL широко распространена в медицинских вузах, где такая методика является наиболее приближенной к реальным условиям работы будущих специалистов. 🤔 Принцип обучения на проблемах тонкой нитью тянется через всю программу AndroidSprint. С самых первых инструкций по настройке среды разработки и задач на переменные до погружения в реальные проекты наших партнеров на блоке "Аутстаффинг". Мы научились балансировать между переходом в рабочие процессы компании с долей стресса от нового материала и педагогическим подходом при объяснении и решении проблем. 😐 PBL — это не только про учебу, это подход к жизни. Когда вы решаете реальные задачи, будь то работа или повседневные дела, вы не только закрываете конкретную проблему, но и учитесь новому. Это развивает способность быстро адаптироваться и находить решения в неопределенности. Неважно, учитесь ли вы сфере айти или строите бизнес — сталкиваясь с задачами, мы развиваемся. Так что не бойтесь проблем, они наши лучшие учителя.
Помните эксперименты с зефиром из 1970-го? Психолог Уолтер Мишел говорит детям: "Вот зефир. Съешь сейчас или жди 20 минут - дам два." Дети творили чудеса самоконтроля: • Закрывали глаза руками • Отворачивались от стола • Пели песни • Представляли зефир облаком • Разговаривали сами с собой В айтишке та же история каждый день. Один зефир сейчас - это когда: • Копируешь код из ChatGPT (раньше со Stack Overflow) • Пишешь всё в одном файле на 2к строк • Игноришь warning'и линтера - "потом поправлю" • Деплоишь в пятницу вечером // да, классика И знаете что? Мы используем те же трюки, что дети: - Закрываем глаза: "Не буду смотреть на быстрое решение, сначала сам попробую" - Отворачиваемся: закрываем GPT и открываем документацию (ага, как же) - Поём песни: врубаем музыку, пока рефакторим говнокод вместо "а, похуй, работает же" - Представляем облака: визуализируем, как наш код будет выглядеть через год - Говорим с собой: "Нет, мы так не делаем. Мы делаем по-человечески. В ЭТОТ РАЗ блеать" Но вот проблема... У детей было 20 минут. У нас: • Изучение основ - МЕСЯЦЫ • Рефакторинг легаси - недели • Написание тестов - дни И всё это время мозг орёт: "СЪЕШЬ ЗЕФИР! Быстро! Другие уже в прод выкатили!" Но кто ждёт второй зефир, получает: • Код, который не стыдно на review показать • Проекты, которые не превращаются в легаси через полгода • Навыки, за которые на рынке реально платят • Зарплату в два раза выше // проверено В конце концов, два зефира всегда лучше одного. Особенно когда это зефир со вкусом senior-зарплаты. 🙂 P.S.: главное, пока ждешь 2 зефирки, чтобы тебя не сбил зефировоз 😕
Как устроен AI-редактор кода и почему я бросил его создание ИИ-редактор кода — это прежде всего редактор. Нужен инструмент, который позволяет редактировать файлы. Cursor для этой цели сделал форк VS Code — и это видно невооружённым глазом, и по структуре, и по внешнему виду. VS Code построен на Electron — фреймворке на базе Chromium. По сути, браузер. К сожалению, именно так строится подавляющее большинство кроссплатформенных десктопных приложений. Я решил не делать исключений. Грубо говоря задача делится на три части: правильный бэкенд, кастомизация клиента изнутри и их интеграция. Причём бэкенд — это не просто прослойка до API какой-то модели. Это отдельная система со своей инженерией, а не обёртка над нейросеткой. Если они смогли — значит, и я смогу. Весной 2025 года сделал форк VS Code и начал строить. Это был наивный оптимизм, от части. VS Code — это здоровенный проект: сотни тысяч строк, сложная архитектура, система расширений, терминал, отладчик и ещё куча всего. И он постоянно обновляется — Microsoft запустил свой Copilot и фигачит коммиты без остановки. Первое время я реально не понимал, за что хвататься. Читал исходники, разбирал архитектуру руками. AI тут помогает в основном анализом и объяснениями — надо самому понимать, как работает система из миллионов строк кода. В мае 2025 я просто бросил. Сейчас время быстрых. Есть гипотеза - сделал прототип, протестил и получил "фидбек от реальности". У меня ушло несколько месяцев, до рабочего MVP — ещё далеко, деньги утекают, результата нет. Но история на этом не закончилась.
