Come includere sviluppatori rookie nel tuo progetto?

Stiamo pensando di insegnare ad alcuni dipendenti che hanno esperienza di programmazione a livello di hobbista generale o pari a zero per scaricare il carico di lavoro.

Usiamo Python / Django che ha la documentazione più amichevole in circolazione e un gioco da ragazzi da imparare.

Attualmente sono un dipartimento IT individuale per la mia azienda e non ho abbastanza ore per sviluppare tutto ciò di cui l'azienda ha bisogno. Non siamo una società di software, ma aiuta ad avere l'IT interno per automatizzare le attività, sviluppare le funzionalità del servizio clienti, analizzare i dati, ecc.

Come si integrano lentamente i rookie lavorando sul tuo codebase? Supponi di avere un tirocinante: cosa fanno? Sono completamente riluttante a lasciarli progettare o sviluppare il codice di base poiché ci occuperemo degli errori / degli strani schemi di progettazione per anni. Come sviluppatore principale, sarò io quello che dovrà aggirare il loro codice.

Il mio pensiero era che i rookie modificassero solo il codice esistente, non costruendo mai funzionalità di base. Posso scaricare il lavoro su di essi con semplici compiti dopo aver creato la funzione stessa.

Vorremmo che i nostri dipendenti imparassero / trovassero valore nell'azienda e in genere facciamo in modo che le persone "scalino le classifiche".

È pratica normale insegnare alle persone con programmazione di livello generale / hobbistico? Come funziona il "passaggio di livello" in una società di software per programmatori di livello junior? Quando iniziano a lavorare sul codice principale?

Sto cercando di decidere se causerà più danni che aiuto, o se c'è un modo in cui possiamo usare il loro aiuto senza rischiare potenzialmente il codice del sito principale (ambienti isolati?).

Se deleghi il debuttante a un ruolo inefficace, lui / lei non impareranno mai nulla di sostanziale e certamente non ti saranno di grande utilità.

Permettetemi di darvi un consiglio: il mio primo lavoro IT fuori dalla scuola è stato presso una società di produzione relativamente piccola dove avrei lavorato su software per assistere gli ingegneri di vendita nella stesura di preventivi per vari progetti. Dovevo anche aiutare il ragazzo IT che gestiva da solo l'IT per l'intera azienda.

Il ragazzo era un disastro stressato e affaticato, e il peggior perfezionista di micro-gestione in cui abbia mai lavorato. Avrei dovuto alleggerire il suo carico di lavoro, ma ha trascorso quasi tutto il tempo a controllare me e il mio lavoro in modo preoccupante come se stessi lavorando (non ha quasi mai lasciato l'ufficio, penso che disprezzasse la sua famiglia). Se avessi commesso un singolo errore, avrebbe perso completamente la testa e avrebbe iniziato a fare una scenata: "Sapevo che non avrei dovuto fidarmi di te per questo, era troppo importante!" e altri sfoghi.

Il punto che sto cercando di sottolineare è di NON essere così. Non solo renderà i principianti infelici e distruggerà il loro morale, ma brucerai la candela ad entrambe le estremità preoccupandoti del loro lavoro.

Offri loro la possibilità di mettersi alla prova ma hanno specifiche tecniche formali, revisioni del progetto e revisioni del codice. Inoltre è possibile testare ciò che producono per assicurarsi che soddisfi i requisiti.

Penso che rimarrai sorpreso dalla capacità di alcuni di loro.

Lavoravo in un negozio di software, dove stavamo programmando un grande progetto (tempo di accelerazione significativo).

I principianti sono stati trattati come veterinari. A loro è stato assegnato un leader tecnico e hanno iniziato le funzionalità "da sole". Lo stile dell'architettura era dettato, ma erano liberi di elaborare un proprio design pulito. Gli "strani schemi di progettazione" sono stati eliminati durante le revisioni (giornaliere) del codice dei pari.

Un errore che ho visto in un altro negozio: supponiamo che "core" sia difficile e "ui" sia facile. I principianti hanno avuto un momento più facile nel core e hanno incasinato il codice front-end dell'interfaccia utente.

In bocca al lupo!

Volete iniziare dando loro piccole funzionalità discrete da implementare. Definisci l'input che prometti e l'output che ti aspetti e lascia che colleghino i punti. E quindi utilizzare la revisione del codice condotta dal team per garantire la qualità e la revisione tra pari per addestrarli a imparare gli uni dagli altri e a insegnare loro stessi.

Ciò presuppone che si disponga di un'architettura applicativa globale che consenta di costruire unità atomiche di logica in modo disaccoppiato. Altrimenti, ti stai dirigendo verso un mondo di dolore mentre ci lavorano più sviluppatori - questo sarebbe il caso anche con i vecchi professionisti.

Inevitabilmente, ci saranno alcune persone che lo prendono, imparano in fretta e si alzano. Assicurati di continuare ad alimentare loro attività che sono solo un piccolo passo oltre le loro attuali capacità. Nulla educa qualcuno come un compito che inizia impossibile. Inevitabilmente avrai delle persone che ci provano e non riescono mai ad afferrarlo. Queste persone dovrebbero essere ringraziate per i loro sforzi e trasferite con grazia verso qualcos'altro.

In che modo la tua azienda può permettersi di prendere tempo dagli altri dipendenti, ma non assumere qualcuno con esperienza di programmazione? La quantità di tempo che dedichi all'allenamento, alla risoluzione dei problemi e al mantenimento della mano è costosa.

L'unica cosa che io abbia mai fatto in questo settore è insegnare alle persone come utilizzare un autore di report o forse un codice VBA / Macro per Excel. Di solito do i set di dati per riutilizzarli. Far loro imparare l'SQL è una cosa lunga, ma l'ho visto fatto (pagato per loro per ottenere una formazione esterna). La maggior parte di queste persone erano analisti finanziari che hanno la capacità di imparare a programmare, ma potrebbero non aver impiegato del tempo. Provare questo con alcune persone in operazioni è una cosa a lungo termine.

Assicurati di avere la persona giusta e che vogliono davvero imparare a programmare. Non avrai tempo di insegnare loro tutto. Dovranno fare molto da soli.

@louisgab aveva ragione sulla revisione del codice. Questo sarebbe anche il mio primo passo. Una cosa fondamentale che ti aiuterà è assicurarti che debbano correggere i propri errori sia che li trovi nella revisione del codice o in seguito. Hanno vinto; non si rendono nemmeno conto che stanno commettendo errori a meno che non debbano ripararli. Assicurati anche di spiegare perché la soluzione che hanno usato è un errore e perché ciò che stai proponendo è migliore. Le prime settimane si sentirà come se avessi più lavoro a causa di avere queste altre persone, ma se fai le tue recensioni di codice e spieghi le cose e ti aspetti che imparino, in poche settimane saranno molto più utili che se tu fai tutto da solo. Ma c'è un impegno iniziale del tuo tempo per metterli al passo con i tempi di cui il tuo management deve essere consapevole.