Quali sono le competenze che ogni programmatore diplomato al college dovrebbe avere? [chiuso]

Avevamo un docente ospite nella nostra scuola che ha seguito una tangente per quanto riguarda i diplomati e non essendo all'altezza del livello di abilità che si aspetta, cioè. conoscenza di un linguaggio linguistico compilato come Java, C ++ o C #, un linguaggio di scripting come Python o Ruby, un framework web. Quali sono alcune altre abilità che pensate debbano essere assolutamente fondamentali per gli studenti laureati?

Di gran lunga direi l'entusiasmo di imparare. Il college non vuole davvero darti le competenze necessarie per diventare un programmatore. Ha lo scopo di insegnarti le abilità necessarie per apprenderle .

I neolaureati hanno bisogno di qualcosa di più del semplice desiderio di imparare, hanno bisogno di un'ossessione per l'apprendimento, una comprensione di come apprendere e una solida base nelle realtà del software. In genere non mi interessa quali lingue conosci, ma ogni junior deve:

1. Comprendi la storia . L'informatica è un campo ben studiato, con molti problemi risolti. Conoscere questo fatto apre la porta all'apprendimento da ciò che è venuto prima di te. Anche sapere che c'è una ricca storia da cui estrarre la conoscenza è più che molti laureati. Ciò include cose come la notazione big-O, la storia degli algoritmi, i principi dei profeti (Knuth, K&R, Hofstdater, ecc.) E pratiche e schemi comunemente accettati.

2. Sappi che può essere risolto . Sono sempre sorpreso quando uno sviluppatore è sconcertato da un problema. Parte dell'apprendimento per imparare è il semplice principio che i problemi sono facilmente solubili, sempre. Una volta che lo sai, incornicia il tuo pensiero per trovare una risposta sana.

3. Comprendi la decomposizione . Non solo i problemi possono essere risolti, ma il percorso per farlo è semplice come dividere e conquistare. Riduci un problema fino a componenti più semplici e la tua risposta si presenterà sempre da sola.

4. Sapere come misurare . Oltre a poter scomporre i problemi, i nuovi sviluppatori devono sapere come raccogliere informazioni su questi problemi. Per quanto? Quanto largo? Quanto velocemente? Quanti? I fatti semplici sono un passo verso la comprensione e il pensiero oggettivo. Fare ipotesi senza fatti è un modo semplice per perdersi nello spazio problematico.

5. Sii obiettivo . Tutti i problemi possono essere decomposti, misurati e compresi semplicemente. I problemi che non possono essere compresi semplicemente richiedono ulteriori scomposizioni, misurazioni e comprensione. Non c'è motivo di arrabbiarsi o sentirsi frustrati, né è produttivo discutere di teorie o di dare la colpa. Qualsiasi comportamento o convinzione irrazionale relativo al processo di risoluzione dei problemi è un veleno che rende le soluzioni molto difficili da trovare.

6. Preferisce schemi e principi . Incontrerai decine di modi giusti per fare cose, linguaggi, modelli di programmazione, architetture di computer e persino metodi di ingegneria. Non esiste un solo modo giusto, ma ci sono solidi concetti di base che è possibile applicare più e più volte. Impara a vedere questi schemi, poiché guideranno il tuo apprendimento e il pensiero in ogni fase del processo.

1. Una passione per la programmazione bene
2. Umiltà
3. La capacità di apprendere rapidamente cose nuove

Come datore di lavoro, assumerò solo persone come programmatori che:

1. Esperienza con il singolo passaggio attraverso il codice.
2. È possibile selezionare un design appropriato per risolvere un semplice problema specifico.
3. È in grado di implementare il codice che riflette il progetto scelto patern.

Nella mia esperienza, meno del 5% dei laureati in scienze informatiche che presentano domanda per lavori di programmazione possiede effettivamente queste competenze, a livello di base. Queste sono le competenze minime necessarie per essere commercialmente utili e, soprattutto, non tutti sono in grado di apprendere queste abilità.

Altre belle persone sono:

• Esperienza di lavoro su un progetto di gruppo
• Uso del controllo del codice sorgente
• Esperienza di test unitari

Questi facilitano la loro integrazione con il team di sviluppo esistente, ma sono materie che normalmente possono essere insegnate sul posto di lavoro.

Una volta avevo una squadra che "ereditavo" con il personale per lo più neolaureato e ho avuto la mia esperienza nel fatto che coloro che avevano programmato veramente "accanto" allo studio (per guadagnare qualche soldo extra) erano i membri del team più capaci. Quindi l'esperienza è la chiave e poco importa quale lingua.

Tuttavia, se guardi cosa cercano i recruiter (in tutti i siti di recruiter comuni come jobserver.com ecc.) È interessante osservare che c'è molto da chiedere per C ++, C #, Java, ma ci sono anche altri cercati e anche cose "esotiche" come COBOL sono ancora in circolazione.

1. Abilità interpersonali e comunicative
2. Approccio pragmatico (non quella teoria accademica)
3. Capacità di pensare come un cliente che non è tecnicamente propenso
4. Capacità di valutare ciò che è importante / e ciò che può essere ignorato, in termini di costi / benefici
5. Capacità di lavorare in gruppo
6. Capacità di pensare in modo strategico: architettura, estensibilità, scalabilità
7. Apertura nell'accettare che gli insegnamenti universitari abbiano poco a che fare con il mondo reale (dipende dall'università - un po 'meglio su questo).

Il processo di apprendimento in questa professione non finisce mai. Bisogna costantemente imparare e migliorare se stesso, altrimenti si "stacca" dal gioco molto velocemente.

Le altre risposte sono buone, ma direi che l'abilità trascurata n. 1 nell'università sembra essere la vera ingegneria del software .

Le lezioni di base per insegnare OOP e una lingua come Java sono fantastiche, ma nel 3 ° e 4 ° anno perché gli studenti (almeno nella mia università locale) scrivono compilatori e sistemi operativi invece di imparare come identificare e creare una buona architettura, come analizzare i requisiti e creare da ciò un elenco di specifiche tecniche, e forse soprattutto, qual è la differenza tra il buon codice che funziona e il cattivo codice che funziona.

È come se le nostre università volessero quasi sfornare programmatori anziché ingegneri del software . Non assumerei mai qualcuno che non mostrasse abilità / talento in ingegneria.