Александр Ламков — Friendly Frontend

🥨 Ты не «учишься программированию». Ты учишься терпеть неопределённостьКогда я начинал, я думал, что программирование — это про алгоритмы, структуры данных, паттерны. Ну, про знания. Выучил — применил — работает. Как математика в школе: есть формула, подставил числа, получил ответ. Оказалось — нифига подобного.Большую часть времени ты сидишь и не понимаешь, правильно ли ты вообще делаешь. Не в смысле «допустил баг» — это как раз решаемо. А в смысле: ты принял архитектурное решение, и у тебя нет способа узнать, было ли оно верным. Может, через три месяца всё развалится. Может, нет. Может, ты выбрал не тот подход, и через полгода придётся переписывать. А может, это и был лучший вариант из возможных, просто он выглядит криво.И вот сидишь ты с этим ощущением. Каждый день.Я помню, как писал свой первый более-менее серьёзный проект и раз в час гуглил «как правильно сделать X». Как будто где-то есть скрижаль с правильными ответами, а я просто пока не нашёл. Скрижали нет. Есть куча статей, где люди с одинаковой уверенностью говорят противоположные вещи.Самое тяжёлое — это не «я не знаю, как решить задачу». Это «я решил задачу, но понятия не имею, хорошо ли я её решил». И никто тебе не скажет. Код работает? Ну ок. Тесты проходят? Ну ок. А нормально ли это спроектировано — ты узнаешь потом. Или не узнаешь, потому что проект закроют раньше.И к этому вообще никак не готовят. Ни курсы, ни универ, ни ютуб. Там тебе дают задачу, ты её решаешь, тебе говорят «правильно» или «неправильно». А потом ты выходишь на работу — и всё. Обратной связи от вселенной больше нет. Есть код-ревью, но ревьюер часто сам не уверен, он просто более привык к этому состоянию.Собственно, вот что по-настоящему отличает тех, кто остаётся в профессии, от тех, кто уходит. Не знание фреймворков. Не скорость печати. А способность нормально функционировать в ситуации, когда ты не уверен. Просто делать, принимать решения, двигаться дальше — и не сходить с ума от того, что «а вдруг неправильно».Я до сих пор иног

🤣 Самый переоценённый навык в разработке — знать синтаксисНа днях консультировал начинающего фронтендера, и он прямо гордился тем, что знает все методы массивов наизусть. Прям вот сиял. И я сижу такой, киваю, а в голове одна мысль: ну и что? Я сам половину из них подсматриваю каждую неделю, и это не мешает мне закрывать задачи.У меня на работе за последние полгода ни разу не было ситуации, где проблема упиралась в синтаксис. Зато было полно ситуаций, где надо было сесть и подумать — как разбить фичу на части, какие куски потащат за собой другие, что сломается, если поменять вот эту штуку. И вот тут никакое знание reduce vs forEach не спасает. Тут надо головой работать, а не памятью.Я сейчас активно использую ИИ-агентов в работе, и знаете что стало самым важным? Не код, а то, что идёт до кода. Грамотно декомпозировать задачу, чётко описать что нужно, продумать граничные случаи — вот на это уходит основное время. Агент напишет тебе что угодно, но если ты сам не понимаешь, что должно получиться — на выходе будет мусор. Инструменты поменялись, а голова по-прежнему главная.Я часто замечаю, что ребята, которые приходят за менторством, фокусируются не на том. Человек знает деструктуризацию и spread, а попросишь его спроектировать простую форму с тремя состояниями — ступор. Потому что вся энергия ушла в запоминание, а не в понимание. Синтаксис выучить легко, с этим справится кто угодно. А вот научиться думать над структурой — это уже другая история.Я оглядываюсь на свой рост и понимаю, что больше всего мне дало не заучивание, а копание в чужом коде. Сидишь, смотришь, пытаешься понять — почему человек сделал именно так. Иногда понимаешь, иногда нет. Но голова начинает работать по-другому. А синтаксис… ну синтаксис подсмотришь.

😓 Ты не понимаешь проект не потому что он сложныйПервый день на новом проекте. Открываешь репу — 200 файлов, папки вложены друг в друга как матрёшки, какие-то утилиты, хелперы, обёртки над обёртками. Ты смотришь на это и думаешь: «Я тупой». Спойлер — нет. Ты просто не знаешь контекст. И это вообще разные вещи.Код сам по себе редко бывает прямо сложным. Ну серьёзно, там те же компоненты, те же функции, тот же fetch за данными. Безысходность от того, что ты не знаешь, зачем это всё написано именно так. Почему тут кастомный хук вместо обычного стейта. Почему этот компонент рендерит детей через функцию. Почему роутинг сделан через три слоя редиректов. Без контекста любое решение выглядит безумным. А когда узнаёшь историю — «а, там был баг на проде, пришлось костылить» — всё сразу встаёт на место.Мозг вообще не умеет схватывать большие системы целиком, он так не работает. Ты не можешь открыть проект и сразу понять всё. Ты понимаешь кусками. Сначала один модуль, потом соседний, потом как они связаны. И постепенно в голове собирается карта. На это уходит недели, иногда месяц-два. Это нормальная скорость, а не признак того, что ты не тянешь.Лучший способ въехать — не читать весь код подряд, а взять конкретную задачу и пройти по цепочке. Вот кнопка, вот обработчик, вот запрос, вот как данные возвращаются и рендерятся. Один сценарий от начала до конца. Потом второй. Потом третий. И через пару недель ты уже ориентируешься нормально, хотя 80% кодовой базы даже не открывал.Все через это проходят, кстати. Даже сеньоры на новом проекте первые недели чувствуют себя стажёрами. Просто они уже привыкли к этому ощущению и не паникуют.

🤨 Почему "знаю React" почти ничего не значитВот ты выучил хуки, можешь useState/useEffect написать с закрытыми глазами, даже useRef не пугает. Открываешь резюме, пишешь "React" в навыки. А потом приходишь на проект — и оказывается, что знание React это процентов 15 от того, что реально нужно.Потому что на проекте тебя никто не попросит «написать компонент с хуками». Тебя попросят разобраться, почему форма на три экрана тормозит. Или прикрутить авторизацию так, чтобы она не разваливалась на каждом редиректе. Или понять, почему стейт обновляется не тогда, когда ты ожидаешь, и данные мелькают как попало. И вот тут выясняется, что useState ты знаешь, а что делать — не очень.Джуны часто переоценивают фреймворк, потому что он на виду. React — это то, что ты видишь в каждой вакансии, про него все курсы, все туториалы. И создаётся ощущение, что вот выучишь его — и ты фронтендер. Но React это просто инструмент рендеринга. Обёртка. А под ней — архитектура, работа с API, управление состоянием, обработка ошибок, доступность, перформанс. И вот это всё никакого отношения к React не имеет.Я бы даже сказал так: чувак, который средне знает React, но хорошо понимает как работает браузер, как устроен HTTP, умеет нормально декомпозировать задачу и дебажить — он полезнее, чем тот, кто вызубрил все хуки наизусть, но теряется, когда что-то идёт не по туториалу. Потому что фреймворки меняются, а базовые навыки остаются.Короче, React знать надо, никто не спорит. Но если ты думаешь, что это главное в твоём стеке — ты путаешь обёртку с содержимым.

🧐 Большинство задач на работе — это не "разработка", и это нормальноКогда начинал, я был уверен: работа фронтендера — это сесть с утра и писать код до вечера. Компоненты, логика, всё красиво. А потом вышел на первый проект и понял, что большую часть дня я вообще не пишу код. Читаю чужой, пытаюсь понять, почему компонент рендерится три раза. Сижу на созвоне, где полчаса спорим про название пропса. Ковыряю баг, который ловится только в Safari. И вот так — процентов 70 времени.И ты такой сидишь, думаешь: «За неделю написал строк 50 нового кода, наверное я отстой». Не, ты нормальный. Просто задача — не строки производить, а разобраться и решить. Иногда решение — это вообще удалить код. Иногда — сходить к дизайнеру и выяснить, что фичу можно сильно упростить. Иногда — день убить на настройку линтера, зато потом вся команда скажет спасибо.С ростом тоже прикол — ты его не замечаешь. Просто в какой-то момент ловишь себя на том, что чужой код читаешь быстрее. На ревью видишь проблемы до того, как они стрельнут. Можешь джуну нормально объяснить, почему сделали так, а не иначе. Это всё рост, просто он тихий.Вообще самый жирный буст у меня был не от написания кода, а от копания в чужом. Лезешь в легаси, пытаешься понять логику решений. Споришь на ревью, оказываешься неправ — и доходит почему. Чинишь баг, про который вообще никто не знает, откуда он взялся. Вот тут и прокачка, а не в очередном todo-приложении на выходных.Короче, если кажется что «мало кодишь» — забей. Все так работают. Просто в туториалах об этом не рассказывают.

📡 Куда я пропалКороче, если вы заметили, что последние пару месяцев тут стало тише — вам не показалось. На YouTube два месяца ничего не выходило, в Telegram тоже писал через раз. Не потому что забросил или потерял интерес. Просто закончился ресурс.Основная причина — смена работы. Новый проект, новая команда, новые процессы. Кто менял работу, тот знает: первое время ты вечером заканчиваешь работу, у тебя в голове остаётся ровно ноль свободного места. Вся энергия уходит на то, чтобы въехать в кодовую базу, запомнить имена людей и понять, как тут вообще всё устроено. Садиться после этого писать пост или монтировать видео — ну такое.Я какое-то время пытался тянуть и контент, и адаптацию одновременно. Предсказуемо подвыгорел. В какой-то момент просто разрешил себе нажать паузу. Делать контент через силу — так себе стратегия, на выходе получается вымученная ерунда, которую и самому неприятно перечитывать.Сейчас всё понемногу устаканивается. На работе уже не чувствую себя новичком, который боится что-то сломать. Появляется энергия, а вместе с ней — желание снова что-то делать. Причём за эти два месяца я дофига тем накопил в заметках — про которые прям хочется высказаться. Руки не доходили, но список рос. Так что с контентом проблема точно не в том, что нечего сказать. Ах, да, я ж ещё в марте планировал релизнуть курс по TS'у, но тогда не вывез. Сейчас думаю, что в мае всё точно будет. Не обещаю — скорее твердо обозначаю своё намерение.Ещё скоро иду гостем на подкаст, третий раз в жизни. Такие штуки неплохо встряхивают и напоминают, что тебе вообще-то есть что сказать. Ну и в целом — я никуда не делся, просто жизнь временно забрала чуть больше, чем обычно. Возвращаюсь к нормальному темпу. Как-то так.

🚪 Почему «подсмотреть решение» — это не читерствоЧасто вижу, как новички боятся открыть чужое решение, будто это какое-то страшное преступление. Типа «если посмотрел — всё, ты считерил, теперь твоё обучение не считается». Из-за этого люди могут по 5–6 часов долбиться в одну задачу, даже когда уже давно встали намертво и ничего не понимают.Давайте разделим две вещи: списывание и нормальное обучение. Списывание — это когда ты просто копируешь код, не вникая, лишь бы закрыть задачу. А обучение — это когда ты смотришь, как другой человек подумал, какие приёмы использовал и почему именно так. Действия внешне похожи, но на деле это совершенно разные вещи.У меня тоже был период, когда я принципиально всё «дожимал сам». Звучит красиво и благородно, но на практике это часто превращалось в тупое топтание на месте. Ты не учишься новому — ты просто крутишься в рамках того, что уже знаешь.Чужое решение — это, по сути, сгусток чужого опыта. За пару минут ты можешь увидеть подход, до которого сам бы доходил несколько часов… или вообще никогда не дошёл. Главное — не просто скопировать, а разобраться: почему так сделано, какие есть другие варианты и где это может сломаться. Вот в этот момент и происходит настоящее обучение.Но есть и другая крайность, в которую легко скатиться — бездумная копипаста. Когда ты сразу берёшь готовое, вставляешь к себе и идёшь дальше, даже не пытаясь понять. В таком случае ты действительно ничему не учишься, а просто прячешь свои пробелы.Поэтому я для себя вывел простое правило: если сильно застрял — нормально посмотреть решение. Но потом обязательно нужно его «присвоить»: переписать своими руками, упростить, попробовать сломать и собрать заново. Пока решение не стало по-настоящему твоим — толку от него почти никакого.

Чем больше я учусь, тем чаще ловлю себя на одной неприятной мысли: кажется, я на самом деле ничего толком не знаю. А самое обидное — это ощущение не проходит, а только усиливается.Поначалу всё выглядит довольно просто. Есть базовый стек, понятные задачи, ты что-то собираешь — и в голове складывается приятное чувство «ну ок, разобрался, я в теме». А потом начинаешь копать глубже… и внезапно понимаешь, что раньше видел только верхушку айсберга. Просто раньше ты не замечал, сколько всего под ней скрывается.Особенно жёстко я это прочувствовал, когда начал разбираться не только «как сделать», но и «почему так сделано». Архитктура, внутренности библиотек, чужие решения — и вот ты уже сидишь и смотришь на код, который вроде бы должен понимать, но не понимаешь. И в этот момент накрывает ощущение, что раньше ты был «сильнее», быстрее писал, меньше сомневался, увереннее двигался. Хотя по факту ты просто начал видеть больше слоёв, больше последствий, больше возможных ошибок.Самая подлая часть в том, что это бьёт по уверенности. Хочется линейного роста: вчера не умел, а сегодня умею. А здесь наоборот: чем дальше идёшь, тем больше вопросов, тем меньше ощущения контроля. И мозг делает самый простой вывод — «я, видимо, стал хуже». Это очень удобная, но абсолютно ложная интерпретация происходящего.Я для себя это переформулировал так: если тебе начинает казаться, что ты ни хрена не понимаешь — значит, ты хотя бы начал это замечать. Раньше ты спокойно проходил мимо всех этих нюансов с мыслью «да норм всё». уже не проходит. Это не значит, что ты стал хуже. Наоборот — у тебя наконец появилась глубина, которой раньше не было. Просто она чувствуется не как сила, а как постоянное трение и дискомфорт.Это не самая приятная стадия. Здесь нет ощущения «я молодец, я вырос». Здесь скорее постоянный фон из сомнений и перегрузки. Но именно в этом месте обычно и происходит нормальный рост — не красивый и не вдохновляющий, а такой, от которого периодически хочется всё упростить и перестать лезть г

😕 Почему большинство «советов опытных разработчиков» вредны для новичковКак создатель обучающего контента для новичков, я стараюсь валидировать то, что пишу и говорю через призму «мой зритель/читатель – я 5 лет назад, а не я сегодняший». Потому что большая часть советов, которые дают «опытные разработчики», новичкам не помогает. Иногда – просто не подходит, иногда – откровенно тормозит рост.Когда человек с опытом что-то советует, он говорит из своей реальности. У него уже есть база, насмотренность, куча принятых решений за плечами. Он видит систему целиком и автоматически достраивает недостающие куски в голове. Новичок же этого контекста не видит. И в итоге один и тот же совет в двух разных головах превращается в разные вещи.Например, классическое: «не усложняй». Для условного мидла это означает: не городи лишние абстракции, если можно решить проще. Для новичка это часто превращается в «можно писать как попало, главное чтобы работало». И вместо упрощения получается грязь.Или любимое: «не используй лишние библиотеки». Для человека с опытом это про контроль и понимание, что ты тащишь в проект. Для новичка это легко превращается в страдание и изобретение велосипеда там, где можно было просто взять готовое решение и пойти дальше.Ещё один частый совет: «сначала пойми, потом пиши». Звучит логично, но по факту новичок часто не может «сначала понять». Ему нужно писать, ошибаться, ломать и через это уже доходить до понимания. Иначе получается бесконечное чтение теории без практики.Со временем я осознал то, что для мидла – норма, для новичка же может быть преждевременной оптимизацией. А то, что для сеньора выглядит как «очевидно», для новичка вообще не существует как концепция. В этом месте советы начинают работать против. Потому что они даются без уточнения: на каком ты уровне и в каком контексте это вообще актуально.Поэтому, если ты учишься, есть довольно полезный фильтр. Любой совет стоит прогонять через простой вопрос: это сейчас упрощает мне жизнь или усложняет? Если п

🗑 Почему 80% учебных проектов – мусор (и это ок)Когда я смотрю код учебных проектов новичков, у меня регулярно возникает мысль, что процентов 80 из них – откровенный мусор. Я сейчас именно про код, а не про то, как приложение выглядит в браузере. UI может быть вполне ок, фичи могут работать, но если глянуть исходный код – там регулярное дублирование, спорные решения, переменные а-ля var1 и data3, куски логики, которые непонятно зачем вообще существуют.И это норм! Учебный проект вообще не обязан быть красивым внутри. Более того – он почти всегда должен быть неправильным. Потому что в этот момент человек не «пишет хороший код», он проверяет гипотезы, пробуеь одно решение, потом другое, что-то ломает, что-то переписывает. Делает вещи, которые в реальном проекте никто бы не пропустил в прод. Так и выглядит обучение.Настоящая беда, когда учебные проекты превращаются в фальшивую витрину: чистая архитектура, аккуратные компоненты, консистентный нейминг — ну буквально всё копипаста из туториала.Проблема в том, что реальное обучение выглядит не так. Когда человек действительно учится, проект неоднократно рассыпается, ибо половина смелых решений заводит в тупик. Когда новичок спустя пару недель открывает свой же код и думает что за херню я тут написал — вот так и надо! Когда человек реально учится, его код постепенно упрощается. Он начинает выкидывать лишнее, замечает дублирование, понимает, что половина «умных решений» была просто усложнением.Когда человек имитирует бурную деятельность – происходит обратное. Код становится всё сложнее, появляются абстракции ради абстракций, архитектура ради архитектуры, сервисы, фабрики, слои «на будущее». Формально всё выглядит серьёзно, по факту человек просто пытается выглядеть разработчиком.Самый полезный учебный проект – тот, на который через пару месяцев немного стыдно смотреть. Потому что этот стыд означает одну простую вещь: с тех пор ты вырос.А вот если старые проекты кажутся идеальными – не очень хороший знак. Либо проект был сли