October 2006 - Posts
Riflettevo stamattina davanti al caffè sul ruolo del docente.
Soprattutto sul fatto che a volte ciò che si ritiene più "avanzato", quindi difficile, quindi materia per pochi, in realtà sia la parte più semplice da illustrare.
Mi spiego con un esempio: parli in aula di CLR, gestione della memoria, algoritmo di GC, generazioni, GC concorrente, man mano ti puoi spingere in là, per lo meno fin dove arrivano le tue conoscenze.
Tendenzialmente ti fermi ad un certo punto, sintetizzi, dici "qui il runtime fa così, non entriamo nel dettaglio per non complicarci la vita, ...".
E l'aula se ne sta.
Dopo magari ti capita, in altro contesto, di parlare con un "non-tecnico" dei rudimenti della programmazione.
E lui non se ne sta mai, dannazione.
"Ma perchè è così ?", "Ma chi lo dice al computer di fare sta roba ?".
Insomma, ti sta chiedendo cos'è una variabile, sarai in grado di illustrare il concetto, sarà più facile che parlare di algoritmi di GC !
Ma diavolo, no !
Intanto perchè hai di fronte un "pubblico" che non è del mestiere.
Non puoi dare per scontate le cose, ma neanche quelle più basilari.
E allora scopri che poi queste "basi" tanto semplici non lo sono, da capire e da spiegare.
Ed è interessante perchè, nel momento in cui ti sforzi di trasmetterle a persone che non ne hanno nozione, ti trovi ad indagare le ragioni dietro quegli assiomi che ormai, nel momento in cui specializzi le tue conoscenze, sei costretto a dare per assodati.
Sì sì, i concetti li hai, solo che accidenti, come fai a trasmetterli ?
Qual è, questa volta, il punto in cui puoi dire "non entriamo nel dettaglio per non complicarci la vita" ?
Sei capace di spiegare cos'è un'applicazione in termini di transistor ? Devi farlo o è un'inutile approfondimento ?
Urca, e pensare che dovevi solo dare una definizione di "ciclo for" !
Qui sta secondo me la bravura del docente.
Nella sintesi, nell'inquadramento, nella scelta del contesto, dei suoi limiti, dei suoi postulati.
E queste sono qualità che vanno ben al di là del "tecnico", della GC concorrente, del Virtual Dispatch, della Pipeline ASP.NET, ... insomma, metteteci il dettaglio più nascosto della più recente tecnologia.
Appena rientrato dal ristorante e in attesa di accasciarmi sul letto in albergo, scrivo questo post per fissare un pensiero che mi si è materializzato in testa durante la giornata odierna (passata molto piacevolmente ad assistere al workshop Architecture Days organizzato da UgiDotNet) e che, presumibilmente, domattina non sarà più così chiaro ed evidente (prevengo la domanda e ... no, non ho assunto sostanze stupefacenti).
Il pensierino della ninna è questo - nel seguito uso il plurale perchè mi è rimasto da oggi un buon sapore di community.
Noi (architetti ? sviluppatori ? solution designer ?), noi insomma, che studiamo i linguaggi e le piattaforme di sviluppo, le metodologie, i modelli e le best practices, noi che insegniamo queste cose, o che a nostra volta le impariamo leggendo un libro o seguendo una conferenza, noi che pensiamo e ripensiamo a come realizzare una BELLA applicazione (sì sì, intendo dire bella, perfino con un'accezione estetica), noi che ci facciamo in 4 per evitarci un "bagno di sangue" e non solamente perchè non sappiamo nuotare, noi che magari ci scarichiamo le versioni beta del .NET Framework vNext.Next.Next e le proviamo di notte perchè durante il giorno scriviamo stored procedures in PL/SQL o interfacce utente in MFC (senza nulla togliere ...), beh, sapete che vi dico: che facciamo un gran bel mestiere !
Oggi ho riassaporato alcuni aspetti del mio lavoro che spesso rischiano di passare in secondo piano, soprattutto quando la routine del quotidiano ti fa dimenticare lo scopo per cui hai scelto di scrivere, progettare, insegnare software.
Che è diverso (o, almeno, non è necessariamente uguale) alle "implementazioni" pratiche e lavorative delle tue aspettative.
Le quali non ti devono MAI far dimenticare l'essenza delle cose a cui aspiri.
Ho appena iniziato ad esplorare VSTS/TFS quindi, in attesa di provare le cose ed esprimere dei giudizi in merito, per ora mi limito a segnalare le news e i consigli che leggo in giro.
Intanto questo, di
Lorenzo Barbieri, sull'utilizzo di TFS come SCC anche da Visual Studio 6.
Dal
forum di UGIDotNet: http://forum.ugidotnet.org/b.asp?m=61898
Update
Bastava un po' di ricerca in più per trovare
questo webcast, tenuto dallo stesso Lorenzo. Online c'è la registrazione dell'evento.
Un paio di giorni fa ho avuto una discussione interessante con un mio amico (nonchè sviluppatore), durante un breve viaggio in treno.
Discussione piuttosto di ampia portata, di cui però riporto un estratto specifico.
Contesto: lui sta sviluppando un'applicazione, abbastanza complessa, sia dal punto di vista architetturale che da quello puramente "algoritmico": multi-tier, calcoli matematici piuttosto pesanti, ecc...
L'osservazione sulla quale ci siamo trovati d'accordo è che l'utente finale (e di conseguenza il cliente, che può coincidere con l'utente o essere un suo fornitore) ha una percezione completamente diversa della complessità di un sistema software rispetto alla nostra (noi == "i programmatori-analisti-blablabla").
Innanzitutto difficilmente l'utente è in grado di differenziare i componenti di un'applicazione: un client-server monolitico e la UI di un sistema ultra-stratificato si avviano sempre con un doppio click su di un'icona del desktop. Scusate l'estrema banalizzazione ma penso che rappresenti bene il concetto per cui l'utente ha, generalmente, conoscenze informatiche basse, o comunque non sufficientemente raffinate per riuscire a riconoscere le interazioni fra i tier del sistema che abbiamo disegnato ed implementato. (E non è tenuto ad averle, sia chiaro).
Corollario: il programma E' la sua interfaccia utente.
Corollario del corollario: modificare un algoritmo matematico complicatissimo ha un peso paragonabile all'aggiunta di una combo-box di lookup in una maschera.
Sto estremizzando.
Però seguitemi nel ragionamento ...
Ponendo sullo stesso livello attività così diverse, sia come difficoltà che, di conseguenza, come tempi necessari ad implementarle, si pongono sullo stesso livello gli sviluppatori che le realizzano.
Mi spiego meglio: il mio amico si lamentava del fatto che per realizzare gli algoritmi di cui sopra fossero necessarie conoscenze matematiche avanzate, ma che queste non fossero percepite dal cliente nel momento in cui questo compra il prodotto (e paga chi lo realizza).
Che, detta in altri termini, è: "Perchè io, che mi sono fatto il **** 5 anni all'università per imparare i misteri della matematica più avanzata, trovo un caso in cui senza queste conoscenze il problema è irrisolvibile, applico le mie conoscenze e lo risolvo, alla fine vengo valutato e pagato come uno che si legge in 2 settimane un libro su C#, si inventa programmatore riempiendo l'interfaccia utente di controlli colorati e disomogenei e mette qualche effetto speciale nel suo programma (tipo gli ErrorProvider controls, x esempio) ?
La risposta che gli ho dato io (che per inciso non ho neanche un decimo delle sue competenze in campo matematico e fisico) è che dipende tutto dalla percezione che il cliente ha del prodotto che gli si propone e che lui paga.
Credo che questo sia vero, ma se qualcuno avesse qualche obiezione per smentirmi, vi giuro, ne sarei veramente contento !!!