Zwykle piszę o IT – na różne, bardziej lub mniej wyspecjalizowane tematy, takie jak SAN/SAN lub FreeBSD, ale teraz spróbuję wystąpić na obcym polu, dlatego dla wielu czytelników moje dalsze rozważania mogą wydawać się dość kontrowersyjne lub wręcz naiwne. Tak czy inaczej, tak właśnie jest, więc nie zamierzam się obrażać. Jednak jako bezpośredni konsument wiedzy i usług edukacyjnych, przepraszam za ten straszny biurokratyzm, a także jako entuzjastyczny amator pragnący podzielić się urbi et orbi swoimi wątpliwymi „znalezieniami i odkryciami”, prawdopodobnie nie będę mógł milczeć.
Dlatego wierzcie mi, przeskakujcie ten tekst dalej, póki nie jest za późno, albo pogódźcie się i przetrwajcie, bo, dowolnie cytując znaną piosenkę, wszystko, co chcę, to jechać na moim rowerze.
Aby wszystko sobie poukładać, zaczniemy od początku – od szkoły, która powinna uczyć podstawowych rzeczy o naukach i otaczającym świecie. W zasadzie bagaż ten jest przekazywany za pomocą tradycyjnych metod scholastycznych, takich jak wkuwanie starannie wydobytej szkolnej programu, zawierającego ograniczony zestaw przetwarzanych przez nauczycieli wniosków i wzorów, a także wielokrotne powtarzanie tych samych zadań i ćwiczeń. Z powodu tego podejścia klarowność fizycznych lub praktycznych znaczeń w tych tematach często zanika, co, moim zdaniem, powoduje krytyczne uszczerbki w systematyzacji wiedzy.
Ogólnie rzecz biorąc, z jednej strony metody szkolne są dobre do masowego wbijania minimalnie obowiązkowego zestawu informacji do głów ludzi, którzy nie bardzo chcą się uczyć. Z drugiej strony mogą hamować rozwój tych, którzy są w stanie osiągnąć więcej niż zwykłe wytrenowanie odruchu.
Przyznaję, że przez te 30 lat, odkąd opuściłem szkołę, sytuacja mogła się poprawić, ale podejrzewam, że i tak nie oddaliła się zbytnio od średniowiecza, tym bardziej, że religia znów powróciła do szkoły i czuje się w niej całkiem dobrze.
Nigdy nie uczęszczałem do college'u ani do innej instytucji zawodowej, więc nie mogę się na ten temat wypowiadać, ale istnieje duże ryzyko, że nauka zawodu tam może ograniczyć się jedynie do treningu konkretnych umiejętności praktycznych, zaniedbując przy tym podstawę teoretyczną.
Idziemy dalej. Na tle szkolnym instytucja edukacyjna, czy to uczelnia, z perspektywy zdobywania wiedzy, wydaje się prawdziwą oazą. Możliwość, a w niektórych przypadkach wręcz obowiązek samodzielnego nauki, większa swoboda wyboru metod poznawania i źródeł informacji otwiera szerokie możliwości dla tych, którzy mogą i chcą się uczyć. Wszystko zależy od dojrzałości studenta oraz jego aspiracji i celów. Dlatego, mimo że wyższe wykształcenie w pewnym sensie zyskało reputację sztywnego i odstającego od rozwoju nowoczesnych IT, wielu studentów zdąża wypracować metody poznania oraz zdobyć szansę na nadrobienie niedostatków szkolnego wykształcenia i na nowo opanować sztukę uczenia się autonomicznie oraz samodzielnego zdobywania wiedzy.
Jeśli chodzi o różnorodne kursy organizowane przez dostawców sprzętu IT i oprogramowania, należy zrozumieć, że ich głównym celem jest nauczenie użytkowników korzystania z ich programów i sprzętu, dlatego często algorytmy i teoretyczne podstawy, a także najważniejsze szczegóły tego, co kryje się 'pod maską', omawiane są na zajęciach tylko w takim zakresie, w jakim producent jest zmuszony to zrobić, aby zapewnić ogólne informacje o technologii, nie ujawniając jednocześnie tajemnic handlowych i nie zapominając podkreślić swoich przewag w porównaniu do konkurencji.
Z tych samych powodów procedura certyfikacji pracowników IT, szczególnie na poziomach podstawowych, często grzeszy ocenianiem mało istotnych informacji, a testy zadają oczywiste pytania, lub co gorsza: sprawdzają u kandydatów refleksyjne opanowanie materiału. Na przykład, dlaczego nie zapytać na egzaminie certyfikacyjnym inżyniera 'z jakimi argumentami: -ef, czy -ax należy uruchomić polecenie ps', mając na myśli ten konkretny wariant UNIX lub dystrybucję Linux? Tego rodzaju podejście wymagałoby od testowanego wcześniejszego wyuczenia się na pamięć tego oraz wielu innych poleceń, nawet mimo iż te parametry zawsze można wyjaśnić w man, jeśli w pewnym momencie administrator je zapomni.
Na szczęście postęp nie stoi w miejscu, a za kilka lat jedne argumenty się zmienią, inne staną się przestarzałe, a nowe pojawią się i zajmą miejsce poprzednich. Tak stało się w niektórych systemach operacyjnych, w których z biegiem czasu zaczęto używać wersji narzędzia ps, preferującej składnię bez „minusów”: ps ax.
A co wtedy? Oczywiście, należy przeprowadzić ponowną certyfikację specjalistów, a lepiej wprowadzić jako zasadę co N lat, lub przy wydaniu nowych wersji oprogramowania i sprzętu, odbieranie „przestarzałych dyplomów”, tym samym zmuszając inżynierów do przystąpienia do certyfikacji według zaktualizowanej wersji. Oczywiście, certyfikacja powinna być płatna. A to dlatego, że certyfikat jednego dostawcy utraci znaczącą wartość lokalną, jeśli pracodawca specjalisty zmieni dostawcę — zacznie kupować podobny sprzęt u innego dostawcy. I dobrze, gdyby dotyczyło to tylko „zamkniętych” produktów komercyjnych, do których dostęp jest ograniczony, a więc certyfikacja w ich przypadku ma pewną wartość z powodu swojej względnej rzadkości. Niemniej jednak, część firm z powodzeniem narzuca certyfikację także na „otwartych” produktach, na przykład, jak to ma miejsce w niektórych dystrybucjach Linuxa. Co więcej, inżynierowie sami starają się również „podpiąć” do certyfikacji Linuxa, wydając na nią czas i pieniądze, mając nadzieję, że to osiągnięcie zwiększy ich wartość na rynku pracy.
Certyfikacja pozwala standaryzować wiedzę specjalistów, dając im jednolity, pewien średni poziom wiedzy i doskonali umiejętności do automatyzmu, co, rzecz jasna, jest bardzo wygodne dla takiego stylu zarządzania, który operuje pojęciami takimi jak: roboczo-godziny, zasoby ludzkie i normy wydajności. Korzenie takiego formalnego podejścia sięgają złotego wieku epoki przemysłowej, do dużych fabryk i przedsiębiorstw przemysłowych, zbudowanych wokół linii produkcyjnej, gdzie wymagane jest, aby każdy pracownik wykonywał określone czynności dokładnie i w bardzo krótkim czasie, a na myślenie po prostu nie ma czasu. Zresztą, aby myśleć i podejmować decyzje, w fabryce zawsze są inni ludzie. Oczywiste jest, że w takiej schemacie człowiek staje się „zębatką systemu” – łatwo wymienialnym elementem o znanych charakterystykach wydajności.
Jednak nawet w firmie, która nie jest przemysłowa, a w IT, takie niezwykłe zjawisko jak lenistwo, skłania ludzi do dążenia do uproszczenia. W systemie Skills, Rules, Knowledge (SRK) wielu z nas dobrowolnie woli korzystać z umiejętności, które zostały wypracowane do automatyzmu i przestrzegać zasad, które stworzyli mądrzy ludzie, zamiast podejmować wysiłki, by dogłębnie zgłębiać problemy i zdobywać samodzielnie wiedzę, ponieważ to przypomina wynajdywanie kolejnego bezsensownego roweru. I głównie cały system edukacji, zaczynając od szkoły, a kończąc na kursach/certyfikacji specjalistów IT, sprzyja temu, przyzwyczajając ludzi do wkuwania, zamiast badań; treningowi umiejętności przydatnych do konkretnych aplikacji lub sprzętu, zamiast zrozumienia przyczyn źródłowych, wiedzy o algorytmach i technologii.
Innymi słowy, podczas nauki lwia część sił i czasu poświęcana jest na opanowanie podejścia „Jak wykorzystać dany instrument”, a nie na szukanie odpowiedzi na pytanie „Dlaczego to działa tak, a nie inaczej?” Z tych samych powodów w dziedzinie IT często stosuje się metodę „best practices”, opisującą zalecenia dotyczące „najlepszego” skonfigurowania i używania różnych komponentów lub systemów. Nie, nie odrzucam idei najlepszych praktyk, są one bardzo dobre jako ściąga lub lista kontrolna, ale często takie zalecenia stosuje się jak „złoty młotek”, stają się one niezmiennymi aksjomatami, których inżynierowie i menedżerowie przestrzegają bezwiednie, nie zadając sobie pytania „dlaczego” dana rekomendacja została podana. I to jest dziwne, bo jeśli inżynier przestudiował i wie materiał, nie musi bezmyślnie polegać na autorytecie, które pasuje w większości sytuacji, ale jest całkiem możliwe, że nie ma zastosowania w konkretnej sytuacji.
Czasami, w związku z najlepszymi praktykami, sytuacja osiąga absurd: nawet w mojej praktyce zdarzył się przypadek, kiedy dostawcy, oferujący ten sam produkt pod różnymi markami, mieli nieco różniące się poglądy na temat danej kwestii, więc kiedy na prośbę klienta przeprowadzali coroczną ocenę, jeden z raportów zawsze zawierał ostrzeżenie o naruszeniu najlepszych praktyk, podczas gdy drugi, przeciwnie, chwalił za pełne dostosowanie.
I niech to brzmi zbyt akademicko i na pierwszy rzut oka nieprzydatnie w takich dziedzinach jak wsparcie systemy IT, gdzie wymagane jest stosowanie umiejętności, a nie nauka przedmiotu, ale jeśli jest chęć wydostania się z zaklętego kręgu, mimo braku naprawdę cennych informacji i wiedzy, zawsze znajdą się sposoby i metody, aby wszystko zrozumieć. Mi przynajmniej wydaje się, że pomagają:
- Krytyczne myślenie, podejście naukowe i zdrowy rozsądek;
- Poszukiwanie przyczyn i badanie pierwotnych źródeł informacji, tekstów źródłowych, standardów i formalnych opisów technologii;
- Badanie w przeciwieństwie do wkuwania. Brak strachu przed "rowerami", których budowa umożliwia przynajmniej zrozumienie, dlaczego inni programiści, inżynierowie i architekci wybrali konkretną drogę rozwiązania podobnych problemów, a w najlepszym wypadku, stworzenie lepszego roweru niż wcześniej.
Źródło: habr.com
