Imparare a essere un buon sviluppatore: quali parti puoi saltare? [chiuso]

Questi sono suggerimenti basati non su quello che ho fatto, ma su ciò che penso avrei dovuto fare col senno di poi:

1. Salta le nuove tecnologie hyped perché la maggior parte di esse fallirà. Fai delle eccezioni per coloro che hanno una quota o un piano aziendale, ma hanno sempre una strategia di opt-out (tecnologia sostitutiva).
2. Salta a diventare un esperto in ogni linguaggio e libreria di programmazione. Cerca di diventare un esperto dei relativamente pochi (sette) linguaggi di programmazione e librerie che pagano per quello che ti piace fare. Detto questo, non perdere mai l'occasione per cercare di capire le sfumature di un diverso linguaggio di programmazione. Diventare competenti in una nuova lingua e le sue librerie standard impiegano circa due mesi.
3. Salta le tecnologie a piattaforma singola ogni volta che c'è una soluzione alternativa.
4. Salta MS Windows. Ha troppi vizi.
5. Salta diventando uno specialista, ma consenti in modo selettivo agli altri di pensare che è ciò che sei.
6. Salta il voodoo aziendale ("architettura dei componenti enterprise guidata dall'utente") se puoi. Non conduce da nessuna parte.
7. Salta C ++ (lascia che siano gli altri a occuparsene) e attendi i collegamenti Python.

In realtà, puoi saltare qualsiasi cosa se ti fidi della tua capacità di apprendere. Penso che quello che vuoi sapere sarebbe stato meglio rispondere ad una domanda del tipo:

• Conosco questo e mi manca che . Cosa dovrei imparare entro un anno da adesso?
• Mi piace avere progetti che pagano bene, ma quello che mi piace veramente è tale . Cosa dovrei imparare per farlo entro un anno?

Ricorda che i buoni sviluppatori sanno tutto, perché l'informatica raramente si occupa di calcolare se stessa, ma più spesso di applicarla a qualsiasi campo dello sforzo umano, che si tratti di fisica teorica, conservazione degli ecosistemi o effetti fotografici in The Matrix .

Infine, ti invitiamo a conoscere il design, l'astrazione, gli algoritmi e la complessità. Io, i programmatori che mi hanno insegnato e i programmatori che rispetto ti ringrazieranno e ti apprezzerò per questo. Se hai tempo per studiare, ti consiglio di leggere la prima edizione di codice completo .

Scegli un'applicazione per animali domestici. Questo dovrebbe essere qualcosa che può iniziare molto semplicemente ma ha una certa complessità mentre scavi più a fondo. Dovrebbe anche essere qualcosa che ti interessa perché passerai molto tempo con esso. Assicurati anche che faccia qualcosa. Non provare a scrivere un framework o un webservice in questo momento. Solo una normale app guidata dall'utente.

Scarica git, mercurial o bazaar e scopri come creare un repository con loro (è semplicissimo).

Ora implementa il tuo progetto per animali domestici usando qualsiasi tecnologia ti piaccia al meglio delle tue capacità. Datti una scadenza in modo che tu possa fare in modo che sia fatto. Utilizzare il repository di controllo del codice sorgente creato per tracciare le modifiche. Non preoccuparti di rami e simili, ma assicurati di essere in grado di evitare errori.

Quando hai finito di scrivere la tua app, etichettala. Questo è il tuo V1. Visualizza Funzionando efficacemente con il codice legacy di Michael Feathers, Principi, modelli e pratiche di sviluppo software agile e Codice pulito e Andrew Hunt e David Thomas Il programmatore pragmatico . Sentiti libero di leggerli in qualsiasi ordine, anche per saltare tra loro. Molte idee sono ripetute, ma rafforzeranno anche la tua comprensione perché sono presentate da prospettive diverse. (Probabilmente vorrai prendere in mano il GoF Design Patterns per riferimento)

Mentre leggi i libri, prova ad applicare ciò che stai imparando per migliorare il tuo progetto. Assicurati di utilizzare il controllo del codice sorgente come diario delle modifiche che apporti.

Se fatto correttamente dovresti aver imparato un buon numero di buone abilità come: refactoring, design guidato da test, miglioramento del codice esistente e come (e quando) applicare modelli di progettazione (tra le altre competenze).

Idealmente, avresti un mentore che ti aiuti a valutare i tuoi progressi. Se interessati, puoi contattarmi (firstinitiallastname su kharasoft dot net), e ti aiuterò con un piano e fornirò una recensione.

Congratulazioni per aver preso l'iniziativa di portare avanti la tua carriera! Molti premi arriveranno da esso.

Conosci il segreto di un buon sviluppatore?

Non lo sai tutto ma sai cosa non sai e dove trovare maggiori informazioni su ciò che non sai quando ti serve.

• Sapere tutto ciò che hai citato nei dettagli non è possibile - troppo per un cervello da gestire.
• Ricordare tutto questo non è possibile - la conoscenza non utilizzata viene cancellata dalla memoria
• Nella maggior parte delle situazioni pratiche non ti serve comunque molto

Cercare di raggiungere l'impossibile porterà solo a ansia, insonnia e perdita di autostima.

Penso che la risposta sarà diversa per ogni sviluppatore, a seconda di cosa vuole specializzarsi. Raccomando il seguente algoritmo per determinare una buona risposta:

1. Scegli un progetto semplice che usi un'abilità che ti interessa apprendere.

2. Implementalo, concentrandoti su quella competenza.

3. Nota cosa ti piace del risultato di quel progetto e cosa non ti piace.

4. Per le cose che ti piacciono sul modo in cui è stato realizzato il progetto, chiediti: "È qualcosa che penso di poter specializzare in quello che mi piacerebbe o è collegato a qualcosa in cui potrei specializzarmi e che mi piacerebbe? "
   un. Se è così, pensa ad altre abilità che sono legate a questa specializzazione e scrivile.
   b. In caso contrario, datti una pacca sulla schiena, annotalo come qualcosa in cui sei bravo e vai avanti.

5. Per le cose che non ti sono piaciute del modo in cui è stato realizzato il progetto, chiediti: "È qualcosa che dovrei sapere come fare (o voler sapere come fare), o è questo un aspetto di sviluppo che potrei e vorrei lasciare agli altri in generale? "
   un. Se pensi di voler o dovresti sapere come farlo, aggiungilo alla lista iniziata nel passo 4a. b. Se pensi di poter lasciare quell'aspetto agli altri, sospira in modo malinconico oltre i tuoi limiti come essere umano, annotalo come debolezza e vai avanti.

6. Scegli un'abilità dall'elenco di cose a cui potresti specializzarti e cose che dovresti sapere da 4a e 5a. Scegli quello che pensi sia più importante da sviluppare per avvicinare la tua programmazione a ciò che vuoi che sia.

7. Confrontate i progetti semplici che potreste fare usando quell'abilità. Scegli uno, possibilmente un progetto che ti consenta di praticare un'altra abilità che è anche in cima alla lista in modo da poter uccidere 2 piccioni con una fava (sebbene n / 2 sia la stessa complessità di n, sarà comunque più veloce in questo modo).

8. Torna al passaggio 2, utilizzando questo progetto.

Ripeti questo ciclo per il resto della tua vita, o finché non desideri più essere un buon programmatore (ehi, se vuoi smettere di scrivere codice per nutrire gli orfani affamati, non ti fermerò!)

Mi sono specializzato in test e applicazioni web a più livelli. Il mio prossimo progetto sarà la pratica di TDD e forse ASP .NET MVC 2. TDD è quello di migliorare la mia forza nei test (io sono un SDET, quindi TDD mi darebbe solo un'idea dei test unitari, che generalmente non faccio tranne sui miei strumenti di test) e per aiutare con una debolezza nel buon design (spero), e MVC è di aiutare con la mia debolezza nel design del front-end. La mia lista include cose come prestazioni di test, sicurezza web e collaborazione con un web designer per creare un sito web bello (e di bell'aspetto).

Un altro consiglio che ho ricevuto all'inizio e che ho trovato molto utile: le specializzazioni possono essere ampie o profonde. In altre parole, dilettarsi in un po 'di tutto è una specie di specializzazione. Tienilo a mente quando cerchi di capire cosa vuoi che sia la tua specializzazione.

Scusa se volevi qualcosa tagliata e secca. Non penso che la domanda abbia una risposta del genere.

Ho programmato per anni (da quando avevo 7 anni - ho circa 30 anni).

Se fossi nella tua posizione l'unica cosa che suggerirei vivamente - ma che non vedo nella maggior parte delle altre risposte è trovare almeno un altro programmatore con cui lavorare insieme su un progetto definito.

Come si legge sulla programmazione Agile - SCRUM ecc. e si lavora in modo agile e basato sui test. Lavora insieme - ma non lasciare che uno di voi scriva la maggior parte del codice - lavora davvero su di esso come un paio di sviluppatori.

E mentre scrivere la tua versione di tutto può essere informativo - i migliori sviluppatori che conosco sono maestri nell'evitare di scrivere codice EXCEPT per le cose che devono assolutamente fare da sé - ovvero il nucleo di ciò che è unico nel loro progetto.

Per il resto del tempo riutilizzeranno il codice in modo estensivo: chiamate API, utilizzate progetti open source (ove appropriato) e in breve evitate di reinventare la ruota (oi livelli di accesso ai dati, ecc.) solo per il gusto di farlo.

E poi nel fare questo - specialmente con i progetti open source, essi contribuiranno anche a quei progetti - leggeranno il codice, lo ripuliranno, correggeranno bug, contribuiranno con le estensioni ecc.

Lo sviluppo del mondo reale consiste solitamente nel lavorare come parte di un team - quindi ti incoraggio vivamente a farlo. Se non conosci altri programmatori che desiderano lavorare su un progetto specifico con te, ti suggerisco di guardare oltre i 1000 di progetti open source e selezionarne uno o più per essere coinvolto attivamente - probabilmente puoi trovare uno o più progetti che gratta un "prurito" personale e molto probabilmente troverai un progetto a cui puoi contribuire e trovare altri sviluppatori con cui lavorare.

E personalmente scarterei il parere che il tuo atteggiamento di "saltare quello che posso" è sbagliato, quando assunzioni gli sviluppatori voglio sviluppatori che non provano a fare tutto da soli. Preferirei strongmente agli sviluppatori il cui primo istinto non è quello di scrivere da soli, ma gli sviluppatori il cui primo istinto è vedere come possono raggiungere le esigenze e le esigenze aziendali senza scrivere codice (e quindi scrivendo il codice minimo necessario).

Il tutto pur tenendo a mente e tenendo ben presenti le esigenze aziendali - e sì a volte i test mostreranno che devi, in effetti, dover riscrivere un codice o scriverlo da solo (a volte puoi quindi contribuire a migliorare progetto).

È semplicemente una questione di leggere e imparare cose quando ne hai bisogno.

Se ti trovi bloccato da qualche parte o hai la sensazione che "la mia soluzione manchi qualcosa" - questo è il momento in cui dovresti passare un po 'di tempo per saperne di più!

Cercare di trovare i bit da saltare non è l'atteggiamento migliore da avere.

Detto questo, puoi mirare a concentrarti su alcune aree una volta che hai un'idea delle parti di essere un dev che preferisci.

Forse attenersi allo sviluppo web, a scapito di Windows Dev per esempio.

Mi piace essere un tuttofare, in quanto mi rende più utile.

In un anno non è probabile che siano state completate "alcune buone app / siti / applicazioni web", specialmente in una curva di apprendimento ripida. L'unica cosa che imparerai è burnout.

Invece, concentrati su quello che ti interessa e usalo come strumento di apprendimento. Non preoccuparti della qualità della produzione (non lo sarà), ma usala come sandbox a cui puoi continuare a tornare.

Ad esempio, sono interessato al fantasy baseball. Nel corso degli anni, ho sviluppato molte cose relative a questo, da una raccolta di statistiche su robot, a un sito Web solo HTML, a un'applicazione Web completa con un database SQL Server scalabile che la alimenta, a ... Il mio prossimo progetto per animali domestici potrebbe essere un'applicazione in tempo reale di Silverlight per consentire ai ragazzi di sedersi intorno a un tavolo virtuale per fare il draft.

Nessuna di queste cose è così utile al di fuori del mio mondo. Tuttavia, ognuno di loro mi ha aiutato a diventare un programmatore migliore e ad apprendere le tecnologie al di fuori della mia zona di comfort.

Ignora il fatto di preoccuparti di quale linguaggio iniziare a programmare.
Basta sceglierne uno e andare.
Passa il tuo tempo ad apprendere i dettagli dell'API.

Ecco perché:

Which is better, XUL, Eclipse's SWT, or wxWindows? I don't know. They are all such huge worlds that I couldn't really evaluate them and tell. It's not enough to read the tutorials. You have to sweat and bleed with the thing for a year or two before you really know it's good enough or realize that no matter how hard you try you can't make your UI taste like real food.

Joel Spolsky, "Lord Palmerston sulla programmazione" link

Non mi preoccuperei troppo della sindrome "dovrei sapere già questo". In questa linea di lavoro, stai imparando sempre qualcosa di nuovo. Una o due volte l'anno, il mio capo mi invia un link a un documento di 200-300 pagine per un protocollo di comunicazione o un circuito integrato o qualcosa del genere e mi assegna a diventare l'esperto residente sui suoi contenuti. Nessuno si aspetta che tu arrivi ad un punto in cui hai "finito" l'apprendimento.

Per quanto riguarda il processo di sviluppo, prendi quello che viene. Non saprai veramente cosa è più utile finché non lo fai una volta o due. Valuta la tua performance e apporta miglioramenti la prossima volta.

Ad esempio, l'anno scorso ho avuto molti problemi con l'instabilità della costruzione. Avevo paura di aggiornare dal controllo del codice sorgente perché sembrava che ogni volta che l'ho fatto, avrei finito per passare una mezza giornata a preparare di nuovo tutto. Tuttavia, se avessi aspettato troppo a lungo tra gli aggiornamenti, l'unione alla fine sarebbe stata orrenda. Di tanto in tanto ho anche bug urgenti in cui non posso posticipare l'aggiornamento e che ha reso difficile tenere traccia delle modifiche parziali che avevo già apportato per nuove funzionalità.

Bene, la mia azienda sta lavorando per correggerlo su scala generale, ma nel frattempo avevo bisogno di qualcosa che potrei usare per me stesso. Ho fatto qualche ricerca sulla stabilità delle build, ho scoperto il controllo della versione distribuita, ho sperimentato alcuni modelli di branching e ora ho un sistema ibrido molto funzionale che utilizza diversi rami di bazaar localmente e il controllo della sorgente centralizzato della mia azienda quando ho bisogno di condividerli.

Il mio punto è che se mi avessi chiesto due anni fa cosa dovrei apprendere in merito agli strumenti e ai processi software, non avrei potuto dirtelo. Se non si dispone di un simile ambiente di lavoro per il mio, un controllo sorgente ibrido è solo una complessità extra senza vantaggi marginali, ma ha notevolmente aiutato la mia produttività personale e la sanità mentale.

Il prossimo per me sta lavorando sulle mie capacità di stima, ma non ho idea di cosa succederà dopo, e io certamente non so cosa troverà di più un estraneo su Internet utile un anno da ora. Solo tu puoi rispondere.

Vorrei condividere due punti qui:

1. Pensare in termini di algoritmo sarebbe sempre di aiuto. Quando stavo iniziando, penso sempre agli scenari di vita reale e agli algoritmi attuali che ci stanno dietro e cerco sempre di ottimizzarli.
2. Mai ogni smettere di imparare e capire Nuove cose / tecnologie, nei computer non c'è niente come GURU , devi sempre imparare e devi accettare questo fatto in anticipo e continuare ad imparare.

Non importa quello che fai, purché continui a seguirlo e impara a fallo bene .

Tutte le idee che hai pubblicato sono buone cose da sapere e ti aiuteranno. Quale ti interessa di più? Hai detto che le tue abilità di Unix sono deboli. Hai pensato di mettere Linux sul tuo computer? Conoscere già C sarebbe d'aiuto, dato che potresti avere i piedi bagnati nella programmazione dei sistemi Unix senza lo stress aggiuntivo dell'apprendimento di una nuova lingua. Potrebbe anche essere un'opportunità per conoscere i driver dei dispositivi, se ti interessa.

Consiglio vivamente di imparare l'assemblaggio e i principi funzionali a un certo punto della tua formazione per sviluppatori. Entrambi si sono dimostrati molto utili per me nel mio ruolo "normale" come programmatore Java. Ho imparato Lisp e Prolog. Personalmente preferisco il Lisp, ma è una questione di opinione. Assemblea ti insegna a pensare a come il computer vede il tuo programma, e penso che sia importante per ogni programmatore imparare. la programmazione funzionale ti insegna a pensare in modo più deterministico, che nel mio caso mi ha aiutato a scrivere un codice più testabile e che è sicuro per i thread.

Quindi scegli qualcosa che ti piace e trascorri un paio di mesi con esso. Sarai il migliore per questo, e potrebbe rivelarsi un trampolino di lancio per il prossimo progetto nella tua autoeducazione. Oh sì, e qualunque cosa tu faccia, non smettere di imparare non . Nel secondo momento, inizi a ristagnare.

Smetti di provare a diventare uno sviluppatore decente in un anno. Impara a diventare un buon sviluppatore tra 10 anni.

Dall'articolo collegato:

The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again. There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music.

Tra un anno sarai ancora un azzardo. Non c'è niente che tu possa fare al riguardo. Le buone aziende considerano gli junior come un investimento. Quello che cercano non è una buona abilità attuale, ma un'abilità potenziale, una buona conoscenza delle basi e l'entusiasmo. È necessario ottenere queste qualità in un'intervista per ottenere un lavoro entry level.

Quanta programmazione fai nel tuo tempo libero? Questo sarà probabilmente il fattore chiave per convincere un potenziale datore di lavoro che si sta andando a migliorare rapidamente. Quali progetti hai completato ? I progetti completati mostrano la dedizione.

Sono stato impiegato solo in 2 aziende diverse, ma ognuna aveva la propria tecnologia interna che avevo bisogno di imparare prima di poter essere produttiva. Quel bump iniziale non ridurrà molto con quanta esperienza hai. I buoni datori di lavoro si aspettano un periodo di apprendimento iniziale.

Smetti di preoccuparti e vai al programma. : D

Mi piacerebbe solo darti i miei passi di letture ispiratrici e i miei momenti più difficili finora.

Ci sono stati alcuni momenti "WOW" nella mia carriera nel software. Sono andati come segue:

Modelli di primo modello di testa : questo mi ha davvero aperto il mondo di OOP / OOD, un punto fermo.

Robert C. Martin - Clean Code - Non ho dormito per giorni con entusiasmo da questo! Per quanto semplice, il ragazzo aveva dimenticato cosa significava avere un codice pulito, e questo mi ha rimesso in sesto.

Robert C. Martin - Agile Pattern and Practices - Ora vivo la mia carriera di coding basata su questi principi. La parola SOLID mi passa per la mente per ogni pezzo di codice che scrivo. Questo in combinazione con Clean Code, sono stato influenzato così tanto da loro che, al tempo stesso, ho convinto il mio datore di lavoro a farmi insegnare all'intera compagnia di circa 15 sviluppatori. Non ero nemmeno un anziano, bravo in presentazioni, ma il mio entusiasmo ha fatto sì che accadesse.

Il mio ultimo momento "WOW" è stata la scoperta di TDD. Ho condiviso la mia realizzazione con altri 2 amici intimi che hanno avuto lo stesso effetto "WOW". Siamo stati tutti agganciati e ora ci esercitiamo il più possibile e discutiamo sempre l'importante dei test nel ciclo di vita dello sviluppo del software: meglio avere un codice di auto-verifica di un gruppo di umani molto più lenti per eseguire i test per voi;)

Un ultimo punto da me che sento è molto vicino al mio cuore, è che se vuoi una vera comprensione fondamentale di una tecnologia, come un parser di script, una libreria REST, un framework di test, ecc, allora scrivi uno ! Solo per divertimento! Non solo ti piacerà, ma ho scoperto che il tentativo di scrivere cose che ancora non comprendo pienamente, mi dà molto più rispetto e una comprensione molto più profonda di questo, e mi costringe a capirlo a fondo.

Mi dispiace, mi sono appena reso conto di quanto potrei aver divorato dalla domanda. Quello che ho menzionato sopra è stato il mio nucleo assoluto. Nessuno dei materiali di cui sopra mi ha lasciato e mi ha dato un pensiero così astratto che l'apprendimento è davvero diventato più ampio e più facile. Quindi, in risposta alla tua domanda, cerca di non saltare i principi fondamentali della scrittura del codice e della progettazione del software. Altri strumenti specifici per risolvere problemi specifici, non sono così importanti.

L'apprendimento e l'accumulo di conoscenze è come costruire un edificio, ogni mattone si siede su un altro, si basano sulle loro fondamenta.

Se inizi a saltare le cose, affrettandoti, finisci con i fatti sgangherati, supportati in onda. Non osi usarli per paura che cadano, e lo faranno. I fatti possono essere falsi, se non sono associati alla ragione, perché è necessario conoscere i loro limiti.

Sono particolarmente preoccupato che tu voglia saltare le basi, la matematica, gli algoritmi e i loro parenti. Senza una solida comprensione qui, mai non riuscirai a fare "altro che i loop nidificati più semplici" .

Non avere fretta, il lavoro è lì per sempre, il tempo per l'apprendimento ininterrotto non lo è. Impara tutto quello che puoi, nell'ordine in cui trovi che ne hai bisogno, non lasciare mai un buco scollegato.

Come suggerisce Jeff O, se vuoi essere un buon programmatore non perderai mai l'apprendimento.

Devi capire che c'è così tanto che potresti potenzialmente imparare che è solo collegato alla programmazione che, se vuoi sapere tutto e essere bravo in questo, starai lì per milioni di anni. Quindi concentrati su ciò che renderà la tua vita buona. Che si tratti di puro godimento, denaro, impegno scientifico o qualsiasi altra combinazione di motivi, è questo che devi scegliere e su cosa dovresti investire il tuo tempo e dormire.

Chiediti esattamente cosa sia uno sviluppatore decente e fai proprio questo: esercita la tua arte su progetti di vita reale che ti guideranno a dimenticare che ore sono.

Per me essere uno sviluppatore decente include capire come ottenere e scrivere buoni requisiti, come gestire il progetto, come testare, come presentare i risultati, come giudicare chi potrebbe essere in grado di aiutarmi e chi no (reclutare) , come collaborare con gli altri, come soddisfare il capo e il cliente.

A livello tecnico, essere un buon sviluppatore per me include la possibilità di progettare, revisionare, codificare, eseguire il debug, testare, scrivere manuali utili per gli utenti, commentare il codice per gli altri sviluppatori in modo significativo, gestire le versioni, simulare e trova sempre una soluzione per migliorare la produttività su base giornaliera, per automatizzare le attività (che si tratti di test, debug, analisi dei dati per le previsioni di carico o altro). Significa essere in grado di fare velocemente e amp; codice sporco quando necessario o giustificato, ma anche in grado di fare un codice pulito, ben pensato.

Tutto ciò che è acquisito non attraverso l'apprendimento per il gusto di farlo, ma l'apprendimento per uno scopo, per risolvere un bisogno che hai lì e poi. Imparare per il gusto di farlo è buono per darti una solida base, ma imparare per uno scopo è buono per renderlo reale.

Un buon sviluppatore alla fine è colui che è in grado di raccogliere ciò che è necessario per l'attività a portata di mano.

Sembra che tu sia dappertutto. Penso che le persone apprendano di più quando si concentrano su un'area specifica e scavano davvero dentro perché quando lo fai invariabilmente ti imbatti in alcuni problemi che richiedono l'apprendimento di qualche altro strumento. In questo modo puoi far crescere le tue abilità organicamente e in modo altamente interconnesso in modo da non perdere le conoscenze acquisite perché ogni nuova idea o strumento che viene incorporato nella tua cassetta degli attrezzi mentale ti permetterà di imparare altre molto più facilmente.

Scegli un buon progetto Open Source che ti interessi e inizia ad apprendere il codice e contribuisci a correzioni di bug e nuove funzionalità. Questo è qualcosa che ogni programmatore dovrebbe fare.

Inoltre, inizia subito un progetto, l'unico modo per imparare è cercare di trovare soluzioni per un problema reale. Se non stai costruendo nulla, non hai ancora nessun problema da risolvere.