Quando un developer incontra una nuova tecnologia, la prima reazione è spesso la stessa:
“Devo studiarmela bene prima di poterla usare.”
Così si apre la documentazione, si guarda qualche tutorial, si leggono articoli, si seguono corsi e si iniziano a memorizzare concetti.
Dopo qualche giorno, però, ci si rende conto di una cosa: abbiamo studiato molto, ma sappiamo ancora poco di come usare davvero quella tecnologia.
Il problema non è necessariamente il tempo, ma l’approccio.
Non devi imparare tutto
Una delle trappole più comuni quando si impara una nuova tecnologia è pensare di doverne conoscere ogni aspetto, ma nella maggior parte dei casi non è così. Quando inizi a lavorare con una tecnologia nuova, non ti serve conoscere tutte le sue API, tutte le configurazioni possibili o tutte le funzionalità avanzate.
Ti serve capire:
- che problema risolve
- come si inserisce nel progetto
- quali sono i concetti fondamentali
- come svolgere le operazioni più comuni
- dove trovare le informazioni quando qualcosa non funziona
Il resto arriverà con l’utilizzo.
Un developer efficace non è quello che conosce a memoria tutta la documentazione, ma quello che sa orientarsi abbastanza bene da riuscire a costruire qualcosa.
Parti dal problema, non dalla tecnologia
Quando devi imparare qualcosa di nuovo, evita di partire dalla domanda:
“Come funziona questa tecnologia?”
È una domanda troppo grande.
Parti invece da:
“Cosa devo riuscire a fare con questa tecnologia?”
Supponiamo di dover utilizzare Redis per la prima volta (un saluto e tanta stima per Salvatore Sanfilippo!).
Potresti passare ore a leggere come funziona Redis in generale.
Oppure potresti partire da un obiettivo concreto:
“Devo salvare temporaneamente i dati di una sessione e recuperarli velocemente.”
A quel punto la ricerca diventa molto più specifica.
Devi capire come connetterti a Redis, come salvare un valore, come recuperarlo, come impostare una scadenza e come gestire gli errori. Non hai ancora imparato Redis, ma hai imparato la parte di Redis che ti serve per risolvere il problema.
Ed è esattamente così che dovrebbe iniziare l’apprendimento.
Il progetto è il miglior insegnante
Il modo più veloce per imparare una tecnologia è spesso usarla prima di sentirsi pronti.
Un piccolo progetto può insegnarti in poche ore cose che un corso di dieci ore non riesce a trasmetterti. Perché quando costruisci qualcosa emergono immediatamente le domande giuste:
- Come configuro questa cosa?
- Dove devo mettere questa configurazione?
- Come gestisco questo errore?
- Perché questo codice non funziona?
- Qual è il modo corretto di fare questa operazione?
- Cosa succede se il dato non esiste?
- Come faccio a fare questa cosa in produzione?
Queste domande hanno un valore enorme, perché non stai imparando informazioni astratte. Stai imparando per risolvere un problema reale.
La documentazione non va letta tutta
Un altro errore comune è pensare alla documentazione come a un libro da leggere dalla prima all’ultima pagina.
Tipo il super manuale del super dev. Spoiler: non lo è!
La documentazione è soprattutto uno strumento di consultazione. Quando inizi una nuova tecnologia, ha senso leggere le sezioni introduttive per capire il modello mentale e i concetti principali. Tipo il libretto delle istruzioni per il dev (si lo so, è molto esagerata come metafora)
Dopodiché, però, dovresti iniziare a cercare ciò che ti serve. Devi imparare a fare domande precise.
Non:
“Come funziona PostgreSQL?”
Ma:
“Come creo una relazione tra queste due tabelle?”
Non:
“Come funziona Docker?”
Ma:
“Come faccio a esporre questa porta dal container?”
Più la domanda è precisa, più velocemente trovi la risposta e questa capacità diventa ancora più importante man mano che fai esperienza.
Imparare significa anche saper cercare
Un developer non può ricordare tutto, è semplicemente impossibile. Puoi conoscere molto bene un linguaggio e dimenticare la sintassi di una funzione che non usi da sei mesi. Quindi puoi aver utilizzato una libreria per anni e non ricordare una determinata configurazione.
Puoi incontrare un errore che non hai mai visto.
La differenza non sta nel ricordare tutto, ma sta nel sapere dove cercare e come verificare quello che trovi.
Documentazione ufficiale, repository, issue, esempi, forum e strumenti di AI possono diventare parte del tuo processo di apprendimento, ma c’è una distinzione importante: trovare una soluzione non significa aver capito la soluzione.
Se copi una risposta senza sapere perché funziona, probabilmente hai risolto il problema di oggi. Se capisci perché funziona, hai imparato qualcosa che potrai riutilizzare domani, questa cosa ve l’ho già detta in altri articoli, ma non smetterò mai di dirlo perchè è fondamentale per crescere.
Un metodo semplice per imparare in pochi giorni
Quando devo imparare una tecnologia nuova, un approccio efficace può essere diviso in quattro fasi.
1. Capire il modello mentale
Prima di scrivere codice, cerca di capire come ragiona quella tecnologia.
Qual è il suo scopo?
Quali concetti utilizza?
Quali problemi cerca di risolvere?
Non serve ancora entrare nei dettagli.
L’obiettivo è costruire una mappa mentale.
2. Costruire qualcosa di piccolo
Subito dopo, metti le mani sul codice.
Non iniziare da un progetto enorme.
Costruisci qualcosa di abbastanza piccolo da poterlo completare rapidamente, ma abbastanza concreto da costringerti a utilizzare i concetti fondamentali.
È qui che inizierai a capire davvero la tecnologia.
3. Affrontare i problemi reali
Una volta che il primo esempio funziona, prova a romperlo.
Cambia qualcosa.
Fai un errore.
Gestisci un caso che non avevi previsto.
Cerca di aggiungere una piccola funzionalità.
È in questa fase che la conoscenza superficiale inizia a trasformarsi in competenza.
4. Tornare alla documentazione
Solo a questo punto torna sulla documentazione. Ora avrai un contesto. Capirai meglio ciò che stai leggendo e soprattutto saprai quali parti meritano davvero attenzione. Potresti scoprire funzionalità che non conoscevi, alternative migliori al tuo approccio o limitazioni che non avevi considerato. La documentazione letta dopo aver messo mano alla tecnologia ha un valore completamente diverso.
Il vero obiettivo non è diventare esperti
Dire “voglio imparare questa tecnologia in pochi giorni” può essere fuorviante.
In pochi giorni difficilmente diventerai esperto, ma puoi diventare operativo. E spesso è esattamente quello che serve. Essere operativi significa riuscire a:
- iniziare un progetto
- comprendere gli esempi principali
- scrivere codice funzionante
- leggere la documentazione
- risolvere problemi comuni
- riconoscere quando stai facendo qualcosa nel modo sbagliato
- sapere dove approfondire
Da lì inizia il vero apprendimento. Perché una tecnologia non si impara una volta sola. La impari mentre la utilizzi.
La velocità arriva dalla selezione
Imparare velocemente non significa assorbire più informazioni degli altrim, ma selezionare meglio le informazioni che ti servono. Se cerchi di imparare tutto, finirai per disperdere il tuo tempo. Se invece individui il 20% dei concetti che ti permettono di fare l’80% del lavoro, puoi diventare produttivo molto più rapidamente.
Poi arriveranno i casi particolari.
Le funzionalità avanzate.
Le ottimizzazioni.
Le best practices.
I problemi più complessi.
Ma non devi conoscerli prima di iniziare, devi incontrarli quando diventano necessari.
Non aspettare di sentirti pronto
Forse la cosa più importante da capire è questa:
non devi sentirti pronto per iniziare a usare una tecnologia.
Devi iniziare a usarla per diventare pronto. È una differenza piccola solo apparentemente. Aspettare di conoscere una tecnologia prima di utilizzarla può trasformarsi in un ciclo infinito di tutorial, corsi e documentazione. Utilizzarla subito ti costringe invece a fare domande, commettere errori, cercare risposte e costruire collegamenti. Ed è proprio questo processo che trasforma l’informazione in competenza. Alla fine, imparare una nuova tecnologia in pochi giorni non significa imparare tutto. Significa imparare abbastanza per iniziare a costruire.
Il resto lo imparerai mentre costruisci.
