Cosa dovrebbe sapere ogni programmatore?

Indipendentemente dal linguaggio (i) di programmazione o dai sistemi operativi utilizzati o dall'ambiente in cui si sviluppano, cosa dovrebbe sapere ogni programmatore?

Alcuni retroscena:

Sono interessato a diventare il miglior programmatore che posso. Come parte di questo processo, sto cercando di capire ciò che non conosco e mi farebbe molto beneficio se lo facessi. Mentre ci sono un sacco di liste intorno alla linea di "n cose che ogni sviluppatore [inserire il linguaggio di programmazione] dovrebbe sapere", devo ancora trovare qualcosa di simile che non sia limitato a un linguaggio specifico.

Mi aspetto anche che queste informazioni siano di interesse e vantaggi per gli altri.

Come ingoiare l'orgoglio e ammettere gli errori senza prenderli sul personale.

Come pensare come un utente e non come un programmatore geek tecnico.

Quando chiedere aiuto e quando NON chiedere aiuto.

Come leggere il codice di altre persone.

Familiarità con i sistemi di controllo della versione. Non deve essere tutti, ma i concetti di base che possono essere applicati a tutti dovrebbero essere conosciuti.

Ecco i miei 10 bit:

• Come essere umili. Siamo tutti qui per imparare. Puoi essere più intelligente di altri, ma ci sono molte persone più intelligenti di te.
• Come studiare / consumare informazioni. Non ti conosco, ma studio per sempre! Libri, Internet, qualunque cosa!
• Che cos'è un dizionario e come utilizzarlo e come scoprire rapidamente gli acronimi.
• Quali sono gli strumenti di base del commercio e cosa fanno (IDE, CVS et al).
• Conoscere terminologia comune e cosa significano: modelli di progettazione, usabilità, test (ah!), Stack, ecc.
• Comprendere OOP.
• Sii "capace" in almeno una lingua, niente di straordinario, sappi solo come identificare variabili e metodi, ecc. Da qui puoi imparare VELOCE.
• Comprendi che alla fine le persone usano il software e vogliono renderle felici.

Forse è troppo sottile, ma lo considero "sapere quale problema risolvere". Molti programmatori (e persone normali) sprecano sforzi enormi per risolvere cose che semplicemente non sono molto importanti; oppure creano una soluzione, con una grande quantità di lavoro extra, che non è proprio ciò che è necessario.

Come rilassarsi È il segreto della produttività.

Alla fine, forza di volontà e caffeina non sono sufficienti. Questa costante contrazione che facciamo è molto dannosa.

Questo è un grosso problema.

Tipo di dati di base e teoria dell'algoritmo. Cose come notazione O grande, array, code, ecc.

Come scegliere lo strumento giusto per il compito giusto e non prendere parte a stupide guerre infuocate sui suoi strumenti di programmazione preferiti.

Bene, ecco il mio 0,02 $:

• L'apprendimento non si ferma mai. Non importa quanto tu pensi di essere bravo, c'è sempre qualcuno migliore di te e c'è sempre qualcosa che puoi migliorare di te stesso. Se smetti di imparare, inevitabilmente ti degraderai come programmatore. Leggere libri. Leggi i blog. Parla con altri programmatori.
• Prova ad imparare diverse lingue. Almeno uno di essi orientato agli oggetti. Inoltre, dovresti sapere qualcosa sulle varie tecnologie legate alla lingua che impari (ad es. Se impari Java, sarebbe bello sapere qualcosa di Spring e così via ...).
• Refactoring. Prima o poi avrai bisogno di quella conoscenza.
• Scopri come gestire il codice legacy.
• Scrivi unit test. Informazioni su TDD.
• Impara a lavorare in gruppo.
• Scrivi un codice elegante e leggibile. Come dice il vecchio proverbio: "Scrivi il tuo codice come se la persona che lo manterrà fosse un serial killer psicotico che sa dove vivi".
• Impara come essere pigro e disciplinato allo stesso tempo. I bravi programmatori hanno entrambe queste qualità. Per quanto strano possa sembrare, non sono contraddittori tra loro, ma complementari.

Non è possibile testare la qualità in un prodotto.

Ogni programmatore dovrebbe comprendere i modelli di progettazione .

Sono un po 'in ritardo su questo, ma andrò con le conoscenze stabilite da Edsger Dijkstra:

Oltre a un'inclinazione matematica, una padronanza eccezionalmente buona della propria lingua madre è il bene più vitale di un programmatore competente.

Se non riesci a scrivere un buon paragrafo, è probabile che non puoi scrivere neanche un buon codice.

Non essere troppo emotivamente coinvolto, attaccato o religioso riguardo a una determinata tecnologia, sistema operativo o linguaggio - nessuno è perfetto - a lungo termine probabilmente finirai per desiderare di poter creare la tua ala carte da ciò che come su ognuno diverso.

Pensala come un'auto - potresti non aver mai guidato una determinata auto prima, ma tutte hanno chiavi, volante, acceleratore e freno - dovresti essere in grado di entrare in una e partire rapidamente dopo aver individuato dove. Tratta i sistemi operativi e le lingue in modo simile e concentrati sull'apprendimento dei concetti essenziali sottostanti anche se sei alle prese con le specifiche di una determinata istanza.

E nel tempo cerca di capire e apprezzare la discendenza, il patrimonio e i punti in comune delle varie tecnologie che ti aiuteranno a mantenere la prospettiva. Renditi conto, ad esempio, che, mentre l'albero evolutivo si sta ramificando attivamente e pieno di vicoli ciechi, nel tempo la tecnologia tende a convergere ripetutamente intorno alle "migliori pratiche" e alle "economie di scala" ( ad esempio notare che un Mac non è poi così diverso da un PC sotto il cofano in questi giorni ...).

Infine, ricorda, non importa quanto ti diverta, la tecnologia rappresenta essenzialmente una lente imperfetta tra ciò che la tua mente può immaginare e ciò che effettivamente produci. Fai del tuo meglio, impara a imparare e resta adattabile ...

Come programmare in C.

Che il giorno in cui smetti di imparare dovrebbe essere il giorno in cui non sei più un programmatore.

Test di unità e debug.

• Espressioni regolari
  • A cosa servono
  • Quando non è a utilizzare le
  • Come scrivere regex leggibili
  • Come eseguirne il debug

È stato menzionato prima, ma penso che meriti la sua risposta.

Nessuno vuole usare il software. Vogliono risolvere i problemi.

Caffè e IntelliSense sono i tuoi migliori amici di sempre.

Come osservare un grande oggetto complicato e scomporlo in piccoli oggetti semplici che svolgono ancora lo stesso compito quando vengono rimessi insieme.

Non fidarti mai di un utente ( specialmente se l'app è pubblica!), Spesso faranno tutto il possibile per interrompere l'app in un modo o nell'altro.

Renderlo a prova di futuro ed espandibile: non si sa mai quando si desidera espanderlo in pochi anni e si rende conto di quanto sforzo sarebbe necessario per ricodificare il codice creato male.

Che il programmatore non sappia tutto e dovrebbe sempre cercare di imparare nuove lingue / tecnologie, ecc.

Le basi del buon design dell'interfaccia utente e del design della comunicazione (aka graphic) .

Vedo così tante app e progetti rovinati dal cattivo design o dalla scarsa usabilità. Imparare le basi può fare la differenza. Inoltre, le tecniche di risoluzione dei problemi visivi (ovvero come comunicare visivamente un concetto) sono una sfida stimolante che dovrebbe aprire gli occhi su nuovi modi di vedere, che a loro volta dovrebbero avere un impatto sul codice.

Un libro consigliato è Il libro di design del non designer di Robin Williams

Ecco cosa ne dice Joel Spolsky :

Wow! Tutti devono fare un po 'di progettazione grafica e non tutti i team di software hanno il lusso di progettisti professionisti. Questo eccellente e sottile libro ti darà una comprensione dei principi che stanno dietro l'impaginazione, i caratteri, ecc. La buona notizia è che puoi leggerlo nella vasca prima che l'acqua si raffreddi, e il giorno successivo, le tue finestre di dialogo e punti di forza e le pagine Web inizieranno a sembrare migliori.

Ogni programmatore dovrebbe sapere come imparare rapidamente. Molte volte entri in un lavoro e ti verrà chiesto di sviluppare una tecnologia che non hai mai usato. Potrebbero darti circa una settimana per rimetterti in piedi (se sei fortunato) prima che ti venga chiesto di scrivere un codice di qualità di produzione.

Controllo della versione. E per citare la mia ragazza: "Non voglio solo che tu faccia i piatti, voglio che ti piaccia !"

I requisiti cambiano, il tuo codice dovrà adattarsi e potresti essere tu o meno a doverlo adattare.

Ci sono state diverse domande qui relative agli argomenti che sono interessati da questo.

In cima alla mia testa:

1. Pochissimi problemi di programmazione richiedono matematica oltre ad addizione, sottrazione, moltiplicazione e divisione. Se stai pensando di utilizzare il calcolo per risolvere un problema, cerca esaustivamente le alternative prima di farlo.

2. Ogni volta che ti ritrovi a indovinare come dovrebbe funzionare qualcosa, stai sbagliando. Non è il tuo lavoro essere telepatico.

3. La persona che ti fornisce le specifiche raramente sa tutto quello che vuole fino a quando non le hai cancellate.

4. Più della metà dell'essere un grande programmatore viene dal rapporto con gli esseri umani. Interagire con il proprio team, gestire il proprio manager e perfezionare l'utente finale è metà del lavoro.

5. Il buon codice è scritto per essere letto dalle persone tanto quanto deve essere letto dal compilatore.

6. Le migliori pratiche e la realtà pratica saranno in conflitto più di quanto il programmatore pensi, ma meno del manager. Quando sembrano essere in conflitto, sta a te delineare e comprendere il conflitto e poi cedere alla pratica. La soluzione sottile e intelligente è solo migliore di quella brutta e brutale se a lungo termine è più conveniente.

7. I grandi strumenti non possono diventare grandi programmatori, ma i cattivi strumenti ci rendono ugualmente terribili.

8. Non guardare mai una tecnologia, ma cerca sempre la migliore alternativa.

9. Più lingue conosci, meglio sarai in quello che stai usando.

10. Non essere disturbato dal lento insinuarsi di pensieri orientati alla programmazione nella tua vita quotidiana. Anche quando non siamo al computer, tutti soffriamo di limiti di larghezza di banda, penalizziamo le prestazioni a causa del cambio di attività e dobbiamo caricare elementi dall'archivio di backup. I computer dovrebbero imitare il pensiero umano e gli analoghi sono ovunque.

Leggere il codice di altre persone non ti rovinerà il cervello, ma piuttosto capire perché non lo avresti fatto in questo modo (se meglio o no è un'altra domanda).

Questo ti dà la programmazione di gedankenexperiment , e occasionalmente trovi qualcuno che implementa qualcosa di meglio! Come in meglio.

Questa risposta si espande naturalmente alla lettura del proprio codice, quindi si espande per utilizzare il controllo versione e DIFF, e quindi a 42.