Перейти к основному содержимому

Познание и обучение

В РАЗРАБОТКЕЛАБОРАТОРИЯНЕ ОБЯЗАТЕЛЬНО

Когнитивный контекст специалиста​

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

Познание в контексте IT — это процесс формирования внутренней картины мира, в которой технологии занимают функциональную, но не исключительную роль. Обучение — это освоение синтаксиса языков или интерфейсов библиотек, и выстраивание устойчивых когнитивных стратегий: как искать, как проверять, как интегрировать, как отвергать.

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

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

  • фрагментации образовательных траекторий;
  • давления со стороны рынка труда, требующего немедленной прикладной отдачи;
  • отсутствия в профессиональной среде нормативных моделей когнитивного развития, отличных от «знать → применить → получить результат».

1. Познание​

1.1. Познание как процесс, а не как результат​

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

  • эмпирический — наблюдение, эксперимент, фиксация данных;
  • теоретический — обобщение, формулирование закономерностей, построение объяснительных моделей;
  • методологический — рефлексия над самими средствами и ограничениями познавательной деятельности.

В IT эти уровни проявляются, например, следующим образом:

  • при отладке программы разработчик наблюдает за поведением кода (эмпирия), формулирует гипотезу о причине ошибки (теория) и выбирает стратегию проверки — дебаггер, логирование, unit-тест (методология).

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

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

1.2. Познавательная нагрузка и когнитивная экономия​

В IT широко распространены практики, снижающие явную познавательную нагрузку:

  • использование готовых решений (библиотек, фреймворков, low-code-платформ);
  • копирование фрагментов кода из открытых источников;
  • автоматическая генерация документации или тестов.

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

Когнитивная экономия — не порок. Она необходима для фильтрации потока информации и сохранения ресурсов. Однако её следует осознавать и контролировать:

  • знать, где находится граница между «я понимаю» и «я умею применять»;
  • уметь в любой момент «распаковать» абстракцию и перейти к более глубокому уровню;
  • регулярно проверять, не деградировала ли экономия в привычку избегать усилия.

2. Структура, трудности, стратегии​

2.1. Обучение как проект, а не как событие​

Большинство представлений об обучении в IT носят событийный характер: «пройду курс», «получу сертификат», «закончу буткемп». Такой подход естественен — он соответствует инженерной ментальности, ориентированной на завершённые артефакты. Однако обучение не является проектом с чёткими входами и выходами. Оно не завершается — оно трансформируется.

Реальная образовательная траектория IT-специалиста состоит из чередующихся фаз:

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

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

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

2.2. Познавательная инерция и эффект «ложной близости»​

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

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

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

  • Python-скрипт для обработки Excel-файлов и Python-приложение на Django — оба на Python, но требуют принципиально разного набора знаний (работа с файловой системой vs архитектура веб-приложений, stateless-модель, безопасность, масштабирование);
  • написание unit-тестов для утилитной функции и построение end-to-end-тестового сценария — оба «тестирование», но различаются по целям, инструментам, уровню абстракции.

Эффект ложной близости ведёт к двум типам стратегических ошибок:

  • недооценке усилий, необходимых для перехода в смежную область («я же уже пишу на Python, ML будет легко»);
  • переоценке собственной готовности к решению комплексных задач («я сделал CRUD, значит, могу писать enterprise-системы»).

Осознание этого эффекта позволяет строить обучение более реалистично: по принципу «в чём принципиальное отличие X и Y? Какие новые концепции мне придётся ввести? Какие старые — пересмотреть?».

3. Личность как результат познавательной деятельности​

Понятие личности в профессиональном контексте часто сводят к набору soft skills: «коммуникабельный», «стрессоустойчивый», «умеет работать в команде». Такая редукция удобна для HR-процессов, но не отражает сущности. Личность — это структура субъектности: способность человека выступать в качестве инициатора, автора, ответственного за выбор и его последствия.

В IT эта структура формируется под давлением двух противоположных тенденций.

С одной стороны — технологическая объективация. Инструменты, процессы и метрики стремятся максимально устранить субъективность:

  • код должен быть идемпотентным, независимо от того, кто его написал;
  • CI/CD-пайплайн исполняется одинаково, вне зависимости от настроения оператора;
  • SLA измеряется в цифрах, а не в впечатлениях.

Это правильно и необходимо — без этого невозможна масштабируемость, предсказуемость, безопасность. Однако при недостаточной культурной рефлексии подобная объективация распространяется на производителя: человек начинает воспринимать себя как «ресурс» — заменяемый, измеримый, оптимизируемый. Его ценность определяется тем, сколько единиц работы он выполнил за единицу времени.

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

Разрыв между этими двумя полюсами и порождает профессиональное выгорание, импосторский синдром, ощущение «бессмысленности труда». Когда человек выполняет работу, требующую высокого уровня субъективного участия (принятие решений), но получает обратную связь только по объективным параметрам (скорость, количество, соответствие чек-листу), возникает когнитивный диссонанс: «Я думаю — но мне за это не платят. Мне платят за то, чтобы я не думал».

Выход — в осознанном разделении сфер:

  • в зоне инструментального исполнения стремиться к максимальной стандартизации и автоматизации;
  • в зоне смыслового проектирования — к максимальной рефлексии и ответственности.

Развитие личности в IT — это, прежде всего, развитие способности видеть эту границу и сознательно пересекать её, когда это необходимо. Это умение различать, где требуется строгая дисциплина следования протоколу, а где — смелость постановки нового вопроса.

Личность здесь — не украшение, не «хобби после работы». Это операционная характеристика: от неё зависит, сможет ли специалист:

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

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

4. Кругозор и профессиональная устойчивость​

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

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

Широкий кругозор выполняет три ключевые функции в IT:

Во-первых, он обеспечивает контекстуальную избыточность.

Когда знания фрагментированы («я знаю Spring, но не знаю, что такое транзакция в принципе»), любое изменение контекста — смена технологии, переход от монолита к микросервисам, интеграция с внешней системой — требует полной перестройки мышления. Когда же человек обладает базовыми моделями (например, понимает, что такое состояние, инвариант, изоляция), он может «перевести» новую технологию на уже знакомый язык концепций. Это существенно снижает порог входа в новые области.

Во-вторых, он снижает риск когнитивного застоя.

IT-среда стимулирует постоянное обновление инструментов, но не всегда — обновление мышления. Можно десять лет писать на JavaScript, но оставаться на уровне представлений 2012 года — если не сталкиваться с идеями из других дисциплин: лингвистики (как устроены языки, чем формальные отличаются от естественных), кибернетики (как системы поддерживают устойчивость), теории сложности (почему некоторые задачи фундаментально трудны). Без такого «внешнего импульса» мышление склонно к рутинизации: новые инструменты воспринимаются как «старые, только с другим синтаксисом».

В-третьих, он создаёт резерв смысла.

Когда профессиональная идентичность сужается до «я — тот, кто пишет код на C#», любая внешняя угроза (автоматизация, сокращение, технологический сдвиг) воспринимается как угроза существованию. Если же идентичность включает в себя «я — человек, который учится, анализирует, создаёт решения», то смена стека или даже сферы деятельности не разрушает её, а лишь трансформирует.

Кругозор — это системная практика:

  • сопоставлять понятия из разных областей (например, «дедлок» в БД и «тупик» в транспортной логистике);
  • задавать себе вопрос: «Как бы это объяснил человек, далёкий от IT?»;
  • регулярно сталкиваться с непереводимым — с тем, что не укладывается в привычные категории.

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

5. Практические стратегии обучения​

Обучение в IT часто начинается с выбора курса. Это ошибка. Курс — это инструмент. Инструмент можно использовать эффективно только при наличии чёткого замысла.

5.1. Диагностика исходного состояния​

Первый шаг — не «что мне выучить?», а «что я уже знаю, но не осознаю как знание?».

Многие начинающие считают, что «ничего не знают», потому что не могут написать веб-приложение с нуля. Однако они могут:

  • понимать, как работает поиск в Google (модель запрос-результат, релевантность);
  • настраивать Wi-Fi роутер (представление о сетях, IP, аутентификации);
  • использовать Excel для анализа (табличная модель данных, формулы как функции);
  • объяснять родственникам, почему нельзя открывать письма от неизвестных (базовая модель угроз).

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

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

  • какие действия я совершил?
  • какие предположения лежали в основе этих действий?
  • какие альтернативы я отверг и почему?
  • какие риски я считал приемлемыми?

Это упражнение выявляет скрытые модели мышления и позволяет оценить, насколько они соответствуют реальности. Часто оказывается, что «я ничего не знаю» — это преувеличение, а «я всё знаю» — иллюзия, основанная на удачных совпадениях.

5.2. Постановка обучающей цели как проектирование будущего состояния​

Цель вида «стать джуном» или «выучить Python» неуправляема: она не позволяет оценить прогресс, скорректировать траекторию, распределить ресурсы.

Эффективная цель — это описание желаемого поведения в конкретном контексте. Например:

  • «Я могу самостоятельно реализовать REST API на FastAPI, покрыть его тестами, задеплоить в Docker-контейнере и написать документацию в OpenAPI»;
  • «Я могу провести code review у коллеги, найдя не только синтаксические ошибки, но и потенциальные уязвимости, связанные с инъекциями или неправильной обработкой ошибок»;
  • «Я могу объяснить нетехническому заказчику, почему его требование приведёт к росту технического долга, и предложить альтернативу».

Такие формулировки дают:

  • критерий завершённости («я это сделал — цель достигнута»);
  • возможность декомпозиции («что нужно знать и уметь, чтобы это сделать?»);
  • основание для выбора инструментов (курс, книга, менторство, эксперимент).

5.3. Пет-проект как среда познания​

Пет-проект часто рассматривают как «демонстрационный артефакт для резюме». Это узкое понимание.

Пет-проект — это лаборатория познания. Его ценность не в результате, а в процессе:

  • он позволяет столкнуться с неудобными вопросами, которые опускаются в учебных задачах («как хранить секреты?», «что делать при частичном сбое?», «как понять, что система работает некорректно, если ошибки не падают?»);
  • он вынуждает принимать компромиссы — между скоростью и качеством, между функциональностью и поддерживаемостью, между собственным пониманием и общепринятыми практиками;
  • он создаёт личный контекст для абстрактных понятий: паттерн «наблюдатель» перестаёт быть словом в книге, когда вы его реализуете для уведомлений в своём приложении.

Ключевые принципы работы с пет-проектами:

  • начинайте с ограничения, а не с идеи. Вместо «я хочу сделать соцсеть» — «я хочу научиться работать с WebSockets, поэтому сделаю чат, где максимум 3 пользователя и нет аутентификации». Ограничение фокусирует усилие;
  • фиксируйте не только код, но и рассуждения. В README или отдельном дневнике: почему выбрана такая БД, а не другая? Какие варианты архитектуры рассматривались? Что пошло не так и как это было исправлено? Это — ваш персональный корпус опыта;
  • не стремитесь к завершённости. Лучше три раза переписать одну и ту же функцию с разными подходами, чем один раз доделать проект «до конца» и забросить.

Пет-проект успешен, если после него вы точнее формулируете свои вопросы. Это — признак роста.

6. Компенсаторные и синергетические дисциплины​

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

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

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

Компенсаторные дисциплины, напротив, сознательно вовлекают другие когнитивные системы:

  • Физическая активность (бег, плавание, йога, силовые тренировки) активирует мозжечок, базальные ганглии, вестибулярный аппарат — структуры, отвечающие за координацию, ритм, внутреннее равновесие. Они усиливают нейрогенез в гиппокампе, что напрямую повышает способность к обучению и консолидации памяти;
  • Художественное творчество (рисование, лепка, сочинение музыки) задействует правополушарные процессы: образное мышление, многозначность, восприятие целостности. Это снижает доминирование аналитического стиля и позволяет находить неочевидные связи между элементами;
  • Изучение естественных языков (даже на базовом уровне) тренирует металингвистическую осведомлённость — способность рефлексировать над структурой языка как такового. Это напрямую полезно при работе с DSL (domain-specific languages), при проектировании API (как языков взаимодействия) и при чтении технической документации на английском без автоматического перевода смысла на родной.

Такие занятия восстанавливают базовую когнитивную инфраструктуру, без которой работа становится всё менее эффективной.

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

Примеры:

  • Изучение истории технологий (как истории социальных практик) позволяет видеть в современных трендах не «революционные прорывы», а вариации старых паттернов. Например, концепция «серверлесс» — возврат к модели time-sharing 1960-х, адаптированной под экономику облачных вычислений. Такое видение помогает предвидеть ограничения и побочные эффекты задолго до их проявления;
  • Знакомство с юриспруденцией (даже на уровне базовых принципов: презумпция невиновности, иерархия норм, субсидиарность) формирует мышление, ориентированное на интерпретацию правил в условиях неопределённости. Это критически важно при работе с требованиями, где формулировки часто противоречивы, неполны или устарели;
  • Изучение психологии восприятия (например, принципов Гештальта или когнитивных искажений) позволяет проектировать интерфейсы, API, логи и отчёты так, чтобы минимизировать когнитивную нагрузку пользователя. Вопрос «почему разработчик пропустил этот баг?» перестаёт быть обвинением, а становится вопросом о структуре внимания в конкретной среде;
  • Чтение художественной литературы, особенно реализма и модернизма, развивает навык интерпретации мотивов и неявных контекстов. Это напрямую применимо при анализе требований: за формулировкой «нужна кнопка „Экспорт в Excel“» может стоять потребность в аудиторской проверке, в возможности ручной корректировки данных, в интеграции с устаревшей отчётностью — и только умение «читать между строк» позволяет выявить это до начала реализации.

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

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

7. Эпистемологическая зрелость​

Эпистемологическая зрелость — это способность человека осознавать природу собственного знания: откуда оно берётся, какие у него границы, как оно изменяется, чем отличается от мнения, веры или догадки.

В IT эта зрелость проявляется не в отсутствии ошибок (ошибки неизбежны), а в характере реагирования на них.

7.1. Уровни эпистемологического развития (по адаптированной модели Берри и Берри)​

Можно выделить несколько устойчивых позиций, через которые проходит специалист:

Позиция 1: Знание как данность

Знание воспринимается как набор фиксированных истин, передаваемых авторитетами (курсы, документация, senior-разработчики). Ошибки интерпретируются как личная несостоятельность: «я не выучил», «я не понял». Вопрос «почему так?» редко возникает — важен только «как сделать».

Позиция 2: Знание как инструмент

Знание оценивается по функциональности: «работает — не трогай», «не работает — замени». Появляется прагматизм: разные инструменты для разных задач. Однако отсутствует рефлексия над почему инструмент работает в одних условиях и не работает в других. Множественность подходов воспринимается как «хаос», «всё меняется», «никто не знает, как правильно».

Позиция 3: Знание как модель

Человек осознаёт, что любое знание в IT — это модель. Модель упрощает, выделяет существенное, игнорирует детали. Её ценность — адекватности цели.

  • ORM — модель, скрывающая сетевые и транзакционные детали ради упрощения бизнес-логики;
  • CI/CD — модель управления изменениями, основанная на гипотезе о том, что частые мелкие деплои безопаснее редких крупных;
  • Даже «чистый код» — модель, оптимизирующая читаемость за счёт, например, увеличения числа абстракций.

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

Позиция 4: Знание как процесс коэволюции

Специалист понимает, что знание и практика изменяются вместе. Новые инструменты трансформируют саму постановку задач. Например, появление Kubernetes изменило то, как деплоятся приложения, и то, какие требования считаются разумными (например, обязательность stateless-компонентов).

На этом уровне человек способен:

  • различать технологический тренд (временная волна интереса) и структурный сдвиг (изменение базовых допущений);
  • участвовать в конструировании новых моделей;
  • обучать других, не передавая рецепты, а показывая, как строить модели под задачу.

7.2. Как формировать эпистемологическую зрелость?​

Требуется специальная практика:

  • Ведение инженерного дневника

Фиксация:

  • Какую модель я использовал при принятии решения?
  • Какие допущения лежали в её основе?
  • Какие данные подтвердили или опровергли эти допущения?
  • Как бы я перестроил модель, зная то, что знаю сейчас?

Это превращает опыт в структурированную память.

  • Практика «объяснения вглубь»

Выбрать любое утверждение («используйте HTTPS», «избегайте глобальных переменных», «делайте маленькие PR») и задавать себе цепочку вопросов «почему?» минимум пять раз.
Пример:

  • Почему использовать HTTPS? → Чтобы шифровать трафик.
  • Почему шифровать? → Чтобы предотвратить перехват данных.
  • Почему перехват опасен? → Потому что данные могут быть конфиденциальными.
  • Почему конфиденциальность важна? → Потому что нарушение может привести к ущербу (юридическому, репутационному).
  • Почему юридический ущерб несёт вес? → Потому что организация функционирует в правовом поле, где ответственность опосредована нормами…
    На пятом уровне вы вышли за пределы IT — и это нормально. Так вы обнаруживаете фундаментальные ценности, на которых строится ваша техническая позиция.
  • Работа с историческими артефактами

Изучение устаревших технологий для понимания:

  • Почему COBOL до сих пор работает в банковских системах?
  • Почему в 1990-х годах доминировали монолиты?
  • Почему early Unix был написан на ассемблере, а позже — на C?

Это позволяет увидеть, что «лучшие практики» всегда контекстуальны: они оптимальны при определённых ограничениях (стоимость памяти, скорость сети, культура разработки). Отсюда — устойчивость к модным лозунгам вроде «микросервисы — это будущее» без анализа при каких условиях они действительно лучше.

Эпистемологическая зрелость — это «я знаю, как я знаю, и как могу перестать знать то, что мешает».

Обучение как образ жизни​

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

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

Альтернатива — рассматривать обучение как образ жизни: как способ присутствия в мире, как практику поддержания когнитивной и личностной целостности.

В этом случае:

  • неудача в трудоустройстве — повод пересмотреть свою модель рынка;
  • появление нового фреймворка — возможность проверить, насколько гибка ваша система понятий;
  • потеря работы — окно для рефлексии: чему я научился как человек, а не только как исполнитель?

IT — про вопросы, которые человечество задаёт себе с помощью технологий:

  • Как организовать сложное?
  • Как сохранить целостность при масштабировании?
  • Как управлять неопределённостью?
  • Как разделить ответственность между человеком и машиной?

Эти вопросы стары как цивилизация. Технологии меняются — вопросы остаются.

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

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