Di solito scrivo di IT – su argomenti più o meno specializzati come SAN/Storage o FreeBSD, ma ora cercherò di cimentarmi in un campo che non è il mio, quindi le mie future considerazioni potrebbero sembrare abbastanza controverse o addirittura ingenue a molti lettori. Tuttavia, è proprio così, e non ne sono offeso. Tuttavia, come consumatore diretto di conoscenze e servizi educativi, pardon per questo orrendo linguaggio burocratico, e come entusiasta dilettante desideroso di condividere urbi et orbi le mie discutibili "scoperte e intuizioni", dubito di poter restare in silenzio.
Quindi, o saltate oltre questo testo finché è tempo, oppure rassegnatevi e sopportate, perché, citando liberamente una celebre canzone, tutto ciò che voglio è andare in bicicletta.
Per chiarire le idee, cominciamo dal principio: dalla scuola, che dovrebbe insegnare le basi delle scienze e del mondo che ci circonda. Questo bagaglio viene presentato principalmente attraverso metodi tradizionali di insegnamento, come la memorizzazione di un programma scolastico accuratamente diluito, che contiene un insieme limitato di conclusioni e formule semplificate fornite dagli insegnanti, oltre a ripetizioni frequenti degli stessi compiti ed esercizi. A causa di questo approccio, spesso si perde la chiarezza dei significati fisici o pratici nei temi studiati, il che, a mio avviso, causa un danno critico alla sistematizzazione delle conoscenze.
In generale, da un lato, i metodi scolastici sono buoni per inculcare in modo massiccio un insieme minimamente obbligatorio di informazioni nella testa di chi non ha molta voglia di studiare. Dall'altro, possono ostacolare lo sviluppo di chi è capace di raggiungere di più, oltre a semplicemente allenare un riflesso.
Posso immaginare che in questi 30 anni da quando ho lasciato la scuola, la situazione sia migliorata, ma sospetto che non ci si sia allontanati troppo dal medioevo, soprattutto considerando che la religione è tornata a far parte della scuola e si sente piuttosto a suo agio lì.
Non ho mai frequentato un college o un'altra istituzione educativa professionale, quindi non posso dire nulla a riguardo, ma c'è un forte rischio che lo studio di una professione lì si riduca esclusivamente alla formazione di abilità pratiche specifiche, trascurando la base teorica.
Andiamo avanti. In un contesto scolastico, un istituto educativo o un'università rappresenta una vera e propria oasi per l'acquisizione del sapere. La possibilità, e persino in alcuni casi l'obbligo, di studiare il materiale autonomamente, insieme a una maggiore libertà di scelta dei metodi di apprendimento e delle fonti informative, offre ampie opportunità a chi può e vuole imparare. Qui tutto dipende dalla maturità dello studente e dalle sue aspirazioni e obiettivi. Pertanto, nonostante l'istruzione superiore abbia in qualche modo guadagnato la reputazione di essere rigida e in ritardo rispetto allo sviluppo delle moderne tecnologie informatiche, molti studenti riescono comunque a sviluppare metodi di apprendimento e ad avere l'opportunità di colmare le lacune dell'istruzione scolastica, riacquisendo la scienza di apprendere in modo autonomo e di acquisire conoscenze.
Per quanto riguarda i vari corsi organizzati dai fornitori di attrezzature e software informatici, è importante comprendere che il loro obiettivo principale è insegnare agli utenti a utilizzare i loro programmi e apparecchiature. Pertanto, gli algoritmi e le basi teoriche, così come i dettagli più significativi di ciò che è nascosto "sotto il cofano", vengono spesso trattati nelle lezioni solo nella misura necessaria affinché il produttore possa fornire informazioni generali sulla tecnologia, senza rivelare segreti commerciali e senza dimenticare di evidenziare i propri vantaggi rispetto ai concorrenti.
Per gli stessi motivi, la procedura di certificazione per i professionisti IT, soprattutto a livelli iniziali, spesso si concentra su verifiche di conoscenze poco significative, mentre i test pongono domande ovvie, o peggio: valutano la padronanza riflessiva del materiale da parte dei candidati. Ad esempio, perché non chiedere a un ingegnere durante l'esame di certificazione «quali argomenti: -ef o -ax dovrebbero essere usati per eseguire il comando ps», facendo riferimento a una particolare versione di UNIX o a una distribuzione di Linux? Questo approccio richiederebbe ai testati di memorizzare a memoria questo e molti altri comandi, nonostante il fatto che tali parametri possano sempre essere chiariti in man, nel caso in cui un amministratore li dimentichi in un certo momento.
Fortunatamente, il progresso non si ferma mai, e tra qualche anno alcuni argomenti cambieranno, altri diventeranno obsoleti e ne appariranno di nuovi che sostituiranno i precedenti. Come è successo in alcuni sistemi operativi, dove nel tempo è stata utilizzata una versione dell'utility ps che preferisce una sintassi senza «tratti»: ps ax.
E quindi? Esatto, è necessario riesaminare i professionisti, meglio sarebbe stabilire come consuetudine una revisione ogni N anni, oppure con l'uscita di nuove versioni di software e hardware, ritirando i "diplomi obsoleti", in questo modo incoraggiando gli ingegneri a ottenere certificazioni sulla versione aggiornata. E, naturalmente, la certificazione deve essere a pagamento. E questo considerando che il certificato di un venditore perderà significativamente valore locale se il datore di lavoro del professionista cambia venditore — inizia ad acquistare attrezzature simili da un altro fornitore. E sarebbe comprensibile se ciò avvenisse solo con prodotti commerciali "chiusi", l'accesso ai quali è limitato, e di conseguenza, la certificazione su di essi ha un certo valore a causa della sua relativa rarità, tuttavia alcune aziende impongono con successo la certificazione anche per i prodotti "aperti", come avviene con alcune distribuzioni di Linux. Inoltre, gli ingegneri stessi cercano di "accapparrarsi" anche la certificazione su Linux, spendendo tempo e denaro, sperando che questo risultato aumenti il loro valore nel mercato del lavoro.
La certificazione consente di standardizzare le conoscenze degli specialisti, fornendo loro un livello medio uniforme di competenze e affinando le abilità fino a renderle automatiche. Questo è particolarmente utile per uno stile di gestione che opera con concetti come: ore lavorative, risorse umane e standard di produzione. Le radici di questo approccio formale risalgono all'epoca d'oro dell'industria, quando grandi fabbriche e impianti industriali erano costruiti attorno alla catena di montaggio, dove ogni lavoratore deve eseguire azioni specifiche con precisione e in tempi molto ristretti, senza il tempo di riflettere. Tuttavia, per pensare e prendere decisioni, ci sono sempre altre persone in fabbrica. È evidente che in questo schema, l'individuo diventa un 'ingranaggio del sistema' – un elemento facilmente sostituibile con caratteristiche di prestazione ben definite.
Ma anche in un'azienda non industriale, nel settore IT, una qualità sorprendente come la pigrizia spinge le persone a cercare semplificazioni. Nel sistema Skills, Rules, Knowledge (SRK), molti di noi preferiscono volontariamente utilizzare competenze automatizzate e seguire le regole stabilite da persone intelligenti, piuttosto che sforzarsi di esplorare i problemi in profondità e acquisire conoscenze in modo autonomo, poiché ciò somiglia all'invenzione di una nuova bicicletta inutile. E, in generale, l'intero sistema educativo, dalla scuola fino ai corsi/qualifiche per specialisti IT, favorisce questo comportamento, abituando le persone a memorizzare piuttosto che a esplorare; a praticare abilità utili a specifiche applicazioni o attrezzature, piuttosto che a comprendere le cause radicate, apprendere algoritmi e tecnologie.
In altre parole, durante la formazione, la maggior parte delle energie e del tempo è dedicata a sviluppare l'approccio «Come utilizzare questo o quel strumento», anziché a cercare una risposta alla domanda «Perché Funziona così e non in altro modo?» Per questi stessi motivi, nel settore IT si usa spesso il metodo delle «best practices», che descrive raccomandazioni per la «migliore» configurazione e utilizzo di determinati componenti o sistemi. No, non rigetto l'idea delle best practices, è davvero utile come cheat sheet o check list, ma spesso tali raccomandazioni vengono utilizzate come un «martello dorato», diventando assiomi incrollabili, cui ingegneri e management si attengono in modo rigoroso e senza riflessione, senza prendersi la briga di chiedersi «perché» si dà tale o tal'altra raccomandazione. E questo è strano, visto che se un ingegnere ha esaminato e sa il materiale, non ha bisogno di affidarsi ciecamente a un'opinione autorevole, che è valida nella maggior parte delle situazioni, ma che è particolarmente inapplicabile al caso specifico.
A volte, a causa delle best practices, si arriva all'assurdo: nella mia esperienza, c'è stato un caso in cui i fornitori dello stesso prodotto con marchi diversi avevano leggermente opinioni diverse sulla questione, quindi quando, su richiesta del cliente, conducevano la valutazione annuale, uno dei rapporti conteneva sempre un avviso di violazione delle best practices, mentre l'altro, al contrario, elogiava il pieno rispetto.
E anche se ciò può sembrare troppo accademico e, a prima vista, non applicabile in settori come supporto i sistemi IT, dove sono richieste abilità piuttosto che studio, ma se c'è la voglia di uscire dal circolo vizioso, nonostante la scarsezza di informazioni e conoscenze veramente importanti, ci sono sempre modi e metodi per capire tutto. A me sembra, almeno, che aiutino:
- Pensiero critico, approccio scientifico e buon senso;
- Ricerca delle cause e studio delle fonti primarie di informazione, testi di partenza, standard e descrizioni formali delle tecnologie;
- Indagine in contrapposizione alla memorizzazione mnemonica. L'assenza di paura nei confronti dei "ciclomotori" offre l'opportunità, almeno, di comprendere perché altri sviluppatori, ingegneri e architetti abbiano scelto una particolare soluzione a problemi simili e, al massimo, di creare un ciclone ancora migliore di prima.
Fonte: habr.com
