Cosa fare quando ti trovi di fronte a un compito di programmazione che non hai mai fatto?

Ho iniziato la mia carriera come sviluppatore .NET 3 mesi fa e dopo un lungo piano di formazione su diverse tecnologie, modelli e concetti, gli sviluppatori che mi stavano supervisionando hanno deciso di essere pronto a partecipare a uno dei tanti progetti gestiti dall'azienda.

Sono davvero entusiasta di poter finalmente iniziare a scrivere codice. Il team a cui sono entrato è piuttosto piccolo per ora perché stava iniziando con un nuovo progetto, il che è fantastico perché posso essere coinvolto nell'intero ciclo di vita del progetto. È un progetto SPA basato sul web con un supporto che utilizza l'API Web ASP.NET MVC / ASP.NET e in front-end il framework Durandal e le relative librerie.

Il mio problema è che dopo aver avuto un incontro con i miei colleghi e aver stabilito i compiti e le stime per il mese successivo, mi trovo in una posizione che non so se sono in grado di svolgere uno qualsiasi dei compiti.

Non ho mai svolto nessuna delle attività create e non so come procedere.

Ad esempio, una delle attività create è la creazione di un meccanismo generico di gestione degli errori per l'intera applicazione.

Come si procede di solito di fronte a compiti che non ha mai svolto?

Ci sono diverse cose che puoi e dovresti fare per prepararti all'attività:

• Pensa al problema e disegna alcuni diagrammi. Assicurati di sapere qual è il problema che stai cercando di risolvere.
• Fai delle ricerche su ciò che stai cercando di fare. Internet è una preziosa fonte di informazioni. Non sto dicendo di chiedere a Stack Overflow - sto dicendo di fare delle ricerche su come altre persone hanno già risolto un problema come il tuo o affrontato. Questo è quello che Google ha inventato: "La gestione delle eccezioni come preoccupazione a livello di sistema" . Personalmente, cerco sempre di imparare dagli altri.
• Infine, e questo potrebbe essere il più importante, parla con le altre persone del tuo team per ottenere maggiori chiarimenti e indicazioni su cosa fare. Voglio sempre vedere nuovi ingegneri venire a chiedere consigli sui progetti.

Non sapere come fare qualcosa non finirà mai davvero. Ogni giorno incontro problemi che non ho mai affrontato prima. Avere la capacità di capire come risolvere nuovi problemi è estremamente importante. Anche i vecchi problemi non sono mai del tutto vecchi - nella programmazione, c'è quasi sempre una nuova svolta o una richiesta affinché la tua soluzione funzioni in un modo nuovo o diverso.

Questo è il motivo per cui sono un ingegnere; Adoro scoprire cose nuove.

Non smettere mai di imparare cose nuove. L'apprendimento è ciò che ti rende migliore.

Non esiste una soluzione perfetta, ma alcune cose che potrebbero aiutare:

• Suddividi le attività nelle unità più piccole possibili: suddividile fino a quando non hai cose che puoi fare.

• Riafferma l'attività immediata o il problema a portata di mano per assicurarti di averlo veramente compreso. Quindi eseguire alcune analisi e ripetere.

• Scegli prima l'attività più semplice, anche se sembra troppo semplice solo per dare slancio . Alcune persone preferiscono il compito più difficile, quindi il "duro lavoro" è fuori mano. Ho scoperto che il "compito più semplice" in genere funziona meglio perché stai solo cercando di ottenere un certo slancio e ho visto "il primo più difficile" portare a stallo dei progetti prima che ottengano un vero slancio.

• Chiedi aiuto per selezionare l'attività e l'approccio giusti per iniziare.

• Cerca un mentore in grado di darti un feedback costante (idealmente quotidiano) per una settimana o due.

• Poni molte domande ma concentrati sull'essere educato con i tuoi compagni di squadra. Chiedi sempre se hanno tempo e presta attenzione ai soliti segni verbali e non verbali che in quel momento non hanno tempo.

• Tieni un elenco aggiornato dei problemi che stai riscontrando e poi, nella mischia quotidiana o in un momento regolare di tua scelta, affrontali con gli altri.

• Non aver paura di porre le domande più elementari. Ipotesi di altri possono essere difficili da contestare, ma se non riesci a procedere con ciò che ti viene dato devi rimetterti in discussione.

• Se conosci l'obiettivo, fai tutto il possibile fino a quando non rimani bloccato, quindi pubblica i progressi e la domanda su Stack Overflow.

Ovviamente non hai idea di come scrivere un "meccanismo di errore generico". Nessuno sa come scrivere un "meccanismo di errore generico" fino a quando non saranno definiti alcuni requisiti. Sembra che tutto ciò che hai è l'idea di qualcuno che un "meccanismo di errore generico" sia in qualche modo richiesto per avviare questo progetto.

Personalmente, vorrei respingere questa nozione. Scrivere qualcosa di "generico" prima di implementare i reali requisiti dell'utente è quasi sempre una perdita di tempo. E poiché è generico , per definizione non è specifico per la tua azienda o applicazione, quindi c'è probabilmente qualcosa di già disponibile che soddisferà circa il 95% delle tue esigenze.

Ma dal momento che sei il membro junior, respingere potrebbe non essere una grande idea. Quindi devi parlare con le persone che pensano di aver bisogno di un "meccanismo di errore generico" e scoprire quali servizi si aspettano che questo meccanismo fornisca. Quindi cerca in rete per vedere se qualcosa di già scritto sarà sufficiente. Se trovi qualcosa, proponi semplicemente di usarlo. Probabilmente non saranno d'accordo, perché chiunque chieda un "meccanismo di errore generico" probabilmente soffre di un brutto caso di non inventato qui.

In caso contrario, il passo successivo è definire un'interfaccia per il meccanismo di errore e farlo approvare dalle parti interessate. Successivamente, l'implementazione sarà probabilmente banale.

=================

PS Ci sono alcuni programmatori che pensano che il modo per avviare qualsiasi progetto sia scrivere una "piattaforma" per fornire tutti i servizi comuni che saranno necessari ai moduli dell'applicazione. Questo di solito si trasforma in mesi di banale lavoro reinventando cose già prontamente disponibili gratuitamente. Fino a quando non raggiungi i limiti di prestazione delle soluzioni disponibili, non c'è motivo di scrivere servizi "piattaforma". Né c'è motivo di scrivere wrapper attorno alle API esistenti. Se si esegue il refactoring continuamente, apparirà magicamente l'esatta fasciatura richiesta dall'applicazione.

Penso che tu soffra più dall'ansia che da un deficit di abilità. Ad un certo punto, non era tutto nuovo? Ti è mai stato assegnato un compito e non sei stato in grado di risolverlo in una certa misura? Sei pagato per capire le cose.

Utilizza la tua squadra - Se fai parte di una buona squadra, dovresti essere in grado di chiedere aiuto. Ci sono cose che saprai che nemmeno i più anziani non sapranno. Chiedere aiuto non è un segno di debolezza (non più che correre verso un sito di domande).

Ricerca : una ricerca Web sulla gestione generica degli errori non ha prodotto nulla? Potresti non trovare un'intera soluzione. Dovrai lavorarci sopra e adattarlo alla tua app comunque.

Prototipo : cambia la tua prospettiva sull'attività dalla produzione al prototipo. Basta avere qualcosa da lavorare e costruire da lì. Quando arrivi al punto puoi usarlo, quindi inizia a pensarlo come produzione. Ora non vedrai l'attività come qualcosa che non sai nemmeno da dove cominciare.

Farsene una ragione - Solo fare cose che sai come fare diventerà noioso. Ti porta anche in una trappola di forzare alcune soluzioni ripetendo ripetutamente le stesse cose (se ti piace ripetere le cose, vai a lavorare su una catena di montaggio). Preparati a fare errori. Quelli che ti dicono che sanno tutto, non chiedono mai aiuto o fanno ricerche, stanno solo mentendo.

È la vecchia battuta sui dottori che ancora "praticano" la medicina; non hanno nemmeno tutte le risposte.

Rallegrati del fatto che non stai facendo qualcosa che hai fatto cento volte prima. Hai trovato la gioia dello sviluppo del software (per me, comunque, YMMV) - imparare a guidare mentre percorri l'autostrada a velocità straordinarie. Questo è il genere di cose per cui un grande sviluppatore vive ed eccelle.

Il mio processo personale è qualcosa del genere:

• Ricerca. Scopri se e come questo problema, o un problema simile, è stato risolto in precedenza. Anche se puoi trovare solo informazioni su soluzioni per lingue o piattaforme diverse, può comunque essere estremamente informativo.
• Prototipo. Il modo migliore in assoluto per fare qualcosa di giusto è fare prima quello sbagliato. Crea una soluzione, inventando tutto mentre procedi, in base alla tua ricerca. Cerca di renderlo conforme ai requisiti principali, prendendo in considerazione i requisiti accessori. Non preoccuparti di renderlo bello o perfetto o estensibile o flessibile o performante, fallo semplicemente funzionare. Prendi appunti delle lezioni apprese: cosa ha funzionato, cosa no, potenziali blocchi stradali, ecc. Quindi getta via il codice. Se sei preoccupato di sembrare sciocco per aver impiegato troppo tempo, fallo nel tuo tempo libero. Ti avvantaggia personalmente, in termini di conoscenza.
• Design. Combina le tue conoscenze esterne (ricerca) con le conoscenze personali (lezioni prototipo apprese) e formula un progetto di ciò che pensi possa essere il modo giusto di farlo.
• Cooperare. Trova un membro del team senior, mostra loro il tuo progetto proposto, ottieni feedback. Mostralo a qualcun altro, ottieni il loro feedback. Affina il tuo design.
• Iterate. Se non sei ancora sicuro della tua soluzione, assicurati che le revisioni tra pari facciano parte del tuo ciclo di iterazione. Porta regolarmente l'implementazione a un membro del team senior per un feedback.
• Sii felice: hai migliorato le tue conoscenze e la tua carriera e hai dovuto fare qualcosa di nuovo e interessante invece di qualcosa di vecchio e noioso che hai fatto mille volte prima. Prova a rendere il tuo prossimo progetto una sfida ancora più grande.

E, infine, non preoccuparti troppo delle apparenze. Come manager del team di sviluppo, preferirei avere qualcuno in grado di dimostrare di poter apprendere tutto ciò di cui ha bisogno per apprenderlo quando ne ha bisogno, piuttosto che qualcuno in grado di dimostrare di conoscere già l'unica cosa che stiamo cercando di fare in questo momento. Il primo sarà più utile per qualsiasi cosa finiamo per fare domani, il mese prossimo o l'anno prossimo.