Путь разработчика
12 subscribers
1 link
Я Александр. Занимаюсь веб разработкой уже более 20 лет. На этом канале вы найдёте советы, истории и размышления по софт скилам, основанные на моём опыте работы. Уверен, они будут полезны тем, кто хоть как-то связан с разработкой.
Download Telegram
Работай в потоке

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

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

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

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

Как насчёт когнитивной тренировки? Чтобы поддерживать свой мозг в тонусе хорошо бы заниматься чем-то, кроме "потокового дофамина" (просмотр рилсов, чтения твитов и игр в пустышки). Отдыхать это одно, но умеренная тренировка мозга это другое.

Чтение хороших книг, решение каких-то задач или выполнение каких-то упражнений это минимум, который должен быть. Но нужно что-то большее. Как вам решение математических кроссвордов? Считаю это хорошим и простым способом тренировки своих навыков. Либо решение каких-то логических задач. А для разработчиков отличным вариантом будем решение алгоритмических задач на определенных ресурсах.

Ещё мне нравится тренировать способность делать 2 простых дела одновременно. Например, правой рукой перекладывать вещи из одной стопки в другую, а левой рукой (в тоже самое время) что-то доставать из шкафа или с полки. Но можно и сложнее, главное заниматься этим. Можно попробовать слушать 2 разговора одновременно и понимать суть каждого.

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

Давайте порассуждаём о ставках и навыках в IT. Если должность разработчика предполагает зп ниже рынка, то максимум мы можем получить кандидата уровня ниже среднего, либо новичка с желанием роста. Но слабые разработчики это некачественные реализации задач. А плохо сделанные задачи это плохое итоговое приложение. Плохо реализованное приложение это боль тимлида и руководителя. В итоге приходится искать какой-то компромисс. И варианта 2: либо тимлид уходит из проекта, либо проект закрывается.

Если мы смогли найти новичка с желанием роста, то результат мы получим максимум через пол года. За пол года мы получим некачественные реализации задач. А плохо сделанные задачи это плохое итоговое приложение. Плохо реализованное приложение это боль тимлида и руководителя. Ну и всё как описано выше. Однако есть третий путь. Тимлид тратит время на обучение новичка, а через пол года сотрудник (уже опытный) уходит на другое место работы.

А если растить новичка как часть семьи? Поддержка, взаимопомощь, менторство. Единый коллектив, единые цели, единый результат. Все довольны. Но расход по ресурсам возрастает на порядок. Проектирование развития сотрудников должно быть глобальным. Процесс должен быть комплексным. Часто это боль директора. В итоге директору приходится искать компромисс. Обычно компромисс подразумевает сокращение расходов. А значит приходится искать сотрудников с зп ниже рынка.

В итоге круговорот разработчиков становится обыденностью. Может это и не плохо. Свежая кровь, новые идеи, креативные решения, неочевидные баги, нестандартные проблемы, сорванные сроки, закрытые проекты, боль руководителей. Что-то тут не сходится. А проекты, в итоге, вытягивают идейные. А кто ты? Готовый работать за идею или во благо себя? Каждый отвечает сам. Но подумать над этим вопросом надо как можно раньше.
Идея как способ самореализации

Каждый день в голову приходит что-то мелкое: «переставить стол к окну» или «попробовать планировать утро». Такие мысли обычно сырые и не тянут на откровения. Чаще всего мы их игнорируем - забыли через минуту, и всё. Но именно в этом бытовом мусоре часто скрывается то, что потом меняет распорядок дня, настроение или планы на год.

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

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

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

Андрей Петрович Ершов родился в Москве в 1931 году и прожил всего 57 лет, но успел стать живой легендой советской науки. Один из пионеров системного программирования, академик АН СССР, он не просто писал код - он стоял у истоков Сибирской школы информатики. В 1960 году он переехал в Новосибирский Академгородок, где и занимался своей деятельностью. Под его руководством и при его участии были созданы такие языки программирования, как Альфа, Альфа-6 и трансляторы с них. А также он занимался разработкой искусственного интеллекта. Ершов был «программистом номер один» в стране, заложив основы того, как мы сегодня понимаем разработку ПО.

Роль Ершова в развитии советских IT - уникальна. Он не копировал Запад, а двигал собственную науку: первым в СССР перевел и внедрил идеи структурного программирования и доказательства корректности алгоритмов. По сути, он построил мост между абстрактной математикой и «железом» вычислительных машин. Без Ершова советская кибернетика долго бы оставалась на уровне счетов и перфокарт. Он воспитал поколение исследователей, которые позже адаптировали мировой опыт под нашу действительность.

Эта история - яркий пример того, как личная одержимость может сдвинуть горы, но система оказывается сильнее. Даже гений Ершова упирался в стену Госплана, отсутствие совместимости с западными архитектурами и пресловутый «железный занавес». Учёный стремился дать СССР собственный Unix и массовое программирование, но командно-административная экономика требовала отчётности, а не прорывов. Его идеи тормозились ведомственными барьерами - драма человека, который знал, КАК надо, но не мог переписать правила игры.

Несмотря ни на что, Ершов - образец того, как двигать отрасль ценой собственного здоровья и времени. Он работал на износ, умирая от болезни, но продолжал читать лекции и редактировать журналы. Его целеустремлённость сегодня кажется фантастической: когда всё против тебя, но ты веришь в силу информации, можно создать школу мирового уровня с нуля. Хотите быть похожими на него? Тогда забудьте об отговорках. Берите пример с Ершова - пишите код, учите других и помните: история помнит тех, кто работал, а не тех, кто ждал.
Тематический фестиваль как хорошая книга

Недавно я был на CodeFest 2026 в Новосибирске. Подобное мероприятие я посещаю впервые. Всё понравилось и было много полезной информации. За 2 дня я посетил 12 тематических выступлений разного направления. Большую часть по профессиональной деятельности, немного по личным предпочтениям. Но т.к. я там был впервые, то с парой выступлений промахнулся. Но даже в таком случае там было что почерпнуть для себя.

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

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

Юмор - это не просто способ поднять настроение в опенспейсе, а настоящий рабочий инструмент тимлида. Когда дедлайны горят, а баги размножаются быстрее, чем мы успеваем их фиксить, вовремя вставленная шутка способна мгновенно разрядить напряжение в команде. Она сбрасывает накопившийся стресс и помогает переключить мозг с паники обратно в режим продуктивного решения проблем.

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

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

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

Важно понять: полностью избавиться от тревожности невозможно, да и не нужно. Это всё равно что пытаться удалить системные логи - они всегда будут появляться. Вместо войны с собой стоит выстроить здоровые механизмы управления этим состоянием. Это требует регулярных "тренировок": практики осознанности, чёткого разделения рабочего и личного времени, а также умения переключать контекст. Выдержка приходит с опытом, когда вы учитесь не игнорировать сигналы тревоги, а экологично их обрабатывать, задавая себе вопрос: "Что именно я могу контролировать прямо сейчас?".

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

Мир сильно меняется. За последние 5 лет он изменился настолько, насколько раньше не менялся за 50 лет. И этот рост увеличивается. Успевать за ним довольно непросто. И такие изменения для кого-то могут стать причиной краха его надежд и желаний. 10 лет назад мы мечтали об одном, а сейчас это уже прошлое.

И в этом быстро меняющемся мире нужны другие цели. Нужны более прогрессивные планы и более амбициозные задачи. Но чтобы реализовать такие грандиозные планы нужны титанические усилия. А есть ли на них ресурсы? Это вопрос с неоднозначным ответом. Поэтому нужны новые подходы и новые парадигмы. Нужно по новому быть лучше.

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

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

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

Наконец, не стоит недооценивать влияние благодарности на внутреннюю мораль команды. Когда мы слышим искреннее "спасибо" или "отличная работа", наш мозг вырабатывает дофамин, вызывая чувство удовлетворения и гордости. Это не только поднимает настроение, но и значительно повышает продуктивность: счастливый сотрудник работает эффективнее. Регулярная похвала создает эффект "эмоционального резонанса" - позитив передается от одного члена команды к другому, формируя общий высокий моральный дух. В итоге выигрывают все: снижается уровень стресса и выгорания, улучшается климат в коллективе, а совместные проекты завершаются быстрее и качественнее. Помните: признание чужих заслуг не умаляет ваших собственных, а лишь умножает общую силу команды.
Возраст объединяет?

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

Главное преимущество такого коллектива - когнитивная синхронность. Ваши одногодки, как правило, мыслят в похожих парадигмах: вы учились на одних и тех же технологических трендах, читали одни и те же статьи на Хабре или Medium, проходили через одни и те же «грабли» при переходе с jQuery на VueJs или с монолита на микросервисы. У вас примерно общий срез знаний и, что важнее, - общий культурный код: вы шутите над одними мемами, ссылаетесь на одни и те же культовые игры или фильмы, и вам не нужно тратить время на расшифровку базовых понятий. Это создает невероятно быструю обратную связь в код-ревью и минимизирует коммуникативные шумы.

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

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