Зазвичай я пишу про ІТ – на різні, більш-менш вузькоспеціалізовані теми на кшталт SAN/СХД чи FreeBSD, але зараз я спробую виступити на чужому полі, тому багатьом читачам мої подальші міркування здадуться достатньо спірними або навіть наївними. Втім, так воно і є, і тому я не в образі. Однак, як безпосередній споживач знань та освітніх послуг, пардон за цей страшний канцеляризм, а також як захоплений дилетант, який прагне поділитися urbi et orbi своїми сумнівними «знахідками та відкриттями», промовчати я навряд чи теж зможу.
Тому ви або проскакуйте цей текст далі поки не пізно, або змиріться і терпіть, тому що, вільно цитуючи відому пісню, все, що я хочу, це гнати свій велосипед.
Отже, щоб розкласти все по поличках, почнемо здалеку – зі школи, яка, за ідеєю, повинна вчити базовим речам про науки та навколишній світ. В основі своєї цей багаж подається за допомогою традиційних прийомів схоластики, на кшталт зубріння ретельно вихолощеної шкільної програми, що містить обмежений набір висновків і формул, що препаруються вчителями, а також багаторазових повторень одних і тих же завдань і вправ. Через цей підхід у темах, що вивчаються, часто втрачається ясність фізичного чи практичного смислів, що, на мій погляд, завдає критичної шкоди систематизації знань.
Загалом, з одного боку, шкільні методи хороші для масового втовкмачення мінімально-обов'язкового набору інформації в голови тих, хто не дуже хоче вчитися. З іншого, вони можуть гальмувати розвиток тих, хто здатний досягти більшого, ніж просто натренувати рефлекс.
Припускаю, що за ті 30 років, як я покинув школу, становище змінилося на краще, але підозрюю, що це все одно не надто далеко пішло від середньовіччя, тим більше, що релігія знову повернулася до школи і там цілком добре почувається.
Я ніколи не відвідував коледж, або інший професійний навчальний заклад, тому нічого не можу сказати про них по суті, проте великий ризик, що вивчення професії там може звестися виключно до тренінгу конкретних прикладних навичок, упускаючи при цьому теоретичну базу.
Йдемо далі. На шкільному тлі освітній інститут, або університет, з погляду набуття знань виглядає справжньою віддушиною. Можливість, і навіть у деяких випадках обов'язок вивчення матеріалу самостійно, велика свобода вибору способів пізнання та джерел інформації відкриває широкі можливості для тих, хто може і хоче навчатися. Тут все залежить від зрілості студента та його прагнень та цілей. Тому, незважаючи на те, що вища освіта якоюсь мірою заслужила репутацію відсталого, що відстає від розвитку сучасних ІТ, все-таки багато студентів встигають відпрацювати методи пізнання, а також набути шансу відшкодувати неповноцінність шкільної освіти і заново опанувати науку вчитися автономно та самостійно. набувати знання.
Що стосується різноманітних курсів, які організовують постачальники ІТ обладнання та програмного забезпечення, то треба розуміти, що їхня основна мета – навчити споживачів користуватися їхніми програмами та обладнанням, тому часто алгоритми та теоретичні основи, а також найважливіші деталі того, що приховано «під капотом» , розглядаються на заняттях лише тією мірою, як і виробник змушений це зробити, щоб дати загальні інформацію про технології, не розкривши у своїй комерційної таємниці і забувши підкреслити свої переваги проти конкурентами.
По тем же причинам, процедура сертификации ИТ специалистов, особенно на начальных уровнях, часто грешит проверками малосущественных знаний, а тесты задают очевидные вопросы, или хуже того: проверяет у соискателей рефлекторное владение материалом. Как, например, почему бы на сертификационном экзамене не спросить у инженера «с какими аргументами: -ef, или -ax следует запускать команду ps», имея в виду данный конкретный вариант UNIX или дистрибутив Linux. Подобный подход потребует от тестируемого заранее вызубрить наизусть эту, а также многие другие команды, даже несмотря на то, что эти параметры всегда можно уточнить в man, если в какой-то момент администратор их забудет.
На щастя, прогрес не стоїть на місці, і за кілька років одні аргументи зміняться, інші застаріють, а нові з'являться і займуть колишні місця. Як це сталося в деяких операційних системах, де з часом почали використовувати версію утиліти ps, яка віддає перевагу синтаксису без «мінусів»: ps ax.
И что же тогда? Правильно, необходимо пересертифицировать специалистов, а лучше взять за правило, раз в N-лет, или с выходом новых версий ПО и оборудования, отзывать «устаревшие дипломы», тем самым, побуждая инженеров проходить сертификацию по обновленной версии. И, разумеется, необходимо сделать сертификацию платной. И это при том, что сертификат одного вендора ощутимо потеряет локальную ценность в том случае, если наниматель специалиста поменяет вендора – начнет закупать аналогичное оборудование у другого поставщика. И ладно, если бы это происходило только с «закрытыми» коммерческими продуктами, доступ к которым ограничен, и потому, сертификация по ним имеет некоторую ценность из-за своей относительной редкости, однако часть компаний вполне успешно навязывает сертификацию и по «открытым» продуктам, например, как это случается с некоторыми дистрибутивами Linux. Более того, инженеры сами стараются «подсесть» и на сертификацию по Linux тоже, тратят на нее время и деньги, в надежде, что это достижение прибавит им вес на рынке труда.
Сертифікація дозволяє стандартизувати знання фахівців, даючи їм єдиний середній рівень знань і відточує до автоматизму навички, що, звичайно, дуже зручно для такого стилю менеджменту, який оперує поняттями на кшталт: людино-годинник, людські ресурси та норми виробітку. Коріння такого формального підходу веде в золоте століття індустріальної епохи, на великі фабрики та промислові підприємства, побудовані навколо конвеєра, де потрібно, щоб кожен працівник виконував конкретні дії точно і в дуже обмежений термін, а на те, щоб думати, у нього просто немає часу. Втім, щоб думати та приймати рішення, на заводі завжди є інші люди. Очевидно, що людина в такій схемі перетворюється на «гвинтик системи» – елемент, що легко замінюється, з відомими характеристиками продуктивності.
Але й на не промисловому підприємстві, а в ІТ, така дивовижна якість як лінощі, змушує людей прагнути спрощення. У системі Skills, Rules, Knowledge (SRK) багато хто з нас добровільно воліє користуватися відпрацьованими до автоматизму навичками та дотримуватися правил, які розробили розумні люди, а не докладати зусиль, досліджувати проблеми вглиб та набувати знань самостійно, адже це так схоже на винахід чергового безглуздого. велосипед. І, в основному, вся система освіти починаючи зі школи і закінчуючи курсами/сертифікацією ІТ-фахівців потурає цьому, привчаючи людей до зубріння, замість досліджень; тренуванні навичок придатних для конкретних екземплярів додатків чи обладнання, замість розуміння кореневих причин, знання алгоритмів та технологій.
Іншими словами, під час навчання левова частка сил і часу приділяється тому, щоб відпрацьовувати підхід.Як використовувати той чи інший інструмент», а не на пошук відповіді на запитання «Чому це працює так, а не інакше? З цих же причин, у сфері ІТ найчастіше застосовується метод «best practices», що описує рекомендації щодо «найкращого» настроювання та використання тих чи інших компонентів чи систем. Ні, я не відкидаю ідею best-practices, вона дуже хороша як cheat sheet або check list, але часто подібні рекомендації використовуються як «золотий молоток», вони стають непорушними аксіомами, яким інженери і менеджмент слід неухильно і бездумно, не знаючи часу. питанням «чому» дана та чи інша рекомендація. І це дивно, адже якщо інженер вивчив и знає матеріал, йому не потрібно сліпо покладатися на авторитетну думку, яка придатна в більшості ситуацій, але цілком імовірно, не застосовується до конкретного випадку.
Іноді у зв'язку з best-practices доходить до абсурду: навіть у моїй практиці був випадок, коли вендори, що поставляють один і той же продукт під різними торговими марками, мали погляди на предмет, що трохи різнилися, тому коли вони на прохання замовника проводили щорічний assessment, один зі звітів завжди містив попередження про порушення best-practices, тоді як інший навпаки хвалив за повну відповідність.
І нехай це звучить надто академічно і на перший погляд не застосовується у таких сферах як підтримка ІТ-систем, де потрібне застосування навичок, а не вивчення предмета, але якщо є бажання вирватися із зачарованого кола, незважаючи на мізерність по-справжньому важливої інформації та знань, завжди знайдуться способи та методи у всьому розібратися. Мені принаймні здається, що допомагають:
- Критичне мислення, науковий підхід та здоровий глузд;
- Пошук причин та вивчення первинних джерел інформації, вихідних текстів, стандартів та формальних описів технологій;
- Дослідження на противагу зубріжці. Відсутність страху перед «велосипедами», будівництво яких дає можливість, як мінімум, розібратися, чому інші розробники, інженери та архітектори обрали той чи інший шлях вирішення подібних проблем, а як максимум зробити велосипед ще краще, ніж раніше.
Джерело: habr.com
