Domanda:
Come trovo un terreno comune con un collega che la pensa in modo molto diverso da me?
user5621
2017-07-18 13:16:52 UTC
view on stackexchange narkive permalink

Progetto circuiti elettrici per vivere. Negli ultimi anni, ho stabilito un metodo di progettazione logica che funziona per me e mi aiuta a tenere traccia di come tutto è collegato insieme. Poiché questi progetti possono diventare giganteschi, raggruppo i sottoprogetti in un modo specifico, nomino le mie reti in un modo specifico, ecc. Non è una questione di giusto / sbagliato, ma piuttosto solo di come penso alle cose.

Sono stato l'unico designer nella mia azienda per diversi anni. Un paio di mesi fa è stato assunto un collega per assumere parte del lavoro. Ho trovato difficile tenere traccia della sua struttura di fare le cose. Sembra pensare in modo molto diverso a me stesso e organizza i suoi progetti in un modo molto diverso da me. Gli ho parlato di questo, ma ha detto che questo è ciò che ha un senso logico per lui. Tuttavia, quando guardo il suo lavoro, mi ci vuole il doppio del tempo necessario per capire cosa sta succedendo rispetto a quello che sarebbe se fosse un mio progetto.

È significativamente meno esperto di me (io ho 10 anni, lui 2). Non so se il suo metodo sia dovuto al fatto che non si è ancora veramente stabilito o se è davvero così che fa le cose.

Come posso trovare un terreno comune con il mio nuovo collega? Voglio essere rispettoso di lui, ma il suo stile di design sta davvero intralciando il nostro progresso come squadra.


Per chiarire da dove provengono le mie tecniche: sono stato formato da un'azienda che era molto più grande e aveva uno standard di progettazione interno consolidato. Non mi sono chiesto da dove venisse. Quando ho iniziato presso il mio attuale datore di lavoro, una delle prime cose che ho chiesto è stata "qual è il tuo standard di progettazione?". Non ne avevano uno, e io ero praticamente lasciato a usare le tecniche che avevo imparato. Questi si sono leggermente evoluti per soddisfare le esigenze di un'azienda più piccola. Ho lavorato davvero solo per queste due società, quindi non sono stato in grado di valutare oggettivamente il mio processo di progettazione rispetto al settore nel suo complesso.

Quanto tempo in più impiega il tuo collega per lavorare con i tuoi progetti?È molto più facile rispondere a questa domanda se uno dei due approcci è oggettivamente più efficace :)
@Erik È difficile essere obiettivi perché è naturale per me pensare che il mio stile sia il migliore.Non ha accennato se trova la mia strada illogica.Non so come farei a chiedere.Forse "questo ha senso per te?"Quando esaminiamo il mio codice.Non voglio davvero essere condiscendente perché sono molto più esperto.
Non esiste una struttura o un modello di uno standard di buona pratica da seguire nella progettazione di circuiti elettrici?
@Leon Quando sono stato formato, l'azienda che mi ha formato ne aveva uno, che è ciò che mi è stato insegnato e che ha costituito la base di ciò che uso oggi.Modificherò un po 'di più la domanda.
@stanri va bene, allora dovresti documentare i tuoi standard se pensi che siano impeccabili oltre ogni dubbio o trovarne alcuni vicini a quello che hai ora o anche meglio quelli su cui si basava la tua formazione e applicarli!Non c'è altro modo per comunicare in modo efficiente tra persone che inevitabilmente hanno idee diverse e sono cresciute in diverse abitudini quando imparano una materia!
Il tuo collega probabilmente la pensa allo stesso modo sui tuoi metodi di raggruppamento.
@TotumusMaximus certo, motivo per cui voglio stare attento nel considerare la sua opinione invece di dichiarare meglio la mia strada.
Nessuno indicherà i circuiti elettrici / gioco di parole comune ?!
@Jake HA!Non me ne sono nemmeno accorto.È divertente.
nella programmazione, è comune per i team definire una * guida di stile *, che dice cose come "se crei una variabile che è una costante, fai precedere il suo nome da un trattino basso".di solito, i team usano guide di stile che sono già state scritte da altri e sono pubblicate online, come la guida di stile di gnu.quando non è disponibile una guida di stile ben scritta adatta a un determinato caso d'uso, il team lavora * insieme * per creare una guida di stile per il proprio progetto.
Hai trascorso diversi anni lavorando da solo e hai sviluppato una serie di abitudini personali legate al lavoro.Non c'è assolutamente nulla nel tuo post per dimostrare se queste sono buone o cattive abitudini, ma (quasi per definizione!) Pensi che siano buone, altrimenti presumibilmente lavoreresti in un altro modo.O devi imparare la lezione di base che "ci sono più modi per scuoiare un gatto" rispetto a quello che stai attualmente utilizzando, o devi passare a un altro lavoro in cui non devi lavorare con nessun altro!
Non dovresti.Il tuo sistema è superiore.Perché è lì - è in tutti i progetti.Esperienza a parte (che manca seriamente al tuo nuovo collega) il tuo sistema è stabilito E tutto il lavoro esistente lo segue - il che significa che a meno che qualcuno non pianifichi cambiamenti, dovrebbe essere usato perché la coerenza ha una qualità propria.Questo è il tempo di HR per seguire la procedura stabilita.
@TomTom Senior: "Passiamo tutte le nostre password nei nostri siti web utilizzando GET" Junior: "Aspetta, GET mostrerebbe la password nell'URL, penso che dovremmo cambiarla."Senior: "Non dovremmo. Il nostro sistema è superiore. Perché è presente - è presente in tutti i progetti. Ti segnalo per non aver seguito la procedura stabilita."
Si.Commento di Smartass su un caso limite.Molto bene.
@TomTom pensi davvero che questo sia l'unico esempio che qualcuno potrebbe inventare?Gli esempi vengono utilizzati per dimostrare errori fondamentali nella logica.In questo caso, l '[is-dovrei fallacia] (https://en.wikipedia.org/wiki/Is%E2%80%93ought_problem).Capisco che in molti casi far oscillare la barca è un male, ma se l'OP ammette di non conoscere la migliore pratica, la barca potrebbe non essere stabile per cominciare.
@LordFarquaad Questa è tutta una questione di * stile *.Sono stato nel settore abbastanza a lungo per conoscere le corrette pratiche tecniche standard.
@stanri quindi attenersi assolutamente a queste pratiche e chiedere anche al tuo junior.Non ho scritto schemi circuitali dai tempi del college, quindi non conosco gli approcci di stile corretti o anche se ce ne sono di sicuramente corretti.Se lo fai di sicuro, allora attieniti anche a quelli (e di nuovo, prendi anche il tuo junior).Se non sei sicuro, penso che la risposta di nvoigt sia perfetta, soprattutto se si considera la scalabilità futura.
@WoodrowBarlow Sono abbastanza sicuro che la tua guida di stile dice che se crei variabili che sono costanti, dovresti invece creare una costante._grumble, brontolio, brontolio _...
Solo ipoteticamente, supponiamo che tu gli abbia chiesto di spiegare una delle sue convenzioni - e hai visto che in realtà aveva più senso del tuo modo.Come vorresti sentirti?Cosa vorresti dire?
@Beta Gli ho chiesto, e ha detto che ha senso per lui personalmente.Il ragionamento che ha dato era soggettivo.Se vedessi che il suo ragionamento aveva senso, probabilmente ne adotterei le parti rilevanti.
Tre risposte:
nvoigt
2017-07-18 13:28:51 UTC
view on stackexchange narkive permalink

Progetto circuiti elettrici per vivere.

Come posso trovare un terreno comune con il mio nuovo collega?

Hai lavorato tutto solo per anni. Il tuo standard ha senso per te. Dovresti davvero cercare lo standard del settore su questo. Prima o poi assumerai più ragazzi o forse cambierai azienda. La progettazione di circuiti elettrici non è esattamente un territorio hipster. Le persone l'hanno già fatto e hanno avuto gli stessi problemi che hai tu. Come tenersi organizzati.

Hai questo problema con 2 persone, immagina solo le aziende con team di 10 o 100. Hanno degli standard. Trovatene e leggetene un po 'e poi decidete insieme se volete adottarne uno o costruirne uno vostro sulla base di quelli. Uno standard aiuta anche nell'acquisizione di nuovi lavoratori. Possono leggerlo e adattarsi invece che il tuo team debba correggerli ogni volta fino a quando non sono frustrati.

Quindi cerca gli standard del settore. Quindi scegline uno.

Questo è un buon punto.Non ho lavorato da solo per tutta la mia carriera;Sono stato formato da un designer molto esperto per i primi 4 anni circa, che ha costituito la base per le tecniche che uso oggi (si è anche evoluto un po 'da allora).Quella compagnia era più grande e aveva uno standard di progettazione, ma non so se si basasse su uno più ufficialmente riconosciuto.Lo esaminerò.
+1 E voglio sottolineare la parte ** decidere insieme **.Non limitarti a scegliere il tuo preferito e ordinare al tuo collega di seguirlo.Devi discutere di ciò che ha più senso per i tuoi progetti, il tuo flusso di lavoro e per voi due.
Guardando intorno ai circuiti esistenti, o ci sono davvero molti standard o generalmente non vengono seguiti.In entrambi i casi, c'è un xkcd corrispondente: https://xkcd.com/927/
Questo può essere eccessivo per una piccola azienda, se le cose del ragazzo sono di buon livello e funzionano, e non ti danno eccessivo fastidio, direi di lasciarlo fare piuttosto che picchiare il povero ragazzo in testa solo perché lo facose diverse.
Dipende anche dalla posizione di entrambi.Se il nuovo lavoratore ha una posizione uguale alla tua, potrebbe vederti cercare di lavorare insieme per creare uno standard come minaccia.Ti suggerisco di andare prima dal tuo supervisore e di farlo salire a bordo.Vendi al supervisore il vantaggio di creare e documentare uno standard.Quindi il supervisore ASSEGNA il compito a entrambi di creare quello standard.Ci vorrà sicuramente del tempo per farlo, in particolare per redigere la documentazione e che deve essere approvata dai superiori indipendentemente dal fatto che l'altro ragazzo le cose sia una buona idea.
@PlasmaHH esiste un xkcd per tutto?
Danikov
2017-07-18 13:58:06 UTC
view on stackexchange narkive permalink

Abbiamo problemi simili nella codifica, per quanto riguarda lo stile e le preferenze personali. Di tanto in tanto arriva qualcuno che si sente molto forte su una certa cosa (tabulazioni contro spazi, quando mettere il tutore sulla riga successiva, ecc.) E, se sono odiosi, faranno una sorta di ampio raggio impegno che renda tutto conforme al loro modo di fare le cose. In alternativa, potrebbero coinvolgere l'intera squadra in infinite discussioni su qualcosa che non ha importanza quanto pensano ( i materiali del capannone delle biciclette).

Il le risposte a questo tipo di problemi iniziano con la conformità. Non c'è niente di peggio che avere più standard applicati a metà perché diversi membri del team lavorano inconsapevolmente o consapevolmente l'uno contro l'altro. Se trascorri la maggior parte del tempo a lavorare sui tuoi progetti e puoi rispettare l'approccio reciproco quando devi lavorare sui loro, non è un impatto enorme. Tuttavia, se qualcuno trascorre una quantità negativa di tempo a convertirsi alle proprie preferenze ogni volta che qualcosa passa sulla scrivania o si verifica uno yo-yoing passivo-aggressivo dei cambiamenti, hai un problema.

In secondo luogo, non farlo. t dondolare la barca. Se hai uno standard coerente che non è il tuo preferito, mantienilo coerente e non cambiarlo esclusivamente per preferenze personali. Tali sforzi di solito hanno pochissimi vantaggi e la possibilità di introdurre errori difficili da trovare. Avviare un nuovo progetto è il momento giusto per selezionare uno standard. Qualsiasi standard misto all'interno di un progetto (da nuovi contributori che non riescono a seguire un vecchio standard, o solo una decisione di cambiare) può lasciare le cose disordinate e confuse.

La terza cosa di cui hai bisogno è la leadership. Alla gente piace parlare di queste cose, ma non è sempre la discussione più produttiva da avere. Prenditi un po 'di tempo per parlarne, ma alla fine qualcuno deve mettere i piedi per terra e assicurarsi che tutti aderiscano agli stessi standard.

Quindi il mio consiglio per te sarebbe: discuti con lui del suo stile, ma alla fine prendi una decisione finale su uno stile unico con cui puoi convivere entrambi. Impara il suo stile e come rispettarlo per i design esistenti, ma per tutti i nuovi design usa lo stile comune concordato e rispettalo l'un l'altro. Non aver paura di ripetere quale potrebbe essere quello stile e discuterne ulteriormente, ma assicurati che tali modifiche siano concordate e comprese da tutte le parti coinvolte.

Non penso che tabulazioni / spazio o il posizionamento delle parentesi graffe siano equivalenti.Quelli sono cosmetici e le modifiche possono essere automatizzate.Dalla descrizione dell'OP mi sembra che il suo problema sia con l '** architettura ** del design: * Poiché questi design possono diventare giganteschi, raggruppo i sottoprogetti in un modo specifico, nomino le mie reti in un modo specifico, ecc.*.Non ho mai visto standard software per tali decisioni architettoniche.
Inoltre, un programmatore che si unisce a un altro che ha lavorato per anni per un'azienda (codebase consolidata) merita di essere licenziato per aver creato selvaggiamente il caos in tale codebase.La coerenza è una qualità a sé stante, a meno che il modo stabilito non sia una schifezza assoluta (cosa che accade).
@MatthieuM.Quando ho creato questa domanda, inizialmente ho scritto un'analogia di programmazione poiché mi capita di fare un bel po 'di programmazione, ma poi mi sono reso conto che l'architettura software è diversa dall'architettura hardware e non sarebbe rappresentativa della domanda reale.
Dipan Mehta
2017-07-18 13:57:10 UTC
view on stackexchange narkive permalink

Identifica le lacune

È relativamente facile entrare in conflitto con persone che non la pensano come te. I fratelli cresciuti sotto gli stessi genitori spesso incontrano attriti a causa di tali differenze. Il primo passo è identificare dove si trovano le lacune. Quanto gravemente siamo in disaccordo o no, quali aree hanno divari più gravi, in che modo questi divari ci influenzano oltre i semplici comfort di base: ad esempio, influisce sulla produttività? o il risultato finale del lavoro?

Comprendere il punto di vista reciproco

Perché l'altra persona pensa in modo diverso, a causa del proprio punto di vista. queste lacune si riducono man mano che si ha sempre più comunicazione. Quando incontriamo persone diverse da noi, impariamo di più: esempio per esempio. Più hai una comunicazione aperta, più possiamo analizzare se l'altra persona sarà o meno d'accordo o in disaccordo indipendentemente dai nostri gusti.

Impara a isolare risultati finali e dipendenze

Alcuni aspetti non verranno mai risolti perché sono fondamentali per la nostra personalità e le nostre idee fondamentali. Quindi, mentre impariamo a identificare ciò che sembra irrisolvibile, dobbiamo identificare i modi in cui possiamo separare le responsabilità o semplificare il modo in cui possiamo rimanere agnostici rispetto al punto di vista dell'altro e ricevere-consegnare il lavoro richiesto reciprocamente e per l'organizzazione.

Aumenta positivamente

Quando le cose non sembrano essere facili o influisce sul lavoro, sii obiettivo su dove i pensieri differiscono reciprocamente e su come influisce sul finale output del lavoro. Presentalo ai tuoi superiori che hanno le autorità per dividere i domini, o aree di lavoro o processi di configurazione che semplificano questi problemi di attrito.

Non portare l'attrito a casa o sulla testa

Anche se potrebbe volerci del tempo per risolvere le lacune nel pensiero delle persone, e gli adulti sicuramente non rinunceranno facilmente alle loro idee. Quindi ci saranno anche periodi in cui questi attriti ci mettono a disagio. Sii obiettivo e non prendere personalmente gli elementi di questi disaccordi. Ciò sarà essenziale per far sì che il tuo lavoro sia produttivo e di qualità e ti consentirà di stare tranquillo quando tornerai a casa.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...