Come possiamo migliorare l'istruzione e la formazione generali del programmatore? [chiuso]

La scorsa settimana, stavo solo guardando questa fantastica intervista di Kevin Rose di Phillip Rosedale, di Second Life.

E hanno avuto una straordinaria discussione su come trovare, assumere e identificare i buoni programmatori e quanto sia difficile trovarne di buoni.

Il che mi ha portato a pensare davvero al modo in cui apprendiamo i programmatori. Per la maggior parte di noi, me compreso, siamo autodidatti. Il che è grandioso di essere un programmatore, chiunque può imparare e sviluppare abilità.

Ciò significa anche che non esistono standard reali su cosa sia / sia un buon programmatore e che tipo di ambiente incoraggi la crescita delle capacità di programmazione.

Questa non è tanto una domanda, ma solo un desiderio in me, di vedere come possiamo cambiare la cultura della programmazione e i responsabili della programmazione, in modo da incoraggiare l'educazione e l'auto-miglioramento.

Ci sono molte strade per la formazione continua, i video di YouTube, i libri, le conferenze, ma a causa della natura esperienziale di ciò che facciamo, non è sempre chiaro ciò che è importante imparare e padroneggiare.

Diamo un'occhiata a The Joel 12 Steps.

Il test Joel

Usi il controllo del codice sorgente?

Puoi creare una build in un solo passaggio?

Realizzi build giornaliere?

Hai un database di bug?

Correggi i bug prima di scrivere un nuovo codice?

Hai un programma aggiornato?

Hai una specifica?

I programmatori hanno condizioni di lavoro silenziose?

Usi i migliori strumenti che il denaro può comprare?

Hai tester?

I nuovi candidati scrivono codice durante il loro colloquio?

Fai test di usabilità in corridoio?

Penso che tutti questi abbiano un valore importante, ma a causa di qualcosa che chiamo il gap esperienziale, se un programmatore o un manager non ha mai avuto alcuna delle conseguenze negative per non aver fatto gli articoli nell'elenco, non vedrà mai la necessità di fare alcun di loro.

Il gap esperienziale, è la mia teoria di base, secondo cui ognuno di noi ha diversi lavori ed esperienze diverse. Quindi per alcuni di noi, che hanno sempre lavorato con dozzine di programmatori, il controllo del codice sorgente è un must. Ma per le persone che sono sempre state l'unico programmatore, non possono immaginare la necessità del controllo del codice sorgente.

Ed è a causa di questo grande difetto nel modo in cui apprendiamo, che valutiamo le persone in base alle migliori pratiche che fanno o meno, e il motivo di entrambi può iniziare una guerra di fiamma.

Valutiamo sempre le persone nel nostro campo in base a ciò che fanno, e pensiamo "Oh, se questo ragazzo / ragazza non sta facendo le migliori pratiche xyz, non può essere un buon programmatore, quindi non perdiamo tempo o energia a parlare con loro ".

Questo è esattamente il motivo per cui abbiamo così tante guerre di fuoco programmabili, che a causa del divario esperienziale non possiamo immaginare che le persone non abbiano preso le decisioni che abbiamo dovuto prendere.

Quindi questo mi ha portato a pensare che dobbiamo assolutamente ripensare il modo in cui formiamo, educiamo e gestiamo i programmatori.

Ad esempio, quale percentuale di voi ha avuto l'incoraggiamento del proprio manager di andare alle conferenze e persino farle pagare?

Per me e per molte persone, questo è estremamente raro, molti di noi vorrebbero andare alle conferenze, per saperne di più, ma i soldi non sono lì per farlo.

Quindi il punto di questa domanda è davvero quello di scatenare come possiamo allenarci, imparare e gestire meglio?

Come possiamo creare una nuova cultura dell'apprendimento che non insulti le persone per non avere le stesse esperienze lavorative.

Sì, abbiamo tutti un lavoro e un lavoro da svolgere, ma la nostra capacità di svolgere bene il nostro lavoro dipende dal nostro desiderio, interesse e supporto nel migliorare la nostra padronanza delle nostre capacità.

In questo momento, vedo la nostra cultura piuttosto disorganizzata, sosteniamo l'élite, ma quelle tonnellate di noi che vogliono migliorare, semplicemente non hanno abbastanza supporto per imparare e migliorare noi stessi.

Voglio dire, come industria, vogliamo essere percepiti come solo ingranaggi sostituibili?

Grazie...

Wow, ottima domanda a cui pensare, difficile rispondere. Poiché tutti noi abbiamo esperienze e desideri diversi, è difficile trovare una soluzione adatta a tutte le dimensioni. Ma emetterò alcune opinioni che ho avuto nel corso degli anni su questo stesso argomento.

1) Smetti di vedere il lavoro saltare come un male e incoraggiarlo. Cambia società ogni pochi anni. Il programmatore viene esposto a molte tecnologie, metodologie e imprese diverse nel corso della loro carriera. Le aziende ottengono un flusso costante di nuove idee.

2) Smetti di vederti come programmatore presso la compagnia X e vediti come un professionista che fornisce un servizio alla compagnia X. Se pensi come un professionista verrai trattato come un professionista. Se siamo visti come ingranaggi sostituibili, è perché ci comportiamo come ingranaggi sostituibili.

3) Le università devono cambiare. Dovrebbero avere un periodo iniziale di 2 anni di istruzione di base nei computer seguito da una scelta. Informatica o ingegneria informatica. E la pista di ingegneria ha bisogno di professionisti che lavorano sul campo ogni giorno, non di qualcuno che scrive solo documenti. E ciò che viene insegnato deve essere pratico, in modo da poter iniziare a correre il giorno dopo la laurea. Forse avere un programma di apprendistato per coloro che non seguono un corso di laurea.

4) Modifica: questo era un po 'rant-ish. Ciò che intendevo dire era che tutti noi abbiamo molto da imparare gli uni dagli altri, indipendentemente dall'età e dall'esperienza.

5) In qualche modo correlato al punto 2. Smetti di vedere il tuo datore di lavoro come responsabile della tua carriera. Sei. E solo tu. Se vuoi andare a una conferenza paga da solo se la tua azienda non lo farà. Metti da parte i soldi ogni anno appositamente per i libri, la formazione e lo sviluppo professionale. Se aspetti che il tuo datore di lavoro ti invii alla formazione, attendi molto tempo. Il tempo trascorso a guardare le tue abilità diventa irrilevante. Non stai facendo abbastanza per permettertelo? Cambiare lavori.

6) Dobbiamo essere onesti con noi stessi e con i nostri colleghi programmatori. La programmazione è difficile. Molto difficile. Vedo ancora pubblicità per la formazione informatica con ricchezze garantite dopo la laurea. Ciò porta molte persone sul campo che semplicemente non sono qualificate o, peggio ancora, non hanno alcun reale interesse oltre il denaro. Dobbiamo trovare un modo per incoraggiarli a ripensare i loro piani di carriera.

A questo punto penso che la mia testa stia per esplodere, quindi concluderò.

Ottima domanda! Non vedo l'ora di leggere altre risposte.

Non penso che sia disorganizzato solo a causa della mancanza di insegnamento. Penso che sia effettivamente riflettente che le "migliori pratiche" differiranno da lavoro a lavoro. Le "migliori pratiche" saranno sempre basate in un contesto particolare.

Ci sono molti incroci per alcune delle aree di lavoro più comuni, ad es. sviluppo web. Tuttavia, penso che sia un errore credere che solo perché è bene impegnarsi in una pratica particolare nella maggior parte dei lavori dovrebbe essere usato in tutti i lavori.

Le pratiche che intraprendi dovrebbero derivare da un'analisi e una sperimentazione di ciò che ti fa lavorare meglio. Non dovrebbero essere scelti attraverso credenze cieche. Solo perché qualcosa fa eco spesso in rete non lo rende una verità nella tua situazione, né una verità (per tutte le situazioni).

Ottima domanda per esercitare la mente, sono d'accordo che qualcosa deve essere fatto, ma penso che sia impossibile rispondere. Il mio tentativo:

Prima di tutto, non uccidere la creatività in generale, devo dire che sono d'accordo con Sir Ken Robinson, guarda questo fantastico discorso su TED . Il nostro sistema educativo sta uccidendo la creatività e deve essere modificato. Soprattutto per i programmatori.

Secondo Insegnare come schemiil nostro campo professionale non è abbastanza maturo. Abbiamo molte cose diverse che pensiamo siano la strada da percorrere, ma non possiamo davvero essere d'accordo su di esse. (pensa a TDD, BDD, Agile vs Waterfall, la quantità di documentazione necessaria, Java o .Net) Nella mia mente ciò è dovuto alla discussione senza contesto e alla grande specializzazione. Non puoi fare la scelta giusta senza sapere in quale contesto viene posta la domanda e non puoi fare la scelta giusta se conosci solo un'opzione. Quando lo riporti all'istruzione sembra impossibile da risolvere. Non puoi aspettarti che qualcuno conosca tutti i possibili contesti e tutte le possibili soluzioni. Ma con i modelli ora hanno alcune soluzioni generali e contesti che si applicano e contesti quando le soluzioni si guastano. IMHO questo è il modo in cui dobbiamo insegnare,

In terzo luogo, disclaimers sugli esempi Penso che ci sia un problema con gli esempi che mostriamo su MSDN, sui Blog, nei libri, ecc. Gli esempi sono spesso messi a tacere per ottenere il punto che lo scrittore sta cercando di fare. Ma negli esempi più elementari ci sono già decisioni su molti livelli. Questi esempi insegnano tutte queste altre decisioni sbagliate. Penso che ogni esempio debba venire con un disclaimer che dice qual è il punto e cosa non dovresti fare in generale. Un ottimo esempio di questo è stato bloggato oggi qui .

Ultima cosa da fare Penso che debba esserci di più da fare. Ho imparato a fare semplicemente, fallendo, risolvendo e discutendo.