Domanda:
Risposta a un suggerimento di correzione di bug detto di segnalare solo bug (non suggerire soluzioni). È tipico?
MortysFriend
2018-06-21 09:20:01 UTC
view on stackexchange narkive permalink

Sono un nuovo dipendente in una società di software e ho visto un'email inviata a un collega da un proprietario di sistema, ma con l'intero team di sviluppo CC, e mi sono preoccupato un po 'per l'ambiente. Sono da poco uscito dal college, quindi questo è il mio primo lavoro quindi ... è normale nelle aziende tecnologiche?


Inviato alla mail list del team di sviluppo di Rick e Cc:

Ciao Rick,

ho eseguito valgrind sul progetto SpaceShip e penso di aver trovato una perdita di memoria in alcuni codici della piattaforma. Credo di aver trovato la fonte e il problema può essere risolto con la differenza di seguito:

  --- 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);  

Ho rieseguito valgrind con la modifica e sembra risolvere il problema!

Grazie,
Morty

Un'e-mail abbastanza ragionevole ho pensato, a cui ha risposto:

Ciao Morty,

Grazie, ma in futuro per favore fornisci le informazioni su come riprodurre un problema, non una correzione suggerita. Non leggo le soluzioni suggerite, perché mi predispongono a un'idea particolare di quale sia il vero problema e quale dovrebbe essere la soluzione. È meglio che vada fresco e decida da solo.

Nei casi in cui ho letto accidentalmente un diff prima di rendermi conto di cosa fosse, ho volutamente speso almeno diversi giorni cercando di dimenticarlo in modo da poterlo approfondire. Quindi darmi un diff rende più probabile che non guarderò nemmeno il problema per un po 'di tempo.

Grazie,

-- Rick

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/79214/discussion-on-question-by-mortysfriend-is-this-tone-unusual-in-a-tech-workplace).
È molto raro avere quel tipo di comunicazione, ma sfortunatamente è comune che ogni azienda / team abbia un membro che non funziona realmente in un team, o è un saputello e così via.Fondamentalmente, finché questo non accade con la maggior parte dei tuoi colleghi, cerca di evitare quella persona e dovresti stare bene.
Undici risposte:
#1
+240
mxyzplk - SE stop being evil
2018-06-21 09:25:50 UTC
view on stackexchange narkive permalink

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".

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/79213/discussion-on-answer-by-mxyzplk-is-this-tone-unusual-in-a-tech-workplace).
La più piccola soluzione che vorrei aggiungere è che OP è l'amico di Morty, non Morty con urgenza.
Non è una soluzione, il Rick ha un problema con il Morty in questo esempio.L'amico di Morty è l'OP ma è solo uno spettatore.
#2
+70
hyde
2018-06-21 12:41:21 UTC
view on stackexchange narkive permalink

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.

"CC'ing ognuno potrebbe o non potrebbe essere un male" - nel caso in cui sapessero come Rick si comporta in queste situazioni, CCing ognuno si sente come il modo più appropriato per assicurarsi che il problema * venga * effettivamente risolto.
#3
+48
Flater
2018-06-21 11:09:10 UTC
view on stackexchange narkive permalink

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.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/79212/discussion-on-answer-by-flater-is-this-tone-unusual-in-a-tech-workplace).
I commenti di @JaneS sono, tuttavia, * correttamente * usati per evidenziare problemi nelle risposte.
Anche se penso che menzionare il problema XY sia rilevante per stabilire se la richiesta di Rick fosse ragionevole qui, non credo che questa sia una risposta alla domanda nel modo in cui l'hai scritta.L'OP ha chiesto se il tono di Rick fosse normale nel settore.Potresti considerare di riformattare la tua risposta per concentrarti su come Rick l'ha gestita, sebbene l'essenza della sua risposta sia valida.
@BloodGain "Potresti considerare di riformattare la tua risposta per concentrarti su come Rick l'ha gestita, anche se l'essenza della sua risposta è valida." Questo è esattamente ciò che indica l'ultima frase della risposta.
#4
+15
Daniel
2018-06-21 16:21:11 UTC
view on stackexchange narkive permalink

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.
Mi piacciono tutti i punti elenco.I primi due sono delle buone linee guida generali generali nella vita.
Riguardo al bambino, è importante che la persona abbia esperienza con l'open source.
Lamentarsi per la mancanza di riproduttori è valido secondo l'IMO.Ma non chiedere alcuna soluzione è piuttosto folle.Non essere in grado di ignorare il pensiero di qualcun altro significa che non puoi ignorare i tuoi pensieri fuorvianti.E se non puoi, allora buona fortuna con la programmazione.Dovresti iniziare in un modo e continuare indefinitamente nella stessa direzione. O refactoring del codice esistente?Devi capire quale fosse l'idea originale e poi ripiegare nel nuovo paradigma che vuoi applicare.
La dichiarazione di Rick che aggiungerà deliberatamente un ritardo al processo, nominalmente in modo da poter liberare la sua mente delicata dall'idea corruttiva di Morty, è petulante e del tutto inaccettabile e deve essere affrontata.Se Morty è eccessivo (la sua abilità e / o portata) una risposta più equilibrata sarebbe "Grazie, Morty, e il tuo rapido suggerimento potrebbe essere parte della soluzione, ma dovrò rivedere più del problema per assicurarmeneè l'approccio migliore. Nel frattempo, puoi documentare questo bug nel nostro bug tracker? È davvero importante inserire tutti i bug in esso! "
@CCTO (e altri commentatori) Ti rendi conto che OP non ha chiesto come affrontarlo, sì?
#5
+14
Alexander - Reinstate Monica
2018-06-21 09:57:26 UTC
view on stackexchange narkive permalink

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.

A volte ricevo ticket web con correzioni CSS suggerite per bug visivi.Il problema è che i selettori sono solitamente super generici (spesso basati solo sui nomi dei tag o su una classe) e interrompono molte altre aree del sito.Tuttavia, mi piace il suggerimento perché di solito mi fa risparmiare un po 'di tempo a trovare il problema esatto, quindi posso semplicemente assegnarlo allo spazio dei nomi in qualcosa di pronto per la produzione ...
@dandavis Non è compito loro risolvere il problema.È il tuo lavoro.Risolvere un problema implica sapere qual è il problema e quali sono i problemi alla soluzione: P
Potresti espandere la parte scortese?Questa risposta è ottima dato che pesa su entrambi i lati, ma è un po 'irregolare.
Devo rispettosamente dissentire.Nella risoluzione dei problemi tecnici, più informazioni sono * sempre * più preziose di meno.In qualità di risolutore di problemi assegnato, è compito degli sviluppatori identificare quali sono le informazioni errate del cliente rispetto ai dettagli di valore.Mantenere alcuni dettagli dallo strumento di risoluzione dei problemi perché potresti "impostarli sulla strada sbagliata" è un'idea ridicola per me e rimprovererei chiunque dei miei dipendenti che ha risposto a un cliente in questo modo.
Tecnico ma non uno sviluppatore di software qui, e sono d'accordo con @DanK.L'unico piccolo aggiustamento che apporterei al rapporto iniziale è di fornire prima i dettagli (magari con qualche benchmark in più) e il diff alla fine.Ciò darebbe a Rick la possibilità di leggere il rapporto senza il diff, ma (IMO come qualcuno abituato a articoli scientifici inclusi gli elenchi di codici) mantenere il diff fuori dal corpo rende la lettura più chiara.
puoi per favore spiegare cosa esattamente non è educato qui?mi sembra completamente privo di offese, mi piacerebbe capirlo
@SargeBorsch: la richiesta di non includere informazioni ordinarie e banali è assolutamente inaccettabile in un progetto collaborativo.E l'intento dichiarato di punire Morty ritardando intenzionalmente il progetto lo raddoppia.È scritto in modo da sembrare carino, ma il significato è palese e improprio.Il fatto che il report del problema includa due righe di diff non è un problema: potrebbe o non potrebbe aiutare, ma non è un problema.Ora, se Morty non dovrebbe dirigere valgrind, e abitualmente riporta cose confuse, * quello * potrebbe essere qualcosa che l'organizzazione deve affrontare, ma non è così.
@SargeBorsch troppe persone confondono l'essere diretti e succinti con l'essere scortesi.Per la cronaca, l '** unico ** problema che ho con l'email è che l'originatore ha ritenuto necessario eseguire il cc all.
@DanK Dipende completamente dal tipo di problema.Non sto sostenendo questo approccio universalmente, ma semplicemente come uno degli strumenti disponibili nella confezione.Molte volte, quando vado da un collega per chiedere aiuto in un'indagine, so che probabilmente sto inseguendo una falsa pista e sto sprecando il mio tempo.Voglio il vantaggio di una nuova prospettiva.
Sono d'accordo con DanK su questo, è importante includere quante più informazioni possibili.Anche se si sbagliano su quale sia la causa principale, potrebbe essere utile sapere * perché * pensano che sia la causa principale, potrebbe portare a maggiori informazioni.
@LordFarquaad Questo non è un gioco di squadra polarizzato.Non sto suggerendo una condivisione delle informazioni gratuita per tutti.Gli esseri umani sono persone facilmente persuadibili.Non è un processo consapevole, quindi non si tratta di essere "un buon informatico".
#6
+10
Martijn
2018-06-21 13:54:07 UTC
view on stackexchange narkive permalink

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.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/79196/discussion-on-answer-by-martijn-is-this-tone-unusual-in-a-tech-workplace).
@Martijin La domanda in realtà afferma che Morty è il "proprietario del sistema", cioè qualcuno responsabile di vedere che questo viene risolto.Indagare sul problema non è davvero fuori dal loro lavoro generale.L'e-mail di Rick è in parte una spiegazione, ma è una spiegazione di una richiesta di essere protetti dal tipo di informazioni normalmente e utilmente scambiate in tali situazioni, e come tale una richiesta che è * fondamentalmente incompatibile * con un progetto di gruppo, non importa comeè ben formulato.Rick è libero di considerare cause e soluzioni alternative, ma non di interrompere le comunicazioni normalmente scambiate.
#7
+4
Ben Mz
2018-06-21 09:31:07 UTC
view on stackexchange narkive permalink

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.

Può essere.Senza più contesto non possiamo davvero sapere se l'email originale è "segnalare l'errore di qualcuno" o "condividere i progressi con gli altri coinvolti in uno sforzo di gruppo" - per quanto ne sappiamo questo è uno sviluppo chiave in un'area in cui c'è stato unsenso condiviso ma non specifico che qualcosa non andava.Nota che non dice "nel tuo codice" - potrebbe essere un presupposto implicito, ma il testo dell'e-mail non è più accusatorio di un tipico bug ticket e meglio ricercato rispetto alla maggior parte.Oppure potrebbe essere un pezzo di testo dall'aspetto molto normale altamente armato nel suo contesto reale.
È abbastanza comune mettere in cc il team quando si affronta un bug importante.
"ha messo in imbarazzo Rick sottolineando il suo errore a tutti" Il software contiene bug.Tutti coloro che sono coinvolti nella sua creazione lo sanno e lo accettano.Posso garantire che ** nessuno ** operasse con l'illusione che Rick fosse un dio della programmazione infallibile.Dovrebbero anche eliminare il loro bug tracker perché è sovversivamente un registro permanente dei fallimenti personali di Rick?Non vengo pagato per assecondare i fragili ego.Vengo pagato per creare un buon software.
@Michael "Non vengo pagato per assecondare gli ego fragili."Questo è il genere di cose che molte persone dicono per giustificare il fatto di essere uno stronzo.
@BenMz Abbastanza vero - sono sicuro che Rick potrebbe provare a fare questa affermazione dopo aver letto alcune risposte qui - ma penso che una persona del genere si identificherebbe erroneamente essendo educata con assecondare.Non è lo stesso.Sono sempre educato al lavoro, ma non dovrei dover camminare sui gusci d'uovo intorno a un individuo perché non può gestire il team di sviluppo che riceve CC via e-mail su un errore facilmente commesso.
Questa risposta presuppone le risposte emotive delle persone in questione quando nessuna di queste era implicitamente o esplicitamente implicita.
@Allan Non puoi giudicare il tono delle comunicazioni sul posto di lavoro senza considerare la risposta emotiva che è probabile che suscitino.
* Sai * Rick era imbarazzato?[Imbarazzo] (https://www.bing.com/search?q=embarrassment&FORM=AWRE) è un'emozione auto-valutativa (anche nota come personale).Non sono stati effettuati attacchi personali.Puoi dire che il tono dell'email è "aspro" o "schietto" o qualsiasi altra cosa, ma non puoi assumere la risposta emotiva perché tutti risponderanno in modo diverso.
@Allan Suppongo che Rick sia imbarazzato.Fare le nostre migliori ipotesi di giudizio su come le persone reagiranno è come il giudice come comunicare con loro.
Una domanda successiva potrebbe essere "Cosa, in quello scambio di email, ti fa * presumere * che Rick fosse imbarazzato?" Per espandere ciò che ho detto prima, non c'è un minimo di attacco personale per giustificare "imbarazzo".Inoltre, la risposta di Rick non si scaglia contro Morty;gli dice di cosa * ha bisogno *.
#8
+1
MonkeyZeus
2018-06-21 20:08:18 UTC
view on stackexchange narkive permalink

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à.

#9
  0
Allan
2018-06-21 20:00:32 UTC
view on stackexchange narkive permalink

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.

La comunicazione è estremamente importante .... Nel mio team il 90% della comunicazione va su slack / jira / github che tutti possono vedere.Per una soluzione che influisce sul prodotto di una squadra penso che dovresti sempre cc a tutta la squadra (o, probabilmente, semplicemente inviarla a tutta la squadra). Per quanto riguarda il problema effettivo nell'e-mail: è stato trovato un problema, è stata trovata una soluzione.Ora pensi che il Lead fa buon uso del proprio tempo scartando problema e soluzione e cercando di verificare che un problema esista e poi trovare una soluzione che potrebbe o non potrebbe essere migliore?così facendo dici al ragazzo che il suo lavoro non ha importanza ...
@xyious - Presumo che tu abbia votato negativamente perché per i motivi della tua discussione.Interessante.La ** domanda ** non riguarda chi ha ragione, la domanda è ** è il tono * insolito ***.Detto questo, qualunque siano le preferenze della persona responsabile del cambiamento, è la loro preferenza.Periodo.
@Allan - un diff a due righe non è "una lista di correzioni da implementare" - ovunque tu lo riceva, non fa parte della situazione della domanda.In termini di ruoli di Morty e Rick, è stato esplicitamente affermato che Morty è il "proprietario del sistema" e dal contesto è chiaro che Rick è l'attuale guru dell'area per il codice in questione.
Quindi, @ChrisStratton hai preso letteralmente il "diff"?SMDH.Lascia che ti chieda questo .... pensi che un medico curante dica allo specialista cosa fare o gli dice i sintomi e aspetta una conferma?
Ho preso la * scala * del diff alla lettera e sono abbastanza sicuro che sia accurata.Il punto centrale della domanda è che Rick ha avuto un attacco per un'azione estremamente normale, ordinaria e corretta.Sembri invece voler rispondere a una situazione molto diversa da quella effettivamente richiesta, espressa anche nella tua speculazione su rapporti che non si adattano alla posizione esplicitamente dichiarata di Morty.
* Ho preso la scala del diff alla lettera ... * Un post che usa "Rick and Morty" come offuscamento dei nomi delle persone in un'e-mail che ha probabilmente meno righe del numero di persone nell'elenco cc e tu prendi ** che ** "sul serio".Non sei un dirigente e si vede.
È diventato abbastanza chiaro che gran parte del problema nel tuo post deriva dal fatto che insisti a rispondere a ** una situazione diversa da quella effettivamente descritta **.Come farebbe notare qualsiasi sviluppatore * esperto *, la differenza mostrata riguarda la dimensione di una correzione per questo tipo di problema * sarebbe * spesso effettivamente.
#10
  0
Joshua
2018-06-21 23:37:16 UTC
view on stackexchange narkive permalink
  --- 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.

Questo potrebbe leggere il diff un po 'troppo letteralmente.Non è una * richiesta pull *, è un po 'di * codice come voce * in un'e-mail.In effetti sta dicendo "forse potremmo risolverlo in questo modo, o forse hai un'idea migliore, ma questo problema è importante per il mio progetto che contiene il tuo codice, e il problema sembra essere di questa forma" Anche se non unito, diffscome questa sono comunicazioni abbastanza normali tra programmatori.
#11
  0
xyious
2018-06-22 00:14:29 UTC
view on stackexchange narkive permalink

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.

Parlando dal punto di vista di un * manager *, vorrei informarti che ogni sviluppatore è un individuo e ogni individuo ha il proprio modo preferito di lavorare.Ognuno di noi deve cercare di accogliere le reciproche idiosincrasie.In questo caso, consiglierei a ** te ** (parlando come il tuo manager se fossi stato Morty) di rispettare il flusso di lavoro preferito di Rick inviandogli ciò che ha chiesto * prima * e poi seguire ciò in cui * credevi * (come inl'email) era il problema seguito da ciò che pensavi (di nuovo, nell'email) come la soluzione.
E per la cronaca .... più andavo avanti nella mia carriera e acquisivo esperienza, meno mi affidavo alla "diagnosi e correzione" senza una chiara articolazione del problema ** prima. ** L'eccezione a questa regolaera se il problema / la soluzione proveniva da una fonte attendibile.Posso dirti che anch'io ignoravo potenziali soluzioni se non erano conformi alle mie esigenze ma non era per arroganza ma piuttosto per una quantità limitata di risorse (cioè tempo) da spendere per decifrare il lavoro altrui.
Quindi informeresti il tuo team di sviluppo che è accettabile (come idiosincrasia) sprecare il tempo di uno sviluppatore (fornendo una soluzione che verrà scartata) e sprecare il tempo di un lead (scartando una soluzione e inventando la propria)?
Vorrei informare il team di sviluppo che perdere tempo non rispettando i desideri / richieste dei responsabili delle rispettive funzioni è ciò che è inaccettabile.Solo perché presumi che la soluzione sia quella corretta non significa che lo sia.Si riduce anche al fatto che il responsabile non può convalidare il problema rispetto alla diagnosi e, in definitiva, alla soluzione.Non stai sostenendo che qualcuno dovrebbe semplicemente accettare una diagnosi e una soluzione proposta fuori mano, vero?Quanto tempo andrebbe perso allora?Quanto tempo si risparmierebbe se i sintomi fossero convalidati ** prima **?
Provalo !Verifica che il problema esista!Verifica che la soluzione risolva il problema!Quindi verifica che la soluzione non rompa nient'altro.Dovresti comunque fare gli ultimi due.Perché dovresti sprecare una soluzione che non hai testato e inventare qualcos'altro che potrebbe anche non funzionare?
BTW, tutto ciò è nella mia risposta sopra.È comunque necessario disporre di unit test.Devi comunque testare costantemente.Perché hai scelto di non testare una soluzione che qualcuno ti ha dato?Come è accettabile in ogni situazione?
Come convalidi esattamente un test (deve meno una soluzione) contro sintomi che ** non erano mai stati articolati in primo luogo?Non dare per scontato che la diagnosi fosse corretta all'inizio.La parte interessante di questo è che la tua risposta * non * affronta mai la domanda reale - * è il tono insolito *.Tuttavia, passi una quantità eccessiva di tempo a difendere la tua posizione.Stai letteralmente spiegando il mio punto per me.
Capisco che sia il titolo, ma non è questa la domanda.Il tono nell'email era inesistente.Non c'è "tono".Sono le parole che sono insolite.Inoltre, non stai discutendo nulla sul tono nei tuoi primi 3 commenti alla mia risposta.Hai iniziato a discutere il processo ...
I miei commenti affrontano la ** tua risposta **.La tua risposta non riesce ad affrontare la domanda generale.Caso in questione, come "Morty" stai fornendo una soluzione ma ignorando la domanda più grande.Quanto tempo hai dedicato a rispondere a qualcosa che non è mai stato chiesto in primo luogo?Qualche consiglio amichevole da qualcuno con più di 25 anni che lo fa ... concentrati su ciò che * effettivamente * ti viene chiesto e non su ciò che * presumi * ti viene chiesto.
@Allan: se il tuo team non può * efficacemente * valutare la modifica proposta * mediante ispezione *, devi licenziarli tutti e sostituirli con sviluppatori competenti.Il problema generale potrebbe richiedere una maggiore attenzione: potrebbe essere solo un esempio di uno più diffuso, ma la * modifica proposta * è una legittima bandiera di un difetto nel codice esistente, un segno della confusione di Morty o di nessun effetto reale.
@ChrisStratton - Mi stupisce a non finire che le persone difendano dal loro respiro morente la loro posizione è assolutamente corretta quando devono ancora identificare i sintomi che richiedono la correzione proposta.** Ogni singola volta che ho adottato il tuo approccio, è costato di più in termini di risorse rispetto al risparmio percepito della semplice implementazione del cambiamento. **
@Allan - il punto che così ** pericolosamente ** ignori è che il codice esistente non deve nemmeno attivare un errore per essere sbagliato.C'è un obbligo assoluto qui di capire se Morty sta indicando un problema reale nel codice esistente, * oltre * a controllare il fallimento del test che ha segnalato, * che può o non può essere in alcun modo correlato a quello *.Anche se la causa effettiva si trova altrove, il codice specifico che Morty ha proposto di modificare ** potrebbe comunque non essere sicuro **.Morty ha ragione?O è semplicemente confuso?Devi scoprirlo e gli sviluppatori * competenti * possono farlo rapidamente.
@ChrisStratton - Scherzi a parte ... quante ipotesi puoi eventualmente fare in due e-mail offuscate?* Se questo o se quello * - non importa.Quello che so è che nessuno può parlare di nessuna delle supposizioni che fai (per quanto ne sappiamo Morty è un idiota spensierato) quindi alla fine sono discutibili.Detto questo, ho avuto molto successo a lavorare con gli sviluppatori soddisfacendo le loro esigenze, non intimidendoli con ipotesi basate su pseudo codice.


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...