"Громоотводы" как результат обучения
Довольно часто ученики, когда рассказываешь им достаточно глубокие вещи о технологиях, с которыми им предстоит работать (или они уже потихоньку работают, "дозревая на должности"), задают примерно такой вопрос - а какова практическая применимость этих знаний?
За этим стоит, по-видимому, желание, под впечатлением ощущая трудности с усвоением всего им объясняемого, составить картину приоритетов, что бы запоминать в первую очередь самое ценное в условиях, когда целиком всё запомнить трудновато.
Тут сразу три ошибки.
Первая - попытка запоминать материал ТАБЛИЧНО, уподобляя свой мозг и его память реляционной БД, к которой после запоминания можно делать запросы а-ля SQL, что бы мозг чётко выдавал по любым критериям запрошенную информацию. Такая методика употреблялась во многих учебных заведениях, где сначала что-то рассказывалось (как бы загружалось), а потом - проверялось на терминологических диктантах или по билетам с вопросами.
На самом деле мозг запоминает информацию в виде т.н. семантической сети, связями в которой выступают цепочки ассоциаций, так что запоминание информации происходит обычно в привязке к контекстам. Куда лучше использовать для запоминания методики наподобии "Zettelkasten", описанную, в частности, в данном ролике: https://youtu.be/cgaktoUoDVQ
Если запоминать всё правильно, то, поверьте, запомнить можно весьма и весьма большое кол-во информации - вот только адекватная методика проверки так же не должна представлять собой а-ля SQL-запрос. Здесь лучше подходит практическая задача, подобранная специально так, что бы проверяемое знание способно было в разы сократить труд по её решению - и если ученик в такой ситуации переданное ему знание не применил, то что толку, что он его запомнил?..
Вторая ошибка состоит в крене в т.н. АНАЛИТИЧЕСКИЙ подход и забывании о системном. Целое не есть сумма своих составляющих и усвоение части материала зачастую даёт не часть результата, а вообще - ничего не даёт. Разработчик должен не только уметь программировать, но и уметь пользоваться git'ом, build-tool'ом, IDE, да и без умения работать с framework'ами часто тоже работодателю не интересен - так же как не является человеком его тело, лишённое, к примеру, головы, как, впрочем, и отделённая от тела голова проф. Доуэля так же пока интересна лишь Беляеву... Жёлудь не породит дума без света, воздуха, почвы, воды и достаточно низкого уровня радиации.
Как говорится, пропасть не перепрыгнуть в 2 прыжка и немножко беременной быть тоже не получится. Мы не всегда, но часто имеем дело с именно системной средой и т.н. "эмерджентные эффекты" (системные) в ней перевешивают. Это происходит от того, что связи между компонентами систем, с которыми мы работаем, зачастую важнее самих этих компонентов, но декомпозируя систему на компоненты, мы оставляем связи "за скобками" - вынося их за рамки рассмотрения.
Третья же ошибка состоит вообще в подходе к обучению как к подготовке к ШТАТНЫМ ситуациям, если не вообще к идеальным и непонимании того, что называется "запасом прочности". Обучаемым зачастую интересно лишь научиться справляться с повседневными ± рутинными задачами на проектах, когда всё ровно и хорошо - Agile-методики работает как надо, сроки не горят, архитектор прекрасно справится с дизайном системы, тимлид всегда выслушает и убедит менеджеров выделить дополнительное время на Вашу задачу в случае, если что-то неприятно-новое-неучтённое в эстимейтах выяснилось в процессе её выполнения, аналитик будет доступен 100% своего рабочего времени и будет рад ответить на любой Ваш вопрос по требованиям к задаче, да и девопс почтёт за честь вечером в пятницу за 15 минут до окончания рабочего дня пролить build с Вашими изменениями на production. Да и "технического долга" на проекте не будет, либо, в случае обнаружения, заказчик одобрит траты часов, дней, а то и недель на его ликвидацию...
Но опыт говорит мне, что конкурентный бизнес (гос.сектор не рассматриваем) - среда довольно турбулентная и непредсказуемая, так что практически на любой работе от сотрудников требуются не только и не столько эффективные действия в обычных обстоятельствах, сколько способность справиться с ситуациями нештатными, аварийными и когда нагрузка на них возрастает в разы. В этих условиях наиболее ценным сотрудником является скорее тот, кто в ситуации, когда "тишь, да гладь", работает в стиле "не бей лежачего" и "спустя рукава", но в случае форс-мажора способен быстро въехать и, "засучив рукава", справиться с проблемами в кратчайшие сроки, спасти при этом начальство от проблем и общее дело - от провала. А те, кто способен справляться с ситуацией лишь в идеальных условиях, обычно создают слишком большую нагрузку на руководство (вынужденное им такие идеальные условия создавать) и по этому малоинтересны - обычно при увольнении таких людей руководитель вздыхает с облегчением, высвобождая массу времени и сил.
При чём, если мы посмотрим на окружающую нас реальность, то начнём видеть это буквально везде. Что бы в дом не ударила молния, у него делают громоотвод. Стул, на котором мы сидим, выдерживает не только наш вес, но и "морально готов" к тому, что мы существенно растолстеем - мы по крайней мере ожидаем, что он не треснет под чуть большим весом - и т.д.
Как в любом работающем техническом решении заложен некоторый "запас прочности", так и любого работодателя интересуют сотрудники, справляющиеся не только с обычными, но и с пиковыми нагрузками - только с такими они чувствуют себя спокойно.
Так что не удивляйтесь, что на собеседованиях вам дают более сложные задачки, чем те, которые перед Вами обычно встают на работе - вас испытывают на прочность, а не проверяют, справитесь ли Вы с повседневной нагрузкой, пусть даже она и будет составлять 98% вашей дальнейшей работы - именно оставшиеся 2% решённых или нерешённых проблем отличают профессионала от простого трудяги.
Как и от хорошего тренера Вы выходите не только с теми знаниями, навыками и пониманием концепций, что Вы будете применять часто, но и с теми, которые помогут Вам редко, но - очень помогут!
Грозы случаются, Вы не властны над ними, но Вы можете позаботиться о том, что бы сделать себе хороший громоотвод.