Cosa fare quando si ha a che fare con un'attività di programmazione che non si è mai svolta?

Ci sono diverse cose che puoi e dovresti fare per preparare il compito:

• 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 ci si è avvicinato. Questo è ciò che Google ha trovato: "Gestione delle eccezioni come sistema Wide Concern ". Personalmente, cerco sempre di imparare dagli altri.
• Infine, e questo potrebbe essere il più importante, parla alle altre persone della tua squadra per ottenere maggiori chiarimenti e indicazioni su cosa fare. Voglio sempre vedere i nuovi ingegneri che vengono a chiedere indicazioni sui progetti.

Non sapere come fare qualcosa non finirà mai. Ogni giorno mi imbatto in 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 per la soluzione di lavorare in un modo nuovo o diverso.

Ecco perché sono un ingegnere; Mi piace capire nuove cose.

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:

• Spezza le attività nelle unità più piccole possibili - scomporle finché non hai cose che puoi fare.

• Ristabilisci l'attività o il problema immediato per assicurarti di comprenderlo davvero. Quindi fai qualche analisi e ripeti.

• Scegli prima il compito più semplice, anche se sembra troppo semplice solo per ottenere lo slancio . Alcuni 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 po 'di slancio e ho visto che il "primo più difficile" ha portato allo stallo dei progetti prima che raggiungessero un reale slancio.

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

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

• Fai 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.

• Mantieni un elenco in esecuzione dei problemi che stai incontrando e poi nella mischia giornaliera o in un orario normale di tua scelta, esaminali con altri.

• Non aver paura di porre le domande più elementari. Le ipotesi di altri possono essere difficili da contestare, ma se non puoi procedere con ciò che ti viene dato devi fare nuovamente domande.

• Se conosci l'obiettivo, fai tutto il possibile finché non rimani bloccato e quindi pubblichi i progressi e le domande su Stack Overflow.

Naturalmente 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 quello che hai sia la nozione di qualcuno che un "meccanismo di errore generico" sia in qualche modo richiesto per avviare questo progetto.

Personalmente, vorrei riprendere questo concetto. Scrivere qualsiasi cosa "generica" prima di implementare le reali esigenze degli utenti è quasi sempre una perdita di tempo. E poiché è generico , per definizione non è specifico per la tua azienda o applicazione, quindi probabilmente c'è già qualcosa che soddisferà circa il 95% delle tue esigenze.

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

Se ciò non riesce, il prossimo passo è definire un'interfaccia per il meccanismo di errore e ottenerla approvata dagli stakeholder. Successivamente, l'implementazione sarà probabilmente banale.

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

P.S. Ci sono alcuni programmatori che pensano che il modo di iniziare qualsiasi progetto sia scrivendo una "piattaforma" per fornire tutti i servizi comuni che saranno necessari ai moduli dell'applicazione. Questo di solito si trasforma in mesi di lavoro banale reinventando roba già prontamente disponibile gratuitamente. Fino a quando non raggiungi i limiti prestazionali delle soluzioni disponibili, non c'è motivo di scrivere servizi "di piattaforma". Né vi è alcun motivo per scrivere wrapper attorno alle API esistenti. Se effettui il refactoring in modo continuo, l'involucro esatto richiesto dalla tua applicazione apparirà magicamente.

Penso che tu stia soffrendo più dell'ansia che di 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 il tuo team : se sei di una buona squadra, dovresti essere in grado di chiedere aiuto. Ci sono cose che saprai che anche i più anziani non lo sapranno. Chiedere aiuto non è un segno di debolezza (non più di correre a qualche sito di domande.)

Cerca : una ricerca web sulla gestione degli errori generici non ha generato nulla? Non è possibile trovare un'intera soluzione. Dovrai lavorarci sopra e adattarlo comunque alla tua app.

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

Get Over It - Solo fare cose che sai fare diventerà noioso. Ti porta anche in una trappola di solo brutale forzando alcune soluzioni ripetendo le stesse cose più e più volte (se ti piace ripetere le cose, vai a lavorare su una catena di montaggio). Siate pronti a fare errori. Quelli che ti dicono che sanno tutto, non chiedono mai aiuto o ricerche, mentono.

È la vecchia barzelletta sui medici che ancora "praticano" la medicina; neanche loro hanno tutte le risposte.

Rallegrati del fatto che non stai facendo qualcosa che hai già fatto cento volte. Hai trovato la gioia dello sviluppo del software (per me, in ogni caso, YMMV) - imparando a guidare mentre sfreccia sull'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 prima. Anche se puoi trovare solo informazioni su soluzioni per diverse lingue o piattaforme, può comunque essere estremamente informativo.
• Prototype. Il modo migliore in assoluto per fare qualcosa di giusto è quello di sbagliare prima. Costruisci una soluzione, inventando tutto mentre procedi, in base alla tua ricerca. Cerca di renderlo conforme ai requisiti principali, tenendo in considerazione i requisiti accessori. Non preoccuparti di renderlo bello o perfetto o estendibile o flessibile o performante, fallo funzionare. Prendi nota delle lezioni apprese: cosa ha funzionato, cosa no, potenziali blocchi stradali, ecc. Quindi buttare via il codice. Se sei preoccupato di sembrare stupido per aver impiegato troppo tempo, fallo nel tuo tempo libero. Ti giova personalmente, in termini di conoscenza.
• Design. Combina le tue conoscenze esterne (ricerca) con le conoscenze personali (le lezioni apprese dal prototipo) e formula un disegno di ciò che pensi sia il modo giusto per farlo.
• collaborare. 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.
• Itera. Se non sei ancora sicuro della tua soluzione, assicurati che le recensioni tra pari siano parte del tuo ciclo di iterazione. Porta regolarmente la tua implementazione a un membro senior del team per un feedback.
• Sii felice - hai avanzato le tue conoscenze e la tua carriera, e devi fare qualcosa di nuovo e interessante invece di qualcosa di vecchio e noioso che hai fatto mille volte prima. Cerca di 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 che possa dimostrare di poter imparare tutto ciò di cui hanno bisogno per imparare come ne hanno bisogno, piuttosto che qualcuno che possa dimostrare di sapere già l'unica cosa che stiamo cercando di fare in questo momento. Il primo sarà più utile per tutto ciò che finiremo domani, o il prossimo mese o l'anno prossimo.