Conversazione con Jon Skeet: Il Chuck Norris della programmazione, su Yellow Duck Podcast

Pubblicato: Ultimo aggiornamento:

Sapevate che quando il codice di Jon Skeet non riesce a essere compilato, il compilatore si scusa? E il fatto che quando Jon fa una ricerca su Google, l'unico risultato è "Torno subito"? Fonte: Stack Overflow

Per chi non lo sapesse, Jon Skeet è un Senior Software Engineer di Google a Londra, Regno Unito. Sebbene alcune delle affermazioni più assurde su di lui debbano ancora essere verificate, ciò che è sicuramente vero è che è l'unico utente di Stack Overflow con una reputazione superiore a 1.000.000.

Dal 1998, questo ragazzo ha contribuito con oltre 34.000 risposte al sito, generando oltre 230.000.000 di visualizzazioni! Cosa chiedere a colui che ha già risposto a tutte le domande immaginabili?

Scopritelo ascoltando la nostra conversazione con Jon Skeet

Marcin Kraszewski ha avuto modo di sedersi con Jon e di chiedergli qualcosa di nuovo. È emerso che ha altre risposte da dare, tra cui alcune che non avete sentito da nessun'altra parte.

Avete sentito la storia di come Jon ha iniziato a sviluppare software costruendo un gioco per computer? E il problema più impegnativo che Jon ha dovuto risolvere come ingegnere?

La nostra conversazione verte su tutto questo, oltre che sui maggiori cambiamenti avvenuti nell'industria del software nell'ultimo decennio, su cosa usavano gli sviluppatori prima di Stack Overflow, su quanto ancora Jon intende contribuire a Stack Overflow, su un confronto tra C# e Java e sulle conferenze preferite da Jon.

Si tratta di un'opportunità unica nella vita per partecipare a un'esplorazione casuale del percorso personale di uno dei nomi più famosi del software.

Potete seguire Jon qui:

Ma prima, ascolta la nostra conversazione con Jon sul Podcast di Yellow Duck

Di seguito troverete la trascrizione scritta della nostra conversazione.

MARCIN: Ok, benvenuti a The Yellow Duck Podcast, oggi ho con me un ospite molto speciale. Parlerò con Jon Skeet, se non sapete chi è Jon Skeet, è uno dei maggiori contributori di Stack Overflow, forse addirittura il maggiore contribuente di Stack Overflow, che è, se non conoscete Stack Overflow, una cosa incredibile. Si tratta di un sito web dove è possibile ottenere risposte a quasi tutte le domande, non solo relative allo sviluppo di software e alla tecnologia, ma anche a Stack Exchange, che è il sito madre di Stack Exchange e dove è possibile ottenere risposte a domande su qualsiasi argomento, dalla commedia improvvisata all'astronomia e alla scienza. Quindi Jon, benvenuto.

JON: Grazie mille. È un piacere essere qui.

MARCIN: Grazie per esserti unito a me nel podcast di Yellow Duck. Ho un po' di cose da chiederti. Prima di tutto, però, vorrei arrivare alla domanda numero uno, che è un po' nella mia mente. Ho fatto un po' di ricerche sulla tua attività su StackOverflow, che è famoso in tutto il mondo e molto esteso. La mia domanda è che lei ha risposto alla sua prima domanda su Stack Overflow il 26 settembre 2008, alle 12:11, secondo le informazioni che sono riuscito a ottenere. Mi parli delle circostanze che hanno portato a quella prima risposta e sappiamo come ha fatto a rispondere. Come hai iniziato a usare Stack Overflow. Come hai ottenuto quella risposta. Come sei arrivato a rispondere a quella risposta. Come è iniziato tutto, insomma.

JON: Quindi, in un certo senso, è stato un esercizio di narcisismo. Ho sentito parlare per la prima volta di Stack Overflow sul blog di Sara Chip. Aveva scritto una recensione della prima edizione di C# in modo approfondito nel 2008, il che sembra essere passato molto tempo, e ho letto la sua recensione e poi ho letto alcuni altri post del suo blog che menzionavano Stack Overflow. Così ho pensato di dare un'occhiata e ho cercato su Stack Overflow le domande a cui rispondere. Non avendo molta idea di cosa fosse il sito, ho cercato domande approfondite su C#, in particolare se ce ne fossero, e c'erano alcune menzioni qua e là, ma c'erano domande su C# e ho pensato: "Posso rispondere a questa domanda, quindi risponderò" e da lì è partito tutto. In precedenza avevo scritto molti newsgroup, sia su C# che su Java Newsgroup, nel decennio precedente, quindi questo sembrava essere un passo avanti nell'evoluzione di questi newsgroup. Non mi era mai piaciuto il software per forum basato su HTML. Per varie ragioni, ma niente mi è stato utile come i newsgroup, mentre Stack Overflow ha cambiato completamente le cose.

MARCIN: Fantastico e siamo tutti molto grati per il tuo contributo. Credo che tu abbia risposto a più di 35.000 domande, un contributo straordinario per la comunità. Quindi, ovviamente, ti siamo tutti molto grati per questo. E penso che sia davvero interessante che tu abbia iniziato, in un certo senso, come hai detto tu stesso, come utente generico che ha appena scoperto il suo sito web e ha deciso di rispondere alle domande, puoi passare alla seconda, alla terza, alla quarta e alle centinaia di domande successive, quando hai sentito che questa era davvero una cosa che volevi fare. Magari con un focus specifico su Stack Overflow, ma in generale. Quando hai sentito questa sorta di passione per rispondere a molte di queste domande, come se avessi questa energia.

JON: quindi è iniziato più o meno 10 anni prima, quando ero ancora all'università e rispondevo alle domande su Java nei newsgroup molto prima che C# fosse in circolazione e partecipavo a discussioni che non sono così rilevanti per Stack Overflow, ma postavo moltissimo nei newsgroup Java e in gran parte si trattava del fatto che mi piaceva aiutare le persone, e questo non è puramente altruistico. Mi piace aiutare le persone perché mi migliora come programmatore, mi migliora decisamente come comunicatore, cosa che ritengo sia incredibilmente importante nell'ingegneria del software, e poi c'è l'effetto di aiutare non solo la persona che ha posto la domanda, ma, si spera, anche le persone successive, che è ciò per cui Stack Overflow è davvero ottimizzato. E credo che alcuni dei problemi per cui le persone fanno domande sbagliate siano quelli di pensare solo al loro bisogno immediato, invece di pensare a come posso fare una domanda che mi aiuterà, ma anche ad aiutare le persone che arriveranno in seguito. Se si parte da questa prospettiva, la comunità di Stack Overflow si basa proprio su questo e il numero di impressioni che le buone domande possono ottenere è enorme, così si può aiutare l'intera comunità mondiale di programmatori.

MARCIN: Sicuramente. Si tratta di un'idea grandiosa che, come sai, credo fosse davvero qualcosa che doveva essere creato. Le persone erano pronte a condividere le loro conoscenze e Stack Exchange e Stack Overflow sono stati creati proprio in tempo, come hai detto tu, c'erano altri modi per condividere le conoscenze. Ma credo che questo sia forse il più accessibile per tutti gli utenti che vogliono avere una risposta alle loro domande. È un modo molto efficace e credo che sia anche ben moderato, almeno per quanto riguarda i follower locali.

JON: sì. Il grado di moderazione è sicuramente un punto dolente per molti utenti, e non solo per alcuni, che hanno provato a fare una domanda e l'hanno fatta male, senza fornire abbastanza dettagli o con troppi dettagli. Ci sono infiniti modi diversi in cui si può porre male una domanda e ritengo che la moderazione sia uno dei punti di forza del sito, che cerca di mantenere alta la qualità del sito e di renderlo il più utile possibile, ma è sicuramente un punto dolente e penso che ci sia del lavoro da fare in termini di comunicazione degli obiettivi del sito, in modo che tutti possano tirare nella stessa direzione. Non è che qualcuno. Beh, sono sicuro che ci sono alcune persone che fanno domande sbagliate di proposito o che moderano in modo cattivo solo per il gusto di farlo. Ci sarà sempre qualche stronzo in giro, ma tendo a pensare che la maggior parte delle persone non sia stronza. Si comportano in modo gentile, dedicano il loro tempo e vogliono un sito di alta qualità.

Se riusciamo a fare in modo che tutti siano allineati, l'esperienza sarà migliore per tutti. Quindi c'è ancora un po' di lavoro da fare in termini di comunicazione e di tutti i tipi di cose che possono essere molto difficili perché se siete bloccati su un problema immediato e non vi siete mai registrati o avete fatto una domanda o altro su Stack Overflow prima d'ora la vostra prima tentazione è quella di vedere un muro di testo che vi dice che questo è il tipo di domanda che dovreste fare e come dovreste affrontare le cose e voi pensate semplicemente e pensate: "Non mi interessa, voglio fare subito la mia domanda", mentre in realtà se vi prendete cinque, dieci minuti o anche mezz'ora per navigare nel sito, consultando le varie risorse di aiuto, ho scritto un lunghissimo post sul blog: "Ecco cosa cerco in una domanda", che ha lo scopo di aiutare le persone a fare domande, ma posso capire la frustrazione e il motivo per cui le persone saltano tutto questo e lo dicono subito. Permettetemi di fare la mia domanda ora. Presumo di sapere cosa sto facendo ed è molto spiacevole che questo dia loro un'idea dell'esperienza e se le persone non leggono l'aiuto che è stato dato loro, allora nessun miglioramento in quell'aiuto può davvero superare il fatto che non lo stanno leggendo. Quindi è difficile

MARCIN: La cosa interessante di Stack Overflow sembra essere che almeno al momento so che tutti i dati di Stack Overflow sono disponibili. È possibile scaricare l'intero set di dati e questo è importante.

JON: Assolutamente sì. Sì, e questo è stato un obiettivo fin dal primo giorno.

MARCIN: Pensi che sia una parte importante del fatto che Stack Overflow continui a essere popolare.

JON: non lo so, è sicuramente una funzione. È bello che, ad esempio, tutte le domande di Stack Overflow siano state importate in Google BigQuery, il che significa che le persone possono eseguire query su tutti i tipi di dati e c'è Stack Overflow. Anche gli strumenti di analisi dei dati sono disponibili in questo modo e quindi è possibile fare ogni tipo di data mining sulle domande di Stack e diversi data scientist hanno fatto proprio questo. Quindi è molto interessante su questo fronte. Si crea anche una sorta di fiducia nel fatto che Stack Overflow non è il proprietario dei vostri contributi. Tutti lo fanno, hanno una licenza appropriata, quindi anche se Stack Overflow come azienda fallisse, le informazioni non andrebbero perse, ma non so quanto sia importante, credo che la sua importanza vari a seconda di chi lo chiede, ma l'importanza per la comunità delle scienze dei dati. Sospetto che, non essendo un membro di quella comunità in particolare, sia stata una vera e propria miniera di tesori.

MARCIN: Ho sentito parlare di alcuni progetti che cercano di utilizzare Stack Overflow per addestrare un algoritmo di apprendimento automatico a scrivere software o almeno a eseguire il debug di un software, e questo è sicuramente un uso interessante dei dati. Per quanto riguarda Stack Overflow, ad esempio, probabilmente ci sono molte domande che sono davvero molto simili e quasi uguali, ma non del tutto. Pensa che nel prossimo futuro si possa trovare una soluzione, magari utilizzando l'apprendimento automatico o qualcosa del genere, per ridurre in qualche modo la quantità di contenuti duplicati o quasi.

JON: Giusto, quindi Stack Overflow cerca già di trovare domande simili e le suggerisce mentre si pone la domanda: "Hai dato un'occhiata a queste cose? Pensiamo che siano simili". E anche dopo aver posto la domanda. C'è un elenco sul lato destro che mostra i potenziali duplicati o le domande correlate ed è relativamente facile chiudere una domanda come un duplicato, perché se si ha un tag d'oro, c'è un badge d'oro in un tag particolare, è possibile chiudere le cose guardando molto facilmente quello che viene chiamato il martello dei duplicati. È difficile perché l'apprendimento automatico non sarà mai accurato al 100%, quindi non si vuole impedire alle persone di porre domande. Anche se si sospetta fortemente che si tratti di un duplicato. È quasi necessario chiedersi se si è davvero sicuri. Hai davvero controllato tutte queste cose, ma non so, mi sembra che il problema sia un po' meno grave. L'aspetto dei duplicati rispetto a quello delle persone che fanno domande e non forniscono abbastanza informazioni o il giusto tipo di informazioni per poter dire se si tratta di un duplicato o meno. E spero che. So che Stack Overflow ha avuto qualche iterazione di una sorta di procedura guidata per porre domande del tipo: "Che aspetto ha il tuo codice, che linguaggi stai usando? Hai creato un esempio breve ma completo che dimostri il problema". Questo genere di cose. Non è chiaro cosa funzionerà esattamente, ma so che il team sta lavorando duramente per migliorare l'esperienza delle domande, perché fondamentalmente Stack Overflow si basa sul fatto che vengano poste buone domande.

MARCIN: Sicuramente e perché presumo che ci saranno sempre domande da porre, indipendentemente dalla tecnologia e dalla sua durata. Qual è la ragione principale? Qual è il motivo che spinge a porre sempre nuove domande, anche sul C#, al quale, come ho già detto, lei ha risposto, insieme a vari altri argomenti, a 35.000 risposte, ma ce ne sono sempre di più. Credo che questo faccia parte della natura dell'ingegneria del software e che non si possa astrarre tutto.

JON: In parte è dovuto al fatto che il linguaggio sta cambiando, quindi attualmente sto scrivendo su C# 7.2 e devo imparare nuove cose per poterne poi scrivere. Quindi sarebbe del tutto naturale che le persone facessero domande su C# 7.2 o su altre cose che sono abbastanza nuove, perché C# 7.0 è ancora abbastanza nuovo. Quindi, con l'evoluzione dei linguaggi, dei nuovi framework, delle librerie e di tutti i tipi di cose. Ci saranno sempre nuove aree su cui fare domande. E poi ci sono persone che fanno domande su aree già esistenti e alcune di queste domande saranno nuove, altre non saranno nuove e altre ancora potrebbero essere nuove domande mascherate. Per esempio, in C# il modo esatto in cui le espressioni lambda catturano le variabili, in particolare per ogni iterazione, cambia in C# 5 e questo ha causato un sacco di domande prima di C# 5 quando non era ideale il modo in cui funzionava. Molte di queste domande sono effettivamente dei duplicati, ma in realtà ho risposto a molte di esse perché ce ne sono molte che non sembrano ovviamente correlate. È solo quando si conosce la risposta che si può capire che queste due cose sono lo stesso problema solo sotto mentite spoglie. Quindi ci saranno sempre cose in cui solo chi risponde sa che in realtà si sta affrontando lo stesso problema di qualcun altro e se queste domande dovrebbero essere chiuse come duplicati è probabilmente una questione da discutere. Ma sì, ci saranno sempre nuove persone che si avvicinano all'ingegneria del software, il che è una cosa fantastica, e alcune di queste credo stiano trattando Stack Overflow come una risorsa di apprendimento. Li incoraggerei a farlo. Penso che Stack Overflow sia una grande risorsa per la risoluzione dei problemi. Non è un ottimo modo per imparare un linguaggio da zero, non si può prendere un compilatore Java o anche un IDE e Stack Overflow e imparare Java da zero in questo modo. Non è un modo efficiente di imparare il linguaggio. Invece un libro o un tutorial è un approccio molto più strutturato e Stack Overflow è ottimo per questo. C'era questo esempio e mi aspettavo che facesse questo e invece ha fatto qualcos'altro. Ed ecco perché penso che dovrebbe comportarsi in questo modo e in realtà si comporta in modo diverso. Qualcuno potrebbe spiegare esattamente cosa sta succedendo? Questo tipo di domande è ottimo per Stack Overflow, quindi è sicuramente una sorta di complemento ad altri strumenti di apprendimento, ma non credo che sia ottimo come strumento di apprendimento iniziale. O come unico modo per imparare una lingua, ma ci saranno sempre persone che imparano le cose per la prima volta. E, come ho detto, se siete relativamente nuovi a una lingua o a una tecnologia, sarà molto più difficile per voi trovarla. Domande correlate, perché non è detto che si sappia esattamente a cosa si riferisce la domanda in quel momento, quindi non mi aspetto che l'insieme o il flusso di domande si esaurisca presto. Questo è dovuto in parte alle nuove persone, in parte alle nuove tecnologie e in parte ai vecchi utenti che fanno cose che non hanno mai fatto prima, per cui potrei ancora scrivere in C# e fare una nuova domanda su C# e circa la metà delle mie domande credo siano relative a C# stesso, il che potrebbe sorprendere le persone. Non c'è niente di meglio che conoscere un linguaggio ragionevolmente bene per essere consapevoli delle cose che vanno storte o che sono davvero inaspettate e quindi è davvero utile fare domande su Stack Overflow e dire: "Ehi, mi aspettavo davvero che questo accadesse e ho buone ragioni per aspettarmelo a causa di tutta la mia precedente esperienza, ma significa che qui si finisce per fare domande su tecnologie che normalmente non ci si aspetterebbe di fare".

MARCIN: E su Stack Overflow l'idea di trovare una risposta online è da quanto tempo parte integrante dell'ingegneria del software. In passato, infatti, si era costretti a ricorrere a un paio di bacheche e a un paio di newsgroup per la documentazione. Ma sembra che molti professionisti usino regolarmente Stock Overflow per molti dei loro progetti e probabilmente è per questo che Stack Overflow ha finito per affrontare la questione con le sue licenze, dicendo che si deve essenzialmente menzionare il fatto che si tratta di cicli da cui si è preso il codice. Quindi, secondo lei, come è cambiata l'ingegneria del software e Stack Overflow nel corso degli anni?

JON: Penso che l'ingegneria del software sia cambiata in parte perché stiamo usando più tecnologie e meno tecnologie ben documentate, quindi tutti usano librerie di terze parti a destra e a manca in questi giorni, o la maggior parte delle persone lo fa, e le librerie sono dotate di diversi gradi di documentazione e in una certa misura Stack Overflow ha quasi preso il posto della documentazione in alcune situazioni. C'era il progetto di documentazione di Stack Overflow, che alla fine è stato cancellato perché non funzionava bene per la situazione, ma certamente Stack Overflow fa sempre più parte del kit di strumenti quotidiani di un ingegnere informatico. E parte di questo è dovuto al fatto che Stack Overflow reagisce così rapidamente. Ricordo che nel 2008-2009, quando Stack Overflow era ancora molto giovane. Jeff Atwood diceva che a volte bisognava postare una domanda e aspettare 20 minuti per avere una risposta. E sono rimasto a bocca aperta pensando che 20 minuti sono un tempo incredibilmente breve. E ha ragione: se fai una buona domanda, di solito entro 20 minuti ricevi una risposta. E questo non era il caso dei newsgroup. Non so se sia solo per il numero di persone che leggono le cose o per il modo in cui il mondo si muove più velocemente, ma di certo si aspettava spesso un giorno intero prima di ricevere una risposta in un newsgroup, mentre in questi giorni tendo a scoprire che ci metto più tempo a scrivere una domanda di quanto ne serva per ricevere una risposta. Quindi raramente impiegherò meno di mezz'ora per scrivere una domanda, perché sto facendo ricerche, costruendo un esempio completo e ponendolo nel modo più chiaro possibile e tutto ciò richiede tempo. Ma certamente entro mezz'ora, quindi se mi ci è voluta mezz'ora per scrivere la domanda, meno di mezz'ora dopo ho almeno ricevuto commenti che dicono: "Sì, sembra strano. È una cosa nuova. Non sono sicuro di cosa stia succedendo qui o di una risposta effettiva che spieghi la soluzione al problema. Quindi sì, il fatto che sia a bassa latenza lo rende effettivamente molto più praticabile. E questo se dovete fare una nuova domanda. Il 90% delle volte che mi trovo di fronte a un problema per il quale Stack Overflow mi aiuta, non devo affatto porre la domanda perché qualcun altro l'ha già posta. Ho scoperto che, soprattutto in aree con cui ho meno dimestichezza, come Python o gli script Bash o qualcosa del genere, molto spesso faccio delle ricerche su Stack Overflow e trovo la risposta esattamente alla domanda che volevo. È fantastico.

MARCIN: Vi capita che le persone che hanno scoperto lo sviluppo di un'offerta e vogliono saperne di più, stiano solo imparando il primo linguaggio? Trovi che non investano abbastanza tempo nell'apprendimento del nucleo. Come ho detto, la documentazione di base e la conoscenza del linguaggio prima di rivolgersi a qualcosa come Stack Overflow?

JON: Penso che sia difficile dire quale sia la percentuale di persone che lo fa, ma sicuramente vedo alcune persone che lo fanno e non conoscono nemmeno il linguaggio e gli strumenti. Ma ritengo che nelle scuole e nelle università manchi l'insegnamento del processo diagnostico ed è per questo che ho una specie di sfuriata sul fatto che nel Regno Unito ci sono molti più corsi di informatica che di ingegneria del software e, per quanto io sia molto grato che ci siano corsi di informatica, abbiamo sicuramente bisogno di informatici. Probabilmente c'è più bisogno di ingegneri del software che non hanno bisogno di conoscere i dettagli del funzionamento di un compilatore, ma che avrebbero bisogno di un corso su come risolvere un problema e approfondirlo. E se non riuscite a risolverlo, ecco come chiedere informazioni. Che si tratti di chiedere ai colleghi o di chiedere su Stack Overflow o di trovare un bug o altro, si tratta di aspetti così semplici del processo diagnostico, che consistono nel non cercare di fare il passo più lungo della gamba. Se siete alle prime armi con un linguaggio, fate prima alcune cose semplici. Io tendo a scegliere qualcosa come le applicazioni per console, piuttosto che tuffarmi immediatamente nelle applicazioni web e nelle applicazioni per dispositivi mobili, ad esempio, il che dipende interamente dal linguaggio, naturalmente se si utilizza un linguaggio che è completamente rivolto allo sviluppo web, allora forse una console sarà impossibile, ma laddove possibile utilizzare l'ambiente più semplice possibile. L'ambiente in cui il debug vi aiuterà il più possibile, dove non avete bisogno di 100 righe di boilerplate solo per far funzionare due righe di codice, questo tipo di cose è davvero utile per prepararvi al successo in modo efficace, in modo da poter imparare un aspetto di un linguaggio, un aspetto di una libreria alla volta, piuttosto che annegare in un mare di ok. Ho 100 centinaia di righe di codice e non ne capisco nulla e mi viene dato un messaggio di errore che non capisco nemmeno io e non so da dove cominciare. Il problema è che si parte da un punto in cui c'è troppa roba che non si capisce. Quindi, in un mondo in rapida evoluzione, e sono colpevole di questo come chiunque altro, se cerco di imparare una nuova tecnologia, per quanto dica che vorrei iniziare in modo semplice. Spesso penso: "Ho solo una cosa da fare, quindi mi tuffo". Così faccio anche la cosa sbagliata, ma so abbastanza che se mi blocco faccio marcia indietro e provo a fare qualcosa di più semplice, ma in un mondo in rapido movimento è forte la tentazione di tuffarsi subito perché ho bisogno di fare qualcosa subito, ma trovo che sia molto più produttivo e a lungo termine fare un passo indietro e cercare di camminare prima di correre.

MARCIN: Vi siete mai trovati in una situazione, magari all'inizio della vostra carriera, in cui avete iniziato a risolvere un problema che era già stato risolto e poi vi siete resi conto che, in realtà, si trattava di una cosa risolta, si può semplicemente usare un'API o una libreria affidabile.

JONSì, e a volte sembra esserci una sorta di avversione per le librerie di terze parti. Un esempio classico è la manipolazione dell'XML, per cui si vedono persone che dicono: "Ho solo bisogno di fare l'escape degli ampersands, quindi userò le stringhe e costruirò direttamente l'XML", per poi scoprire che "Oh no, c'è un'altra cosa che causa un problema" e, prima o poi, ci sono centinaia di righe di codice che potrebbero essere completamente evitate se si usasse una libreria XML per iniziare e che sarebbe molto più robusta e sicura in tutti i tipi di cose. Quindi sì, le persone dovrebbero usare librerie di terze parti. Se le si sceglie con cura, però, ci sono anche un mucchio di librerie piuttosto scadenti. Ma la scelta di una buona libreria può fare la differenza in un progetto.

MARCIN: E lei direbbe che è qualcosa che si acquisisce con l'esperienza, che è quello che sto dicendo: la saggezza per essere in grado di dire se ho davvero bisogno di scrivere del codice per risolvere questo problema specifico.

JON: In una certa misura. È in parte una questione di esperienza e in parte una questione di trattenersi, perché se si vede che si può fare qualcosa e significa scrivere del codice e si pensa che sarebbe divertente scriverlo. Allora c'è sempre la tentazione di scrivere quel codice anche se non è necessario. E io ho sicuramente questa tentazione. Anche quando non dovrei e a volte scrivo uno strumento veloce in C# anche se non è il linguaggio più appropriato per usarlo, perché è il linguaggio che conosco meglio e quindi forse mi rende più efficace a breve termine. Forse a costo della produttività a lungo termine. Non credo che ci si debba preoccupare troppo. Non ci abbattiamo troppo per questo genere di cose, ma teniamole d'occhio. C'è molto da imparare facendo un passo indietro e osservando il proprio lavoro per capire dove sto usando molto tempo in modi che finiscono per non essere produttivi e come posso ridurlo un po' nel tempo, senza pensare che questo significhi che sono un pessimo sviluppatore e che dovrei abbandonare del tutto l'ingegneria del software. Cercate sempre di migliorarvi nel tempo.

MARCIN: Ottimo. Bene. Ora credo che quello che vorrei fare è provare a fare un po' di storia, ad esempio se potessi raccontarci la storia di quando tutti hanno iniziato a programmare. Qual è la tua storia di quando hai iniziato a programmare? Quando ti sei interessato a qualcosa come l'ingegneria del software o la programmazione o il coding o come vuoi chiamarlo in quel momento?

JON: Quindi era molto presto. Comprammo lo spectrum 48 K Sinclair di Aztec allo Spectrum quando avevo credo il 1984, quindi avevo otto anni. Lo Spectrum era uscito due anni prima, nel 1982, e all'inizio mi limitavo a giocare, poi ho iniziato abbastanza rapidamente a fare del semplice coding. Lo spectrum era dotato di un interprete BASIC integrato. Così, quando si avvia il computer, si può immediatamente iniziare a digitare il codice e il manuale dello spectrum in dotazione era molto buono per insegnare la programmazione, almeno quella di base. Ricordo che un giorno, quando mio padre era a casa perché per qualche motivo era malato, scrissi uno stupido gioco sparatutto che consisteva in una navicella spaziale probabilmente composta da alcuni caratteri ASCII e un alieno appariva in un punto a caso e tu muovevi la tua navicella in alto e in basso e poi premevi il tasto del fuoco o qualsiasi altra cosa, era assolutamente banale e per nulla divertente da giocare. Ma questa era la prima volta che scrivevo qualcosa di interattivo ed era incredibile la sensazione che mi dava. Credo che in parte sia dovuto al fatto che all'epoca tutti i giochi erano piuttosto grezzi: mi piacevano Jetpack e Lunar Jet Man, ecc. Ma si trattava di giochi piuttosto semplici, quindi il fatto che stessi scrivendo qualcosa di semplice non mi scoraggiò. Mi dispiace un po' per i ragazzi di oggi che, se seguono il mio consiglio e fanno qualcosa di molto semplice per iniziare, finiscono con un piccolo gioco di testo che magari ti chiede di indovinare un numero a caso e ti dice se stai diventando troppo alto o troppo basso, ecc. Beh, se si confronta questo con Overwatch o qualsiasi altro gioco a cui si sta giocando per divertimento. È piuttosto difficile capire come si colleghino, perché siamo lontani un milione di anni luce da una semplice cosa di testo alla grafica 3D che va avanti a grande velocità con la rete e ogni genere di cose. Ma allora era fantastico. Così scrivevo il mio codice in questo modo. C'erano anche riviste che contenevano elenchi da digitare. Quindi compravi un libro e invece di avere un nastro sul fronte con il codice che potevi semplicemente caricare, dovevi digitare tutto e i vantaggi di questo erano che sembrava immensamente noioso, ma stavi imparando tutto il tempo. Ecco come si può scrivere codice senza che sia particolarmente enfatizzato. Credo di averne tratto un grande beneficio e ricordo che uno dei miei primi progetti significativi fu la scrittura di un interprete Logo, che avevamo sui computer BBC Micro a scuola. Avevamo un interprete Logo in cui c'era una specie di finto robot e si poteva dire vai avanti di cento, gira a destra di 90 gradi ecc. e lui disegnava fogli sullo schermo. Mi piaceva molto, ma non c'era sullo spectrum, così ne ho implementato uno mio, perché non sapevo che fosse una cosa difficile che avrebbe richiesto molto tempo, e invece l'ho fatto, ma è stato incredibilmente soddisfacente e credo che sia una prova della qualità del manuale di spectrum il fatto che effettivamente ho imparato la trigonometria dal manuale di spectrum, perché non l'abbiamo ancora fatta in matematica, avevo solo non so 10, 11 o 12 anni. Quindi non avevo ancora studiato la trigonometria a scuola, ma il manuale dello spettro era abbastanza chiaro da permettermi di imparare abbastanza per realizzare un interprete di logo. E ripensandoci, mi piacerebbe vedere il codice ora. Ho il sospetto che sia assolutamente pessimo. E naturalmente si è perso nella notte dei tempi. Ma a posteriori sono ancora immensamente orgoglioso di quanto fosse orribile quel codice. Potreste scrivere il vostro elenco di loghi. Potevi salvarlo su nastro, potevi caricarlo di nuovo, potevi eseguirlo... Era tutto estremamente bello.

MARCIN: E man mano che procedeva con questa competenza, ha sempre pensato di lavorare come ingegnere del software o era interessato ad altre cose e poi è stato in qualche modo indirizzato o sa qual è stato il processo che l'ha portata a entrare in questo campo?

JON: Credo di aver pensato fin dall'età di 13 o 14 anni che questa sarebbe stata la mia carriera. Quindi sì. Non ho scelto l'informatica all'università, mi sono laureato in matematica e ho pensato che forse sarei finito a fare ricerca in matematica. Ho scoperto di non essere abbastanza bravo in matematica per fare un dottorato o altro. Ma sapevo che sarebbe stato qualcosa che riguardava l'informatica. Ai tempi della scuola ero interessato alla vita artificiale, così mi sono laureato in matematica e poi ho fatto un master in informatica per un anno e durante le vacanze sono finito a lavorare con un amico alla Digital Electronics e da lì sono partito. Sono sempre stato pessimo nel dirigere la mia carriera, ho sempre lasciato che andasse da un posto all'altro, come mi divertivo, quindi ho sempre considerato il divertimento molto più importante del denaro, e certamente il riconoscimento che ottengo da Stack Overflow e dalla scrittura è molto piacevole. Non è mai stato un obiettivo deliberato nella vita quello di diventare famoso o altro. Ma la sorta di bizzarra micro-celebrità che ottengo grazie a Stack Overflow è piuttosto divertente e un po' strana, ma fare cose divertenti nel proprio lavoro è sempre molto più importante per me, quindi mi assicuro di avere un buon equilibrio tra lavoro e vita privata e di poter vedere spesso la mia famiglia. La mia famiglia è incredibilmente importante per me, ma non ho prestato molta attenzione alla mia carriera come potrebbero fare persone più consapevoli.

MARCIN: Come possono i genitori sviluppare l'interesse dei bambini per la programmazione?

JON: Ho tre figli, uno dei quali si interessa di Arduino, fa un po' di coding e si diverte anche con Python. Un altro ha iniziato a usare Python più di recente, ma in precedenza stava usando scratch, che è interessante, è un ambiente più visivo e non so molto della scienza o dell'insegnamento ai bambini della programmazione. Ho provato a insegnare ai miei figli a programmare in Python con un approccio molto graduale e penso che sia ottimo per gli adulti, ma non sono sicuro che riesca a suscitare l'interesse dei bambini. Almeno non con il metodo che mi è stato insegnato. O sono io a non essere un buon insegnante, il che è del tutto plausibile, ma credo che la cosa più importante sia assicurarsi che sia qualcosa che i bambini vogliono fare. Quindi è stato solo quando ho smesso di cercare di insegnare la programmazione ai miei figli che hanno iniziato a farlo da soli e a imparare molto di più. Mio figlio maggiore ha fatto un po' di cose con Arduino e Raspberry Pi. Sono sicuro che queste cose non le ho mai viste perché di tanto in tanto dice: "Potrei avere questi pezzi, per favore". E poi va a costruire cose a caso e questo è stato il modo in cui ho imparato anch'io. Per quanto ne so, i miei genitori non mi hanno mai sorvegliato in termini di programmazione. Erano solo felici che fossi felice e mi incoraggiavano a uscire nel mondo esterno. Ogni tanto, ma erano contenti che facessi qualcosa di creativo e che imparassi da me stesso. Quindi, se riuscite a incoraggiare i ragazzi a trovare qualcosa che si divertano a fare da soli e a far capire che siete felici di aiutarli ogni volta che lo desiderano, ma che non li costringerete a farlo. Adesso è il momento di fare mezz'ora di programmazione. Credo che questa sia la ricetta del successo. I bambini amano imparare. Magari non amano la scuola, ma amano imparare e fare cose creative. Quindi lasciateli liberi di dare sfogo alla creatività come meglio credono e vi stupiranno con quello che riescono a fare.

MARCIN: Pensi che l'idea che tutti debbano imparare il codice, soprattutto se si cerca di introdurlo maggiormente nei programmi di studio, sia una buona idea o costringa inutilmente le persone a imparare qualcosa che in realtà non vogliono. È una buona idea o costringe inutilmente le persone a imparare qualcosa che in realtà non vogliono.

JON: Penso che ci siano due aspetti: uno è che è bene esporre tutti al coding perché abbiamo questo stereotipo malsano dell'aspetto di un programmatore di computer che sta davvero danneggiando il nostro settore. Quindi, se riusciamo a esporre le persone e a dire che il coding è davvero così, e se riusciamo a dare alle persone un'esperienza positiva, allora le persone che non si sarebbero mai dette "questa è una cosa che voglio fare per me" potrebbero scoprirlo. In realtà, lo adorano. Quindi penso che questo sia molto vantaggioso. E l'altro aspetto è che il software gestisce così tanto del mondo che penso che avere un'idea di ciò che è coinvolto, anche al livello più grezzo, sia molto utile. Allo stesso modo in cui ritengo che le persone dovrebbero avere lezioni di pianificazione finanziaria, con le nozioni di base: ecco cosa sono le pensioni, ecco cosa sono i prestiti, ecco come funziona il mercato azionario. Non perché possano diventare banchieri, ma perché possano destreggiarsi in un mondo che è così orientato alla finanza, avendo solo un'idea del fatto che sì, lo stesso vale per la politica e per tutti i tipi di cose, i tipi di parti della realtà che influenzeranno il vostro mondo. È bene avere una comprensione di base. Non dico di sapere molto di politica o di finanza, ma sono molto contento di quello che so perché mi aiuta a vedere il resto del mondo. Penso quindi che il software abbia un ruolo preciso da svolgere in quanto nessun ragazzo di oggi proviene da ambienti della classe media nei Paesi sviluppati e ci sono altre conversazioni che possiamo fare sulle aree in cui i ragazzi non entrano in contatto con i computer a causa della povertà, eccetera, ma molti ragazzi avranno un'interazione con i computer. Quindi, se li vedono come se stessero eseguendo del codice, è un codice molto complicato, ma ho un'idea di come sia fatto il codice. E l'idea di sapere che cos'è il cloud, nella misura in cui si tratta di computer che girano da qualche altra parte in un centro dati gestito da Google o Amazon o Microsoft o qualsiasi altra cosa, e di avere le basi di questo può aiutare a fare qualsiasi altra cosa, non c'è bisogno di fare coding da soli per trarre beneficio dalle idee di base su come funzionano i computer.

MARCIN: E ora con qualcosa come chrome, ad esempio, con la sua barra degli strumenti per gli sviluppatori. Puoi prendere chiunque stia usando Internet e dirgli: "Ti sei reso conto che tutto questo sta accadendo mentre stai usando questo sito web, sai, tutte queste attività e potrebbero anche non capirlo". Ma in un certo senso rivela cosa c'è dietro la tenda. E credo che a volte sia un ottimo modo per mostrare a qualcuno che non ha alcun interesse, diciamo, per l'argomento e dire: OK. Lasciate che vi mostri, lasciate che vi mostri cosa sta accadendo su questo sito web mentre lo utilizzate. Penso che sia incredibile che si possa aprire la console e iniziare a hackerare un po' di javascript senza dover fare nulla.

JON: Assolutamente sì, e applicarli l'uno all'altro. Ci sono molti altri modi per fare pezzi di codice di base solo per un browser, anche in C# ora c'è Tray.net che permette di iniziare a scrivere ogni cosa solo nel browser e certo dietro le quinte c'è un container cloud in esecuzione da qualche parte. Ma si può sicuramente iniziare a vedere codice in una miriade di linguaggi solo dal browser. E penso che ci sia qualcosa da dire per l'informatica, avendo anche questa esposizione. Ho tenuto conferenze ai lupetti, alle guide e persino alla gilda della mia chiesa metodista locale, composta per lo più da persone in pensione o quasi, che nella maggior parte dei casi non si sarebbero mai occupate di informatica, e ho tenuto una conferenza che ha mostrato loro un po' di informatica senza che i computer fossero coinvolti in alcun modo. Ho mostrato loro un po' di informatica senza l'ausilio di computer: ad esempio, se avete una pila di fogli di carta, come potete ordinarli in modo efficiente e ho sentito alcuni algoritmi diversi che potete usare. E che cosa significa se c'è una sola persona che cerca di ordinarli, allora si può usare un algoritmo. Se avete 10 persone diverse, il metodo che avete scelto può essere utilizzato anche da molte persone diverse. Così si finisce con una sorta di merge sort o altro e cose come la complessità algoritmica che fornisce esempi reali di quanto tempo ci vuole per fare cose diverse. Se avete più input per appendere le camicie su una linea di lavaggio o qualsiasi cosa sia, penso che le persone possano trovare questo tipo di cose interessanti se non sono scoraggiate. Ma non appena si inizia a parlare di calcolo, molte persone si allontanano immediatamente. Quindi c'è molto da dire sulla necessità di rendere le cose disponibili in modo non minaccioso e non paternalistico e questo richiede una notevole abilità in settori che io non ho. Ho fatto quello che ho potuto, ma sono sicuro che educatori migliori sarebbero in grado di fare molto meglio. Penso che sia molto importante.

MARCIN: Continuiamo qui. Quali sono le tue risorse oltre a Stack Overflow? C'è qualche risorsa che ti piace davvero? Voglio dire, sono un fan dei libri di O'Reilly, ma quali sono le risorse che usi quando vuoi imparare un nuovo linguaggio o qualcosa del genere.

JONI libri sono ottimi per l'apprendimento delle lingue perché vi portano in un ordine particolare e al giorno d'oggi, naturalmente, questo vale anche per i tutorial online, a patto che siano stati scritti in modo appropriato e, per esperienza, ci vuole molto impegno per scrivere risorse che insegnino tutte le caratteristiche di una lingua in un ordine specifico che vi aiuterà a imparare. Perciò qualcuno potrebbe scrivere un tutorial C# che in realtà non è affatto buono, perché si limita a fornire un'analisi del cervello. È quindi necessario scegliere, ma qualcosa di strutturato per l'utente fa una grande differenza Una buona documentazione sulle API è sempre molto apprezzata. Quindi .NET tende a essere abbastanza ben documentato e il nuovo browser delle API rende più facile trovare la documentazione ecc. Incoraggerei le persone che scrivono librerie a impegnarsi davvero per scrivere una buona documentazione da affiancare a tali librerie. Non ha senso avere il serializzatore JSON più veloce del mondo. se nessuno riesce a capire come usarlo. Ma o uso le stesse risorse che usano gli altri, che si tratti di tutorial e libri o semplicemente di cercare i risultati giusti quando sono addestrato a scrivere bene come posso fare qualsiasi cosa. Inserire qualcosa in un PDF o qualsiasi altro compito mi capiti a portata di mano. Sì, cerco su Internet, uso Stack Overflow, uso libri, uso tutorial, uso librerie e la loro documentazione. Sì, credo che sia più o meno così.

MARCIN: E cosa ne pensa di questa idea che è dovuta al fatto che siamo quasi coetanei. L'idea che a una certa età le persone diventino semplicemente dei manager. L'ha visto accadere? È vero o sei unico in questo senso, visto che stai ancora sviluppando software, oppure sei... Immagino che cosa direbbe a questo proposito.

JON: Non sono certo l'unico. Direi che ho attivamente detto di non aver gestito la mia carriera. Il fatto di ottimizzare il divertimento mi ha fatto resistere attivamente alla gestione per un bel po' di tempo. Sono stato manager per sei mesi e ho scoperto che c'è molto da dire al riguardo. In particolare, mi piace pensare di essere empatico e cerco consapevolmente di esserlo, perché credo che sia un'abilità importante per un ingegnere informatico. Ma ovviamente si riferisce anche alla gestione e quindi ho pensato che sarebbe stato interessante provare a gestire e ci ho provato, ma poi è stato appropriato per me tornare a un ruolo di contributore individuale. Si possono fare molte cose in termini di leadership come ingegnere del software senza gestire. E non è necessario scrivere sempre codice, per cui probabilmente scrivo più codice della maggior parte delle persone con un livello di seniority equivalente perché ho scelto di farlo e ho resistito attivamente a cose che avrebbero potuto avere un impatto più ampio ma senza essere altrettanto divertenti per me, come ad esempio passare molto tempo a scrivere documenti di progettazione e sì, scrivo ancora documenti con una certa frequenza, di solito in modo abbastanza informale, ma non sono un grande fan della scrittura di documenti enormi con tutti i tipi di pezzi che non saranno rilevanti per nessuno. Preferisco di gran lunga andare al sodo in modo semplice e veloce. Ma scrivere documenti per contribuire a più team dicendo: "Ok, credo che tutti noi abbiamo questo problema. Vediamo se riusciamo a trovare insieme una soluzione che abbia un impatto più ampio rispetto al fatto che io stesso scriva codice per risolvere il problema. Penso che una delle cose a cui probabilmente si dovrebbe puntare, man mano che si acquisisce esperienza, è vedere dove questa esperienza può aiutare altre persone. In un certo senso si tratta sempre di codificare, in un certo senso di condividere le proprie conoscenze con gruppi di utenti, conferenze e altro. E risolvendo i problemi all'interno di un'azienda, si può essere in grado di vedere più chiaramente di altre persone che magari hanno meno esperienza e che si sono appena unite a un team o qualsiasi cosa sia. Ma per quanto riguarda il fatto che le persone debbano diventare manager o meno, personalmente ritengo che sia del tutto normale che qualcuno arrivi e inizi a dirigere immediatamente senza aver necessariamente svolto il lavoro in prima persona. Se si tratta di qualcosa in cui si è bravi, grazie all'empatia e all'apprendimento, si può imparare cosa comporta un lavoro anche senza averlo svolto, purché si sia consapevoli di non averlo fatto e di non avere un'esperienza diretta. Quindi non credo che ci debba essere una correlazione diretta tra l'età e la percentuale di lavoratori che sono manager. Di certo spero di continuare a scrivere codice fino alla pensione e probabilmente non mi occuperò di gestione in misura significativa. Se a un certo punto dovrò diventare manager, lo farò al meglio delle mie capacità, ma non credo che dovrebbe essere un requisito e penso che molte aziende facciano la cosa sbagliata promuovendo a manager persone che in realtà sarebbero molto più felici e produttive come codificatori.

MARCIN: Per quanto riguarda l'idea che sì, probabilmente è un'idea sbagliata che dopo 15 anni di scrittura di software si diventi manager e che sia quello che fanno tutti. So solo che c'è una certa pressione, almeno nella Silicon Valley californiana, per cui le persone sono davvero preoccupate di avere 29 anni, per esempio, e di essere troppo vecchie per essere assunte da alcune aziende che sono ossessionate dall'idea di assumere solo persone di 22, 23 o 24 anni.

JON: Non vorrei essere assunto da un'azienda ossessionata dall'assunzione di ventiduenni. Preferirei lavorare per un'azienda che valorizza le persone per quello che sono, per quello che possono raggiungere e per quello che possono raggiungere insieme. Quindi non solo le loro capacità attuali, ma anche il loro potenziale. Quindi non ho sperimentato personalmente questo tipo di agismo. Mi scusi, ma sono consapevole che si tratta di una preoccupazione. Direi certamente che non ho sperimentato alcun degrado, che io sappia, in termini di capacità di codifica. Continuo a programmare in modo felice e produttivo come sempre. Per quanto ne so. Spero quindi che le aziende prendano nota di questo tipo di cose e assumano persone in grado di svolgere il lavoro.

MARCIN: Credi che ci sia qualcosa di buono. Per esempio, parliamo di tutte le altre professioni. Si tende a considerare che se qualcuno si occupa di fisica da 30 anni, non c'è nessuno che dica: "Non sai più cosa stai facendo". Il fatto che l'ingegneria del software sia così strettamente legata alla tecnologia e che la tecnologia si sviluppi così rapidamente fa sì che le persone diano per scontato che se lo fai da così tanti anni allora sei un po' fuori dal mondo o c'è qualcosa che differenzia l'ingegneria del software da tutte le altre discipline che fa sì che le persone abbiano l'idea che una persona abbia una certa età e abbia certe idee su di lei.

JON: Forse è questa l'impressione che si ha, ma direi che è probabilmente inesatta. È necessario essere disposti a imparare cose nuove. Almeno se si vuole essere in grado di andare avanti in settori nuovi e stimolanti. Se si lavora con il COBOL da 30 anni e si è deciso di non imparare nient'altro oltre al COBOL, sono sicuro che si può ancora essere produttivi e va bene così. Ma non dovreste aspettarvi di ottenere un lavoro in JavaScript o simili senza aver mostrato alcun interesse a continuare a imparare. D'altra parte, io conosco solo C# e Java a livello professionale, perché ho scoperto che c'è abbastanza roba nuova da imparare in C# e non ho abbastanza tempo per imparare F# e D e Rust e Go e tutti i tipi di cose che altre persone vanno più o meno in profondità. Ma dipende dai singoli individui quanto vogliono fare e bisogna essere consapevoli del fatto che se si decide di non imparare, se si decide di smettere di imparare, con il tempo si perde valore. Ma ad essere onesti sospetto che ci siano abbastanza sistemi legacy che per la maggior parte delle lingue si potrebbe ancora essere ragionevolmente preziosi anche se si decidesse di smettere di imparare. Francamente non vedo perché si dovrebbe smettere di imparare, perché è sempre interessante fare cose nuove. Ma richiede una discreta quantità di tempo e credo che le aziende dovrebbero essere disposte a investire questo tempo nei loro ingegneri, in modo che gli ingegneri non sentano il bisogno di imparare cose nel tempo altrimenti dedicato alla famiglia, per esempio. Quindi c'è una discreta quantità di sviluppo attivo che dovrebbe far parte del vostro lavoro. Essere un buon ingegnere Sopher nella vita lavorativa significa anche imparare cose nuove. Per la maggior parte degli sviluppatori, come ho detto, ci sono alcune aree più tradizionali in cui questo non è così rilevante, anche se direi che anche gli sviluppatori Cobol che continuano ad andare avanti e a imparare cose nuove sono in grado di vedere come possono applicare le loro competenze Cobol ad altri ambienti. Forse ci sono container che eseguono COBOL in questi giorni e improvvisamente ci sono sistemi di container basati su cloud che possono eseguire COBOL e improvvisamente si possono spostare tutte le macchine on-premise in off-premise. Quindi c'è spazio per tutti i tipi di persone che vogliono sempre imparare un nuovo linguaggio. Persone che vogliono applicare tutte le competenze tecnologiche a nuovi ambienti e persone che non vedono molto valore nell'imparare cose nuove. Sì, posso dire di non immedesimarmi particolarmente in questo tipo di persone, ma l'ingegneria del software è un campo così vasto che sono sicuro che ci sono vite utili e produttive che si possono trascorrere. Applicare tutte le competenze esistenti a sfide sempre nuove. Potrei usare C# 7 per il resto della mia vita e continuare a fare cose nuove anche se non imparo nessuna nuova area linguistica. Non è quello che voglio fare io, ma sono sicuro che per altre persone sia così. Potrebbe essere la strada che vogliono percorrere.

MARCIN: E tutto ciò è dovuto al fatto che la maggior parte dei linguaggi è completa per Turing e quindi si può fare qualsiasi cosa con qualsiasi linguaggio. Voglio dire che, in linea di massima, è

JONProbabilmente non ne sono sicuro. Penso che i linguaggi si evolvano, certamente C# si è evoluto per i casi d'uso a cui è destinato, quindi alcune delle funzionalità che vengono aggiunte ora non avrebbero avuto senso 10 anni fa, prima che il cloud computing diventasse molto diffuso, e stiamo assistendo ad altre aree, come quella dei giochi, in cui C# sta dominando in modo quasi inaspettato con piattaforme come Unity. Ci sono quindi delle caratteristiche del linguaggio che sono in qualche modo orientate al gioco e al calcolo ad alte prestazioni a bassa latenza e penso che sia fantastico. È vero che si possono fare cose in altri linguaggi o in versioni precedenti di linguaggi, ma è molto più produttivo e interessante usare le nuove funzioni perché sono state progettate per rispondere in particolare alle vostre esigenze.

MARCIN: Qual è il vostro IDE preferito?

JON: Studio visivo

MARCIN: Utilizzate una determinata metodologia?

JON: Get Code Done. Non uso Kanban o non vorrei dire una metodologia specifica del genere. Credo nei test, non necessariamente nello sviluppo guidato da test, ma almeno nello sviluppo affiancato da test, a volte guidato da test, dipende dalla situazione. Non mi piace avere molto codice di produzione non testato. Quindi questo è un aspetto dello sviluppo Agile, ma non è un aspetto che personalmente non utilizzo per intero. Non faccio molto pair programming. L'ho fatto in passato e l'ho trovato molto utile. In passato ho fatto della programmazione non a coppie e l'ho trovata assolutamente valida. Considero importante avere un buon rapporto con i colleghi, quindi la revisione del codice è molto importante per me e la revisione del codice è onesta e sincera. Ma questo non è legato a nessuna metodologia in particolare.

MARCIN: Che consiglio daresti a chi si trova in quella situazione in cui sta imparando una lingua da, diciamo, tre mesi, tre o sei mesi. E si sente come se non fosse abbastanza intelligente per impararla bene. Come se ci fossero troppi errori da correggere. Che tipo di consiglio hai per quelle persone che hanno un certo interesse, ma sentono di non riuscire a superare questo ostacolo?

JON: Quindi, se siete ancora interessati e pensate che potrebbe piacervi se solo riusciste a farlo meglio, cercate delle persone. Quindi, che si tratti di leggere blog o di trovare un gruppo di utenti, trova persone con cui puoi interagire e ottenere lezioni individuali, se possibile, perché può essere piuttosto solitario cercare di trovare risposte solo da dietro uno schermo. Se invece vi presentate, se vi impegnate con qualcuno a tu per tu, spesso possono capire che il vostro modello mentale è un problema, perché vi state immaginando qualcosa nel modo sbagliato, e questo potrebbe essere molto difficile da ottenere solo da piccoli pezzi individuali. Se non vi piace, allora cercate un'altra lingua, perché ce ne sono molte là fuori.

MARCIN: Quale linguaggio di programmazione è superiore, Java o C#?

JON: Personalmente direi assolutamente C#. Ora, non ho esaminato i dettagli delle funzionalità di Java 9 e conosco solo le funzionalità di job rate, ma mi sembra che C# abbia preso alcuni degli errori commessi da Java e ne abbia commessi alcuni a sua volta. Ma in generale, C# sembra essersi sviluppato più velocemente e in modo davvero efficace. Il team di C# è incredibilmente intelligente e molto attento a come sviluppa il linguaggio. Siamo arrivati a C# 7.2 e sembra che sia andato in un'ottima direzione e che sia gestito molto bene e ben specificato. Detto questo, Java è migliore che mai e non credo che ci sia abbastanza da far sì che chi lavora su una base di codice Java debba buttare via tutto e iniziare a usare C#. Ma se potessi scegliere in qualsiasi momento, sceglierei sicuramente C# in qualsiasi giorno.

MARCIN: Fantastico! Jon Skeet ti ringrazia per essere stato ospite del podcast di Yellow Duck. Se hai dei link da inviarmi e delle conferenze che farai, mandami pure tutte le informazioni.

JON: Grazie.

MARCIN: Sì, grazie, ciao!

Condividi post

Per saperne di più sulle assunzioni nel settore tecnologico

Iscrivetevi al nostro Learning Hub per ricevere utili approfondimenti direttamente nella vostra casella di posta elettronica.

Verifica e sviluppo delle competenze di codifica senza soluzione di continuità.

Guardate i prodotti DevSkiller in azione.

Certificazioni di sicurezza e conformità. Ci assicuriamo che i vostri dati siano sicuri e protetti.

Logo DevSkiller Logo TalentBoost Logo TalentScore