Minu väga subjektiivne arvamus professionaalsest ja mitte ainult IT-haridusest

Tavaliselt kirjutan IT-st – erinevatest, enam-vähem kitsalt spetsialiseeritud teemadest nagu SAN/SK või FreeBSD, kuid nüüd püüan astuda võõrale alale, nii et paljudele lugejatele võivad minu edasised arutlused tunduda piisavalt vaieldavad või isegi naiivsed. Ometi ongi see nii, ja seetõttu ma ei kannata. Siiski, kui otse õppimise ja haridusteenuste tarbijana, vabandage selle kohutava bürokraatia pärast, ja samuti kui vaimustunud algaja, kes soovib jagada urbi et orbi oma kahtlaste "leidudega ja avastustega", ma tõenäoliselt ei suutnud vait olla.

Seetõttu kas hüpake sellest tekstist edasi, enne kui on hilja, või leppige ja taluge, sest, vabalt tsiteerides tuntud laulu, on kõik, mida ma tahan, see, et sõita oma jalgrattaga.

Nii et, et kõik õigesse paika panna, alustame kaugetest kohtadest – koolist, mis peaks õpetama põhiasju teadustest ja ümbritsevast maailmast. Peamiselt antakse see pagas edasi traditsiooniliste scholastika meetodite kaudu, nagu mehaaniline päheõppimine hoolikalt kooritud kooliprogrammist, mis sisaldab piiratud hulka õpetajate poolt käsitletavaid järeldusi ja valemeid, samuti korduvate sama ülesande ja harjutuse tehtud korduste kaudu. Selle lähenemise tõttu kaotatakse sageli uuritavates teemades füüsiliste või praktiliste tähenduste selgus, mis minu arvates toob kaasa kriitilise kahju teadmiste süsteemimisele.

Kokkuvõttes, ühelt poolt, on koolimeetodid head massiülekande tegemiseks minimaalsete kohustuslike teadmiste peapeale õppele neile, kes ei taha tõeliselt õppida. Teiselt poolt võivad need takistada nende arengut, kes suudavad saavutada rohkem, kui lihtsalt refleksi treenimist.

Ma möönan, et selle 30 aasta jooksul, mil ma koolist lahkusin, võib olukord olla paremaks muutunud, kuid kahtlen, et see on ikkagi liiga kaugele keskaegadest, eriti kuna religioon on taas kooli tagasi jõudnud ja tunneb seal end üsna hästi.

Ma ei ole kunagi ülikooli ega muud kutsekooli käinud, seega ei oska ma nende kohta sisuliselt midagi öelda, kuid on suur risk, et eriala õppimine seal võib piirduda ainult konkreetsete praktiliste oskuste treenimisega, jättes kõrval teoreetilise baasi.

Liigume edasi. Kooliaasta taustal näeb hariduskohustus, nagu ülikool, teadmiste omandamise osas tõeliselt hästi välja. Võimalus, ja mõnel juhul isegi kohustus, õppida materjali iseseisvalt, suurem valik haridusmeetodeid ja infallikaid avavad laiad võimalused neile, kes suudavad ja tahavad õppida. Kõik sõltub tudengi küpsusest ning tema püüdlustest ja eesmärkidest. Seetõttu, kuigi kõrgharidus on mingil moel teeninud maine, et see on aeglane ja jääb tänapäeva IT arengust maha, suudavad ikkagi paljud üliõpilased omandada õppimise meetodeid ning saada võimaluse parandada koolihariduse puudujääke ja uuesti õppida teadma, kuidas iseseisvalt teadmisi omandada.

Mis puutub erinevatesse kursustesse, mida korraldavad IT-seadmete ja tarkvara tootjad, siis tuleb mõista, et nende peamine eesmärk on õpetada tarbijaid kasutama nende programme ja seadmeid, seega käsitletakse sageli algoritme ja teoreetilisi aluseid, samuti olulisi detaile, mis jäävad „kapoti alla“, tunni jooksul ainult niipalju, kui tootja on sunnitud seda tegema, et anda üldine ülevaade tehnoloogiast, paljastamata samas kaubanduslikku saladust ja unustamata rõhutada oma eeliseid võrreldes konkurentidega.

Sama põhjustel on IT-spetsialistide sertifitseerimisprotsess, eriti algtasemel, sageli ebaaus, kuna see hindab ebaolulisi teadmisi ning testid esitatakse ilmselgeid küsimusi või veel hullem: hindavad kandidaatide refleksset teadlikkust materjalist. Näiteks, miks ei võiks sertifitseerimise eksamil küsida insenerilt "milliste argumentidega: -ef või -ax tuleks käivitada käsk ps", silmas pidades konkreetset UNIX-i varianti või Linuxi distributsiooni. Selline lähenemine nõuab, et testitav peaks eelnevalt selgeks õppima need ja paljud teised käsud, hoolimata sellest, et neid parameetreid saab alati täpsustada man-lehel, kui administraator need mingil hetkel unustab.

Õnneks ei seisa progress paigal ja paaril aastal muutuvad mõned argumendid, teised aeguvad ning uued tekivad ja võtavad vanade koha. Nii nagu on juhtunud mitmesugustes operatsioonisüsteemides, kus aja jooksul hakati kasutama ps-utiliidi versiooni, mis eelistab süntaksit ilma "miinuseta": ps ax.

Ja mis siis? Õige, spetsialiste tuleb uuesti sertifitseerida, või veel parem, teha põhimõtteks kord N-aasta jooksul või uute tarkvara ja seadmete versioonide väljatulekul tühistada "aegunud diplomid", seeläbi julgustades insenere läbima sertifitseerimist uuendatud versiooni järgi. Ja loomulikult tuleb sertifitseerimine muuta tasuliseks. Ja see on näiteks juhul, kui ühe pakkuja sertifikaat kaotab kohalikult väärtust, kui spetsialisti tööandja vahetab pakkujat - hakkab ostma sarnast varustust teiselt tarnijalt. Ja oleks hea, kui see juhtuks ainult "suletud" kommertstooted, millele pääs on piiratud, ja seetõttu on sertifitseerimine nende puhul mingisugust väärtust oma suhtelise harulduse tõttu, kuid osa ettevõtteid surub sertifitseerimist edukalt ka "avatud" toodete jaoks, näitena, nagu juhtub mõnede Linuxi distributsioonidega. Veelgi enam, insenerid püüavad ise "haarata" ka Linuxi sertifitseerimist, kulutades sellele aega ja raha, lootuses, et see saavutus suurendab nende kaalu tööjõuturul.

Sertifitseerimine võimaldab spetsialistide teadlikkust standardiseerida, pakkudes neile ühtlast teadmistaset ja lihvides oskusi automaatsete toimimisteni, mis on muidugi äärmiselt mugav juhtimisstiili jaoks, mis opereerib mõistetega nagu: inimtunnid, inimressursid ja tootmisstandardid. Sellise formaalse lähenemise juured ulatuvad tööstusajastu kuldaega, suurtele tehastele ja tööstuslikele ettevõtetele, mis on rajatud konveierite ümber, kus iga töötaja peab täitma konkreetseid toiminguid täpselt ja väga piiratud ajas, samas kui mõtlemiseks ei ole tal lihtsalt aega. Siiski, mõtlemiseks ja otsuste tegemiseks on alati teised inimesed tehases. On ilmne, et inimene sellises skeemis muutub „süsteemi hammasrataks“ – kergesti vahetatav element tuntud jõudluse omadustega.

Kuid ka mitte-tööstuslikes ettevõtetes, sealhulgas IT-s, ajab see hämmastav omadus, nagu laiskus, inimesi püüdlusele lihtsuse poole. Skills, Rules, Knowledge (SRK) süsteemis eelistavad paljud meist vabatahtlikult kasutada automatiseeritud oskusi ja järgida tarkade inimeste välja töötatud reegleid, selle asemel et pingutada, uurida probleeme sügavamalt ja omandada teadmisi iseseisvalt, kuna see sarnaneb jälle mõttetuks ratta leiutamisega. Ja põhimõtteliselt toetab kogu haridussüsteem alates koolist kuni IT-spetsialistide kursuste/sertifitseerimiseni seda, harjutades inimesi meeldejätmise asemel, mitte uurimisele; oskuste treenimisele, mis sobivad konkreetsete rakenduste või seadmete jaoks, mitte juurte põhjuste, algoritmide ja tehnoloogiate mõistmiseks.

Teisisõnu, õppimise ajal kulutatakse suur osa jõududest ja ajast lähenemise lihvimiseks "Kuidas kasutada seda või teist tööriista", mitte küsimusele vastuse leidmiseks "Miks See, it works this way and not otherwise? For these same reasons, the IT field often employs the method of 'best practices', describing recommendations for the 'best' configuration and usage of certain components or systems. No, I do not reject the idea of best practices; it is quite good as a cheat sheet or checklist, but often such recommendations are used as a 'golden hammer', becoming unbreakable axioms that engineers and management follow unwaveringly and mindlessly, not bothering to find out the answer to the question 'why' is a particular recommendation given. And it's strange, because if an engineer uurinud ja kuidas seda teha. Ja seepärast käitub Google ühes suhtes väga targalt: lubab Androidi inimestel teha kõike omamoodi. is competent in the subject matter, they should not blindly rely on authoritative opinions that are suitable in most situations but may not apply to a specific case.

Sometimes it even reaches absurdity with best practices: I once encountered a case where vendors supplying the same product under different brand names had slightly differing views on the matter. Therefore, when they conducted the annual assessment at the request of the client, one of the reports always contained a warning about violating best practices, while the other praised full compliance.

And while this may sound too academic and at first glance inapplicable in areas like toetamine IT systems, where applying skills is required rather than studying the subject, if there is a desire to break out of the vicious circle, despite the lack of truly important information and knowledge, there will always be ways and methods to figure everything out. At least it seems to me that the following help:

• Critical thinking, scientific approach, and common sense;
• Looking for reasons and studying primary sources of information, original texts, standards, and formal descriptions of technologies;
• Researching instead of rote learning. Not fearing 'bicycles', the construction of which allows, at the very least, to understand why other developers, engineers, and architects chose a particular path to solve similar problems, and at most, to make the bicycle even better than before.

Allikas: habr.com