sto leggendo il libro “Pragmatic Thinking and Learning” e mi sto soffermando su alcuni punti interessanti legati all’apprendimento.
In particolare io mi riferisco al nostro settore quindi all’apprendimento in ambito IT (tecnologia, design, architettura, metodologie, …).
Come sappiamo esistono differenti modi di apprendere:
- Leggere libri
- Realizzare un progetto personale
- Apprendimento tramite esperienza in azienda
- Apprendimento tramite corsi offerti dall’azienda
- Partecipazione a sessioni tecniche e a community
- Webcast
- Podcast
- Lettura di articoli / blog sul web
- Mentoring
- Gruppi di studio
- …
Ci sono tantissimi professionisti che stimo e rispetto (e molti sono qui su ugi) con un bagaglio di competenza tecnica immenso che spazia campi di applicazioni diversi e sorge spontanea la domanda:
Qual e’ il vostro modo efficace di apprendere?
Come e’ evoluto nel corso degli anni?
Una classica risposta e’ con la pratica! Si e’ vero, capisco che la pratica e’ la chiave ma qui entra in gioco il fattore tempo.
Quanto tempo extra-lavoro dedichi all’apprendimento?
Io personalmente ne dedico molto in quanto sono estremamente appassionato ma misuro che i progressi non sono rapidi come vorrei.
Il mio manager dice che e’ solo una questione di esperienza ma non condivido la sua affermazione. Voi?
Condividete la vostra esperienza perfavore, penso che possa nascere una discussione interessante.
Per concludere vorrei riportare una frase significativa del libro:
“There's always going to be a new technology or a new version of an existing technology to be learned. The technology itselft isn't as important; it's the constant learning that counts."
Questa e' una fase che fa riflettere:
ReplyDelete"Build to learn, not learn to build"
Il mio approccio e l'approccio dell'educazione in generale e' al contrario. Come fai a costruire se non hai le informazioni per farlo? A me piace conoscere il piu' possibile prima di "costruire" in modo da costruire meglio. A quanto pare anche costruire qualcosa di fatto male e poi imparare dopo e' piu' efficace. Ma dal punto di vista temporale quale dei due metodi e' piu' efficace?
Io ho sempre adottato un mix dei due approcci... prima mi leggo uno o due libri sull'argomento principale e poi applico... e poi altri libri piu' avanzati... e cosi' via...
Conosco persone che smanecchiano e basta e non leggono... questo e' il male per me anche se spesso quelle appaiono piu' "fighe" perche' hanno qualcosa di concreto da mostrare (pur quanto dietro sia scritto da cane) e tu non hai nulla... e sale un senso di inconcludenza, di delusione
La verita' sta sempre nel mezzo, saggio ma nessuno dice come raggiungere "il mezzo"
> Il mio manager dice che e’ solo una questione di esperienza ma non condivido la sua affermazione. Voi?
ReplyDeleteAssolutament no: sicuramente l'esperienza conta parecchio, ma tocca anche studiare e pure tanto.
Nel mio caso direi che la proporzione e' 50/50, anche se non e' facile scindere le due attivita' (studio e applicazione) perche' nel nostro mestiere si impara parecchio affrontando di volta in volta i problemi che si presentano. E' l'orizzonte che si espande, o che non si espande se non ci si mette anche una buona dose di studio.
-LV
Ciao Ludovico,
ReplyDeletecome dicevo appunto non e' facile!
Per quanto riguarda le modalita' di studio quali preferisci?
come rispondi alle altrea domande che ho messo in grassetto?
Grazie
I libri per la teoria e la documentazione *ufficiale* per i dettagli tecnici. Web/pod cast vanno anche bene, per una rapida overview, mentre blog e forum, salvo poche eccezioni, meglio lasciarli perdere perche' e' piu' disinformazione che altro. Di mentoring e gruppi di studio ne ho fatti ben pochi visto che quando ho cominciato era la meta' degli anni '80, quando in Italia informatica e ancora di piu' ingegneria del software erano materie esoteriche per pochi appassionati. E ovviamente pochi pochi ma buoni buoni, cioe' erano tempi in cui chi apriva bocca sapeva quello che diceva e all'80% delle domande si rispondeva con un semplice e meritato RTFM. Poi sono arrivati gli anni '90, il Web, e la cosiddetta democratizzazione della programmazione, e da li' in poi solo discesa per tutta la categoria: l'ultima volta che ho provato a ri-iscrivermi a ingegneria informatica, 7-8 anni fa, al prof gliel'ho dovuto spiegare io cosa era un puntatore doppio perche' non riusciva a capire il mio compito, e si trattava di un semplice algoritmo di ricerca in un albero.
ReplyDeleteCome ti dicevo, il tempo che dedico allo studio e' almeno il 50% del tempo totale che dedico al lavoro. Personalmente non faccio nessuna differenza fra tempo del lavoro e tempo extra: non capisco nemmeno quale dovrebbe essere questa differenza, se non per il fatto che alcuni progetti mi vengono pagati e altri sono auto-commissioni che pagano in termini di auto-apprendimento, cioe' ampliamento delle mie competenze, e poi, si spera, in quanto ai possibili risvolti commerciali in un qualche prossimo futuro. L'approccio che adotto e' comunque lo stesso: massima serieta' e mai scrivere codice se non con tutti i crismi e che io stesso per primo non capisca a fondo.
Per riepilogare: tocca *studiare* (non semplicemente leggere) i libri per la parte teorica, e tocca imparare a leggere e a leggere bene la *documentazione* per sapere cosa uno sta facendo. Quanto agli smanettoni ritengo senza mezzi termini che siano i veri nemici della nostra professione e la vera ragione per cui nessuno ha piu' rispetto per quello che facciamo, la vera ragione per cui il 90% dei sistemi fa schifo a dire poco, e la vera ragione per cui oggi guadagno il 50% di quello che guadagnavo ad inizio carriera.
> “There's always going to be a new technology or a new version of an existing technology to be learned. The technology itselft isn't as important; it's the constant learning that counts."
Se ne potrebbe parlare per ore, comunque sono (abbastanza) d'accordo.
-LV
Grazie mille per la condivisione,
ReplyDelete>"I libri per la teoria e la documentazione *ufficiale* per i dettagli tecnici"
In ambito Microsoft per documentazione *ufficiale* intendi MSDN? o altro? Io spesso trovo MSDN povera e mi chiedo spesso come fanno coloro che scrivono libri a raccogliere materiale.
>"democratizzazione della programmazione, e da li' in poi solo discesa per tutta la categoria"
Purtroppo :(
>"il tempo che dedico allo studio e' almeno il 50% del tempo totale che dedico al lavoro"
Tu sei libero professionista o dipendente? Io come dipendente ho a disposizione "solo" il 10% del mio tempo (mezza giornata) riservata al self development con eccezioni ovviamente in particolare se serve del tempo per studiare una nuova tecnologia. Ma sono sempre eccezioni da richiedere.
>"Personalmente non faccio nessuna differenza fra tempo del lavoro e tempo extra...non capisco >nemmeno quale dovrebbe essere questa differenza"
Extra lavoro significa tempo al di fuori dell'orario lavorativo, cioe' quanto tempi sottrai al tuo tempo libero.... per esempio io faccio un paio di orette la sera di studio e qualcosa nel weekend quando possibile... ma questo non e' normale per la maggior parte delle persone, se lo faccio e' solo perche' sono appassionato
>tocca *studiare* (non semplicemente leggere) i libri per la parte teorica
Eh gia' ! Tipo io sto studiando WPF e mi sto leggendo "WPF Unleashed". Il libro contiene sia teoria che pratica o per te questo e' un libro solo pratico? Cosa significa per te teoria?
>"imparare a leggere e a leggere bene la *documentazione* per sapere cosa uno sta facendo"
Anche qui a cosa ti riferisci MSDN? come leggi la documentazione?
>"smanettoni ritengo senza mezzi termini che siano i veri nemici della nostra professione "
sono completamente d'accordo!
P.S. Ovviamente lavoro una media di 12 ore al giorno per 6 gorni alla settimana: poi ovviamente ogni 9-12 mesi vado in overload e mi prendo una pausa di 2-3 mesi. A volte anche di piu', anche 6-9 mesi senza un lavoro ufficiale, ma quello e' quando mi rimetto a studiare qualcosa a tempo pieno... Ma questo perche' ancora non ho famiglia: che e' un monito ai giovani a non perdere tempo perche' quando poi ci si mettono la moglie e i figli tocca macinare e basta, e quello che si e' seminato si raccoglie...
ReplyDelete-LV
> In ambito Microsoft per documentazione *ufficiale* intendi MSDN? o altro? Io spesso trovo MSDN povera e mi chiedo spesso come fanno coloro che scrivono libri a raccogliere materiale.
ReplyDeleteSi', MSDN e' la documentazione ufficiale per cio' che riguarda le tecnologie MS. Personalmente trovo che sia scritta egregiamente (a parte alcune aree in cui e' carente, ma si tratta di politiche commerciali MS, non del fatto che i ragazzi di Redmond non sanno scrivere documentazione adeguata), semmai e' che tocca imparare a leggerla: anche per me, che venivo dal mondo Unix e dall'abitudine al "man" e a tutto un altro stile, c'e' stata una "curva di apprendimento" in questo senso. Inoltre tieni conto che, sempre per via di politiche commerciali, la documentazione disponibile al pubblico e' un sottoinsieme della documentazione disponibile ai partner privilegiati: politiche discutibili forse (ma forse anche no), comunque per il lavoro quotidiano quello che trovi su MSDN e' assolutamente sufficiente. Again, il fatti e' che: tocca *imparare a leggerla*.
> Tu sei libero professionista o dipendente? Io come dipendente ho a disposizione "solo" il 10% del mio tempo (mezza giornata) riservata al self development con eccezioni ovviamente in particolare se serve del tempo per studiare una nuova tecnologia. Ma sono sempre eccezioni da richiedere.
Al momento sono dipendente, ma ho fatto anche il libero professionista, sia in Italia che in UK. Se la tua azienda alloca il 10% del tempo al self-development, direi che sei persino fortunato, di solito l'allocazione e' 0% e anzi si fanno solo straordinari a oltranza (grazie anche e ovviamente a manager che non sanno la differenza fra un ufficio sviluppo e un fast-food, ma questo e' un altro capitolo...). Ma l'indicazione che davo e' diversa: *non* scindere le due cose, e quando devi affrontare un argomento nuovo prenditi i tuoi tempi e spazi, senza neanche stare a chiedere autorizzazione a nessuno, cioe' va vista come parte *integrante* del lavoro e della pratica quotidiana, non come un tempo extra.
> Extra lavoro significa tempo al di fuori dell'orario lavorativo, cioe' quanto tempi sottrai al tuo tempo libero.... per esempio io faccio un paio di orette la sera di studio e qualcosa nel weekend quando possibile... ma questo non e' normale per la maggior parte delle persone, se lo faccio e' solo perche' sono appassionato
Molte persone si accontentano di scaldare la sedia e portare a casa la pagnotta con il minimo sforzo, e se la possono portare a casa di raffa (leggi, soldi facili) sono ancora piu' contente. Ci interessa? :)
> Tipo io sto studiando WPF e mi sto leggendo "WPF Unleashed". Il libro contiene sia teoria che pratica o per te questo e' un libro solo pratico? Cosa significa per te teoria?
Lo considero un tema strettamente tecnico. Per teoria intendo cose del tipo (ne butto giu' giusto alcune che mi vengono in mente al volo): matematica, informatica, organizzazione aziendale, questioni economico-finanziarie, questioni legali, architettura (non del software), principii e teoria di ingegneria, ma anche discipline piu' spiccatamente umanistiche tipo linguistica, teoria della comunicazione, e perche' no filosofia e storia, ecc. ecc. Tieni conto che la nostra disciplina e' (a mio avviso) per meta' un'ingegneria, per meta' una scienza sociale...
E adesso basta, senno' diventa un'intervista al sottoscritto e nessun altro dice la sua! :)
-LV
Ciao Andrea,
ReplyDeleteanch'io sto leggendo Pragmatic Thinking and Learning e lo trovo stupendo ...
Per quanto riguarda il mio metodo di studio ti segnalo piuttosto quello che è il suo maggior difetto (e ne riduce l'efficacia): porto avanti troppi argomenti contemporaneamente, e questo crea notevole dispersione (dovrò usare una kanban board anche per le mie letture con un wip limit non superiore a 3/4). Purtroppo lo faccio un pò per indole e un pò perchè ho organizzato il mio rapporto con i clienti in modo "insano"; sto vedendo di riorganizzarmi. Certo invidio i 2-3 mesi di studio di Ludovico; se potessi fare 2-3 settimane sarei già felicissimo!
Per il resto preferisco anch'io i libri, ma a volte (a causa anche della dispersione citata sopra) mi consentono di spaziare troppo poco (non ho tempo di leggere tutti quelli che vorrei, e ho famiglia!) e ricorro ad altri strumenti (webcast soprattutto). In questo ambito devo dire che il mio adorato kindle sta cambiando un pò le cose: è favoloso per una lettura forward-only, senza troppi passi indietro e ripensamenti. In questo modo riesco a fare una prima passata veloce tanto per avere un primo orientamento, e anche i manuali sono "meno pesanti".
Quanto alla questione "teoria e/o pratica": pensare ad una sola delle due senza l'altra è molto limitante. Purtroppo la scuola italiana ci ha abituati a dover conoscere tutta la teoria prima di cominciare ad operare. Se ad ingegneria facessero i corsi per la patente di guida studieresti tutta la chimica e meccanica del motore e gli ultimi 5 minuti dell'ultima lezione, tempo permettendo, ti direbbero che per partire devi accelerare mollando la frizione. Per i più fortunati ci sarebbe anche un'auto con cui provare. Tu andresti in giro con patentati di questo tipo? Io no ... Quando ne discuto con i prof. universitari mi dicono che l'università non deve essere vincolata ad una tecnologia specifica, come dire che a scuola guida non facciamo pratica per non vincolarci ad un'auto specifica!
Da questo punto di vista non ci sono dubbi: teoria e pratica si corroborano a vicenda, e il metodo più efficace consiste nell'abbinarle passando continuamente da una all'altra (ma le iterazioni di xp con continua analisi/implementazione ci dicono nulla?).
Ciao!
I miei metodi per apprendere sono: libri, webcast, blog, codice scritto da altri (tipo progetti open, ma non solo) e pratica.
ReplyDelete>Qual e’ il vostro modo efficace di apprendere?
Nel mio caso la pratica è sicuramente quello più efficace.
Con pratica intendo, progetti reali, progetti di prova, test di snippet, ecc ecc
>Come e’ evoluto nel corso degli anni?
Prima davo molto più peso a blog e conferenze (in termini di sessioni), ora un po' più ai libri e conferenze (in termini di scambio di conoscenze). Il codice di blog/libri/forum è pericoloso, molto pericoloso (anche se mio), nella maggior parte dei casi bisogna capire qual'è l'intento di quel codice e poi va riscritto. I libri teorici, tipo design pattern, vanno letti con calma, ragionando su ogni singola frase (chiedendosi cosa vuole dire l'autore con questo?) e vanno letti almeno due volte (infatti mi sono imposto di non coprare per un po' nuovi libri ma di rileggere tutti i vecchi). Spesso la "verità" è già in "mano nostra" ma non lo sappiamo.
>Quanto tempo extra-lavoro dedichi all’apprendimento?
Non ho una quota fissa, diciamo tutto quello che posso dedicare :D.
Provo a dedicare un ora al giorno per i giorni lavorativi.
Se prendo il treno per andare dai clienti il viaggio lo spendo solo per lo studio mai (o quasi) per il lavoro.
Se vado al mare studio. Il Sabato se non lavoro e mi va di studiare studio, altrimenti svago.
Io non sono un grande studioso, anzì direi proprio l'opposto, quindi devo essere in "fase" altrimenti è solo una perdita di tempo.
Certe volte anche la sera dopo cena, diciamo che mi rilassa.
>Il mio manager dice che e’ solo una questione di esperienza ma non condivido la sua affermazione. Voi?
Attenzione che l'esperienza va rinnovata continuamente altrimenti rischia di diventare obsoleta, a quel punto sei del gatto. :D
Molti dev senior credono di averle "viste tutte" di essere in grado di sviluppare qualsiasi cosa.
Per me un senior è in grado di analizzare una soluzione e di vederne altre "mille" diverse.
Quella "esperieza" che dice il tuo manager, personalmente, credo che sia la stessa che ti fa sviluppare con WPF come se fossero le WinForm. Infatti sono al 100% d'accordo con la frase che hai quotato a fine post "...it's the constant learning that counts."
Ti capisco quando dici: "Spesso in azienda sei costretto a compiere decisioni con una conoscenza incompleta mentre a me spesso piace un approccio graduale all’apprendimento che al lavoro non e’ quasi mai praticabile."
Questo aspetto impatta moltissimi fronti come metodologia e tecnologia.
Ci sono delle scuole di pensiero "stile la tua" ed altre che dicono "embrace uncertainty".
Qual è quello più efficace?? booooo :D dipende da molti fattori ovvero dal contesto (è sempre colpa sua ;).
Personalmente in certi casi preferisco una conoscenza completa in altri va benissimo una incompleta.
Ciao!
> Libri: solo se entro le 200 pagine, in pdf da scorrere con gli occhi. Tanto i mallopponi cominciano con 4 capitoli che in genere sono cose che già conosco. 10%
ReplyDelete> Webcast e video corsi: AppDev, MSDN, Pluralsight. Si anche a pagamento. Ne guadagno in tempo vita. 60%
> Provare snippets trovsati qua e la, blog e non, i sorgenti dei libri della apress e dei webcast stessi. 20%
> Parlare con i colleghi e arrivare subito al dunque facendosi commentare il loro codice, se lo ritengo valido. 120%
;)
Grazie per i vostri commenti, speriamo che ne arrivino altri.
ReplyDeleteRiporto qui i feedback che ho trovato piu' interessanti e su cui posso lavorare:
1. Imparare a leggere MSDN
Onestamente uso MSDN molto poco e spesso perche' cercando su google ci capito sopra. Non l'ho mai usata come fonte primaria di apprendimento ma solo per vedere i dettagli di un metodo/proprieta'. Qui Ludovico deve ancora spiegarci cosa intende per "imparare a leggerla" :)
2. Studiare non semplicemente leggere
Questo e' vero ma non sempre facilmente praticabile. Il problema e' sempre la memoria, col passare del tempo si dimentica.
3. Studiare piu' possibile ora finche' non hai famiglia
Io sono fidanzato a distanza con una ragazza italiana che amo molto.
Ora quindi ho tutto il tempo che voglio per studiare.
Quale sara' l'impatto di famiglia e figli?
Anche a me questo spaventa.
Avro' ancora tempo per studiare?
Come vi siete organizzati "voi" che avete famiglia?
4. Non separare studio e lavoro
Questo punto lo vedo molto difficile ma mi e' piaciuto il commento di LV: *non* scindere le due cose, e quando devi affrontare un argomento nuovo prenditi i tuoi tempi e spazi, senza neanche stare a chiedere autorizzazione a nessuno, cioe' va vista come parte *integrante* del lavoro e della pratica quotidiana, non come un tempo extra.
5. Non esagerare col portare avanti troppi argomenti contemporaneamente
Caro Daniele, questo e' uno dei miei principali problemi. Mi piacciono troppe cose e vorrei impare tutto il piu' velocemente possibile. Credo che un modo per aiutarmi a restare focalizzato sono le certificazioni. Nel momento in cui studio per una, mi dedico quasi esclusivamente a quella.
6. Kindle forever
Gia' ora utilizzo il Kindle e non posso piu' vivere senza. E' troppo bello portarsi in giro la propria biblioteca e quando hai bisogno di accesso diretto all'informazione puoi usare il Kindle PC.
7. Progetti Open Source
Qui e' un punto carente per me. Me lo sono promesso gia' da diverso tempo ma non ho ancora incominciato a farlo. Devo leggere e imparare da progetti open source, vedere come altri fanno design, riconoscere pattern, trarre spunto, ecc ecc.
Interessante l'idea di cercarsi progetti open sorce in cui hanno collaborato guru e persone che stimi per vedere come loro scrivono. Non e' facile da applicare ma e' una bella idea.
8. Piu' pratica, non necessariamente progetti completi
Su questo non c'e' dubbio. Come sempre e' una questione di tempo.
Piu' conoscenza orizzontale o piu' conoscenza verticale?
9. Sfruttare le conferenze per scambiarsi conoscenze
Vedere le conferenze come una forma di stimolo e di scambio di conoscenze piu' che come un momento di formazione tecnica.
10. Meno libri ma letti e "studiati" piu' a fondo (es Design Pattern) e letti piu' volte
Anche qui e' una questione di tempo ma sono d'accordo con Matteo. Ci sono certi libri che quando arrivi alla fine senti che devi ricominciare e in cui riscopri nuove cose rileggendoli. Questo punto si collega alla mia tendenza alla dispersione a cui devo stare attento.
11. Videocorsi a pagamento
Non conoscevo Pluralsight. Sono molto curioso di provarlo
Grazie a tutti,
inutile dire che la community e' una delle fonti principali di crescita personale e professionale
> Non l'ho mai usata come fonte primaria di apprendimento ma solo per vedere i dettagli di un metodo/proprieta'. Qui Ludovico deve ancora spiegarci cosa intende per "imparare a leggerla" :)
ReplyDeleteNeanch'io la definirei una "forma di apprendimento", e' semplicemente la documentazione ufficiale. Un'analogia: quando compri un video-registratore, se leggi le istruzioni magari spendi mezz'ora ma poi ne sai usare tutte le funzionalita', se ti metti semplicemente a smanettare magari in mezza-giornata riesci a fare le due cose che ti vengono in mente di farci... Ovviamente nel caso delle tecnologie con cui lavoriamo la mezza giornata e' piuttosto una decina di anni, ma sempre per fare le due cose che ti vengono in mente di fare... :) "Imparare a leggerla" significa alla lettera imparare a leggerla: l'unica cosa che posso aggiungere su questo e' che se uno inizia a consultare la documentazione *sistematicamente* e non solo per caso, dopo qualche settimana tutto diventa piuttsoto chiaro: come e' organizzata, come e' scritta, e dove stanno le cose che ti servono quando ti servono. Provare per credere...
> Piu' pratica, non necessariamente progetti completi
Su questo punto mi sentirei di dare un'avvertenza: l'80% per cento dello sforzo si spende nel 20% finale del progetto. Non e' una regola d'oro, presuppone che non si sia lavorato troppo bene nel primo 80%, ma il punto importante che vorrei segnalare e' che *chiudere* un progetto non e' affatto facile e richiede molta attenzione e impegno. E' fin troppo facile accozzare un po' di cose, farsi un'idea di massima, e passare oltre: la realta' della produzione industriale/professionale e' pero' un'altra, e *chiudere* i progetti e' un'arte in se'.
Grazie a te e a tutti gli altri per lo scambio di idee: il video di Robert Martin mi e' piaciuto parecchio, non lo condivido al 100% (e quando mai!) ma vale sicuramente la pena...
-LV
P.S. Semmai consiglierei progetti piccoli ma sempre completi...
ReplyDelete-LV
Qual e’ il vostro modo efficace di apprendere?
ReplyDeletePer imparare tecnologie informatiche diciamo "teoria in contemporanea alla pratica": invece di leggere un libro dall'inizio alla fine e poi esercitarmi, mi esercito alla fine di ogni capitolo/paragrafo che voglio verificare di persona.
L'acquisto del libro però in genere parte dopo aver sondato il terreno leggendo articoli, visionando webcast, etc..
La metodologia cambia in altri settori e non si applica a tutto anche nelle tecnologie informatiche.
Oltre al metodo efficace di apprendere poi entra in gioco il "modo efficace per persistere", di importanza maggiore nel lungo termine.
Come e’ evoluto nel corso degli anni?
Internet ha rivoluzionato il modo di cercare le informazioni: blog, forum, ebook etc.. rendono veramente semplice sovraccaricarsi di informazioni e la sindrome del "finire il piatto di pastasciutta" diventa pericolosa.
La sindrome del "finire il piatto di pastasciutta" consiste per l'appunto nel finire il piatto anche se siamo pieni perchè ci dispiace buttare la pasta avanzata. Applicata ad internet significa cercare di leggere tutto, applicata ai libri significa leggere dalla prima all'ultima pagina. Per superarla ci vengono in aiuto le tecniche di lettura veloce anche se bisogna stare molto attenti perchè la sindrome cerca di riapparire se è insita nel nostro profondo. Il Kindle può secondo me aiutare a superare la sindrome.
Non sono pienamente d'accordo riguardo ai progetti open source come metodi efficaci di apprendimento. Per il momento senza dilungarmi dico che non sempre è un metodo efficace ed efficiente. Sono comunque un ausilio per diventare guru in determinati settori, sopratutto se di una certa complessità.
Commento ora alcune affermazioni, questi commenti naturalmente non sono da prendere "sul personale" ma è semplicemente la mia opinione.
ReplyDelete-I libri per la teoria e la documentazione *ufficiale* per i dettagli tecnici.
Aggiungo che durante lo sviluppo utilizzo occasionalmente anche Reflector per ovviare a "buchi" nella documentazione (es. classe AsyncOperationManager, etc...), per i dettagli tecnici però non escludo blog e forum (lo spiego più avanti).
Non sapevo che alcuni partner dispongono di una documentazione maggiore e non mi sembra molto fattibile legalmente, scusate se dubito fortemente di questa affermazioni ma servirebbero delle "prove".
Per quanto riguarda "leggere la documentazione" non lo trovo così complicato. All'inizio c'è da capire come è organizzata, una volta scoperto ad esempio che nell'overview di una classe c'è la descrizione generale (e spesso esempi) e quindi se la spiegazione di un metodo non è chiaro bisogna andare li, che ci sono sezioni più generali oltre alla documentazione reference delle classi, che per le Win32 ci sono certe abbreviazioni, etc.. risulta di consultazione agevole.
In alcuni casi esistono lacune e basandosi solamente sulla documentazione si rischia di bloccarsi o comunque si impiega più tempo a capire le cose, bisogna riconoscere velocemente queste situazioni e passare ad un altro "media", una ricerca globale su Internet in questi casi è un modo molto più rapido, se poi da li finiamo su un altra pagina di MSDN library tanto meglio.
-blog e forum, salvo poche eccezioni, meglio lasciarli perdere perche' e' piu' disinformazione che altro.
Non sono assolutamente d'accordo, trovo il loro ausilio praticamente essenziale nella pratica per risolvere rapidamente e in breve tempo alcune problematiche, in genere quando sono bloccato cerco con un motore di ricerca e nella maggioranza dei casi finisco su blog di persone che hanno avuto il mio stesso problema e spiegano come l'hanno risolto.
Aggiungo che i forum specializzati/Microsoft e alcuni siti di answer (es. stackoverflow) sono una risorsa incredibile in quanto le risposte che si ricevono sono assolutamente professionali ma gratuite. L'unico contro può essere che la risposta può arrivare qualche giorno dopo o può richiedere una sorta di dialogo se la domanda non è chiara o la situazione particolarmente complessa.
-... al prof gliel'ho dovuto spiegare io cosa era un puntatore doppio perche' non riusciva a capire il mio compito, e si trattava di un semplice algoritmo di ricerca in un albero.
Non posso giudicare a priori un professore per una cosa del genere, magari non è ordinario e il suo ambito di ricerca è molto lontano dal C/C++. Ti assicuro che ad Ingegneria ci sono persone molto brave.
-Quanto agli smanettoni ritengo senza mezzi termini che siano i veri nemici della nostra professione e la vera ragione per cui nessuno ha piu' rispetto per quello che facciamo, la vera ragione per cui il 90% dei sistemi fa schifo a dire poco, e la vera ragione per cui oggi guadagno il 50% di quello che guadagnavo ad inizio carriera.
In parte possono aver contribuito ma ti assicuro che la lettura del libro "Perchè il software fa schifo" mi ha aperto gli occhi. Non scaricherei sugli smanettoni tutta la colpa. Spesso sono proprio i cervelloni che complicano le interfacce grafiche rendendo inusabile per una certa categoria di utenti il software. Ad ogni modo una discussione approfondita dei problemi dell'informatica non è trattabile in un commento, quindi non entrerei nel merito.
> Ti assicuro che ad Ingegneria ci sono persone molto brave.
ReplyDeleteAnche alle poste ci sono brave persone.
Caro Leonardo, come si dice dalle mie parti: anche le pulci hanno la tosse! Ma ti do ragione, meglio non entrare nel merito.
-LV
Dubito esista una ricetta universale. Io non ne ho una e sarei ben felice di conoscerla.
ReplyDeleteCredo anche che dipenda anche molto dalle proprie esperienze passate. Per esempio ancora oggi il fatto di aver studiato e usato a fondo tutto ciò che c'era dentro il DOS è certamente un bagaglio culturale su cui appoggiare lo studio delle novità. In sostanza si fa prima ad imparare ciò che c'è di nuovo, si intuisce più facilmente il meccanismo di funzionamento di una nuova tecnologia.
Per il resto credo che la lista (libri, articoli, esperienza sul campo, etc.) sia già stata espansa a sufficienza. A mio avviso sbattere la testa sul codice resta sempre il modo migliore per rendere permanente ciò che si è imparato.