Зазвичай я пишу про ІТ – на різні, більш-менш вузькоспеціалізовані теми на кшталт 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