Come posso migliorare le mie capacità mentre lavoro su progetti reali, in assenza di sviluppatori più esperti? [chiuso]

Sono lo sviluppatore principale di una piccola azienda, lavorando con C # e ASP.Net. Il nostro team è piccolo, 2-3 persone, senza molta esperienza nello sviluppo e nella progettazione. Non ho l'opportunità di imparare da altri sviluppatori senior, non c'è nessuno nel mio team che mi guidi e mi aiuti a scegliere gli approcci migliori, dato che mi occupo io della maggior parte dei progetti.

Come posso migliorare le mie capacità di sviluppo software mentre lavoro su progetti reali, in assenza di sviluppatori più esperti?

Ci sono molte fonti da imparare da parte di colleghi più esperti: libri, blog di abili sviluppatori, Stack Exchange, conferenze / conferenze, ecc. Anche le revisioni del codice sono cruciali e CodeReview.SE è una risorsa preziosa.

Vediamo come potrebbe funzionare su un esempio.

Esempio

Stai leggendo un post sul blog che menziona un termine "ETL". Non ne conosci il significato, ma da questo articolo capisci vagamente che si tratta di una sorta di processo o flusso di lavoro che sposta i dati da un supporto dati all'altro.

Vai su Wikipedia e altre risorse e ottieni una visione più precisa della cosa. Non è ancora molto chiaro quando sarebbe utile usare un ETL. Dopotutto, sembra molto più semplice scrivere una query SQL che farà tutto il lavoro, piuttosto che passare troppo tempo a costruire un vero ETL.

Per rispondere a queste domande, prendi in prestito un libro sugli ETL dalla tua biblioteca locale. Spiega che alcuni processi di estrazione-trasformazione-caricamento non sono facilmente realizzabili con una semplice query SQL: non solo la fase di estrazione può gestire diversi supporti dati diversi, non solo un database relazionale, ma anche il passaggio di trasformazione può essere molto complicato per sia validando / normalizzando i dati che mappandoli.

Ora hai una visione chiara di ciò che è un ETL, come usarlo e soprattutto quando hai bisogno di un ETL e quando non è uno strumento appropriato. Nel frattempo, hai implementato un piccolo ETL come progetto personale. Questo progetto ti consente di scoprire alcuni punti che non sono abbastanza chiari per te e che non sono coperti da un libro. Essendo questi punti piuttosto astratti e non correlati al codice sorgente, pubblichi una domanda su Programmers.SE .

Quando hai l'opportunità di crearne uno nella tua azienda, inizi a crearlo. Hai qualche problema. Alcuni sono correlati al codice; pubblichi domande su StackTranslate.it . Altri sono correlati al database; fare le domande su DBA.SE .

Infine, c'è una conferenza organizzata da uno sviluppatore altamente abile su come ottimizzare gli ETL. Partecipi a questa conferenza e ti dà preziosi suggerimenti sui miglioramenti che puoi fare per il tuo progetto.

Inizi anche a seguire un blog di uno sviluppatore che ha lavorato su diversi ETL per anni. È interessante vedere i diversi approcci e, attraverso questo blog, apprendi l'ECCD; sei interessato, quindi prendi in prestito The Data Warehouse ETL Toolkit di Ralph Kimball, il libro che parla in dettaglio del processo di "estrazione, pulizia, conformità e consegna". Lo stesso blog menziona anche molte applicazioni destinate a creare ETL senza capacità di programmazione. Ciò è particolarmente utile per l'ETL che hai fatto per la tua azienda, dal momento che il tuo capo, persona non tecnica, ti chiede costantemente di apportare alcune piccole modifiche a ciò che hai fatto.

Alla scoperta delle cose

IMHO, la parte difficile, quando non hai un mentore o un collega più esperto, è scoprire cose, e per scoprire intendo passare dallo stato "Non ho mai sentito parlare di questa cosa" a "Ho sentito parlare ma non so molto bene di cosa si tratta ".

Se qualcuno rivede il mio codice e dice che dovrei davvero iniziare a usare alcune convenzioni di stile, con un po 'di curiosità posso scoprire che nella programmazione ci sono diversi stili di scrittura del codice, che uno dovrebbe attenersi a uno stile per un determinato linguaggio e base di codice, e che molte lingue hanno strumenti per applicare uno stile (come StyleCop per C #).

Se nessuno mi parlasse dello stile, come potrei sapere che esiste una cosa del genere?

Ecco dove sono utili risorse come blog o Stack Exchange. Wikipedia non sarebbe d'aiuto (a meno che non passi giorni a colpire pagine casuali sulla programmazione), e i libri parlano raramente di queste cose.

Lo stesso vale anche per modelli e pratiche o cose che sono meno correlati al codice. Ad esempio, difficilmente immagino che qualche sviluppatore si svegli la mattina dicendosi che deve imparare qualcosa sull'ITIL mentre non si è mai preoccupato dell'ITIL prima.

Una volta scoperto un nuovo termine, è abbastanza facile impararlo. Se hai dato un nuovo termine "contratti di codice" e sei uno sviluppatore C #, puoi facilmente trovare abbastanza informazioni tu stesso su MSDN (o, meglio, nel libro di Jon Skeet).

La curiosità aiuta

Quando lavoro con gli stagisti, noto sempre che i migliori sono quelli che erano curiosi al di fuori delle loro lezioni. Potrebbero sapere che esiste una cosa chiamata programmazione funzionale anche se nessuno dei loro insegnanti non l'ha mai menzionato, e sebbene non conoscano alcun linguaggio funzionale, sono ancora in grado di spiegare in termini generali cos'è FP e in che cosa differisce dagli altri paradigmi. Potrebbero sapere di Agile, o di Unicode, o del modello di trust parziale / sandbox, solo perché stavano leggendo blog e usando Stack Exchange, piuttosto che semplicemente frequentando le loro lezioni.

Anche quando non hanno un mentore, imparano comunque tutte quelle cose che non vengono raccontate al college.

Sono in una situazione simile: siamo un piccolo team e il nostro lavoro principale sui prodotti di sviluppo consiste principalmente in modifiche incrementali su una base di codice che ha alcuni anni.

Alcune tecniche che sto usando per rimanere aggiornato e migliorare le mie capacità.

Sul lavoro:

• Leggi: libri, blog, materiali PR. Seguo una serie di feed RSS. Quando l'affare O'Reilly del giorno si basa su una tecnologia di cui non ho sentito parlare, ho letto la descrizione del libro. Se la tecnologia ha molte relazioni con qualcosa su cui sto lavorando, passo cinque o dieci minuti a ricercarla in modo un po 'più approfondito, in modo simile alla risposta di MainMa. Lo ripeto con alcuni feed RSS diversi.
• Crea un piano di formazione con il tuo management che può essere supportato con le risorse dell'azienda (tempo e / o denaro)
• Contrariamente alle tendenze della maggior parte dei programmatori, cerca di abbracciare il cambiamento e le nuove opzioni di design. Il cambiamento per il bene non è buono , ma credo che troppo spesso gli sviluppatori evitino di utilizzare un nuovo design o framework a causa del cambiamento. Questa è una linea sottile da percorrere e non correre a decisioni vincolanti, ma tieni d'occhio nuovi modi di fare le cose. Alcuni cambiamenti possono avere vantaggi inaspettati: passare a DVCS mi permette di sperimentare più facilmente sulla nostra base di codici e provare lì nuove tecnologie.
• Ad alcune persone piacciono le conferenze; Ho scoperto che il profitto è piccolo per il tempo investito.

Al di fuori del lavoro:

Ho scoperto che lavorare sulle mie capacità al di fuori del lavoro quotidiano è fondamentale. La libertà di sperimentare, commettere errori e perseguire interessi mi tiene impegnato nell'IT. Se avessi solo i miei progetti sul lavoro e avessi bisogno di limitare il mio apprendimento a ciò che era immediatamente utile, mi sarei esaurito rapidamente.

• Fatti coinvolgere in un progetto non lavorativo. Per me, questo sta sviluppando un sito Web funzionale correlato a un interesse personale. Rifatto liberamente e cerco attivamente di sperimentare diverse tecnologie. Contribuire all'Open Source ti farà conoscere anche il codice di altre persone. Questo ti darà anche del buon materiale da condividere per le interviste con l'azienda che avrà sviluppatori più esperti.
• Code Camp: se c'è un code camp nella tua zona, partecipa. Poiché questi non sono presenti durante l'orario di lavoro e sono gratuiti, senti la libertà di partecipare a qualsiasi sessione per argomenti che ti interessano personalmente. Rispetto alle conferenze tipiche, di solito sono locali e coprono ampie aree tecnologiche, quindi credo che ci sia un valore più concentrato.

E non dimenticare di visitare SO o Programmers.SE frequentemente.

Le risposte qui saranno probabilmente di grande aiuto, ma vorrei sottolineare qualcosa: nulla può sostituire il lavoro con qualcuno migliore di te (per definizioni arbitrarie e personali di meglio) per 8 ore al giorno, 5 giorni alla settimana. Questo è certo.

Se sei il tipo di sviluppatore che vuole sempre migliorare, vuole sempre imparare, alla fine dovrai andare in un'altra società. Questo è inevitabile e dovrebbe essere pianificato.

Quando trovi la compagnia giusta per te, scoprirai che puoi continuare a crescere al suo interno, piuttosto che crescere da essa.

Lo sviluppo del software è uno sport di squadra. Come uno sport, per giocare ad un livello molto alto, devi stare con e competere contro altri che fanno lo stesso. Cerca opportunità per spostarti.

Ricorda che la pratica rende permanente, quindi se non stai costantemente lavorando per migliorare la tecnica e la conoscenza, se lavori in isolamento senza critici o modelli di ruolo, potresti scoprire che le tue abilità non crescono.

In tutto il mondo, le cose stanno diventando più competitive, quindi aspettati che la tua nicchia sia temporanea e preparati per il tipo di opportunità che soddisfa i tuoi criteri per un lavoro soddisfacente, mentre allo stesso tempo ti porta fuori dalla tua zona di comfort per lavorare con un team superiore.

Prima di ricevere suggerimenti, devo dire che ero in una posizione molto simile poco più di un anno fa.

Se stai realizzando i progetti, ma ritieni che ci sia molto spazio per migliorare, questa è una buona cosa.

In un'occasione non avevo la capacità tecnica e la sicurezza per completare il progetto. Spesso compravo un libro, leggevo un blog abbastanza tecnico e mi ritrovavo "fuori dalla mia profondità". Penso che il problema più grande per me sia stato il fatto che non ero esposto a nessuna grande applicazione aziendale. Molto spesso farei qualcosa di buono, ma non avrei nessuno al mio fianco per confermare ciò che ho fatto.

Questo è stato demotivante e stimolante, quindi vedo da dove vieni. Come ho risolto questo problema? Ho lasciato un'azienda e mi sono unito a una casa di sviluppo software consolidata, che mi ha aiutato a fare molta esperienza nell'ultimo anno.

A meno che tu non voglia lasciare l'azienda, suggerirei libri che sono stati scritti dai pionieri del nostro settore. Vorrei iniziare con The Pragmatic Programmer di Andrew Hunt. Il libro contiene tonnellate di utili analogie che sono molto facili da ricordare. I primi capitoli di questo libro mi hanno incoraggiato a scegliere un linguaggio di programmazione molto diverso da quello che usiamo al lavoro. Ho iniziato a leggere letteratura non tecnica - ora credo che leggere romanzi e fantascienza mi renderà un programmatore migliore. Scrivere saggi non è molto lontano dalla scrittura di codice pulito. Alcuni scrittori sono bravi e altri sono cattivi. Questo libro mi ha fatto preoccupare di ciò che scrivo. Una delle analogie si chiama "Windows rotto". Lasci un'auto abbandonata in una strada per giorni e non succede nulla. Dopo aver rotto una singola finestra, l'auto sarà probabilmente distrutta il giorno successivo. Il codice non è diverso. Se vedi un codice rotto o scritto male, correggilo subito, non lasciarlo lì perché prima o poi tornerà a "perseguitarti". Una volta che inizierai a leggere questo libro, acquisirai dozzine di analogie simili che ti faranno pensare al codice in un modo diverso.

Vorrei quindi suggerirti di passare a Clean Code di Robert C. Martin. Questo libro è più pratico in quanto ti costringe a leggere il codice cattivo (buono). L'autore utilizza esempi di codice da uno dei progetti open source. Dici che non c'è nessuno che ti guidi. C'è un'opportunità perfetta per guardare il codice di qualcun altro, confrontarlo con il tuo e vedere come puoi migliorarlo. Per me leggere questo libro è stato come oscurare qualcuno che stava lavorando a un progetto. Il libro pone inoltre una forte enfasi sulla cosa più semplice e difficile: la separazione delle preoccupazioni. L'autore ha chiesto ai pionieri del nostro settore quello che considerano un codice "pulito". Dopo aver letto le loro risposte, sarai in grado di confrontarle con la tua opinione su cosa sia il codice pulito.

Infine, hai considerato di lavorare su progetti open source? Collaborerai con altri sviluppatori, probabilmente più esperti, che saranno in grado di rivedere il tuo codice e indicarti la giusta direzione.

Come ho detto nella mia risposta originale, non accadrà durante la notte. Lo faccio da alcuni anni ormai e quasi ogni giorno scopro di aver sbagliato.

In bocca al lupo!

Esercitati a risolvere i problemi. Leggi e lavora per capire gli altri codici (github è un'ottima risorsa per questo) e invia miglioramenti ad esso. Fare consulenza può davvero aiutarti ad ampliare il tuo set di abilità.