A che punto le critiche "costruttive" al tuo codice diventano inutili?


39

Di recente ho iniziato come sviluppatore junior. Oltre ad essere una delle persone meno esperte della squadra, sono anche una donna, che si presenta con ogni sorta delle sue sfide lavorando in un ambiente dominato dagli uomini. Ultimamente ho avuto problemi perché sento che sto ricevendo troppe critiche pedanti ingiustificate sul mio lavoro. Lascia che ti faccia un esempio di quello che è successo di recente.

Il team leader era troppo impegnato per spingere in alcuni rami che ho creato, quindi non è riuscito a raggiungerli fino al fine settimana. Ho controllato la mia posta, non intendendo davvero fare alcun lavoro, e ho scoperto che i miei due rami erano stati rifiutati sulla base dei nomi delle variabili, rendendo i messaggi di errore più descrittivi e spostando alcuni valori nel file di configurazione.

Non credo che rifiutare il mio ramo su questa base sia utile. Molte 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 tempo per apportare le modifiche e inviare nuovamente. Stiamo lavorando a un progetto che è molto sensibile al tempo e mi sembra che non sia utile rifiutare completamente il codice basato su elementi trasparenti per il cliente. Potrei sbagliarmi, ma sembra che questo tipo di cose dovrebbero essere gestite nel tipo di patch che commette quando ho tempo.

Ora, posso vedere che in alcuni ambienti, questa sarebbe la norma. Tuttavia, la critica non sembra equamente distribuita, il 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 lo affermai, mi dissero 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 già registrato è inaccettabile, come posso dire cosa è giusto e cosa è sbagliato? Se la base della confusione proveniva dal codice sottostante, non credo che '

Mi sento davvero individuato e frustrato in questa situazione. Sono migliorato molto nel seguire gli standard previsti e sono frustrato dal fatto che, ad esempio, quando refatto un pezzo di codice per AGGIUNGERE il controllo degli errori che in precedenza 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 lo avessi mai aggiunto all'inizio? Come è arrivato nel codice per cominciare se era così sbagliato? Ecco perché mi sento così individuato: mi imbatto costantemente in questo codice problematico esistente, che imito o rifletto. Quando lo imito, è "sbagliato", e se lo refactoring, sono rimproverato per non aver fatto abbastanza (e se vado fino in fondo, introducendo bug, ecc.). Ancora una volta, se questo è un problema, non capisco come un codice possa entrare nella base di codice,

Ad ogni modo, come posso gestirlo? Ricorda che in cima ho detto che sono una donna e sono sicuro che questi ragazzi di solito non devono preoccuparsi del decoro quando rivedono il codice di altri ragazzi, ma onestamente non funziona per me e mi sta rendendo meno produttivo. Sono preoccupato che se ne parlo con il mio manager, penserà che non posso gestire l'ambiente, ecc.


18
Sono un ragazzo, junior (in questa azienda), e ho sentito un doppio standard simile. La base di codice sembra spesso una merda, eppure mi aspetto che segua uno standard molto più elevato. Bene, si è scoperto che la merda è entrata lì a causa di "marce della morte" che sono state fatte in passato. Inoltre, apparentemente sembro 5 anni più giovane di me. Quando i miei colleghi hanno scoperto la mia vera età, sono diventato molto più intelligente durante la notte. Gli umani sono scimmie imperfette. Aiuta se condividi il pranzo con loro e ridi alle loro battute, ma non esagerare. I ragazzi interpretano TUTTO come un flirt.
Giobbe

4
@Job: Beh, se la base di codice è una schifezza dovrebbe essere migliore, quindi i tuoi commit devono avere uno standard più elevato. Altrimenti sarebbe diventato ancora più schifoso, giusto? :)
Macke,

@Marcus, hai ragione, ma ciò che sarebbe davvero utile sarebbe se le regole fossero chiaramente indicate e le stesse regole fossero applicate a tutti. Inoltre, c'è qualcosa da dire sulla fusione con gli stessi standard di codice, come menzionato dal richiedente. Ho visto un ragazzo minore lasciarsi andare come capro espiatorio. Il management si è lamentato del fatto che gli ingegneri hanno prodotto troppi bug. Gli ingegneri non sono stati in grado di svolgere un lavoro dignitoso perché la direzione ha dato loro scadenze fisse. Quindi, quando qualcosa va storto, c'è sempre un ragazzo più giovane con il maggior numero di problemi da incolpare e lasciarsi andare. en.wikipedia.org/wiki/Dedovshchina
Giobbe

3
Una cosa che mi ha colpito è "Sono abituati ai ragazzi, quindi non usano il decoro". Direi che devi risucchiarlo a meno che non sia chiaramente un problema di discriminazione. Andresti in un cantiere e ti aspetteresti di essere trattato in modo diverso rispetto al resto dei corniciai? Irrigidito. Se lavori in un ambiente dominato dagli uomini, devi essere in grado di far fronte e adattarti alle diverse norme sociali proprio come devono. Non essere così "sensibile".
Rig

1
So che è in ritardo di diversi anni, ma penso che questo sia un argomento importante per i futuri lettori. Non escludere la possibilità che il tuo team leader semplicemente conosca meglio; è probabilmente più anziano e ha sviluppato un'intuizione per problemi di stile problematico - sfido chiunque in questa situazione a considerare questo come un'opportunità per imparare e crescere. Chiedi rispettosamente chiarimenti su questioni che non capisci e fai attenzione a non interpretare male la personalità arida di un collega come dannosa.
weberc2,

Risposte:


41

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

Il controllo degli errori e i messaggi espressivi sono importanti. Se hai intenzione di aggiungere qualcosa al codice, assicurati che sia corretto e conforme agli standard del team. Allo stesso modo, se stai modificando il codice di qualcun altro, cerca di migliorarlo ove possibile - non andare a riscrivere il tutto, ma cerca di lasciarlo un po 'più pulito di quanto lo hai trovato.

Esiste una versione scritta degli standard di codifica che il tuo team segue? 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 modifiche per la revisione. Come effetto collaterale, puoi usare quello standard scritto per fare appello a futuri rifiuti se lo contraddicono.

Sembra che ci possa essere una certa mancanza di comprensione tra te e il capo squadra. Potrebbe esserti utile chiedere un incontro individuale con lui e discutere cosa puoi fare per migliorare. Puoi iniziare con qualcosa del tipo "Sento che mi mancano ancora molte sfumature di ciò che dovrei fare. Come sviluppatore junior voglio crescere e migliorare. Puoi aiutarmi ad arrivarci?" e vedi cosa succede.


Le risposte di Anna sono generalmente molto ragionevoli. +1. Penso che lavorare dove lavori mi farebbe impazzire. Il tuo management non si preoccupa di rispettare le scadenze? Se il codice funziona, spediscilo. Puliscilo più tardi. Diamine, potresti anche ripulirlo lunedì e farcela nella prossima versione. Questo comportamento del tuo manager non volerebbe mai nel mio posto di lavoro e sono contento di essere in grado di concentrarmi sul rispetto delle scadenze anziché sulla politica. Spero che la tua situazione migliori e che tu trovi una soluzione. :)
jmort253,

11
@ jmort253 Grazie. :) Detto questo, "se il codice funziona, spediscilo" può essere un atteggiamento pericoloso da avere. Il codice di lavoro non è sempre un buon codice (sebbene sia certamente migliore del codice non funzionante) e la qualità del codice è importante a lungo termine. La pulizia successiva non accade quasi mai, poiché compaiono altre scadenze e emergono cose più urgenti. C'è un termine per questo - "debito tecnico".
Adam Lear

@Anna, concorda sull'importanza del codice conforme. Ho letto che il codice non conforme è sufficiente per Linus Thorvalds per rifiutare una patch inviata per Linux sul posto (ma non riesco a trovarla in questo momento).

@ Anna / Thorbjorn - A volte devi solo fare quello che vuole il cliente se c'è una scadenza. Il tuo cliente non capirà molto se ha perso $ 15.000 di entrate commerciali perché volevi semplicemente ripulire gli errori di capitalizzazione. Purtroppo, cercare di eliminare il 100% del debito tecnico non è sempre possibile. Sarebbe simile ad aspettare 40 anni per risparmiare abbastanza denaro per acquistare la casa dei tuoi sogni invece di stipulare un mutuo. Certo, saresti libero e chiaro, ma avresti passato tutta la vita a occuparti di loschi proprietari terrieri.
jmort253,

I progetti open source sono diversi da quelli a scopo di lucro. Molti progetti open source possono permettersi di avere standard più severi perché non sempre si possono avere / perdere profitti. I progetti proprietari hanno obiettivi diversi e, a volte, tali obiettivi aziendali hanno la precedenza. Non sto dicendo che il codice non dovrebbe essere conforme, solo che a volte devi solo fare quello che devi fare e avere la disciplina per tornare indietro e risolvere il problema dopo la distribuzione.
jmort253,

25

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

Le ragioni del rifiuto del check-in (denominazione variabile, qualità dei commenti, posizione della configurazione) mi sembrano piuttosto standard.

Il tempismo è stata la decisione del capo della tua squadra, e non mi preoccuperei se fossi in te. Se qualcuno viene bloccato durante il fine settimana, il responsabile della squadra potrebbe scegliere di consentire il check-in e chiederti di risolverlo in seguito. Se lo ritiene opportuno respingerlo anche se potrebbe bloccare alcuni altri sviluppatori, questa è la sua responsabilità.

Per quanto riguarda il team leader 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. Questo è un buon segno. Si fida di usare il tuo giudizio, quindi vai avanti e fai ciò che sai è giusto. Ciò non significa che devi cambiare il codice di tutti gli altri, ma significa che dovresti assumerti la responsabilità della qualità del codice che scrivi.


2
+1 Ti stai concentrando sulle relazioni e le emozioni. I programmatori con cui lavori hanno un suono molto secco ma si stanno solo concentrando sui problemi del codice. Questo è abbastanza comune negli ambienti di programmazione in cui ho lavorato. L'ho visto a prescindere dal genere.
Michael Durrant,

14

Un'aggiunta alle altre risposte:

Come sviluppatore principale, di solito sono più esigente con gli sviluppatori junior perché sono molto più malleabili rispetto alle persone che lavorano da alcuni anni. (Le mie capacità di ppl non sono così buone ... ancora.)

È molto difficile cambiare qualcuno che ha lavorato (e ha guadagnato un salario decente) per un po 'ed è soddisfatto del suo livello di codice (anche se la qualità potrebbe essere migliorata). A quei ragazzi non importa se cerchi di guidarli a diventare programmatori migliori / fantastici. Sono felici di lavorare nella fabbrica del codice.

I nuovi ragazzi, come te, OTOH, di solito desiderano avere una guida e sapere cosa è giusto e non. Inoltre, sono in grado di assorbire lo storno di addebito e cambiare le loro vie in meglio. Non sono impostati in altri modi.

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

Così ...

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


Ciò solleva molti punti positivi.
sevenseacat,

13

È del tutto possibile che tu sia scelto 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 questo è lo standard, seguilo.
  • Se non capisci lo standard, chiedi chiarimenti.
  • Se la tua interpretazione dello standard o delle istruzioni differisce da quella del capo squadra, chiedi chiarimenti

Non farne una battaglia; se provi a far "sbagliare" la squadra, allora anche se vinci, perdi. Impara la lezione appropriata e continua a crescere.


1
Cercare di seguire un po 'di "standard" con la "T" quando uno ha a che fare con i coglioni come lei descrive non farà molto bene. Sarà una discussione infinita su definizioni e semantica.
MrDatabase,

4
@MrDatabase Per me non sembrano molto carini. Un po 'esigente, forse, ma il diavolo è spesso nei dettagli e una volta che inizi a sfuggire ai tuoi standard, l'intera app può andare in discesa velocemente.
Adam Lear

3
È vero che gli standard dovrebbero essere rispettati. Tuttavia dimostra chiaramente che non è proprio uno standard (gli sviluppatori precedenti non vi aderivano). Quindi i suoi colleghi che le impongono lo "standard" (senza dire qualcosa come "hey guarda ... sappiamo che sembra incoerente ma stiamo davvero cercando di migliorare la nostra base di codice") è ipocrita e inutile. Quando i colleghi si comportano in questo modo, devi adottare un approccio diverso e più intelligente.
MrDatabase,

@ user15859: se ti riferisci alla mia risposta, non era affatto mia intenzione. Credo di aver detto esattamente la stessa cosa che ha detto Anna nella sua risposta. Non era prevista alcuna infrazione. Le violazioni degli standard menzionate sono importanti per la manutenzione a lungo termine e qualsiasi ambiguità nell'ambito di applicazione degli standard deve essere risolta con il responsabile del team. Se fossi pigro non avresti pubblicato qui. Se fossi incompetente non ti importerebbe così tanto. Non credo che tu sia uno di quelli.
Steven A. Lowe,

1
Penso che si stia riferendo a ciò che Woot4Moot ha detto mentre usa "pigrizia e incompetenza" come frase nel suo commento. Penso che la tua risposta vada bene in quanto dà all'OP un ricorso e spazio per agire sulla base della sua interpretazione di ciò che sta realmente accadendo.
jmort253,

10

Nota dell'autore

Pochi anni dopo; L'ho modificato per riflettere in modo più preciso ciò che provo per la situazione. Sto aggiungendo più sfumature alla mia risposta perché sto imparando di più sulla sfumatura in queste situazioni. È facile rivendicare una risposta "in bianco o nero", ma sappiamo tutti che non è così semplice. La mia risposta ora riflette questo.

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

Quando ero a capo di una squadra, trattavo tutti allo stesso modo. Non c'è spazio nella tecnologia per trattare male qualcuno a causa del suo genere. Non so come affrontarlo se ti sta succedendo.

È importante che ti fidi che il capo del tuo team tratta allo stesso modo uomini e donne. Se ci sono prove che non lo è, si applica il vecchio detto: Cambia il tuo ambiente o il tuo ambiente.

Allo stesso modo intendo che tratta tutti allo stesso modo senza rispetto per il genere. Se sta facendo il suo lavoro correttamente, non dovresti vederlo criticare nessun altro; e non dovrebbero vederlo mentre ti critica. Di fronte agli altri, è molto importante che il caposquadra mostri fiducia, anche se ha appena trascorso gli ultimi cinque minuti prima di correggere il comportamento in privato.

Passiamo ora ai problemi che hai sollevato:

Hai controllato il codice che non soddisfaceva lo standard da lui stabilito, 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 (parola strana; perché non penso a un leader come "superiore" alle persone che condurre; ma descrive accuratamente (non adeguatamente) la situazione) sapere qual è la cosa giusta da fare. Se non sanno quali sono gli standard, è colpa mia come leader. Sta a me correggerlo. In questo caso, potresti aver commesso un errore, ma il solo fatto che è successo significa che o non hai detto quale fosse la cosa giusta da fare o 2) non è stato adeguatamente istruito. Né è colpa tua.

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

Se il tuo team ha scritto linee guida per la codifica, seguile. In caso contrario, dovrebbe esserci una sorta di convenzione della comunità per il tuo linguaggio (per .NET e C #, Microsoft ha uno standard che molte aziende seguono).

Chiedi al tuo team leader dove sono le linee guida per la codifica in modo da poter essere sicuro di seguirle. Porta due check-in alle tue riunioni in cui altri due sviluppatori non hanno seguito costantemente le linee guida, in modo che quando dice che non ce ne sono, puoi sottolineare che anche altri sembrano avere problemi con esso, e tutti trarrebbero beneficio dall'avere tali linee guida.

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

Dire "Ci arriverò più tardi" è male. 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 molte persone che ti guardano, e ogni errore che fai è legato al tuo nome nel controllo del codice sorgente per sempre.


1
Ricercherò il commento su "Ci arrivo più tardi". Se avessi un nichel per ogni volta che l'ho sentito, beh, non sarei qui a digitare questo commento. :-)
Eric King,

Per .Net esiste uno stile poliziotto. Attivalo, in modo che il codice non venga compilato fino a quando StyleCop non è soddisfatto. Ciò rimuove la soggettività umana dal bullismo della forza lavoro. Vedi, la tecnologia può aiutarti a decidere se Michael Phelps era il numero 1 o il numero 2. Nel pattinaggio di figura, tuttavia ... figureskating.about.com/od/famousskaters/tp/scandals.htm Essere al comando di una squadra non dovrebbe riguardare il power-trip. Non ci dovrebbero essere [dis-] favoriti in una squadra. Bisogna fare attenzione per assicurarsi che tale impressione non si formi. Un buon modo per farlo è attivare le regole che verifichino il codice e diano una risposta imparziale.
Giobbe

3

In nessun punto del tuo post fai riferimento a 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 a prescindere dal tuo genere e dovresti esserne grato, perché è questo che significa uguaglianza. Sento anche che stai facendo un grande clamore per i piccoli cambiamenti estetici del codice della durata di 5 minuti che ti viene chiesto di fare ora invece di metterli in un elenco di cose da fare e di non aggirarli mai.

In nessun posto del tuo post hai menzionato che ti è stato ordinato di fare queste cose nel fine settimana. Potrebbe essere perfettamente corretto controllare le correzioni lunedì mattina.

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

Per favore, smetti di giocare la carta del genere per niente . Ritengo che ciò non sia dignitoso e mina il concetto di uguaglianza di genere.


1

Non credo che rifiutare il mio ramo su questa base sia utile. Molte 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 tempo per apportare le modifiche e inviare nuovamente. Stiamo lavorando a un progetto che è molto sensibile al tempo e mi sembra che non sia utile rifiutare completamente il codice basato su elementi trasparenti per il cliente. Potrei sbagliarmi, ma sembra che questo tipo di cose dovrebbero essere gestite nel tipo di patch che commette quando ho tempo.

È 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 comportamento si comporta in modo responsabile e fa un buon lavoro, lo sa, che gli altri non sono stati davvero bloccati e lo sprint non sarà in ritardo. Quindi, non preoccuparti. Forse sopravvaluti l'impatto sul tuo impegno. Altrimenti: se il tuo progetto è critico in termini di tempo e supera tutti i test, sarebbe troppo esigente per rifiutare il codice, che potrebbe essere risolto dopo il rilascio in un batter d'occhio.

Fallo funzionare Fallo giusto Fallo veloce

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

Ora, posso vedere che in alcuni ambienti, questa sarebbe la norma. Tuttavia, la critica non sembra equamente distribuita, il 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 lo affermai, mi dissero senza mezzi termini: "Non imitare gli altri, fai solo ciò che è giusto".

Come Junior è difficile trovare una strada nel codice di una società.

Migliore: ce ne sono documentati standard di codifica - e speriamo che imparerai a controllarli.

Di solito: ci sono standard di codifica non documentati - e devi imparare attraverso prove ed errori 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 alla programmazione di culto del carico , in cui non solo si imita denominazione variabile, ma si copia e incolla strutture e modelli dalla base di codice in buona fede, deve essere fatto così. Non farlo! Non imitare nemmeno i nomi delle variabili esistenti.

Attenersi al codice pulito . È una buona pratica e ti dà una posizione facile da difendere. Se è un codice leggibile, verificabile e gestibile, hai vinto per lo più qualsiasi discussione.

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

Lasciare sempre la base di codice in uno stato migliore di quello che era. Anche se il codice circostante con cui stai lavorando è cattivo, pulisci il tuo e se hai tempo aggiusta l'ambiente.


0

Prenditi un po 'di tempo per imparare le varie sfumature delle personalità dei tuoi colleghi. Nella mia esperienza puoi evitare critiche irrazionali, inutili, incoerenti o semplicemente inutili se aggiri le stranezze dei tuoi colleghi.

Ad esempio alcuni colleghi potrebbero essere a posto i postumi della sbornia il lunedì. Possono essere molto irritabili e troppo desiderosi di rifiutare determinati rami di codice o commit. Se devi lavorare con qualcuno come questo, cerca di evitare di inserire il codice il lunedì.

D'altra parte un collega con i postumi della sbornia potrebbe essere troppo blase per preoccuparsi della verbosità dei messaggi di errore ... quindi lunedì mattina potrebbe essere il momento perfetto per impegnare 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 uscire e trovare un altro lavoro!


1
Trova il lavoro prima di smettere, molti responsabili delle assunzioni non intervisteranno nemmeno se non sei impiegato.
Woot4Moo,

-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 lavoro 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 il codice pulito e gli standard non siano importanti, ma il cliente e la sequenza temporale del prodotto non dovrebbero soffrire a causa di un errore di ortografia in qualcosa che nessuna persona non tecnica, cliente o dirigente vedrà mai.

Detto questo, sembra che tu stia lavorando in un ambiente in cui le aspettative non sono chiare o non capisci completamente i requisiti, per qualsiasi motivo.

Indipendentemente dalla situazione, spetta a te prendere il controllo e porre domande chiarificatrici. Sii proattivo, se non lo sei già. I membri del team e il team leader probabilmente ti rispetteranno maggiormente per fare domande per chiarire le regole per il check-in. Potresti anche chiedere una "revisione post-azione" in cui tu e il tuo team leader discutete su cosa avreste dovuto fare e su come può dire la differenza per quanto riguarda quando intraprendere determinate azioni e quando non farlo.

Suggerirei di dedicare del tempo, visto che sei nuovo, a vedere se riesci a superare eventuali 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 afflitto da ambiguità, potrebbe essere il momento di cercare lavoro in un'altra azienda.

Non tutte le organizzazioni sono così draconiane e potresti trovare altri ambienti di lavoro più adatti alle tue esigenze di personalità, stile e comunicazione.


2
Questo non sembra "draconiano"; la coerenza è un componente importante della manutenibilità, la manutenibilità è un componente importante della qualità e il software di qualità ha una probabilità molto maggiore di spedire in tempo e ad un costo inferiore rispetto al "codice di compromesso". Potrebbe essere incoraggiante che qualcosa come l'80% delle aziende di software sia desideroso di compromettere la qualità e subirne le conseguenze, quindi non sembra esserci alcuna carenza di opportunità di lavoro "non draconiane". :)
weberc2

1
Non vorrei lavorare in un ambiente in cui le convenzioni di base non vengono applicate. Se un progetto rinuncia a difendere le sue linee guida sulla codifica, è destinato a diventare non sostenibile a lungo termine. Soprattutto la denominazione delle variabili non è cosa da poco: non importa quanto codice esistente chiama una certa matrice A, non accetterei mai un commit che chiama un'altra matrice Bper coerenza. Ovviamente, non so cosa intendesse l'OP "imitando i nomi [...] usati altrove", tuttavia, data la qualità di un codice che ho visto, potrebbe essere su questa linea.
cmaster
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.