Penso che il mio sia "non esiste un lavoro di cinque minuti" - che i programmatori tendono ad essere eccessivamente ottimisti riguardo allo sviluppo e che dovremmo davvero riflettere sulle implicazioni prima di promettere una soluzione rapida a un problema e poi immergerti per codice
Esiste sempre un modo migliore per scrivere il tuo codice.
Non importa quanto eccellente trovi il codice che scrivi, sarai sorpreso di quanto sia grave se lo rivedi tra qualche anno. Solo perché alcuni anni prima non conoscevi alcuni modelli che conosci oggi, o alcune caratteristiche linguistiche che hai imparato nel frattempo, ecc.
Pensa prima di iniziare a programmare.
Non c'è nulla di più permanente delle soluzioni temporanee :)
Se è terribilmente difficile risolvere un problema, molto probabilmente il problema in sé è mal posto fin dall'inizio.
Il tuo software vivrà molto più a lungo di quanto pensi sia quando lo scrivi.
Ho iniziato la mia carriera negli anni '80. Ho iniziato con un software che ha avuto origine negli anni '70 e che era ancora in uso negli anni '90 (forse più a lungo, non so per certo del suo destino). Alcuni dei miei codici open source sono a metà della seconda decade.
Lavorare bene con gli altri è molto importante.
"Mostrami il tuo 'Vai al ragazzo' e ti mostrerò il tuo problema"
Slapdash Hero Coders: coloro che escono dal codice senza alcun riguardo per la convenzione, la leggibilità o qualsiasi altra cosa stia lavorando, possono causare più danni che benefici.
Non dire che le persone che possono scrivere tonnellate di codice di buona qualità sono cattive. Semplicemente raro.
L'apprendimento di nuove lingue fa parte del lavoro
Ho imparato a conoscere quattro linguaggi di programmazione a scuola negli anni '80, ma ne ho usato uno in un lavoro. Ho avuto quattro lavori in cui non conoscevo nemmeno la lingua che ero stato assunto per usare.
Nel complesso, ho imparato e utilizzato professionalmente forse una dozzina di lingue nella mia carriera, tra cui FORTRAN, c, c ++, c #, java, perl, Tcl, ruby, groovy, awk, python, sh, batch, DCL, javascript e alcuni piccoli DSL. Facendo un po 'di matematica, mi sembra di fare una media di una nuova lingua ogni due anni, anche se c'è un sacco di sovrapposizioni.
Se qualcosa è stata una costante nella mia carriera, è un cambiamento.
Il software non è mai completo.
Ci sono sempre alcuni cambiamenti nei requisiti, miglioramenti, correzioni di bug che devi essere preparati a gestire. Pertanto, sii flessibile e accetta il fatto che "software is never complete" e abbia sempre margini di miglioramento.
Continua a studiare ogni giorno. La conoscenza di oggi è obsoleta domani.
Ironicamente questa risposta dovrebbe essere obsoleta anche domani. Ma davvero, studia duramente una o due cose e sii certificato se è possibile, sii il Dio delle cose (magari linguaggi di programmazione o amministrazione di sistema / rete / database) e tieni sempre d'occhio altre cose minori, come altre lingue senza importanza per te.
Intendo, ad esempio, essere un fantastico professionista dell'amministrazione di Java e Oracle DB, ma studio un po 'di Python, PHP, C ++, HTML5, Javascript, anche se non a un livello di certificazione. Studia ogni struttura web o linguistica esistente. Studia o prova ad avere un'esperienza (di base) con ogni database esistente, come SQL Server, MySQL, Cassandra, HBase, PostgreSQL e l'intero mondo No-SQL come MongoDB e CouchDB. Cerca di avere una certa esperienza con l'amministrazione e la virtualizzazione di Linux.
Questa è la più grande lezione che ho imparato dai miei 16 anni di esperienza. Sono stato per quasi 10 anni un programmatore in mono-lingua, usando Pascal nella sua era, e Visual Basic 6 all'inizio del millennio, e uno sviluppatore PHP da 9 anni. Ma da quel momento apprendo che gli sviluppatori devono sapere almeno un po 'di tutto.
"Se la tua matematica è sbagliata, sei brindisi."
L'ho imparato la prima volta diversi anni fa. L'ho imparato di nuovo solo due settimane fa.
Direi che la migliore lezione che ho imparato è
"Devi sempre scegliere il miglior approccio possibile e non il tuo approccio .
Ho imparato che il miglior principio di design è KISS (Keep it simple, Stupid!) .
Ho imparato che mantenere il tuo codice semplice e pulito dovrebbe essere la preoccupazione principale, e ogni membro del team dovrebbe capire che cosa hai del codice. The KISS principle afferma che la maggior parte dei sistemi funziona meglio se sono mantenuti semplici anziché complessi, quindi la semplicità dovrebbe essere un obiettivo chiave nella progettazione e dovrebbe essere evitata la complessità non necessaria.
Se non è rotto, non aggiustarlo!
Cercare di estendere e migliorare materiale già funzionante potrebbe darti un strong mal di testa
Non ci sono tentativi
Supponiamo che tu abbia un'attività o un gruppo di attività che dovrebbero durare 4 giorni. Quindi il tuo capo o project manager ti chiede se potresti provare a farlo in due giorni per qualche motivo importante. Volendo essere un dipendente buono e flessibile, potresti essere tentato di dire: certo, puoi provare. I risultati più probabili da ciò sono che o perdete la scadenza, o avete intenzione di fare un hack a metà per farlo. E non è colpa del tuo capo chiedendoti di farlo, questo è il suo lavoro. È colpa tua se non hai detto no, qual è il tuo lavoro.
Non puoi contrattare con il tempo. Puoi contrattare con la portata. Sii professionale e non venderti breve.
"Non succederà mai" significa in realtà "Non succederà mai fino al primo giorno di produzione"
È bello scrivere codice di prim'ordine, all'avanguardia e pulito.
Anche se mi viene chiesto di fare qualche soluzione rapida che potrebbe rovinare il codice base, preferisco farlo nel modo migliore.
Scrivere il codice è facile. Il codice di lettura è difficile. Anche se il codice è tuo. Quindi, quando possibile, vai per un approccio leggibile.
Non sei più intelligente di altri. Non pensare mai che il tuo approccio sia il migliore solo perché è tuo.
Prestare attenzione a CHE COSA si dice, non PER CHI è detto. Potrebbero venire idee brillanti per le fonti più inaspettate.
Non essere pigro. Prenditi il tuo tempo per scrivere un bel codice. Dovrai risolverlo comunque a un costo maggiore.
Non utilizzare le fantastiche funzionalità OOP solo perché puoi! - YAGNI (Non ne avrai bisogno)
Use fancy OOP features perché hanno un vantaggio specifico e dimostrabile sul problema che stai cercando di risolvere . Ridi, ma lo vedo sempre. La maggior parte dei programmatori non ha mai incontrato un oggetto che non gli piaceva. Penso che dovrebbe essere il contrario: queste tecniche sono colpevoli fino a prova contraria nei confronti di KISS .
Leggi altre domande sui tag career-development experience interview