Di solito scrivo di IT – su vari argomenti più o meno specializzati come SAN/SAN o FreeBSD, ma ora cercherò di mettermi in gioco su un terreno estraneo, quindi molte mie riflessioni potrebbero sembrare a molti lettori piuttosto controverse o addirittura naive. D'altronde, è proprio così, e non me ne cruccio. Tuttavia, come consumatore diretto di conoscenze e servizi educativi, pardon per questo terribile gergo burocratico, e anche come dilettante entusiasta desideroso di condividere urbi et orbi le mie discutibili “scoperte e intuizioni”, dubito che riuscirò a tacere.
Quindi, potete o saltare oltre questo testo finché siete in tempo, oppure accettare e sopportare, perché, citando liberamente una famosa canzone, tutto ciò che voglio è pedalare la mia bicicletta.
Perciò, per mettere in ordine le idee, iniziamo da lontano – dalla scuola, che teoricamente dovrebbe insegnare le nozioni di base sulle scienze e il mondo che ci circonda. Fondamentalmente, questo bagaglio viene trasmesso attraverso metodi tradizionali di scolastica, come la memorizzazione di un programma scolastico attentamente svuotato, contenente un insieme limitato di conclusioni e formule analizzabili dagli insegnanti, insieme a ripetizioni ripetitive degli stessi compiti e esercizi. A causa di questo approccio, spesso si perde chiarezza nei significati fisici o pratici degli argomenti studiati, il che, a mio avviso, infligge un danno critico alla sistematizzazione delle conoscenze.
In generale, da una parte, i metodi scolastici sono utili per infondere in massa un minimo indispensabile di informazioni nelle teste di coloro che non hanno molta voglia di studiare. Dall'altra, possono rallentare lo sviluppo di chi è capace di ottenere di più rispetto a un semplice addestramento del riflesso.
Ammetto che dopo i 30 anni trascorsi da quando ho lasciato la scuola, la situazione sia migliorata, ma sospetto che in ogni caso non sia andata molto lontano dal Medioevo, soprattutto perché la religione è tornata a scuola e si sente piuttosto a proprio agio.
Non ho mai frequentato un college o un'altra istituzione educativa professionale, quindi non posso dire nulla a proposito, tuttavia c'è un grande rischio che lo studio della professione lì possa ridursi esclusivamente all'addestramento di competenze pratiche specifiche, trascurando la base teorica.
Andiamo avanti. Sullo sfondo scolastico, un istituto educativo, o un'università, in termini di acquisizione di conoscenze appare come un vero e proprio rifugio. La possibilità, e in alcuni casi l'obbligo, di studiare il materiale in modo autonomo, una maggiore libertà di scelta dei metodi di apprendimento e delle fonti di informazione apre ampie opportunità per coloro che possono e vogliono apprendere. Qui tutto dipende dalla maturità dello studente e dalle sue aspirazioni e obiettivi. Pertanto, nonostante l'istruzione superiore abbia in qualche modo guadagnato una reputazione di staticità, arretrata rispetto allo sviluppo delle moderne IT, molti studenti riescono comunque a elaborare metodi di apprendimento e ad avere l'opportunità di compensare le carenze dell'istruzione scolastica e riappropriarsi della scienza di apprendere in modo autonomo e acquisire conoscenze.
Per quanto riguarda i vari corsi organizzati dai fornitori di attrezzature informatiche e software, è importante capire che il loro obiettivo principale è insegnare ai consumatori a utilizzare i loro programmi e attrezzature, pertanto spesso gli algoritmi e le basi teoriche, così come i dettagli più importanti di ciò che è nascosto "sotto il cofano", vengono trattati nelle lezioni solo nella misura in cui il produttore è costretto a farlo per fornire informazioni generali sulla tecnologia, senza rivelare segreti commerciali e senza dimenticare di sottolineare i propri vantaggi rispetto ai concorrenti.
Per le stesse ragioni, la procedura di certificazione degli specialisti IT, soprattutto a livelli iniziali, spesso presenta verifiche di conoscenze poco significative, e i test pongono domande ovvie, o peggio: testano nei candidati il dominio riflesso del materiale. Come, ad esempio, perché non chiedere a un ingegnere durante l'esame di certificazione "con quali argomenti: -ef o -ax si deve avviare il comando ps", tenendo conto di questo specifico formato di UNIX o distribuzione Linux. Tale approccio richiederà all'esaminato di memorizzare a memoria questo, così come molti altri comandi, anche se questi parametri possono sempre essere chiariti in man, nel caso in cui a un certo punto l'amministratore li dimentichi.
Fortunatamente, il progresso non si ferma, e tra qualche anno alcuni argomenti cambieranno, altri diventeranno obsoleti, mentre ne appariranno di nuovi che prenderanno il posto dei precedenti. Come è successo in alcuni sistemi operativi, dove nel tempo si è iniziato a utilizzare una versione dell'utility ps che preferisce una sintassi senza "meno": ps ax.
E allora? Giusto, è necessario riesaminare la certificazione degli specialisti, o meglio, prendere come regola di richiedere la certificazione ogni N anni, oppure con il rilascio di nuove versioni del software e dell'hardware, revocando i "diplomi obsoleti", spingendo così gli ingegneri a seguire la certificazione della versione aggiornata. E, naturalmente, è necessario rendere la certificazione a pagamento. E questo pur considerando che il certificato di un fornitore perderà significativamente il valore locale nel caso in cui il datore di lavoro dello specialista cambi fornitore - iniziando ad acquistare attrezzature simili da un altro fornitore. E va bene se accade solo con prodotti commerciali "chiusi", l'accesso ai quali è limitato, e perciò la certificazione su di essi ha un certo valore a causa della loro relativa rarità; tuttavia, parte delle aziende impone con successo la certificazione anche su prodotti "aperti", come avviene con alcune distribuzioni Linux. Inoltre, gli ingegneri stessi cercano di "attaccarsi" anche alla certificazione Linux, spendendo tempo e denaro in questa direzione, nella speranza che questo risultato aumenti il loro valore sul mercato del lavoro.
La certificazione permette di standardizzare le conoscenze degli specialisti, fornendo loro un livello medio comune di competenze e affinando fino all'automatismo le abilità, il che è ovviamente molto conveniente per uno stile di gestione che opera con concetti come: ore-uomo, risorse umane e standard di produzione. Le radici di questo approccio formale risalgono all'età d'oro dell'era industriale, nelle grandi fabbriche e nelle aziende industriali costruite attorno al sistema di assemblaggio, dove ogni lavoratore deve eseguire azioni specifiche in modo preciso e in un tempo molto limitato, e per pensare non ha semplicemente il tempo. D'altra parte, per pensare e prendere decisioni, in fabbrica ci sono sempre altre persone. È ovvio che in questo schema una persona si trasforma in un "ingranaggio del sistema" - un elemento facilmente sostituibile con caratteristiche prestazionali ben definite.
Ma anche in un'azienda non industriale, ma nel settore IT, una qualità sorprendente come la pigrizia porta le persone a cercare semplificazioni. Nel sistema Skills, Rules, Knowledge (SRK), molti di noi preferiscono volontariamente utilizzare abilità perfezionate fino all'automatismo e seguire le regole sviluppate da persone intelligenti, piuttosto che fare sforzi, esplorare i problemi in profondità e acquisire conoscenze autonomamente, poiché sembra così simile all'invenzione dell'ennesima bicicletta inutile. E, fondamentalmente, tutto il sistema educativo, dalla scuola fino ai corsi/certificazioni per specialisti IT favorisce questo, abituando le persone alla memorizzazione, invece che alla ricerca; all'addestramento delle abilità utili per specifici esempi di applicazioni o attrezzature, invece che alla comprensione delle cause profonde, alla conoscenza degli algoritmi e delle tecnologie.
In altre parole, durante l'apprendimento, la maggior parte delle forze e del tempo è dedicata a perfezionare l'approccio “Come utilizzare uno strumento piuttosto che cercare una risposta alla domanda “Perché funziona in questo modo e non in un altro?”. Per queste stesse ragioni, nel campo IT si applica spesso il metodo delle “best practices”, che descrive raccomandazioni per la “migliore” configurazione e utilizzo di determinati componenti o sistemi. No, non rifiuto l'idea delle best practices, è molto utile come cheat sheet o check list, ma spesso tali raccomandazioni sono usate come un “martello d'oro”, diventano assiomi ineluttabili, ai quali ingegneri e management si attengono rigorosamente e senza riflessione, senza prendersi la briga di scoprire la risposta alla domanda “perché” è stata fornita tale o tal'altra raccomandazione. Ed è strano, perché se un ingegnere ha studiato e conosce il materiale, non ha bisogno di fidarsi ciecamente di un'opinione autorevole, che è adatta nella maggior parte delle situazioni, ma è molto probabile che non sia applicabile al caso specifico.
A volte, in relazione alle best practices, si arriva all'assurdo: anche nella mia pratica ci sono stati casi in cui i fornitori, che offrono lo stesso prodotto con marchi diversi, avevano opinioni leggermente diverse sul tema. Pertanto, quando conducevano su richiesta del cliente una valutazione annuale, uno dei rapporti conteneva sempre un avviso di violazione delle best practices, mentre l'altro, al contrario, lodava per la completa conformità.
E anche se questo può sembrare troppo accademico e a prima vista inapplicabile in settori come highlightsFromPoint() i sistemi IT, dove è richiesta l'applicazione delle abilità e non lo studio della materia, se c'è la volontà di uscire da un cerchio vizioso, nonostante la scarsità di informazioni e conoscenze veramente importanti, ci saranno sempre modi e metodi per comprendere tutto. Almeno per me, sembra che aiutino:
- Il pensiero critico, l'approccio scientifico e il buon senso;
- La ricerca di cause e lo studio di fonti primarie di informazione, testi di origine, standard e descrizioni formali delle tecnologie;
- La ricerca in contrapposizione alla memorizzazione. L'assenza di paura nei confronti delle "bici" da costruire che permettono, almeno, di capire perché altri sviluppatori, ingegneri e architetti abbiano scelto questo o quel percorso per risolvere problemi simili, e al massimo, di rendere la bici ancora migliore di prima.
Fonte: habr.com
