A che punto la critica "costruttiva" del tuo codice diventa inutile?

37

Recentemente ho iniziato come sviluppatore junior. Oltre ad essere una delle persone meno esperte nel team, sono anche una donna, che ha a che fare con ogni sorta di sfide da affrontare in un ambiente dominato dagli uomini. Ultimamente ho avuto problemi perché ritengo di avere troppe critiche pedanti ingiustificate per il mio lavoro. Permettetemi di darvi un esempio di cosa è successo di recente.

Il team lead era troppo impegnato per spingere in alcuni rami che ho fatto, quindi non li ha raggiunti fino al weekend. Ho controllato la mia posta, non intendendo davvero alcun lavoro, e ho scoperto che i miei due rami erano stati rifiutati sulla base di nomi di variabili, rendendo i messaggi di errore più descrittivi e spostando alcuni valori nel file di configurazione.

Non sento che rifiutare il mio ramo su questa base sia utile. Un sacco di persone lavoravano durante il fine settimana e non avevo mai detto che avrei lavorato. In effetti, alcune persone sono state probabilmente bloccate perché non avevo il tempo di apportare le modifiche e di inviare nuovamente. Stiamo lavorando a un progetto che è molto sensibile al fattore tempo e mi sembra che non sia utile rifiutare completamente il codice in base a cose che sono trasparenti per il cliente. Potrei sbagliarmi, ma sembra che questo tipo di cose debbano essere gestite quando si ha il tempo.

Ora, posso vedere che in alcuni ambienti questa sarebbe la norma. Tuttavia, la critica non sembra equamente distribuita, che è ciò che porta al mio prossimo problema. La base della maggior parte di questi problemi era dovuta al fatto che ero in una base di codice che qualcun altro aveva scritto e cercava di essere minimamente invasivo. Stavo imitando i nomi delle variabili usati altrove nel file. Quando ho affermato questo, mi è stato detto senza mezzi termini, "Non imitare gli altri, fai solo ciò che è giusto." Questa è forse la cosa meno utile che avrei potuto dire. Se il codice che è già archiviato è inaccettabile, come dovrei dire cosa è giusto e cosa è sbagliato? Se la base della confusione provenisse dal codice sottostante, non penso che sia mia responsabilità passare ore a refactoring di un intero file che qualcun altro ha scritto (e funziona perfettamente), potenzialmente introducendo nuovi bug ecc.

Mi sento davvero spiazzato e frustrato in questa situazione. Sono diventato molto più bravo nel seguire gli standard previsti, e mi sento frustrato perché, ad esempio, quando refactoring un pezzo di codice per AGGIUNGERE il controllo degli errori che prima mancava, mi viene solo detto che non l'ho fatto rendere gli errori abbastanza dettagliati (e il ramo è stato respinto su questa base). E se non l'avessi mai aggiunto all'inizio? Come è entrato nel codice per cominciare se era così sbagliato? Questo è il motivo per cui mi sento così spiazzato: mi imbatto costantemente in questo codice problematico esistente, che io imito o refactoring. Quando lo imito, è "sbagliato", e se lo rifatto, sono rimproverato di non aver fatto abbastanza (e se vado fino in fondo, introducendo bug, ecc.). Anche in questo caso, se questo è un problema, non capisco come qualsiasi codice entri nella base di codice e perché diventi la mia responsabilità quando è stato scritto da qualcun altro, che apparentemente non ha recensito il suo codice.

Ad ogni modo, come faccio a gestire questo? Per favore ricorda che in cima ho detto che sono una donna, e sono sicuro che questi ragazzi di solito non devono preoccuparsi del decoro quando stanno rivedendo il codice di altri ragazzi, ma onestamente questo non funziona per me e mi sta facendo essere meno produttivo. Sono preoccupato che se parlerò con il mio manager, penserà che non posso gestire l'ambiente, ecc.

    
posta user15859 06.02.2011 - 03:32
fonte

9 risposte

41

C'è una possibilità che tu venga scelto come donna, ma è anche possibile che tu sia solo uno sviluppatore junior e nuovo al lavoro.

I messaggi di controllo degli errori e espressivi sono importanti. Se vuoi aggiungere qualcosa al codice, assicurati che sia giusto e all'altezza degli standard del team. Allo stesso modo, se stai modificando il codice di qualcun altro, cerca di migliorarlo laddove possibile - non esitare a riscrivere il tutto, ma cerca di lasciarlo un po 'più pulito di quello che hai trovato.

Esiste una versione scritta degli standard di codifica seguiti dal tuo team? In caso contrario, potrebbe essere una buona idea scrivere tutto. Puoi guidare lo sforzo scrivendo gli errori che fai e formandoli in una lista di controllo a cui puoi fare riferimento prima di inviare le tue modifiche per la revisione. Come effetto collaterale, puoi usare quello standard scritto per appellarti a futuri rifiuti se lo contraddicano.

Sembra che ci possa essere una mancanza di comprensione tra te e il capo della squadra. Potrebbe essere utile per te chiedere un incontro individuale con lui e discutere cosa puoi fare per migliorare. Puoi farcela con qualcosa del tipo "Mi sento come se mi mancassero ancora molte sfumature di quello che dovrei fare, in quanto sviluppatore junior voglio crescere e migliorare, puoi aiutarmi ad arrivare?" e guarda cosa succede.

    
risposta data 06.02.2011 - 04:33
fonte
25

Sembra che tu stia prendendo questa roba un po 'troppo sul personale. non lo fanno; questo genere di cose succede sempre.

I motivi del rifiuto del check-in (denominazione delle variabili, qualità dei commenti, posizione della configurazione) mi sembrano abbastanza standard.

La tempistica di questa scelta è stata la decisione della tua squadra, e non mi preoccuperei se fossi in te. Se qualcuno è bloccato durante il fine settimana, il responsabile della squadra potrebbe scegliere di consentire il check-in e chiederti di ripararlo in seguito. Se ha ritenuto opportuno respingerlo anche se potrebbe bloccare altri sviluppatori, questa è la sua responsabilità.

Per quanto riguarda la guida della squadra che ti dice di non imitare gli altri ma di fare ciò che è giusto, sembra che stia cercando di darti qualche iniziativa per migliorare la base di codice. È un buon segno Si fida di te per utilizzare il tuo giudizio, quindi vai avanti e fai quello che sai essere giusto. Ciò non significa che devi cambiare il codice di tutti gli altri, ma significa che devi assumerti la responsabilità della qualità del codice che scrivi.

    
risposta data 06.02.2011 - 04:33
fonte
13

È del tutto possibile che tu venga individuato perché ... sei uno sviluppatore junior.

Dalla tua descrizione, sembra che tu non abbia seguito lo standard mentre il team leader lo percepisce .

La soluzione è semplice:

  • Se è lo standard, seguilo.
  • Se non comprendi lo standard, chiedi dei chiarimenti.
  • Se la tua interpretazione dello standard o delle istruzioni differisce da quella del team, chiedi chiarimenti

Non fare una battaglia fuori di esso; se provi a far "sbagliare" la squadra, anche se vinci, perdi. Impara la lezione appropriata e continua a crescere.

    
risposta data 06.02.2011 - 04:01
fonte
13

Un'aggiunta alle altre risposte:

Come Lead Developer, di solito sono più esigente con gli sviluppatori junior perché sono molto più malleabili di quelli che lavorano da alcuni anni. (Le mie capacità ppl non sono poi così buone ...)

È molto difficile cambiare qualcuno che ha lavorato (guadagnando uno stipendio decente) per un po 'ed è soddisfatto del suo livello di codice (anche se la qualità potrebbe essere migliorata). A quei ragazzi non interessa se provi a guidarli a diventare migliori / grandi programmatori. Sono felici di lavorare nel codice di fabbrica.

I nuovi ragazzi, come te, OTOH, di solito desiderano una guida e sanno cosa è giusto e cosa no. Inoltre, sono in grado di assorbire il feeback e cambiare i loro modi in meglio. Non sono impostati in questo modo.

Se prendi a cuore questi consigli e li rendi parte della tua vita quotidiana, scoprirai che in pochissimo tempo dovrai scrivere un codice che è superiore a gran parte della base di codice esistente.

Quindi ...

.. potrebbe essere che stai ricevendo più feedback solo perché hai il potenziale per farne qualcosa. :)

    
risposta data 06.02.2011 - 12:57
fonte
10

Nota dell'autore

A few years later; I've edited this to more accurately reflect how I feel about the situation. I'm putting more nuance into my answer because I'm learning more about nuance in these situations. It's easy to claim a 'black or white' answer, but we all know it isn't that simple. My answer now reflects that.

Da ciò che hai descritto; il comportamento che stai riscontrando non sembra avere nulla a che fare con il tuo genere. Questo non vuol dire che non stai vivendo alcun trattamento legato al genere (spero che tu non lo sia), solo che quello che descrivi non sembra essere correlato al genere.

Quando ero a capo della squadra, ho trattato tutti allo stesso modo. Non c'è spazio nella tecnologia per trattare male qualcuno a causa del loro genere. Non so come gestirlo se ti sta succedendo.

È importante che ti fidi che il tuo team guidi allo stesso modo uomini e donne. Se ci sono prove che non lo sono, allora vale il vecchio detto: cambia il tuo ambiente o cambia il tuo ambiente.

Allo stesso modo intendo che tratta tutti allo stesso modo senza deferenza verso il genere. Se sta facendo il suo lavoro correttamente, non dovresti vederlo criticare qualcun altro; e loro non dovrebbero vederlo criticarti. Di fronte agli altri, è molto importante per il leader del team mostrare sicurezza, anche se ha appena trascorso gli ultimi cinque minuti prima di correggere il comportamento in privato.

Passati ai problemi che hai sollevato:

Hai verificato il codice che non rispettava lo standard che aveva definito, quindi ha rifiutato la tua filiale. Se fossi nei suoi panni, non avrei fatto la stessa cosa allo stesso modo, ma mi sarei assicurato che i miei subordinati (strana parola, perché non penso a un leader come "superiore" alle persone che piombo, ma con precisione (non adeguatamente) descrive la situazione) sapere qual è la cosa giusta da fare. Se non sanno quali sono gli standard, è colpa mia come leader. Spetta a me correggerlo. In questo caso, potresti aver commesso un errore, ma il semplice fatto che sia successo significa che tu eri o 1) non ha detto quale sia la cosa giusta da fare o 2) non è stato appropriatamente mentorato. Neanche è colpa tua.

Una delle parti più importanti dell'essere un programmatore è la consapevolezza che il codice base su cui lavori deve essere gestito da molte persone diverse. Eventuali errori di messaggistica variabili o altre cose che riducono la possibilità di leggere il codice non sono trasparenti per il cliente , perché richiede più tempo per correggere i problemi nel codice che è più difficile da leggere.

Se la tua squadra ha scritto le linee guida sulla programmazione, seguili. In caso contrario, dovrebbe esserci una sorta di convenzione di comunità per la tua lingua (per .NET e C #, Microsoft ha uno standard seguito da molte aziende).

Chiedi al tuo team di piombo dove sono le linee guida sulla codifica in modo da poter essere sicuro di seguirle. Prendi due check-in per le tue riunioni in cui altri due sviluppatori non seguono coerentemente le linee guida, in modo che quando dice che non ce ne sono, puoi far notare che anche altri sembrano avere problemi con loro, e tutti trarrebbero vantaggio dall'avere quelle linee guida.

Se ti tratta in modo equo, allora vedrà questo e questo dovrebbe essere in cima alla sua lista di cose da fare. Se non ti tratta in modo equo, allora hai munizioni se continua a succedere.

Dire "ci arriverò dopo" è sbagliato. Più tardi non succede mai. Prenditi il tempo per farlo bene. Non c'è più tardi nella programmazione.

È difficile quando sei uno sviluppatore junior. Ti senti sotto pressione per esibirti e ci sono un sacco di persone che ti guardano, e ogni errore che fai è legato al tuo nome nel controllo del codice sorgente per sempre.

    
risposta data 06.02.2011 - 04:33
fonte
3

In nessuna parte del tuo post hai menzionato come vengono trattati gli altri. Continui a ripetere che "senti" di essere "individuato" perché sei "una donna".

Penso che tu sia trattato come un programmatore junior indipendentemente dal tuo genere e dovresti essere grato per questo, perché questo è ciò che significa uguaglianza. Sento anche che stai facendo un enorme clamore su modifiche estetiche minori di 5 minuti del codice che ti viene chiesto di fare ora invece di metterle in una lista di cose da fare e non farle mai circolare.

In nessuna parte del tuo post hai detto che ti è stato ordinato di fare queste cose durante il fine settimana. Potrebbe essere perfettamente corretto controllare le correzioni il lunedì mattina.

Il tuo team potrebbe essere un po 'pedante per i miei gusti, ma dal tuo post non vedo nulla di sbagliato nelle sue richieste.

Si prega di interrompere la riproduzione del genere per niente . Ritengo che ciò non sia dignitoso e mina il concetto di uguaglianza di genere.

    
risposta data 21.03.2015 - 12:57
fonte
1

I don't feel that rejecting my branch on this basis is useful. Lots of people were working over the weekend, and I had never said that I would be working. Effectively, some people were probably blocked because I didn't have time to make the changes and resubmit. We are working on a project that is very time-sensitive, and it seems to me that it's not helpful to outright reject code based on things that are transparent to the client. I may be wrong, but it seems like these kinds of things should be handled in patch type commits when I have time.

È difficile dire qualcosa di utile come qualcuno che non ha visto il tuo codice né sa qualcosa sulla pianificazione dei tuoi progetti. Ma se il tuo capo si comporta in modo responsabile e fa un buon lavoro, sa che gli altri non sono stati bloccati e lo sprint non sarà in ritardo. Quindi, non ti preoccupare di questo. Forse hai sopravvalutato l'impatto sul tuo commit. Altrimenti: se il tuo progetto è critico nel tempo e passa tutti i test, sarebbe troppo schizzinoso rifiutare il codice, che potrebbe essere corretto dopo il rilascio in un batter d'occhio.

Fai in modo che faccia in modo che sia veloce

Quindi, se il tuo lead ha preso la decisione di rifiutare il tuo commit, come un professionista dovrebbe sapere, cosa stava facendo.

Now, I can see that in some environments, this would be the norm. However, the criticism doesn't seem equally distributed, which is what leads to my next problem. The basis of most of these problems was due to the fact that I was in a codebase that someone else had written and was trying to be minimally invasive. I was mimicking the variable names used elsewhere in the file. When I stated this, I was bluntly told, "Don't mimic others, just do what's right."

Come Junior è difficile trovare la propria strada in una base di codice aziendale.

Migliore: ci sono degli standard di codifica documentati e spero che imparerai a farcela.

Di solito: ci sono degli standard di codifica non documentati - e devi imparare tramite trial e errore o dovrei dire commit e _reject? Questo è spesso doloroso (come nel tuo caso). Questo a volte è pericoloso in termini di qualità del codice e potrebbe portare a programmazione settoriale del carico , dove uno non solo imita la denominazione delle variabili, ma copia e incolla strutture e motivi dalla base del codice in buona fede, deve essere fatto in questo modo. Non farlo! Non imitare nemmeno la denominazione delle variabili esistente.

Segui Pulisci codice . È una buona pratica e ti dà una posizione facile da difendere. Se è leggibile, testabile e manutenibile, per lo più hai vinto qualsiasi discussione.

E questo porta a un altro (l'ultimo) consiglio: Segui la regola del boy scout !

Lascia sempre il codebase in uno stato migliore di quello che era. Anche se il codice circostante con cui stai lavorando è sgradevole, rendi il tuo pulito - e se hai tempo a sistemare l'ambiente circostante.

    
risposta data 21.03.2015 - 09:34
fonte
0

Prenditi un po 'di tempo per imparare le varie sfumature delle personalità dei tuoi colleghi. Secondo la mia esperienza, puoi evitare critiche irrazionali, inutili, incoerenti o semplicemente inutili se lavori attorno alle tue stranezze da colleghi.

Ad esempio, alcuni colleghi potrebbero essere affamati di lunedì. Possono essere molto irritabili e eccessivamente desiderosi di rifiutare determinati rami o commit di codice. Se devi lavorare con qualcuno come questo, cerca di evitare di scrivere codice il lunedì.

D'altra parte un collaboratore sborniato può essere troppo blasé per preoccuparsi della verbosità dei messaggi di errore ... quindi lunedì mattina potrebbe essere il momento perfetto per commettere il tuo codice :-p

Le stranezze della personalità in ufficio o sul posto di lavoro sono letteralmente infinite. Spero che tu possa imparare chi evitare e quando evitarli. Inoltre, non essere troppo duro con te stesso :-) Puoi sempre smettere e trovare un altro lavoro!

    
risposta data 06.02.2011 - 04:11
fonte
-2

Non ho mai lavorato in un ambiente in cui il codice viene rifiutato sulla base del fatto che alcune convenzioni non vengono seguite. Se fossi nei tuoi panni, sarei tentato di cercare un impiego in un posto in cui sono più autorizzato a prendere le giuste decisioni e in cui il cliente è l'obiettivo principale, non il codice.

Non sto dicendo che codice pulito e standard non siano importanti, ma il cliente e la tempistica del prodotto non dovrebbero soffrire a causa di un errore di ortografia in qualcosa che nessuna persona, cliente o dirigente non tecnico ha intenzione di vedere.

Detto questo, sembra che tu possa lavorare in un ambiente in cui le aspettative non sono chiare, o non comprendi pienamente i requisiti, per qualsiasi motivo.

Indipendentemente dalla situazione, sta a te prendere il controllo e chiedere chiarimenti. Sii proattivo, se non lo sei già. I membri del team e il team lead probabilmente ti rispetteranno di più per fare domande per chiarire le regole per il check-in. Potresti anche chiedere una "revisione post-intervento" in cui tu e il tuo team discutete cosa invece dovreste fare e come può dire la differenza fino a quando prendere certe azioni e quando no.

Suggerirei di dargli il tempo, dal momento che sei nuovo, per vedere se riesci a superare tutti gli ostacoli e risolvere questi problemi con esperienza, comunicazione e apprendimento degli standard. Tuttavia, se dopo diversi mesi la situazione non è cambiata e l'ambiente è ancora tormentato dall'ambiguità, potrebbe essere il momento di cercare lavoro in un'altra azienda.

Non tutte le organizzazioni sono draconiane e potresti trovare altri ambienti di lavoro più adatti alla tua personalità, stile e requisiti di comunicazione.

    
risposta data 06.02.2011 - 07:02
fonte

Leggi altre domande sui tag