Preview
Хей, парни! на связи Иван | White2Hack
И так, кто не знает несколько лет назад, а точнее в 2023 году я собрал большую брошюру про обучение и самообучение. Получилось больше ста страниц: память, внимание, нейропластичность, интервальные повторения, мнемотехники, скорочтение, Pomodoro, мотивация, приоритизация и ещё куча всего. За это время я продолжал преподавать, читать курсы, готовиться к сертификациям, учить языки, осваивать новые security-технологии и собирать свои собственные лаборатории. И постепенно понял неприятную вещь: знать много техник обучения — ещё не значит хорошо учиться.
Можно идеально знать, что такое spaced repetition, завести пять приложений для заметок, купить три курса по Kubernetes — и через месяц всё равно не суметь с нуля объяснить, как работает NetworkPolicy.
Я видел похожую картину и у студентов. Пока слайд открыт — всё понятно. Убираешь слайд и просишь объяснить своими словами — начинается самое интересное. Поэтому сейчас я смотрю на обучение гораздо приземлённее. Мне нужен не красивый процесс. Мне нужен результат, который можно проверить.
Не “я изучил тему”, а “я могу что-то сделать без подсказки”.
Ниже, в этом материале — система, которую я сегодня использую для себя. Она подходит не только для IT\CyberSec: тем же способом я учу английский, читаю технические книги, разбираю видео, готовлюсь к интервью и вхожу в новые области Product Security / AppSec / DevSecOps.
Сразу оговорюсь: здесь не будет обещаний «выучить всё за 20 часов» или магического расписания повторений. В моей старой работе такие формулировки местами были слишком смелыми. Сейчас я бы их не повторял. И, так выдаю базу!
Главный сдвиг: учить не тему, а действие
Самая полезная привычка, которую я вынес из преподавания и собственного обучения: формулировать цель глаголом.
Плохо:
- выучить API Security;
- подтянуть английский;
- разобраться с AWS;
- посмотреть курс по DevSecOps.
Намного лучше:
- найти Broken Object Level Authorization в тестовом API, показать exploit path и предложить remediation;
- за 10 минут рассказать на английском о своём проекте и ответить на follow-up questions;
- построить threat model небольшого сервиса;
- добавить SAST (Static Application Security Testing) и SCA (Software Composition Analysis) в pipeline, намеренно сломать gate, понять причину и настроить policy;
- прочитать главу и через день восстановить её основные идеи без книги.
Это, кстати, хорошо совпадает с тем, как профессиональные cybersecurity frameworks описывают работу: через tasks, knowledge and skills, а не через абстрактное «знаком с безопасностью».
Для себя я называю это performance-first learning.
| Тема | Слабая цель | Проверяемая цель |
|---|---|---|
| English | Improve speaking | Провести 20-минутное mock interview без русского |
| Pentest | Learn web pentesting | Найти и воспроизвести 3 класса уязвимостей в lab |
| AppSec | Learn threat modeling | Сделать threat model сервиса и защитить решения перед инженером |
| DevSecOps | Learn CI/CD security | Настроить security gate и обработать FP/exception |
| Книга | Прочитать 300 страниц | Через неделю объяснить 10 ключевых идей и применить 2 из них |
| Видео | Посмотреть курс | Воспроизвести показанное без видео и решить похожую задачу |
Если цель невозможно проверить, обучение очень легко превращается в потребление контента.
Мой learning loop или как Я сам это делаю
Сегодня мой базовый цикл выглядит примерно так:
Результат, который хочу получить
↓
Карта предмета
↓
Один хороший пример
↓
Объяснить пример самому себе
↓
Закрыть источник и вспомнить
↓
Сделать самому
↓
Получить обратную связь
↓
Вернуться через интервал
↓
Решить похожую, но уже новую задачу
↓
Объяснить другому человеку
Мне нравится эта схема тем, что в ней почти невозможно спрятаться за фразой «я вроде понял». Либо сделал, либо нет.
1. Я больше не начинаю с первой страницы
Открыть книгу на Chapter 1 и дисциплинированно идти до Chapter 27 выглядит правильным. Иногда так и надо. Но при ограниченном времени это часто плохая стратегия входа в новую область.
Сначала я хочу увидеть карту.
Если это книга — смотрю оглавление, введение, summary, заголовки, основные термины. Если это технология — architecture overview, glossary, quick start, типичный workflow. Если это security — assets, trust boundaries, attack surface, identities, data flows, controls, telemetry. Если это английский — не «все времена английского языка», а конкретные ситуации: meeting, email, interview, объяснение finding, disagreement, clarification.
Это тот случай, когда старый принцип 80/20 для меня всё ещё полезен — не как математический закон, а как вопрос:
Какие несколько понятий дадут мне возможность понимать остальные?
Например, прежде чем читать сто страниц про OAuth/OIDC, полезно понять участников протокола, tokens, redirect flow и trust relationships. После этого детали перестают быть набором терминов.
В моей старой брошюре была формулировка: новая информация легче «цепляется» за уже существующий скелет знаний. Сейчас я бы сказал проще: сначала построи систему координат, потом добавляй детали.
2. Новичку не всегда полезно сразу бросаться в задачу. Сначала посмотри один хороший worked example
В IT популярен совет: «не читай — просто делай». В нём есть правда, но для совсем новой области он иногда превращается в другое: человек два часа хаотично тыкается, копирует команды из Stack Overflow и вообще не понимает, почему что-то заработало.
Для нового типа задач мне больше нравится такой порядок:
- посмотреть один качественный решённый пример;
- на каждом существенном шаге спросить себя: почему автор сделал именно это?;
- закрыть пример;
- повторить самостоятельно;
- потом изменить условия задачи.
Исследования worked examples и self-explanation давно показывают, что для раннего этапа освоения сложных когнитивных навыков это может быть эффективнее, чем сразу бросать новичка в полностью самостоятельное problem solving.
В security это выглядит очень естественно. Допустим, я впервые разбираю SSRF (Server-Side Request Forgery). Не просто смотрю готовый exploit, а проговариваю:
Почему этот input controllable?
Почему backend делает server-side request?
Какая trust boundary пересекается?
Что именно доступно из internal network?
Как отличить реальный SSRF от красивого payload, который ничего не даёт?
Какой control устранит root cause, а какой только усложнит эксплуатацию?
Вот в этот момент чужой walkthrough превращается в мою модель.
3. Перечитывание даёт ощущение знания. Retrieval показывает правду
Это, пожалуй, самый ценный инструмент во всей статье. Схема, на которой я сам много раз ловился:
прочитал → понятно → перечитал → ещё понятнее → закрыл → ничего не помню
Знакомость материала очень легко спутать со знанием. Поэтому после небольшого блока я закрываю источник и пытаюсь извлечь материал из памяти.
Не посмотреть правильный ответ ещё раз. Сначала именно вспомнить.
**
После OAuth/OIDC** — нарисовать flow с пустого листа.
После Kubernetes — написать manifest без copy-paste.
После видео по Burp Suite — повторить последовательность действий самому.
После английского — сказать фразу вслух до того, как открыл карточку.
После главы книги — записать 5–7 тезисов по памяти.
Retrieval practice хорошо поддерживается исследованиями обучения и, что для меня важнее, прекрасно работает как диагностика. Если я не могу восстановить идею — значит, проблема обнаружена сейчас, а не на интервью или в production.
Мой простой тест понимания
После любой темы я задаю себе три вопроса:
1. Могу ли я объяснить это без источника?
2. Могу ли я сделать это без пошагового гайда?
3. Узнаю ли я эту же идею в другом контексте?
Первый проверяет память.
Второй — навык.
Третий — transfer.
Вот третий обычно самый неприятный :)
4. Spacing: возвращаться к материалу полезнее, чем пытаться «вбить» его за один вечер
В версии 2023 года я много писал про кривую Эббингауза и давал довольно конкретные интервалы повторений. Сегодня я бы оставил принцип, но убрал магию вокруг цифр.
Распределённая практика работает. Универсального идеального расписания для любого человека и любого материала — нет. Для новой темы я могу начать примерно так:
| Этап | Примерный момент |
|---|---|
| Первый контакт | День 0 |
| Recall без подсказки | В тот же день |
| Короткая проверка | День 1 |
| Ещё одно извлечение | День 3–4 |
| Практика в новой задаче | День 7 |
| Проверка сохранности | Через 2–4 недели |
Но это не календарь религиозных праздников. Если вспоминаю легко — увеличиваю интервал. Если всё развалилось — возвращаюсь раньше.
Для языка это удобно отдавать Anki или другой системе интервальных повторений (SRS). Для технических навыков карточки нужны далеко не всегда. Иногда лучший spaced repetition для AppSec — через неделю получить другую уязвимую API и снова пройти путь identify → exploit → impact → remediation → retest.
5. Для security я использую цикл «увидел → сломал → починил → объяснил»
Вот здесь generic learning advice обычно заканчивается, а мне как раз становится интересно. *Cybersecurity плохо учится только чтением. *Систематический обзор университетских cybersecurity courses показывает устойчивый акцент на active learning, case studies, simulations, virtual labs и project-based assessment. NIST NICE Framework тоже описывает развитие специалиста через реальные work roles, tasks, knowledge и skills; вокруг него существуют challenge-based и hands-on training environments.
На практике я стараюсь превращать тему в цикл:
Observe
↓
Reproduce
↓
Break / Attack
↓
Fix / Mitigate
↓
Retest
↓
Explain the risk
Penetration Testing
Если тема — IDOR/BOLA, мне мало определения из OWASP.
Я хочу:
- увидеть нормальный request;
- понять identity/authorization context;
- изменить identifier;
- воспроизвести unauthorized access;
- доказать impact;
- предложить server-side control;
- проверить fix другим пользователем/tenant.
Тогда vulnerability перестаёт быть карточкой с термином.
Product Security / AppSec
Для каждого класса проблем полезно собрать небольшой mental template:
Asset
→ Entry point
→ Trust boundary
→ Preconditions
→ Abuse / attack path
→ Business impact
→ Control
→ Validation
После десятка реальных разборов ты начинаешь узнавать структуру проблемы раньше, чем вспоминаешь номер или название CWE-класса.
DevSecOps
Здесь я вообще считаю лабораторию обязательной.
Не «я посмотрел, как работает SAST», а:
- добавил scanner в pipeline;
- положил в код заведомую проблему;
- увидел finding;
- настроил gate;
- поймал false positive;
- сделал exception с понятным сроком и owner;
- проверил, что pipeline не превратился в генератор ненависти разработчиков к Security.
Последний пункт часто важнее первых шести.
6. Английский я тоже перестал учить как «предмет»
С иностранным языком особенно легко коллекционировать знания вместо навыка. Можно знать Present Perfect, иметь 8 000 карточек и всё равно зависнуть, когда на митинге тебя внезапно спрашивают:
What exactly is blocking the release?
Поэтому мой подход к языку сейчас сценарный. Не учу слово отдельно, если могу выучить рабочий chunk:
clarify
→ Could you clarify what you mean by ...?
concern
→ My main concern is ...
blocked
→ I'm currently blocked by ...
recommend
→ I'd recommend validating this before release.
Исследования L2 vocabulary показывают, что простое массовое повторение слабее, чем сочетание repetition с retrieval, spacing и semantic elaboration. Исследования corrective feedback также в целом поддерживают пользу обратной связи при освоении второго языка.
Но мне важна практическая часть: слово должно начать жить в речи.
Мой короткий цикл для Technical English
INPUT
услышал / прочитал 5–10 полезных конструкций
RETRIEVAL
закрыл список и попытался вспомнить
OUTPUT
сказал их своими словами в другом контексте
FEEDBACK
проверил формулировку / получил correction
REUSE
использовал через день в новом сценарии
Например, вместо 40 минут vocabulary list я могу 20 минут разыгрывать один сценарий:
SAST нашёл authorization issue перед релизом. Объясни разработчику finding, impact и next step на английском.
Там одновременно тренируются vocabulary, grammar, pronunciation, security thinking и способность не превращать разговор в набор заученных фраз. Если язык нужен для работы — и практика должна быть похожа на работу.
7. Как я теперь смотрю обучающие видео
YouTube очень хорошо умеет создавать ощущение продуктивности. Полтора часа прошло, progress bar дошёл до конца — мозг доволен. А что осталось?
Видео я стараюсь смотреть с остановками по смысловым кускам, а не как сериал. Это хорошо согласуется с исследованиями multimedia learning: learner-paced segmentation снижает перегрузку на сложном материале, а более свежий meta-analysis по video learning показывает преимущества active learning strategies для retention, comprehension и transfer.
Мой режим простой:
10–20 минут видео
↓
PAUSE
↓
3–5 тезисов по памяти
↓
один вопрос: «что здесь было непонятно?»
↓
повторить показанное самому
↓
только потом следующий кусок
Если в видео показывают лабораторию, я не считаю её пройденной, пока не смог сделать хотя бы ключевую часть без автора на втором мониторе.
Скорость 1.5x? Иногда отлично для знакомой темы или review. Для нового плотного материала я лучше посмотрю медленнее и один раз нормально пойму причинно-следственную связь.
Скорость плеера — плохая метрика скорости обучения.
8. Как я читаю технические книги и большие документы
Здесь я разделяю два режима.
Triage reading
Мне нужно понять:
- стоит ли материал моего времени;
- где лежат нужные куски;
- как устроена тема;
- что читать глубоко.
Тогда я быстро прохожу:
TOC → intro → headings → diagrams → summary/conclusion → нужные разделы.
Deep reading
Если раздел реально нужен, скорость перестаёт быть целью. Я читаю небольшой кусок и превращаю его в вопросы:
Почему это работает?
При каких условиях перестанет работать?
Как это выглядит в реальной системе?
Что здесь можно перепутать?
Как я это проверю в lab?
Для сложных тем полезен self-explanation: не просто повторить предложение автора, а связать его с уже известными принципами и объяснить самому себе, почему следующий шаг следует из предыдущего.
Это гораздо медленнее, чем «прочитать 100 страниц за вечер». Зато через неделю есть что вспомнить.
9. Я перестал коллекционировать информацию. Теперь я её сжимаю
Ещё одна ловушка самообучения — бесконечная агрегация.
50 bookmarks.
17 YouTube playlists.
Три Notion workspace.
Папка READ_LATER_FINAL_v2.
И прекрасное чувство, что знания почти принадлежат тебе :) Сейчас для темы я стараюсь иметь одну рабочую точку сборки. Не обязательно красивую.
Мой минимальный шаблон заметки:
# Тема
**Зачем мне это?**
## 5–10 core concepts
## Что я пока не понимаю
## Как это проверить руками
## Ошибки / failure modes
## Что я могу объяснить без источника
## Ссылки на 2–5 действительно хороших источников
После каждого нового источника я не копирую всё подряд, а спрашиваю:
Что в моей модели изменилось?
Если ничего — возможно, источник мне больше не нужен. Это особенно полезно в Product Security, где один и тот же тезис можно встретить в OWASP, NIST, vendor documentation, блоге, conference talk и пяти Medium-постах. Пять ссылок не обязательно означают пять новых знаний.
10. Фокус: я не пытаюсь выиграть у уведомлений силой воли
В старой брошюре у меня был раздел Multitasking VS Focus и отдельный «метод трёх часов без шума».
Сейчас я сохранил идею, но перестал поклоняться цифре «три часа». Для сложного learning block мне нужны:
одна задача
+ один контекст
+ выключенные уведомления
+ заранее понятный output
Иногда это 25 минут. Иногда 50. Иногда полтора часа, если пошла нормальная глубокая работа.
Task switching имеет реальную cognitive cost. Мне не нужно знать точное число потерянных процентов, чтобы заметить очевидное: после Slack → документация → Telegram → lab → почта я каждый раз заново собираю контекст в голове.
Pomodoro
Использую, когда не хочется начинать.
25/5 — отличный starter motor.
Но если я вошёл в сложную лабораторию и на 25-й минуте наконец понял, где ошибка в policy, таймер не имеет права командовать мной только потому, что он помидор.
11. Прокрастинация часто исчезает, когда следующий шаг становится смешно маленьким
«Выучить Kubernetes» — прекрасная задача, если хочется ничего не делать. Она огромная, бесформенная и без точки входа.
А вот:
«Запустить cluster и создать namespace»
— уже почти не страшно.
Мне хорошо работает связка из двух вещей.
1. Уменьшить первый шаг
Не «сегодня два часа английского», а «записать 90 секунд self-introduction». Не «готовиться к OSCP целиком», а «поднять одну penetration-testing машину и сделать initial enumeration». Не «разобраться с Terraform», а «создать один resource и уничтожить его».
2. Заранее решить, когда это произойдёт
Implementation intentions — обычная конструкция если → то.
Если я закончил утренний кофе и открыл ноутбук,
то первые 25 минут работаю над lab до Slack и почты.
Это намного полезнее, чем ежедневное внутреннее собрание совета директоров на тему «есть ли у меня сегодня мотивация?».
12. Сомнение и страх я тоже считаю частью learning loop
Есть забавный момент: чем дольше мы готовимся, тем легче назвать подготовку «обучением» и не проверять себя в реальности. Особенно это видно в двух областях.
Иностранный язык
«Сначала я подтяну grammar, потом начну говорить». Через год grammar стала лучше. Говорить всё ещё страшно.
Security
«Сначала дочитаю весь курс, потом пойду в lab». Курс закончен. Перед пустым terminal всё равно тишина. Для себя я ввёл неофициальное правило minimum viable embarrassment.
Нужно достаточно рано попасть в ситуацию, где немного неловко:
- записать себя на английском и услышать собственные ошибки;
- ответить на interview question без конспекта;
- попробовать exploit и увидеть, что гипотеза была неверной;
- показать threat model человеку, который найдёт в нём дыру;
- написать первый плохой скрипт вместо чтения пятой книги про Python.
Это не самоистязание. Это быстрая обратная связь. Ошибку, которую ты увидел сегодня, не придётся торжественно обнаруживать через шесть месяцев.
13. «Крепкая четвёрка» — мой любимый антидот от перфекционизма
Эту идею из своей старой брошюры я оставляю почти без изменений.
Есть работа «на тройку» — лишь бы отстали.
Есть отличная работа «на пятёрку».
А есть пятёрка-перевёртыш: перфекционизм, который мешает результату вообще появиться.
Человек две недели проектирует идеальный learning plan. Полирует CV вместо отправки applications. Учится писать идеально правильный English sentence и поэтому молчит на встрече. Читает про программирование вместо первого кривого скрипта.
Я предпочитаю крепкую четвёрку:
Сделать достаточно хорошо, получить реальную обратную связь и улучшить следующую итерацию.
В обучении версия 0.1, которую можно проверить, почти всегда полезнее версии 1.0, которая существует только в голове.
14. Не мотивация, а короткий цикл и scoreboard
Мотивация хороша. Просто она не подписывала SLA. Сегодня есть, завтра нет. Поэтому большие цели я режу на циклы примерно по 6–12 недель и заранее решаю, какой observable result должен появиться.
Не:
«улучшить английский».
А:
«через восемь недель пройти 30-минутное mock interview без русского и без заранее написанного текста».
Не:
«изучить AWS Security».
А:
«собрать lab с несколькими attack paths, настроить detection и объяснить архитектуру без слайдов».
Каждую неделю я смотрю не на часы, а на output. Что появилось?
Lab? Threat model? Write-up? Recorded answer? Working pipeline? Решённая задача? Если я десять часов «учился», но ничего из этого не появилось, я не считаю неделю особенно успешной.
Если мне нужно быстро освоить новый security skill
Вот универсальный двухнедельный шаблон, который я бы использовал сегодня.
| День | Работа | Проверяемый результат |
|---|---|---|
| 0 | Формулирую конечное действие | Знаю, что должен уметь сделать |
| 1 | Строю карту темы | 10–15 core concepts + неизвестные слова |
| 2 | Разбираю 1–2 хороших worked examples | Могу объяснить каждый шаг |
| 3 | Повторяю пример без подсказки | Первый самостоятельный результат |
| 4 | Делаю простую лабораторию | Working scenario |
| 5 | Закрываю источники и восстанавливаю тему | Список реальных пробелов |
| 6 | Исправляю пробелы | Короткая обновлённая карта |
| 7 | Беру другую задачу того же класса | Первый перенос навыка (transfer) |
| 8 | Пауза + recall | Проверка retention |
| 9 | Усложняю условия | Failure / attack scenario |
| 10 | Добавляю mitigation | Fix + retest |
| 11 | Объясняю тему вслух | 5–10 минут без конспекта |
| 12 | Решаю задачу без walkthrough | Blind practice |
| 13 | Сам себе экзамен | Questions + troubleshooting |
| 14 | Делаю итоговый артефакт | Lab / write-up / demo / checklist |
Смысл не в том, что любую профессию можно выучить за 14 дней. Смысл в том, что через две недели у тебя должен быть работающий первый слой навыка, а не только история браузера.
Если мне нужно быстрее подтянуть Technical English
Здесь цикл немного другой. Я бы выбрал одну рабочую ситуацию на неделю.
Например: security interview.
День 1 — собрать 10–15 ключевых phrases/chunks
День 2 — recall + 5 коротких ответов вслух
День 3 — 15 минут mock interview
День 4 — разобрать ошибки и переформулировать ответы
День 5 — новый mock без старого текста
День 6 — listening: интервью/митинг кусками + пересказ
День 7 — 20–30 минут разговора без конспекта
Следующая неделя — meetings.
Потом explaining findings.
Потом disagreement / risk discussion.
Так язык постепенно собирается вокруг реальных задач, а не вокруг ощущения «я когда-нибудь закончу учебник».
Что я бы сегодня выкинул из типичного learning advice
За годы вокруг обучения накопилось слишком много красивых правил. Часть из них полезна как метафора, но плохо выдерживает слово «доказано».
Вот что я больше не использую как жёсткую истину:
«Пирамида обучения» с точными процентами
Знаменитые 10% читаем / 20% слышим / 90% делаем часто приписывают Edgar Dale. У этих цифр нет той научной основы, которую им обычно приписывают. Практика действительно важна. Но проценты лучше оставить мотивационным плакатам.
«20 часов — и навык освоен»
20 часов хорошей практики могут дать очень заметный старт. Но сложность навыков различается на порядки. 20 hours — полезный антидот от страха перед стартом, а не гарантия компетентности. Но тоже база. Хотя бы с нее стартануть.
«10 000 часов — и ты эксперт»
Тоже не закон природы. Важны качество практики, feedback, стартовый уровень, область и куча других факторов. Но в целом общйи каркас 10к часов верен.
«Концентрация всегда заканчивается ровно через 25 минут»
Нет. Pomodoro — инструмент организации работы, а не таймер человеческой биологии.
«Есть идеальные интервалы повторения для всех»
Spacing полезен. Конкретная сетка зависит от задачи, человека и требуемого retention interval.
«Скорочтение позволит читать в 3–5 раз быстрее без потери понимания»
Для поиска и triage — можно читать очень быстро.
Для глубокого понимания сложного материала скорость и comprehension приходится балансировать. И это нормально, мен.
Быстрая диагностика: что сломалось в обучении?
| Симптом | Что проверить первым |
|---|---|
| Через неделю ничего не помню | Retrieval + spacing |
| Всё понимаю только пока открыт конспект | Recall без подсказки |
| Посмотрел пять курсов, навык не появился | Практика без walkthrough |
| Не знаю, с чего начать новую тему | Performance goal + карта предмета |
| Lab кажется слишком сложным | Один worked example → self-explanation → повтор |
| Тону в источниках | Один canonical note + 2–5 основных sources |
| Постоянно отвлекаюсь | Single-task block + notifications off |
| Не могу начать | Первый шаг на 5–25 минут + если → то
|
| Боюсь говорить по-английски | Короткий output + correction + повтор |
| Боюсь technical interview | Ответ вслух без конспекта + запись |
| Хочу знать всё до практики | Minimum viable embarrassment |
| Всё полирую и не выпускаю | «Крепкая четвёрка» |
И ещё одна вещь, которую преподавание научило меня ценить
Когда человек может объяснить сложную вещь другому человеку, очень быстро становится видно, где у него понимание, а где набор знакомых слов. Поэтому финальным тестом я часто делаю не quiz, а объяснение.
Попробуй без конспекта рассказать:
- почему эта vulnerability возникает;
- какой trust boundary нарушен;
- почему mitigation реально работает;
- чем severity отличается от business priority;
- почему именно эта фраза на английском звучит естественнее;
- что было главным в прочитанной главе.
Если в объяснении приходится прыгать через логические дыры — отлично. Ты только что бесплатно нашёл следующую тему для обучения.
Итог
После многих лет преподавания и собственного самообучения я всё меньше верю в «секретные техники сверхобучения» и всё больше — в хорошо собранный процесс.
Мне не нужно поглотить максимум информации.
Мне нужно:
понять, что я должен уметь → быстро построить карту → увидеть хороший пример → попробовать вспомнить → сделать самому → получить feedback → вернуться позже → применить в другом контексте.
И повторить цикл.
Самая опасная иллюзия — принять знакомство с материалом за владение им.
Поэтому моя главная метрика сегодня очень простая:
Не сколько я посмотрел и прочитал, а что я теперь могу воспроизвести, сделать и объяснить без подсказки.
Если эта цифра растёт — обучение работает.
Всё остальное вторично.
Источники и что я перепроверил для этой версии (статьи)
Основа статьи — моя self-published брошюра «(Само)обучение: исследования, факты и лучшие практики» (2023) и собственный опыт преподавания, профессионального обучения и самообучения. Для этой версии я отдельно перепроверил ключевые тезисы по исследованиям и профильным материалам. И дабы все могли проверить материалы на которые я опирался при написании материала, ниже вот основная исследовательская база:
- Carpenter S. K., Pan S. C., Butler A. C. The science of effective learning with spacing and retrieval practice. Nature Reviews Psychology, 2022. https://doi.org/10.1038/s44159-022-00089-1
- Agarwal P. K., Nunes L. D., Blunt J. R. Retrieval Practice Consistently Benefits Student Learning: a Systematic Review of Applied Research in Schools and Classrooms. Educational Psychology Review, 2021. https://doi.org/10.1007/s10648-021-09595-9
- Kim S. K., Webb S. The Effects of Spaced Practice on Second Language Learning: A Meta-Analysis. Language Learning, 2022. https://doi.org/10.1111/lang.12479
- Barcroft J. et al. A Review of Laboratory Studies of Adult Second Language Vocabulary Training. Studies in Second Language Acquisition, 2020. https://doi.org/10.1017/S0272263119000500
- Li S. The Effectiveness of Corrective Feedback in SLA: A Meta-Analysis. Language Learning, 2010. https://doi.org/10.1111/j.1467-9922.2010.00561.x
- Chi M. T. H. et al. Self-explanations: How students study and use examples in learning to solve problems. Cognitive Science, 1989. https://doi.org/10.1016/0364-0213(89)90002-5
- Mayer R. E. Using multimedia for e-learning. Journal of Computer Assisted Learning, 2017. https://doi.org/10.1111/jcal.12197
- Zhang Y. et al. Active learning strategies in video learning: A meta-analysis. Educational Research Review, 2025. https://doi.org/10.1016/j.edurev.2025.100708
- How universities teach cybersecurity courses online: a systematic literature review. Frontiers in Computer Science, 2024. https://doi.org/10.3389/fcomp.2024.1499490
- Tang C. et al. Introducing Penetration Test with Case Study and Course Project in Cybersecurity Education. Journal of The Colloquium for Information Systems Security Education. https://journal.cisse.info/index.php/jcisse/article/view/148
- NIST. NICE Framework Resource Center — Education and Training Provider Resources. https://www.nist.gov/itl/applied-cybersecurity/nice/nice-framework-resource-center/resources/education-and-training
- Rayner K. et al. So Much to Read, So Little Time: How Do We Read, and Can Speed Reading Help? Psychological Science in the Public Interest, 2016. https://doi.org/10.1177/1529100615623267
- Gollwitzer P. M., Sheeran P. Implementation Intentions and Goal Achievement: A Meta-analysis of Effects and Processes. Advances in Experimental Social Psychology, 2006. https://doi.org/10.1016/S0065-2601(06)38002-1
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.