Domanda:
Come sopravvivere come sviluppatore junior in un posto di lavoro che non tollera gli errori?
Bbbbbbbbbb
2018-10-04 02:56:41 UTC
view on stackexchange narkive permalink

Il mio amico è uno junior in un luogo di lavoro che richiede al personale di assumersi la responsabilità al 100% del proprio lavoro. In pratica questo significa nessuna revisione del codice. Eventuali errori, errori o inefficienze devono essere identificati personalmente.

Sebbene il personale sia incoraggiato a chiedere aiuto quando incontra problemi, tu non sai cosa non sai e il mio amico è spesso disciplinato dagli anziani (che sono anche manager dell'azienda) quando il loro lavoro non si adatta alle loro aspettative alla fine di un progetto. Questa è la causa di molto stress per i giovani in questione e sta distruggendo la fiducia che hanno nel proprio lavoro.

Anche se posso vedere i meriti di avere un "farlo bene la prima volta" cultura in un posto di lavoro pieno di sviluppatori senior, sembra un ambiente di lavoro ostile per i giovani che sinceramente non sanno niente di meglio.

Qualcuno può suggerire tecniche per la revisione e il controllo degli errori del proprio lavoro? O in alternativa, strategie per coltivare una sana cultura della revisione "impara sbagliando" sul posto di lavoro?

Dovrei aggiungere che questo è apparentemente un luogo di lavoro amichevole e piacevole e gli anziani sembrano del tutto ragionevole sotto tutti gli altri aspetti, il giovane vorrebbe rimanere in azienda se possibile.

Sembra che il tuo amico sia disciplinato da anziani ... che probabilmente * non * sono il manager o il capo del tuo amico e non sono in grado di disciplinare ... cosa dice il capo del tuo amico?
In questa azienda gli sviluppatori senior sono anche i manager
È una piccola azienda leader di sviluppatori, quindi mentre hanno un manager principale a cui riferiscono, quel manager è colpevole di perpetuare questa cultura.Non c'è nessuno anche più in alto che possa portare il problema, il confronto diretto della questione è purtroppo l'unica opzione.
@Bbbbbbbbbb Quindi, il tuo amico ha più di un manager?Ne ha uno a cui risponde?In altre parole, ha degli anziani che non sono il suo manager?
Perché hanno assunto uno junior se non vogliono gli junior?
@solarflare presumibilmente perché vogliono pagare solo per i junior ma si aspettano la qualità dei mid o senior.Sembra un ambiente incredibilmente tossico.
Tre risposte:
PeteCon
2018-10-04 10:37:13 UTC
view on stackexchange narkive permalink

Sebbene ci siano molti buoni risultati nell'apprendimento del Test Driven Development (TDD) del tuo amico, il fatto che lui / lei sia disciplinato da più manager per non essere all'altezza delle capacità di telepatia significa che questo sembra un luogo di lavoro tossico. La persona che non commette mai errori non fa mai niente.

Il mio consiglio non può che essere quello di fare rapidi passi verso l'uscita. Ci sono posti di lavoro migliori e meno stressanti.

Joe Stevens
2018-10-04 09:25:29 UTC
view on stackexchange narkive permalink

Comprendi che il test del software fa parte di ciò che è essere uno sviluppatore di software

Il lavoro di uno sviluppatore è produrre codice testato , non solo "codice".

È tua responsabilità assicurarti che il codice faccia ciò per cui è inteso e non apporti modifiche a cui non è destinato.

Qualcuno può suggerire tecniche per la revisione e il controllo degli errori del proprio lavoro?

Questa domanda è, in realtà, "come faccio a testare il software?". Questa è, ovviamente, una domanda enorme . Per lo meno, leggi e capisci cosa sono unità, integrazione, test di sistema.

Anche se c'è un team di QA dedicato, sono un controllo di seconda linea, non sostituiscono i tuoi test.

Per ogni modifica, dovresti escogitare una sorta di piano di test, anche in modo informale, e il codice non viene "finito" fino a quando non viene superato. Puoi esaminare lo sviluppo guidato dai test, l'inversione delle dipendenze e le derisioni ; sebbene questi concetti specifici siano spesso portati all'eccesso e possano portare a un terribile rigonfiamento del codice, è comunque bene conoscerli.

strategie per coltivare una sana cultura della revisione "impara dagli errori"

Al momento della revisione e successivamente, devi pensare al perché errori sono stati commessi.

Non solo, "cosa ha fatto Sbaglio nel mio sviluppo "(perché tutti commettono errori), ma" perché i miei test non hanno trovato questo errore ".

Perché quando i tuoi test migliorano, il tuo codice migliora. E gli anziani avranno più fiducia, nel tempo, nella qualità dei tuoi risultati.

Se l'OP spende così tanto tempo a far sì che i suoi test catturino ogni caso limite, i manager lo puniranno solo per l'output di codice basso.Il test degli sviluppatori è importante ma non credo sia sufficiente per soddisfare le aspettative che l'OP ha delineato per questa ridicola azienda.
Non abbiamo modo di sapere quanto siano irragionevoli gli anziani o quanto sia cattivo il codice dell'amico dell'OP.Ognuno è l'eroe della propria storia e potrebbe sembrare diversa dall'altra parte del tavolo.Se c'è davvero tolleranza zero per gli errori e supporto zero, sarei d'accordo che l'amico dell'OP dovrebbe correre.
Non ho mai lavorato a un progetto in cui TDD fosse pratico.Nessuno vuole aspettare il codice o pagare per farti passare ore a scrivere test.Di solito se proponi "Mi piacerebbe dedicare un po 'di tempo a scrivere unit test che garantiscano che questo codice si comporti correttamente", ti viene incontro "Sembra fantastico, ma prima abbiamo una lunga lista di nuove funzionalità che vorremmodi implementare ... "
DarkCygnus
2018-10-04 03:16:32 UTC
view on stackexchange narkive permalink

Qualcuno può suggerire tecniche per la revisione e il controllo degli errori del proprio lavoro? O in alternativa, le strategie per coltivare una sana cultura del "imparare dagli errori" rivedono sul posto di lavoro?

Per prima cosa, devo dire che concordo in parte con il commento di Philip; se queste aspettative malsane e questa disciplina sono lo standard, forse il tuo amico potrebbe considerare di cercare un altro lavoro con un ambiente di lavoro migliore. Ma ciò dovrebbe essere fatto come ultima risorsa.

Alcune strategie che potrebbero aiutare qui sono:

  • Team con altri sviluppatori junior e sottopongono a revisione tra pari il tuo codice . Poiché altri sviluppatori junior sono molto probabilmente in una posizione simile (stanno ancora imparando, sono inclini a fare errori), aiutarsi a vicenda è un buon modo per andare. Non solo rafforzerà le loro relazioni e le dinamiche di lavoro, ma li aiuterà anche a fornire codice di qualità superiore e ad imparare a programmare meglio.

  • Chiedi aiuto prima, don non aspettare la fine del progetto . Dato che il tuo amico viene disciplinato al termine dei progetti, sarebbe una buona idea chiedere aiuto prima, in modo che abbia la possibilità di correggere gli errori prima di consegnare e imparare nel processo.

  • Fai una pausa o passa ad un'altra attività prima di esaminarla . A volte si può diventare offuscati o bruciati quando si lavora continuamente a un progetto. Questo, secondo la mia esperienza, a volte aumenta le possibilità che si perda un dettaglio importante o non si riesca a trovare qualche bug. Mi ha aiutato molto a passare ad altre attività oa fare una pausa prima di cercare bug, poiché si può quindi vederlo con una nuova mentalità.


È vale la pena notare che dichiari quelli che disciplinano il tuo amico sono i suoi colleghi anziani e non il suo capo / manager. È probabile che la maggior parte di loro non sia nella nessuna posizione per disciplinare il tuo amico, perché questo sarebbe un ruolo che il capo dovrebbe assumere .

I colleghi senior possono suggerire o fare da mentore , ma non dovrebbero disciplinare a meno che ciò non faccia parte delle loro responsabilità esplicite. Lo sto notando perché è probabile che i colleghi anziani che non sono il capo del tuo amico stiano cercando di spaventarlo o di scoraggiarlo in questo modo per ragioni sconosciute ...

Sono consapevole.Se leggi attentamente, e non solo una parte, ho detto "i colleghi senior ** che non sono il tuo capo ** stanno cercando di ..."


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...