Non sei un fiocco di neve speciale né lavori sotto vuoto

le mie migliori pratiche

A meno che tu non sia il tuo manager, non lo fai arrivare a dettare quali standard utilizzare. E anche se probabilmente lavorerai per gli altri e dovrai comunque rispettare i loro standard.

Questa è una parte significativa della realtà del lavoro per gli altri.

Mantieni anche in mente gli standard hanno molta storia in molti casi. Forse qualche sviluppatore precedente ha fatto qualcosa che ha causato un sacco di problemi quando lo sviluppatore se n'è andato. Forse un manager ha avuto un viaggio di potere. Questo non sarà mai immediatamente chiaro, soprattutto come nuova persona.

L'altra parte della mia frustrazione deriva dal sentirmi come se fossi l'unica persona a cui vengono imposti questi standard.

Sospetto che ciò sia in parte, se non interamente, a causa del tuo atteggiamento. Ci sono molti fattori oltre al tuo lavoro che influenzano il punto di vista del tuo capo su di te.

A questo punto, è probabile che il tuo capo si senta un dipendente problematico. Tutto nella tua domanda dice: "Ho ragione, perché gli idioti con cui lavoro non capiscono e non mi credono! È così ovvio!"

Cosa faresti?

Se vuoi avere un'influenza significativa sul tuo posto di lavoro, impara a "giocare" alla politica dell'ufficio.

Un altro controllo della realtà: se vuoi iniziare a influenzare le persone è necessario farlo in modi che siano efficaci. Ciò significa che le competenze delle persone sono più importanti delle conoscenze tecniche. Prima di essere in disaccordo con questo, renditi conto che tutta la tua domanda è il risultato di questo problema: se le competenze tecniche / la prospettiva fossero della massima importanza non avresti dovuto porre questa domanda.

Questo è il temuto " la componente politica "al lavoro che la maggior parte delle persone tecniche evita.

Una componente chiave della politica è comprendere che il" come "è più importante del" cosa ".

Le persone dimenticheranno ciò che hai detto

Le persone dimenticheranno quello che hai fatto

Ma le persone non dimenticheranno mai come le hai fatte sentire.

Nuova persona che discute con la direzione (specialmente se vengono coinvolti i registi) non è una buona mossa di carriera, quasi mai. Questo è diverso dal disaccordo costruttivo.

Fasi dell'azione

1. Parla con il tuo manager. Indica che ti dispiace per la discussione e chiedi se puoi parlare secondo gli standard attuali
2. In questa conversazione, smetti di discutere. Comprendi il "perché" di ciò che suggerisce il tuo manager. Non presumere automaticamente "sei un idiota"
3. Ascolta quello che dice il tuo manager per "perché". Se non capisci, cerca di capire il perché - non provare nemmeno a non essere d'accordo o a dire "ma, ma, ma". Le persone generalmente si mettono sulla difensiva quando litigano con loro. E diventa molto più disponibile ad ascoltare se ascolti e cerchi di capire prima.
4. Dopo aver compreso appieno perché il tuo manager vuole questi standard (probabilmente dovresti dire qualcosa come "Quindi, se ho capito bene, i motivi perché questi standard sono X, Y, Z "- se non puoi farlo, hai bisogno di maggiori informazioni), chiedi qualcosa come:" Sarebbe ok se spiegassi cosa ho fatto e perché determinare se potrebbero essere incluso nello standard? "

Procedi con leggerezza in questa conversazione. Se hai un qualsiasi livello di argomentazione, è probabile che perdi gravemente, dato che hai precedenti con il tuo manager.

Ottime risposte sopra, ma vorrei aggiungere un altro punto.

Buono, cattivo o no, c'è una storia rispetto a questi standard. Se vengono seguiti, è probabile che sia presente una significativa base di codice scritta in base a questi standard. La tua richiesta di modificare gli standard creerebbe la necessità di rivisitare l'intera base di codice per ristrutturare il vecchio codice. Questo potrebbe essere uno sforzo significativo e aggiunge il rischio di modifiche involontarie al codice. Se il team non tocca il vecchio codice, ora stai abbandonando due (o più) standard.

Nella mia esperienza, se hai più di uno standard, probabilmente non ne hai davvero nessuno.

So che questo non è quello che vuoi sentire, ma la triste verità è che le aziende (o meglio le persone che le gestiscono) non sempre seguono la logica o il "modo migliore". Questo per una serie di motivi, alcuni ragionevoli (compatibilità, conformità, standardizzazione ecc.), Altri no (paura del cambiamento, mancanza di comprensione, ecc.).

L'altra sfortunata verità è che non sei sempre in grado di cambiare la situazione. Alcune cose non cambieranno mai, altre cose che potresti essere in grado di influenzare nel tempo. Quello che dirò, tuttavia, è che sei un nuovo membro dello staff ed è chiaro che c'è una vera forza trainante per fare le cose in un modo particolare. Il mio suggerimento sarebbe di modellarti su questi, che ti piacciano o no, e valutare la tua posizione quando sarai ulteriormente integrato nell'azienda.

Combattere con i dirigenti e i leader dell'azienda è un gioco pericoloso nel migliore dei casi - anche quando sei in cima all'albero tecnico, le persone che possiedono e gestiscono l'azienda possono (ea volte lo faranno) dominarti. Farlo quando sei nuovo è al limite del suicidio.

Solo perché il motivo di uno standard non è visibile non significa che sia irrazionale.

Anche se sono d'accordo con tutto quanto detto sopra (sui nuovi dipendenti che necessitano di massimizzare le loro capacità personali e l'apprendimento della politica aziendale locale ) una cosa che può aiutarti ad abbassare il tuo livello di frustrazione è capire che alcuni standard di codifica si basano non tanto su fattori illogici e arbitrari ma piuttosto su validi ma invisibili quelli.

Considera il tuo esempio che hai descritto come

"un altro standard WTF con cui mi limito a rotolare ma che sembra completamente inutile"

In realtà ho visto questo standard esatto in due diverse organizzazioni e c'era una ragione molto valida per questo.

In entrambi i casi ho scoperto che la direzione utilizzava alcuni software per analizzare il processo di evoluzione di & di sviluppo del codice e questo software aveva aspettative rigorose su come sarebbero stati formattati i commenti (ovvero standard). Le righe "TICKET" che descrivi potrebbero includere solo " commento: " nel tuo reparto, ma più avanti nella produzione potrebbero verificarsi incidenti live che richiedono risoluzione dei problemi e modificare il software. I tecnici e la direzione coinvolti in tali eventi potrebbero aggiungere righe TICKET con elementi come " problema: ", " correzione: ", " modifica: ", " riferimento: ", " prova: ", " decisione: " e persino " norma: ". Se vieni assegnato a lavorare sulla correzione / aggiornamento del codice legacy, potresti vedere alcune righe come quella tu stesso.

Una cosa concreta che posso suggerirti è cercare di imparare qualcosa chiamato "ITIL" e / o "ITSM". Si tratta di raccolte di best practice di livello mondiale per l'IT, sia da un punto di vista tecnico che da una prospettiva di gestione allo stesso tempo. Non ti prendo in giro che può essere molto difficile capirli all'inizio se sei un puro tecnico (non manageriale), ma a lungo termine migliorerà notevolmente la tua capacità di vedere il "quadro generale" e può essere considerato un abilità commerciabili e / o promuovibili se decidi di arrivare al punto di ottenere la certificazione ITIL.

Tutti buoni consigli su: il nuovo ragazzo non dovrebbe fare ondate, ecc e sì, a volte è meglio solo tapparsi il naso e seguire standard, politiche, ecc.

Ma a volte la gestione è sbagliata; a volte gli "standard" di un'azienda sono davvero cattivi o peggiori.

In tal caso, trova un altro lavoro; la lunga esperienza mi ha insegnato che è impossibile riparare un'organizzazione disfunzionale. Quei luoghi hanno una cultura di auto-rafforzamento e se rimani lì troppo a lungo, anche tu ti spezzerai.