Formazione programmazione informatica

[giuseppemag]

Allora bello, vediamo di fare chiarezza, io leggo di uno che a 25 anni chiede come fare ad avere una formazione per diventare programmatore, mi dico, bon diamogli due consigli, visto che ho studiato circa 8 anni e ho alle spalle 14 anni di esperienza come programmatore.

...

Dai, va bene che siamo in italia e che e' il paese dei furbi, ma per avere delle basi per una professione ci vogliono anni di studio, eccheccazzo.

...

Che poi guarda caso, chi sa programmare mi da ragione... come mai?

Ok, caro. Il mio consiglio é diverso dal tuo, ma non é che questo mi turbi come sembra stia eccitando te: puoi pensarla in modo differente, ma non capisco perché vorresti (assieme ad altri) dimostrare che il mio suggerimento é sbagliato...

Professionalmente come programmatore/consulente e come percorso di studi posso vantare esperienza di ordine di magnitudine simile alla tua. So programmare. Non ti do ragione. E non consiglio di avvicinarsi all'informatica come tecnici ma come analisti, specie se si ha una formazione umanistica e non tecnica. Si chiama legge di pareto: occuparsi dei dettagli costa molto di piú di occuparsi del "disegno generale".

Peace

[blue_tech]

ma non puoi occuparti del disegno generale se non hai idea di quello che c'è sotto

è questo il punto... come si diceva giustamente nella prima pagina parlando di iniziare da java o da c: quando ti esce NULL POINTER EXCEPTION che fai se non hai la più vaga idea di cosa sia un puntatore? (tanto non serve sapere i dettagli no?)

andiamo siamo seri... uno prima si impara come funziona una cosa poi va ad occuparsi delle cose più in grande...

è come se uno che non ha mai visto come funziona un'azienda, venisse messo subito al posto di dirigente... la manda in cacca dopo 2 giorni

EDIT:

chissà perchè io che studio informatica in uni (e studio informatica da sempre) mi devo sorbire il corso di architetture degli elaboratori dove vedo com'è fatto il processore (tra le altre cose)... stando al tuo ragionamento non mi servirà mai tanto ci sono i linguaggi di alto livello ormai...

[Recidivo Visual]

Ok, caro. Il mio consiglio é diverso dal tuo, ma non é che questo mi turbi come sembra stia eccitando te: puoi pensarla in modo differente, ma non capisco perché vorresti (assieme ad altri) dimostrare che il mio suggerimento é sbagliato...

Professionalmente come programmatore/consulente e come percorso di studi posso vantare esperienza di ordine di magnitudine simile alla tua. So programmare. Non ti do ragione. E non consiglio di avvicinarsi all'informatica come tecnici ma come analisti, specie se si ha una formazione umanistica e non tecnica. Si chiama legge di pareto: occuparsi dei dettagli costa molto di piú di occuparsi del "disegno generale".

Peace

Mettiamola cosi' che mi sono stufato:

Sia che vuoi fare il programmatore, sia che vuoi fare il consulete/"quel cazzo che vuoi", non puoi sperare di diventarlo solo con una lettura di pagine in internet, anche perche' sarebbe mancanza di rispetto verso chi quella figura professionale lo e' diventata tramite studio e impegno, durato anni.

Puoi essere un programmatore, puoi essere un consulente, ma per esserlo professionalmente valido, c'e' bisogno di impegno e studio, e pratica ( tanta pratica, cazzo ).

Per essere un programmatore capace inoltre ci sarebbe bisogno anche di conoscere come funziona l'hardware a basso livello, certo non e' essenziale, ma per esperienza tutte le persone 'molto capaci' in questo settore erano persone che sapevano come lavorava il basos livello, persone formate da programmazione a basso livello, poi ognuno puo' diventare quello che vuole.

Inoltre per non mancare di rispetto a chi il consulente lo fa bene e profesionalmente, sono persone che hanno competenze anche di programmazione, come hai detto tru stesso che sei consulente, pero' sai programmare, e ci credo, altrimenti che consigli, quello che non sai?!?

Il tuo suggerimento e' sbagliato perche' senza una conoscienza di base dell'informatica e nello specifico della programmazione tutto quello che il tale imparera' dal tuo consiglio sara' un contenitore vuoto, e per quanto bello e luccicante e grande sia il contenitore, sempre vuoto restera', alla prima pressione si accartoccera'.
Se invece il contenitore e' pieno, potra' essere piccolo, ma stai sicuro che anche se e' premuto fortissimo, reggera'.

#include<stdio.h>
main()
{
printf("\n Pace");
}

[y.a.f.ake]

Che buonismo del cazzo

[Recidivo Visual]

Che buonismo del cazzo

P.S. Da noi vige un dubbio mostruoso: per diventare programmatori bisogna essere strani o si diventa strani a furia di programmare...

Io opto per l'una e l'altra. :autoasd:

[y.a.f.ake]

ma non puoi occuparti del disegno generale se non hai idea di quello che c'è sotto

E' vero questo ma è vera anche la sua negazione

[ZioYuri78]

Faccio un esempio, se devi programmare una macchina utensile (non per fare il pezzo, devi programmarla da vergine per farla funzionare) di MSDN non te ne fai niente, devi conoscere il chip su cui vai a lavorare e quindi devi saper programmare in assembler e c++. Se chiedono consiglio al consulente e lui risponde "aspetta che guardo su MSDN" lo cacciano a pedate.

[Sticky©]

Faccio un esempio, se devi programmare una macchina utensile (non per fare il pezzo, devi programmarla da vergine per farla funzionare) di MSDN non te ne fai niente, devi conoscere il chip su cui vai a lavorare e quindi devi saper programmare in assembler e c++. Se chiedono consiglio al consulente e lui risponde "aspetta che guardo su MSDN" lo cacciano a pedate.

Si presume che se io abbia bisogno di consulenza per programmare una macchina utensile non vada a chiamare un consulente che sul CV ha chiaramente scritto di avere esperienza solo su .NET o Visual C++. Scemo io che chiedo consulenza a lui, mi pare ovvio.

[giuseppemag]

{robba buona}

Sono d'accordo con tutto quello che scrivi. Anzi, no: *quasi* tutto

Il fatto di sapere quello che c'é sotto vale fino a un certo punto. Quando ti fermi? Decidiamo che le procedure vanno bene o bisogna sapere come funziona il salvataggio dei registri sullo stack? Sommare due interi é una primitiva o dobbiamo discutere di come accade in binario con un numero di bit limitato? Sommare due bit con resto é una primitiva o dobbiamo scendere fino all'elettronica? E poi la fisica? E poi?

Il bello dell'informatica é che come la matematica moltissimo dipende dal processo di astrazione. Non credo ci sia un livello di astrazione "giusto", dipende dalla tua professione. Se un analista mi parla di aritmetica dei puntatori, beh, la sola idea mi dá i brividi...D'altro canto se uno sviluppatore di embedded devices vuole usare Python, un lol in faccia e un calcio al culo non glieli toglie nessuno! Mi interessa poco che una figura sappia fare bene tutto: basta che faccia bene il suo lavoro e interfacci correttamente col resto del team!!!

[blue_tech]

non so se t'è sfuggito il mio post ma il livello giussto è appunto quello che viene dato per esempio in architetture degli elaboratori dove la cosa più bassa che vedi sono le porte logiche and or e not... non scendi nell'elettronica per vedere come sono fatte le singole porte ma hai sufficente materiale per sapere come funziona il processore perchè vedi la sua architettura per intero... impari come funzionano i registri, una alu, le pipeline, ecc... come interagiscono tra loro e cose così...

E si, in informatica c'è anche un corso di fisica generale se ti può interessare
dato che lavori in uni avrai fatto ste cose no? dovresti sapere qual è il percorso giusto più o meno... poi uno può sempre apporfondire ma questo è il necessario... e se non basta nel corso di sistemi operativi, se lo fai bene, vedi anche come funziona un S.O. all'interno fino alle code di priorità dei processi, interrupt, ecc... con tanto di codice c a bassissimo livello

devi guardare giù punto è basta fatte le basi poi sali sul tetto

[y.a.f.ake]

Sommare due interi é una primitiva o dobbiamo discutere di come accade in binario con un numero di bit limitato? Sommare due bit con resto é una primitiva o dobbiamo scendere fino all'elettronica? E poi la fisica? E poi?

Ma è così bello

Mi interessa poco che una figura sappia fare bene tutto: basta che faccia bene il suo lavoro e interfacci correttamente col resto del team!!!

Quindi ho buttato e sto buttando via il mio tempo

[y.a.f.ake]

non so se t'è sfuggito il mio post ma il livello giussto è appunto quello che viene dato per esempio in architetture degli elaboratori dove la cosa più bassa che vedi sono le porte logiche and or e not... non scendi nell'elettronica per vedere come sono fatte le singole porte ma hai

stocazzo all'uni mi sono smazzato esami di elettronica,elettrotecnica, termodinamica, dico termodinamica,chimica

[ZioYuri78]

stocazzo all'uni mi sono smazzato esami di elettronica,elettrotecnica, termodinamica, dico termodinamica,chimica

Ne ho appena fatto uno di Fisica A .

[blue_tech]

stocazzo all'uni mi sono smazzato esami di elettronica,elettrotecnica, termodinamica, dico termodinamica,chimica

bravo tu hai fatto ingegneria!
prima nasci ingegnere poi c'è il resto... io faccio informatica e esco informatico punto

è una formazione più settoriale se vogliamo

[giuseppemag]

E si, in informatica c'è anche un corso di fisica generale se ti può interessare
dato che lavori in uni avrai fatto ste cose no? dovresti sapere qual è il percorso giusto più o meno... poi uno può sempre apporfondire ma questo è il necessario... e se non basta nel corso di sistemi operativi, se lo fai bene, vedi anche come funziona un S.O. all'interno fino alle code di priorità dei processi, interrupt, ecc... con tanto di codice c a bassissimo livello

Si, é dura prendere laurea e dottorato in informatica senza accorgersi di cosa ti stanno facendo studiare. Non per questo é il percorso giusto: l'informatica cambia e cresce continuamente, e bisogna chiedersi se il curriculum ingegneristico di una volta é il massimo o se servono altri strumenti per padroneggiare al meglio la complessitá. Ad esempio per ragionare in termini di processi concorrenti (un must di questi anni) la conoscenza di dettagli a basso livello é utile quanto saper mescolare la malta serve ad un ingegnere che sta progettando lo space shuttle.

non so se t'è sfuggito il mio post ma il livello giussto è appunto quello che viene dato per esempio in architetture degli elaboratori dove la cosa più bassa che vedi sono le porte logiche and or e not... non scendi nell'elettronica per vedere come sono fatte le singole porte ma hai sufficente materiale per sapere come funziona il processore perchè vedi la sua architettura per intero... impari come funzionano i registri, una alu, le pipeline, ecc... come interagiscono tra loro e cose così...

Non sono convinto che sia il livello giusto, é solo quello comunemente accettato. Non é particolarmente male, ma mi pare lievemente anacronistico! Forse comincia ad essere arrivato il momento di separare meglio le carriere informatiche, come giá accade per le carriere ingegneristiche!

[giuseppemag]

stocazzo all'uni mi sono smazzato esami di elettronica,elettrotecnica, termodinamica, dico termodinamica,chimica

Non che sia un errore, ma secondo me fare ingegneria per essere un informatico non é un centro pieno :shrug:

[ZioYuri78]

Non che sia un errore, ma secondo me fare ingegneria per essere un informatico non é un centro pieno :shrug:

Non condivido, se devo fare un software che richiede ampie conosc(i)enze di fisica (tipo calcolo delle traiettorie di lancio dei satelliti, monitoraggio di essi, triangolazioni gps, strumenti per simulazioni varie, ecc..), sicuramente ingegneria mi viene incontro. Oppure secondo te basta consultare un libro di Fisica per risolvere il problema? Ovvio che l'Ing. Informatico ha una conosc(i)enza più vasta, NON generalizzata, vasta. Ci sono campi dove viene applicata l'informatica che necessitano anche di conosc(i)enze sulla fisica, la chimica, la statistica. Mica è tutto database e programmi per gestire le bolle di entrata .

[giuseppemag]

Non condivido, se devo fare un software che richiede ampie conosc(i)enze di fisica (tipo calcolo delle traiettorie di lancio dei satelliti, monitoraggio di essi, triangolazioni gps, strumenti per simulazioni varie, ecc..), sicuramente ingegneria mi viene incontro. Oppure secondo te basta consultare un libro di Fisica per risolvere il problema? Ovvio che l'Ing. Informatico ha una conosc(i)enza più vasta, NON generalizzata, vasta. Ci sono campi dove viene applicata l'informatica che necessitano anche di conosc(i)enze sulla fisica, la chimica, la statistica. Mica è tutto database e programmi per gestire le bolle di entrata .

Mica ho detto che é inutile, ho detto che non é un *centro pieno*. Infatti va bene per applicazioni di nicchia, quelle che hai citato tu. Far sopravvivere una applicazione con tanta gente che ci lavora per anni é un problema diverso: non sarebbe la prima volta che un ing. produce un prototipo decente (magari in MatLab) che gente piú informatica poi trasforma in una applicazione decente, ben strutturata e vendibile!

ps: occupandomi di gamedev ovviamente vivo apprezzando questo aspetto

[Ronin]

la mia azienda è certificata ... lo so cosa ci vuole per la iso 90001 ... O Ronin te lo dico francamente, mi puoi strascassare il cazzo su tanti argomenti, ma proprio sulla programmazione...
Vai bello, come quell'altro: "hai ragione".

non capisco la necessità di avere un approccio così litigioso, ma se ti aiuta fai pure, conoscendoti non mi infastidisce più che tanto.

il processo la mia azienda è certificata iso => so cosa occorre per certificarsi iso è tipico di quello che chiamo "approccio iso 8000" (cioè di chi crede di aver capito la iso 9000 e invece gli manca almeno un migliaio di punti...).
ci siamo passati tutti, me compreso, non è un demerito: il fatto è che se non lo fai per mestiere, tu sai cosa ci vuole per certificare iso la tua azienda, nell'ambito della visione delle cose che il tuo posto in azienda ti da (es. se sei programmatore lo comprendi per l'ufficio programmazione).
ma il lavoro del consulente, è di saperlo fare per ogni azienda (da quelle che producono oggetti fisici a quelle che si basano sulla conoscenza, e producono prodotti immateriali, , e per ogni ufficio (dai programmatori all'ufficio acquisti, al magazzino fino ai commerciali che vanno in giro dai clienti).

la parte più complicata del lavoro è nell'interoperabilità: spesso iso 9001 vien concepito come "standard" (alla maniera americana anni '80): si crea uno standard per il lavoro, e tutti si uniformano, così tutto diventa interoperabile: se tutti scriviamo con word usando Arial in corpo 10 (banalizzo volutamente, se conoscete gli stili di word), quando mario apre il file fatto da giovanni e gli incolla dentro un pezzo scritto da luca il documento non perde la formattazione. si chiama interoperabilità

peccato se il "tutti" son più di 5-10 persone divise su più di 1 sede, questo approccio si traduce in un catastrofico disastro: è il motivo per cui gli usa negli anni 80-90 son stati sopravanzati dai giapponesi: perchè le persone si creano ognuna i propri standard, e costringere le persone a cambiarli di solito produce o il rifiuto totale (fino al sabotaggio), o un calo della produttività talmente drammatico che lo standard alla fine peggiora l'efficienza dell'azienda invece di migliorarla.

l'approccio qualità prevede che ogni unità (che può al limite essere composta anche da una singola persona) mantenga le proprie procedure, ma vengano implementati sistemi di conversione che consentono l'interoperabilità senza necessità di stravolgere l'attività: nella banalizzazione, mario si crea uno stile con arial 10, luca con times new roman 14, ma lo stile è sempre "Corpo del testo", così quando copio il pezzo di luca nel documento di mario, si trasforma in arial 10 da solo.

"Da solo" è il punto chiave del consulente qualità: la tecnologia informatica è uno strumento che consente di raggiungere la trasparenza del risultato (l'utente non si accorge della complessità del processo).
non è nemmeno l'unico strumento, ma solo uno di una serie.

questo microscopico e banalissimo esempio forse riesce a far inquadrare quello che cercava di spiegarti anche il buon giuseppe: io faccio l'ingegnere, e progetto impianti: per far funzionare bene un impianto di riscaldamento ho bisogno di sapere come funzionano tutti i componenti, dalla caldaia alle pompe, ai radiatori, alle Unità di trattamento dell'aria.
di ciascuno di questi N componenti ho informazioni che un ingegnere che facesse per lavoro il progettista di quel componente chiamerebbe "superficiali".
non saprei mai, lasciato a me stesso, progettare una caldaia, o un bruciatore.

e anche chi progetta il bruciatore, ti assicuro che se magari conosce il processo di sagomatura degli ugelli di fiamma, poi non sa niente dell'elettronica di misura dell'ossigeno e del monossido, e viceversa.

il consulente della qualità assurge a ruolo di "impiantista" del processo aziendale: se è bravo, sarà in grado di introdurre la necessaria automazione per QUALSIASI processo aziendale, anche se a priori non lo ha MAI visto prima: saprà farselo spiegare fino ad enuclearne i passaggi che devono essere resi interoperabili, saprà introdurre standard a chi non li possiede appianando le resistenze, saprà far colloquiare i diversi sistemi (che finchè siete in tre con due win 7 e un win xp è banale, ma quando siete in 4.000 in 17 paesi con 4 differenti backoffice, è un tantino differente...).

in tutto questo, la tecnologia informatica è un puro e semplice mezzo, che deve essere conosciuto ad un livello tale da non spingersi oltre le sue possibilità, ma non è necessario saper governare esattamente nei singoli passaggi "primitivi", proprio come per saper usare bene le forbici non occorre avere molte informazioni sul processo di trafilatura dei metalli ferrosi, se non per sommi capi.

nel mio team io che sono progettista (ingegnere elettrico) e da anni non scrivo più neanche una riga di codice, gestisco anche dei programmatori: loro sanno quel che io non ho bisogno di sapere, esattamente come il motorista ferrari conosce la sagomatura dei pistoni MOLTO meglio di Todt (o chi c'è adesso, non me lo ricordo).
sopra di me si trovano progettisti che hanno degli impianti informazioni che io chiamerei "superficiali", ma che devono svolgere il loro ruolo a livello di intero edificio, ed integrare impianti, strutture, finiture architettoniche, geologia, ecc.

è una catena a più livelli: quando uno dei livelli ha una conoscenza insufficiente del sottostante, la piramide si incrina, e il risultato finale è mediocre.
ma non si può chiedere ad un livello di conoscere il processo del livello inferiore con la stessa profondità: altrimenti non si riesce ad esercitare il ruolo di coordinamento che il livello superiore impone.

per i fornitori di caldaie e ventilatori, io sono "supervisore superficiale" (nel senso che non conosco i loro prodotti a fondo quanto loro, ma ho una visione ampia che mi permette di spiegare loro come devono darmeli); per gli architetti, sono "sottoposto specialista" (perchè conosco gli impianti molto meglio di loro, ma non ho una visione completa del progetto dell'edificio, es. non conosco se non per sommi capi le norme sulle barriere architettoniche, o sui percorsi funzionali).
anche tu che sei programmatore, giustamente non ti spingi fino al progetto del circuito integrato e del linguaggio macchina su cui "gira" il software che scrivi in un linguaggio ad alto livello: non sei completamente ignaro del "come funziona", ma nemmeno lo conosci abbastanza da svolgere il ruolo di specialista di quel settore: per quello ci sono appunto gli specialisti.

perciò ognuno di noi, te compreso, consciamente o inconsciamente, nel suo lavoro astrare il risultato del lavoro di altri (che conosce solo quel tanto che basta per usarlo come strumento), e viceversa vede il proprio lavoro "astratto" da qualcun altro per altri scopi (salvo che lavori in una piccola azienda, e si trovi al vertice della stessa: lo ripeto, il contesto aziendale è quello dell'azienda di almeno medie dimensioni).
il consulente per la qualità è colui che di questo processo ha fatto il proprio (conscio) settore di attività.

nel ruolo di Todt quindi non ci può essere un motorista: ci deve essere uno che è capace di discutere di motori col motorista, di areodinamica col telaista, di mescole col gommista, e di strategie con...l'autista

non c'è il tempo fisico perchè Todt, che magari, se ci si mettesse, sarebbe un ottimo motorista, sappia abbastanza di ciascuno di questi argomenti per padroneggiarlo perfettamente, come uno specialista del ramo: egli deve necessariamente fermarsi prima dell'enucleazione "primitiva" di cui tanto ti vanti, e che invece non è altro che il risultato del tuo ruolo.
altrimenti il ruolo massimo cui potrà aspirare sarà quello di capo motorista, appunto, non di direttore tecnico, o direttore sportivo.
e guarda che non è un apprezzamento qualitativo: il "sottoposto autista" Schumacher guadagna(va) NMILA volte più di Todt: però è diversa la collocazione nella piramide gestionale dell'azienda.
a sua volta non sta a todt stringere accordi di vendita con i distributori ferrari negli states: per montezemolo, todt è uno specialista del ramo propro come il motorista lo è per todt.

perciò, masp, non ho proprio niente da insegnarti in materia di programmazione: se sarò bravo, sarò io, che nel ruolo di supervisore, apprenderò dai miei programmatori i concetti che mi servono per poterli indirizzare verso i risultati che devono essere ottenuti (proprio come imparo dal caldaista il modo di regolar l'impianto che mi fa risparmiare soldi).

ah, e per la cronaca, non ho niente da insegnare neanche come consulente qualità (non lo faccio, nè lo so fare): da costui, apprendo esattamente lo stesso che dal programmatore: quello che mi serve, del suo specifico settore, a livello non superficiale ma neanche troppo approfondito, per far funzionare al meglio il mio team.

non vedo che motivo ci sia di litigare

[Haruki]

mazza quanto hai scritto

[Ronin]

metodo brevettato per zittire chi non la pensa come me
no, dai, è che l'argomento come ho detto all'inizio, è molto vasto per essere trattato su di un forum: volevo dimostrare che quando parlavo di corso apposta per capire i fondamenti del settore, non parlavo a vanvera.

[meL.rtcw]

io son d'accordo con quanto scritto da Ronin, e cioe' non e' che ognuno in un team di sviluppo debba sapere programmare.

Ci sono tanti ruoli da ricoprire e processi IT da gestire che il programmatore e' proprio l'ultima cosa di cui preoccuparsi. Saper le basi della programmazione aiutano in alcuni aspetti e ovviamente porteranno ad un migliore dettaglio, ma non e' indispensabile per poter lavorare in campo informatico.

OT d'esempio: sto scoprendo attualmente il framework ITIL per la gestione dei servizi informatici e mi sta intrippando di fisso la cosa. E la programmazione e le mie conoscenze in campo informatico mi stan facendo far fatica ad astrarre in maniera cosi' alta i concetti come vengono trattati in ITIL.

[MadOne]

ma state dicendo cose ovvie
(a parte l'ultima frase di mel ovviamente, che è una cosa veramente brutta da leggere)

e ciò denota una mancanza di comprensione del testo mica da ridere
anzi

la metto in modo chiaro (per l'ennesima volta), perché altrimenti sembra che avete ragione voi:
1. stiamo parlando della figura del "consulente della qualità"
2. tale consulente, se non vuole essere mediocre (e quindi non essere preso a calci da me medesimo ), DEVE sapere stabilire la qualità di un prodotto/tecnologia/framework/chiamateli_come_vi_pare e saper relazionarli, confrontarli e dare un giudizio critico, sia a livello generale (es. ruby > python per fare A, ma < per fare B, ...) sia a livello decisionale per un singolo progetto (es. per fare A dico di usare X invece di Y perché...)
e questo tipo di competenza la vedo dura svilupparla senza avere alcun bagaglio di programmazione, ma solo a pane e manuali, msdn, ecc ecc

[giuseppemag]

e questo tipo di competenza la vedo dura svilupparla senza avere alcun bagaglio di programmazione, ma solo a pane e manuali, msdn, ecc ecc

Forse perché sei un programmatore. Non lo dico con tono antipatico: solo nella mia esperienza i programmatori tendono a voler "alfabetizzare" alla programmazione quasi tutti quelli che stanno loro intorno, e tendono ad avere un forte senso di superioritá intellettuale (si pensi solo al gruppo culturale elitista degli utenti di Linux e dei devs come sottogruppo ultra-elitario all'interno del primo). Spesso questo atteggiamento é supportato da una capacitá analitica ampiamente superiore alla media, ma si scontra con il ruolo comunque di nicchia che l'informatica svolge nel resto delle attivitá umane.

[Ronin]

mancanza di comprensione del testo... questo tipo di competenza la vedo dura svilupparla senza avere alcun bagaglio di programmazione, ma solo a pane e manuali, msdn, ecc ecc

mi domando quale sia la necessità di offendere gli altri per sostenere i propri argomenti.

tu parli di "conoscenza" come se fosse un flag: o sei un programmatore e c'hai la conoscenza del linguaggio X=on, oppure non lo sei e c'hai la conoscenza del linguaggio X=off.

la realtà è molto diversa da questo approccio: la conoscenza non è uno switch binario, è un valore continuo che va dallo 0 al 100%.
avere il 100% (o cmq più del... boh, 70%) significa essere uno specialista del ramo (perchè significa dover investire una quota maggioritaria del proprio tempo nel mantenere questo tipo di conoscenza aggiornata con l'evoluzione e sperimentata nella pratica).

ma per stabilire le modalità di impiego di uno strumento e comprenderne le potenzialità applicative (e i limiti strutturali) non c'è bisogno di portare il livello di conoscenza al 70% (quello cui tu associ lo switch): basta arrivare al 30% o al 50%.

e guarda che non sto dicendo che per conoscere un linguaggio basta conoscerne le basi: sto dicendo che la conoscenza che occorre avere per svolgere un compito a livello decisionale è selettiva.

provo a banalizzare: per sapere che mi occorre ordinare i dati non ho bisogno di conoscere l'algoritmo merge sort: mi basta sapere che merge sort è più efficiente dell'algoritmo per inserimento. uno specialista del ramo, invece, il merge sort lo deve saper implementare effettivamente.
comprendere il funzionamento del merge sort sta ad un livello di conoscenza più elevato rispetto all'include, al ciclo for, alle chiamate di subroutine (tutta roba che propedeuticamente viene prima: se non la conosco, non riuscirò mai ad implementare il mio algoritmo): ma in un ruolo da "supervisore" io posso selettivamente trascurare alcuni di questi dettagli operativi: l'importante è che sappia orientare chi i dettagli operativi li tratterà verso il risultato concettualmente corretto (=più efficiente).

il mio livello di conoscenza non mi permette (se non aprendo qualche libro e perdendo un sacco di tempo che non ho) di implementare un algoritmo merge sort operativamente: mi permette di sapere concettualmente come funziona, e di stabilire che essendo il numero di dati che devo trattare inferiore ad alcune migliaia, merge sort è più efficiente degli algoritmi 100% ricorsivi come quicksort, e quindi ti chiedo (a te programmatore) di implementare quello.

il livello di competenza che è necessario acquisire per comprendere le cose è molto inferiore a quello che occorre per implementarle in maniera operativa, perchè per funzionare operativamente bisogna sistemare MOLTI dettagli, e ciò richiede molto tempo e molte informazioni, che occorrono perchè il sistema funzioni, ma spostano di ben poco il disegno "complessivo", proprio come per realizzare un impianto di riscaldamento bisogna analizzare ogni singolo tubo e curva e raccordo e radiatore, ma alla fine il grosso del progetto finisce per ricondursi a scelte su alcuni componenti specifici (come la caldaia, che da sola fa metà dell'importo).

il concetto può essere esportato in ogni ambito, e vale a maggior ragione per un ambito che NON si conosce: per diventarne specialista partendo da zero occorrono enormi quantità di tempo; per coglierne gli aspetti concettuali importanti (conoscendolo selettivamente quanto basta a guidarne il processo), ne occorre molto meno (ma occorre più attenzione, ed uno sforzo mentale molto maggiore).
è il motivo per cui i bravi manager possono passare da un'azienda che produce pentole ad un'altra che produce microchip: perchè sono in grado di astrarre dalla competenza del personale tecnico che è loro sottoposto (come me, ndr) i macro-argomenti che regolano il processo produttivo, lasciando i dettagli agli specialisti.
è anche lo stesso motivo per cui i cattivi manager portano le aziende al tracollo: perchè non sono in grado di portare a compimento il procedimento di conoscenza selettiva, e quindi magari si concentrano su dettagli trascurabili lasciando irrisolti nodi fondamentali: ma quello è un guaio della persona, non del procedimento.

per tornare alla metafora automobilistica, schumacher può essere un bravo pilota anche senza essere un motorista; il non essere un motorista NON fa di lui un ignorante totale in tema di motori: per essere un bravo pilota deve avere delle cognizioni in tema di motori per sapere cosa può chiedere al mezzo che guida (sennò poi magari va in testa, ma ad un certo punto il motore lo brucia anche).
ma ciò non significa che schumacher sia in grado di sedersi davanti al CAD, e disegnare i pistoni, le bielle, i cilindri, gli ugelli con il modellatore tridimensionale, e passare i disegni in officina per realizzarli: quelli sono (dal SUO punto di vista) dettagli operativi che possono essere lasciati agli specialisti.

chi sta seduto davanti al cad a disegnare bielle e pistoni, a sua volta non ha bisogno di sapere come il cad internamente gestisce le primitive grafiche, se non a livello concettuale (deve sapere cioè, che ha a disposizione i comandi estrusione, rivoluzione, ecc., ma non ha bisogno di occuparsi in dettaglio delle matrici di trasferimento che descrivono matematicamente il processo) .

e così via: ognuno opera al suo livello di dettaglio, e trascura dettagli dei livelli più approfonditi che lascia ai relativi specialisti.
non comprendere che, in un mondo interconnesso come il nostro, il proprio ruolo non è il più elevato possibile (perchè concettualmente ognuno è SEMPRE specialista per qualcuno e supervisore per qualcun altro) è sintomo di quella superiorità intellettuale di cui parlava giuseppe.