No, non è normale. Tuttavia, ti sei imbattuto in una bestia abbastanza comune, lo sviluppatore elitario Super Titolato. È più intelligente di chiunque altro nella sua mente ed ha il diritto di essere scortese per lo stesso motivo. Ha qualche ascia da macinare contro Morty. Evitatelo quando possibile e andate avanti.

Sebbene sia certamente nei suoi diritti di voler indagare sul problema da solo, una risposta civile è "Grazie per il suggerimento, lo esaminerò". Potrebbe esserci un cattivo sangue preesistente tra i due o potrebbe essere solo selvaggio, ma in entrambi i casi, sebbene questo comportamento non sia sconosciuto in tecnologia, non è accettabile o "normale".

In quanto sviluppatore, trovo il primo rapporto molto utile. Nessuna lunga spiegazione, nessuna lunga traccia di Valgrind da leggere. Con quella patch, ho potuto vedere immediatamente qual è il problema, e se lavorassi su quel codice di recente, probabilmente saprei se è corretto o meno anche senza controllare il codice. Quindi risponderei semplicemente "Grazie per averlo preso" o "Grazie, quel puntatore non dovrebbe essere condiviso, ma so come risolvere il problema ora che l'hai portato alla mia attenzione" o qualcosa del genere.

Inoltre non rilevo alcun sentimento di superiorità nel messaggio.

Ora mettere in CC tutti potrebbe o non potrebbe essere un male. Il codice potrebbe essere qualcosa di cui anche altri sanno, quindi se l'elenco dei destinatari CC è abbastanza breve, va bene. La posta è abbastanza breve e tutti possono vedere immediatamente dalla patch se dovrebbero essere interessati o meno, perdendo solo un po 'di tempo. Tuttavia, se ci sono persone che non sono coinvolte con quella base di codice sorgente in CC, allora era inappropriato.

Un altro problema è, se la persona dovrebbe passare il proprio tempo a eseguire il debug di un problema come questo. Tuttavia, a meno che non siano al di sotto dei propri obiettivi, assumersi la responsabilità dell'intero software in questo modo è generalmente una caratteristica molto preziosa. Mostra entusiasmo e cura, cosa rara davvero. Queste cose possono andare troppo lontano, ma è molto più comune vedere compagni di squadra a cui non importa di meno di un bug nel codice di qualcun altro, a meno che non abbia avuto un impatto diretto su di loro.

Per rispondere la domanda del titolo. Il tono di Morty presentato in questione è, ai miei occhi, professionale e normale. Il tono di Ricks è ... sfortunatamente neanche così insolito, ma è un peccato. Tuttavia, abbiamo tutti brutte giornate, quindi non analizzerò ulteriormente un singolo messaggio anonimo. Potrebbe essere un brutto segno (e sembra proprio così, TBH), o potrebbe far parte di una cultura del posto di lavoro abbastanza decente a cui devi solo abituarti.

So che la domanda ha già avuto una risposta e sono d'accordo con la risposta accettata, ma volevo solo estenderla con ulteriori informazioni.

Quello che hai visto qui è un potenziale XY problema. I problemi XY sono, secondo me, qualcosa che ogni risolutore di problemi (non solo i programmatori) deve essere consapevole ed evitare.

Il principio di un problema XY è abbastanza semplice:

• X è un problema e deve essere risolto.
• Y è una soluzione, ma non la soluzione migliore. Indipendentemente da ciò, viene scelto (o per pigrizia o non capendo che esiste una soluzione migliore)
• Quando si presenta un problema con l'implementazione di Y, le persone dedicano tempo a cercare di far funzionare Y, invece di guardare effettivamente lì è una soluzione Z che si adatta meglio.

Come un chiaro esempio:

• X = Voglio ordinare questi dati di Excel.
• Y = Posso scrivere un'applicazione per ordinare i dati e salvare il file.
• Z = Dovrei imparare a usare la funzionalità di ordinamento di Excel.

Questo è essenzialmente cosa è successo nell'email di Morty. Rick non è in grado di etichettare la richiesta come Y o Z, perché Morty non spiega X. Spiegare X è più importante che offrire la soluzione Y / Z, poiché Rick è in grado di trovare Z quando conosce X, ma può farlo ' t indovinare X dal nulla.

Questo è il problema di X:

una perdita di memoria in parte del codice della piattaforma

Nota che è abbastanza vago. Qual è stato il problema? Dove è successo? Quando è successo? Era un caso limite?

Quindi Morty propone una soluzione Y. Poiché non conosciamo le specifiche di X, quindi non abbiamo modo di valutare se Y è una soluzione appropriata per X.

Questo è il motivo per cui Rick si oppone. Gli viene chiesto di cambiare qualcosa (e di assumersi effettivamente la responsabilità di aver cambiato qualcosa) senza avere scelta . Morty ha effettivamente minato la responsabilità di Rick (scrivere un buon codice) e lo sta sostituendo con una richiesta di cieca fiducia che il codice offerto sia appropriato e valido.

Pensala in questo modo: sei un poliziotto. Un uomo si avvicina e dice "Ho bisogno che tu arresti quell'uomo" (Y).

L'agente di polizia non dovrebbe obbedire, poiché non è in grado di confermare personalmente che l'arresto dell'uomo è autorizzato.

Tuttavia, se l'uomo avesse detto "quell'uomo ha appena ucciso qualcuno a sangue freddo", l'ufficiale di polizia è in grado di comprendere effettivamente il problema e decidere lui stesso la soluzione (arrestando l'uomo).

Questo è fondamentalmente ciò che Morty ha fatto di sbagliato. Penso che Rick avrebbe potuto formularlo in modo più gentile (se fosse Interpersonale.SE riformulerei sicuramente alcune delle frasi di Rick), ma la sua richiesta è valida.

Ignorando se c'è una tensione di fondo tra i due, un problema di comunicazione generale o il tono standard al tuo posto, voglio concentrarmi sulla tua domanda:

Questo tono è insolito in un ambiente di lavoro tecnologico?

No , questo tono non è del tutto insolito.

1. Le persone del settore sono abituate a linguaggi di programmazione sintattici e le specifiche tecniche esatte tendono a volte a dimenticare il tono nella loro comunicazione. Spesso questo non è un problema finché gli estranei non sono coinvolti nella comunicazione. Abituati a un sacco di messaggi tagliati direttamente sul caso.

2. È un cliché, ma sì, ci sono anche quei nerd che hanno solo una scarsa social abilità, quindi è meglio che impari ad affrontarle e non prenderla sul personale.

3. Per molti programmatori il "loro" codice è il loro bambino. Essere segnalati ad alcuni errori innegabili è una cosa: manipolarli può semplicemente attivare alcuni meccanismi di difesa.

Detto questo, può essere fatto in un modo migliore. Come regola pratica, per evitare tali problemi:

• Loda il pubblico, critica il privato.
• Se hai problemi con qualcuno, non usare affatto la posta elettronica per questo!
• Se trovi un bug, segnalalo tramite un meccanismo standard accettato dal team.
• Non fare il lavoro di qualcun altro, a meno che non venga richiesto.

C'è un certo valore per il suo sentimento. So di molte volte in cui la mia intuizione su una causa principale ha portato qualcuno sulla strada sbagliata e ha perso tempo.

Con la maggior parte dei problemi, ogni persona ha certe intuizioni che semplicemente "saltano fuori". Penso che valga la pena provare a sfruttare questo potere. Quando ho bisogno di aiuto su un bug su cui sono bloccato, cerco di evitare di imporre loro le mie intuizioni, in modo che forse le loro possano essere nuove e produttive.

Ma con il modo in cui l'ha espresso .. . era uno stronzo totale.

Chiaramente non tutti sono d'accordo con questo, ma IMO questa è una risposta normale, non prenderla sul personale .

È un'e-mail facile da capire, motiva le sue ragioni perché preferisce non ascoltare la tua soluzione (non perché è la tua soluzione, ma perché vuole una tabula rasa per cominciare).

Non è personale nei tuoi confronti, o insultare o minare affatto, è una spiegazione. È un po 'diretto per alcune persone, ma spesso è una stranezza dei programmatori, essendo diretto e (troppo) reale. Potresti leggere l'intera e-mail con un tono di voce normale, dove spiega il suo metodo preferito. Solo perché non ne sei un fan, non significa che sia una cattiva pratica, incontrerai molte persone che lavoreranno in modo diverso da te.

Sono d'accordo che potrebbe essere formulato un po ' più educatamente, ma ancora una volta, un programmatore spesso dice semplicemente cosa intende senza tutte queste interpretazioni caricate (il che non è una scusa, ma potrebbe essere una spiegazione).

È suo compito risolvere i problemi, non il tuo. Hai appena trascorso del tempo su qualcosa, che avrebbe potuto essere utilizzato altrimenti. Non fraintendermi, è importante fare pratica con la correzione dei bug! Ma studia la soluzione applicata e confrontala con la tua. La tua soluzione potrebbe sembrare corretta, ma l'esperienza potrebbe insegnarti il ​​contrario.

Entrambe le parti sono colpevoli qui.

Morty non avrebbe dovuto inserire in cc. tutti nell'email iniziale. In questo modo ha messo in imbarazzo Rick sottolineando il suo errore a tutti. Non so se Morty stesse cercando di segnare punti in questo modo o se fosse semplicemente uno sciocco. Tuttavia il risultato è stato lo stesso dal punto di vista di Ricks. Morty avrebbe fatto meglio a inviare questa e-mail solo a Rick in modo che potessero risolvere il problema senza che nessuno dovesse sembrare cattivo.

Rick si vergogna di vedere il suo errore segnalato pubblicamente reagire male. Non avrebbe dovuto abbattere Morty. Non avrebbe dovuto criticare pubblicamente Morty per aver cercato di aiutare.

Un esempio di scambio di email non ci dice nulla sulla cultura aziendale. Tuttavia, se l'invio di e-mail pubbliche che segnalano gli errori di altre persone e l'invio di e-mail che dicono alle persone che non dovrebbero offrire aiuto sono comuni lì hai una cultura tossica.

Sfortunatamente, questo tipo di cultura tossica è comune nel software società negli Stati Uniti. Proprio come è stato scritto [1] [2] [3] e detto sul modo in cui un particolare tipo di ingegneri del software tratta gli altri, in particolare non -Gli ingegneri del software e le persone che sono non si adattano allo stereotipo di un ingegnere del software.

Questa cultura non è il modo giusto per trattare le persone. Una buona compagnia, manager e colleghi non tollerano questo tipo di cultura. I buoni dipendenti non si segnalano pubblicamente gli errori a vicenda e i buoni dipendenti non rifiutano l'aiuto degli altri.

Devi capire che questo comportamento è accettabile nella cultura del tuo dipartimento e della tua azienda. Se pensi di essere in un'azienda che è accettata, devi decidere se pensi di poter cambiare la cultura e se è degno lo sforzo. Una cosa importante da capire è se questa cultura proviene dalla leadership o meno. Se la leadership dà un cattivo esempio non ci sarà nulla che tu possa fare. Se questa è la cultura di base, hai qualche possibilità di convincere le persone a cambiare. Sarà un lavoro lungo e duro, quindi farai meglio a decidere che vale la pena aggiustare l'azienda.

Normale è abbastanza soggettivo, soprattutto perché non hai idea della storia di quel posto di lavoro.

O Rick ha terribili capacità interpersonali o c'è del sangue cattivo tra queste due persone.

È possibile che Morty abbia intenzionalmente creato un'email "ragionevole" sperando di attivare Rick.

Dato che sei nuovo, dovrai valutare se questo comportamento tossico si è diffuso anche ad altri o se si tratta di un situazione contenuta.

Qualunque cosa accada, non lasciare che si diffonda nella tua personalità.

Sto scrivendo questo con la prospettiva di un manager con esperienza che copre molteplici aspetti di questo tipo di scenario.

è normale nelle aziende tecnologiche?

Questo è del tutto normale per qualsiasi azienda in quasi tutti i settori, non solo per quello tecnologico.

In linea di massima, l'email inviata a tutti i membri di un team di sviluppo :

• ha evidenziato un sospetto difetto (" penso di aver trovato una perdita di memoria ...")
• ha dichiarato che era stata trovata una presunta soluzione (" credo di aver trovato la fonte e il problema ...")
• ha presentato una lunga lista di correzioni da implementare

Per generalizzare, quello che sta succedendo qui è che una direttiva viene data a Rick da Morty che stabilisce prima una giustificazione della direttiva e poi specifiche di detta direttiva.

Ciò complica ulteriormente la questione in quanto la direttiva è stata data in un'impostazione di gruppo (cc'd a tutti i membri di th e team).

Rapporto organizzativo di Rick e Morty

Non conosciamo il rapporto rispetto ai due individui. Tuttavia, può essere generalmente riassunta come una delle tre possibilità:

• Rick è più anziano di Morty
• Morty è più anziano di Rick
• Rick e Morty sono uguali

Rick dovrebbe prendere direttive da Morty?

• No? Allora Rick è giustificato a respingere
• Sì? Quindi non c'è bisogno di CC tutti. Rick è ancora giustificato nel dire a Morty come svolge al meglio il suo lavoro.

Questa situazione non sarebbe diversa se fosse ...

• Medico. Il dottor Oz dice al dottor No che ha diagnosticato il paziente del dottor No e di fare X, Y e Z senza fornire i sintomi al dottor No.
• Automotive. L'Ingegnere 1 dice all'Ingegnere 2 che è stato trovato un problema nel design delle sospensioni dell'Ingegnere 2 e la soluzione è saldare la linguetta A allo slot B senza fornire i dati di prova per mostrare il problema
• Supporto tecnico - Il tecnico 1 comunica a Tech 2 che c'è un problema con il sistema di Tech 2 e la soluzione è implementare le patch A, B e C senza fornire i messaggi di errore che indicavano il problema.

TL; DR

In conclusione, la persona responsabile dell'effettiva riparazione sta dicendo alla persona di cosa ha bisogno per svolgere correttamente il lavoro. L'unica persona potenzialmente "fuori linea" è Morty per il comportamento passivo aggressivo di mettere in contatto chiunque.

Questo accade ogni giorno in ogni settore. Non è niente di nuovo o insolito.

  --- a / spaceship / DoBattle.cpp +++ b / spaceship / DoBattle.cpp vector<part> parts = getSpaceShipParts (); + shared_ptr<SpaceShip> p = nuovo SpaceShip (parti); -SpaceShip * p = nuovo SpaceShip (parti); engagementInBattle (p, nemico); 

Sfortunatamente, questa modifica risolve il bug (fingendo che il test di valgrind sia adeguato), ma ha introdotto qualcosa di indesiderato, una lotta alla filosofia del codice. Se non sei un contributore regolare, non entrare in lotte di filosofia del codice.

Per evitare la lotta di filosofia, questo avrebbe dovuto essere inviato invece. Sì, oggettivamente è peggio ma è in armonia con lo stile del codice già presente:

  --- a / spaceship / DoBattle.cpp +++ b / spaceship / DoBattle.cpp SpaceShip * p = nuova SpaceShip (parti); engagementInBattle (p, nemico); + delete p;  

Ma con questa risposta dello sviluppatore, presumo che non gli sarebbe piaciuto neanche quello. Sento questo tono un po 'troppo, anche da persone che dovrebbero conoscerlo meglio. Non è normale, ma è sufficiente che tu lo senta molto. Sono deluso.

1) Comunicazione: OP fa sembrare che sia una pratica standard mettere in copia il resto del team di sviluppo. Non vedo mai un motivo per non includere il resto del team di sviluppo in un problema / soluzione che riguarda tutti.

2) Problema / Soluzione: non vedo niente di sbagliato qui. Dovrebbe essere fatto con una richiesta pull, ma supponendo che non sia possibile qui, va bene.

3) Risposta: Tante cose sbagliate che non so nemmeno da dove cominciare.
a ) "Non leggo le correzioni suggerite": Questo è assolutamente terribile. Leggi sempre il codice proposto. C'è una buona probabilità che sia meglio di qualsiasi cosa tu possa inventare ....
b) "Devo aspettare alcuni giorni prima di trovare una soluzione": Lasciami tradurre: "Devo aspettare pochi giorni prima di poter ignorare completamente il lavoro che hai svolto e scartare la tua soluzione. Non solo perderò tempo per ottenere una soluzione implementata, ma anche per trovare una soluzione per un problema che è stato risolto (da il codice che hai scritto che scarterò) "
c) 'guarda qual è il vero problema e vedi quale dovrebbe essere la soluzione': provalo . Provalo per vedere se c'è un problema. Quindi provalo per vedere se il problema è stato risolto. Non guadagni nulla inventando la tua soluzione che deve essere testata invece di provare la soluzione proposta per vedere se risolve tutto. Se non risolve il problema allora puoi provare a trovare una soluzione per la soluzione proposta o una soluzione completa al problema.

Nella mia azienda avrei ha inoltrato la risposta al mio manager immediatamente e senza commenti. È semplicemente inaccettabile.