Per tua informazione, la maggior parte delle università non insegnano cose come JSON. Insegnano cose come la traversata ad albero in profondità che teoricamente potresti applicare nella creazione della tua biblioteca JSON, ma qualsiasi cosa più pratica di quella quasi tutti sono autodidatti o imparati sul lavoro.

Cerca di non metterti sulla difensiva. Spiegare le tecnologie pratiche come JSON è qualcosa che ci aspettiamo di dover fare occasionalmente anche per i laureati. Qualcuno con migliori competenze sociali ti chiederà se prima ti è familiare. Se non te lo chiede, sentiti libero di interromperli e di dirglielo.

Non c'è motivo per cui non possiate indicare che il vostro collega sta fornendo informazioni superflue durante le discussioni tecniche.

Hey Coworker, saltiamo i dettagli banali e arriviamo al nocciolo della questione. Questo non è un uso molto efficace del nostro tempo.

Potrebbe avere la tendenza a spiegare eccessivamente le cose o ad andare fuori tema, ma una buona capacità di sviluppare ogni volta che si interagisce con altri sviluppatori è quella di mantenere le interazioni in maniera educata ma decisa e succinta, in modo che il tempo di tutti sia speso in modo efficiente.

Ad essere onesti, ho delle credenziali piuttosto buone e ho avuto un ex supervisore che mi ha fatto questo per tutto il tempo. Ho seguito un corso approfondito di CS sulla progettazione di database, avevo costruito tutti i tipi di applicazioni basate su database, e lavoravo professionalmente da anni, e lui aveva ancora il coraggio di spiegarmi (davanti a tutti gli altri) i principi della progettazione di database per principianti.

Ma non sono sicuro che lo facesse apposta. La verità è che ci vuole molta energia mentale per mettersi nei panni di qualcun altro e parlare al suo livello. Lo vedi di continuo: gli esperti a volte ti lanciano addosso un gergo senza senso, o altri ti parlano. Ma non è detto che lo facciano sul serio - semplicemente non spendono abbastanza energia per capire come comunicare bene.

Nella mia esperienza, questa è stata la cosa più difficile del tutoraggio di CS. Non solo dovevo comprendere a fondo il materiale, ma dovevo anche usare diversi cicli cerebrali per cercare di entrare nella testa dei miei studenti e capire cosa stavano pensando. Ma non tutti si esercitano a farlo in conversazioni casuali.

Quindi non essere troppo veloce a dare la colpa alla malizia. Potrebbe benissimo essere solo il loro imbarazzo sociale. Vi direi come non prenderla sul personale, ma ci sto ancora lavorando. Neanch'io personalmente lo sopporto…

Questo è simile ad altre risposte, ma con alcuni esempi concreti.

Se state chiedendo aiuto / voi due state discutendo il compito a portata di mano

Quando sono dall'altra parte di questo. È davvero difficile sapere quali sono le conoscenze di base di qualcuno quando si spiega qualcosa.

Sottospiegare e sopraspiegare sono entrambi negativi. La soluzione è comunicare ciò che si fa/non si sa in modo efficace e veloce.

Nel tuo esempio prima di immergersi troppo a fondo nello spiegare JSON, interrompere (policemente) in modo da poterlo spuntare dalla sua ‘lista di cose da spiegare’.

Oh ho capito cos'è JSON. Quello che non so è come deserializzarlo ad un oggetto in C#. Come si fa?

O nella discussione. Come dire se qualcuno ha proposto di usare JSON come formato e tu hai delle preoccupazioni. Interromperesti comunque perché vuoi arrivare rapidamente alla parte rilevante della conversazione.

Conosco bene JSON. Penso che XML potrebbe essere una scelta migliore, dato che i nostri servizi a monte lo prevedono già in XML.

Se siete stati presi in considerazione per non aver fatto qualcosa. Allora seguite lo stesso schema.

Lei: Avreste potuto usare X. X è un -

Lei (interrompendo): Sì, conosco bene X. Ho usato Y perché X ha questo svantaggio. Ho anche preso in considerazione Z, ma ho deciso di non farlo.

Her: Che ne dici di A che è un -

You (interrompendo): Ah sì, ho considerato anche A. Ma non ha funzionato a causa di MOTIVI.

Lei: Se si combina A con Z si possono risolvere MOTIVI.

Lei: Sì, potrebbe funzionare. Mi occuperò di questo.

Di solito il prefisso ‘Yea’ è una forma più piacevole e breve di ‘Sì, ne sono consapevole’, e questo mi tranquillizza.

Finché in generale manterrete un tono neutro non ne uscirete come se non ascoltaste le critiche.

Inoltre, un giorno o l'altro vi sbaglierete. Assicuratevi solo che quando lo siete, siate altrettanto aperti e onesti.

Se state chiacchierando in generale

Ora siamo nell'area del galateo della conversazione educata. Non è esattamente il mio forte, ma ecco come la gestirei io.

In molti casi mi limito a fare un cenno con la testa e aspetto finché non hanno finito. Dopo di che dirò qualcosa come ‘Ah sì, conosco bene JSON. che ho usato in X.“. E continuo la conversazione.

Se ho un posto dove andare, non c'è scelta, devo interrompere. Il che è più difficile in una conversazione normale. Ma fondamentalmente dico solo 'Sì’ e annuisco mentre parlano. E non appena si fermano anche solo un po’ dico la riga del paragrafo precedente.

Caveat

con cui ammonirei tutto quanto sopra: A volte è bene ascoltare comunque, perché si potrebbe cogliere qualcosa che non si sapeva. In effetti spesso _ chiedo alle persone di spiegare concetti come se non ne sapessi nulla.

Disclaimer: Non sono uno sviluppatore di software

Le consiglio di evitare di dare per scontato che sia intenzionalmente accondiscendente. Potrebbe benissimo essere che lei pensi che la tua mancanza di istruzione superiore significhi che non hai conoscenze dei concetti di programmazione di base, ma non ne hai la prova, quindi è meglio che non lo pensi. Spesso spiego i concetti di base nelle riunioni di pianificazione perché mi aiuta ad abituarmi a certi problemi e mi assicura che tutti seguano il mio processo di pensiero, non perché penso che le altre persone nella stanza siano degli idioti.

Oltre alle eccellenti risposte di @Link0352 e @JeffO, dove possibile, raccomanderei solo di riportare delicatamente la conversazione al livello a cui deve essere per una discussione produttiva.

Certo, potremmo manipolare il JSON, ma questo potrebbe portare al problema X. In questo caso, raccomanderei di manipolare l'oggetto direttamente (O qualunque cosa sia).

(presumo che questa interazione sia avvenuta durante una riunione tecnica e che il collega non si sia limitato a gironzolare fino al vostro cubo e abbia iniziato a blaterare di JSON. Se questo è il caso, la mia risposta non è veramente valida).

Oltre ad altre risposte, la mia soluzione generica per le persone che ti spiegano cose ovvie:

Quando hanno finito, gira la tabella. Inizia a spiegare una conoscenza più approfondita dell'argomento recente o a spiegare un altro argomento molto ovvio, ad esempio

altra persona : Json è un grande per … e puoi fare … tu (sorridere / amichevole): Esattamente! Quello che mi piace anche di Json è che si può …..

o se si vuole essere un po ‘cattivo

altra persona : Json è un grande per … e puoi fare ….

tu (sorridente/amichevole): Esattamente! Hai mai sentito parlare di XML? È una [spiegazione di qualcosa di molto ovvio].

Da un altro dev

femmina sono una sviluppatrice con un'istruzione universitaria e lavoro da un po’ di tempo. Devo dire che non ho altro che ammirazione per gli sviluppatori autodidatti. Onestamente c'è una tale quantità di cose che ho faticato ad imparare che non riesco a credere che voi ragazzi siate riusciti ad insegnare a voi stessi. E mi piace discutere con chi è autodidatta perché di solito avete un tipo di competenze completamente diverse da quelle dell'università. È stimolante e piuttosto tbh.

E per quanto riguarda la signora che ha iniziato a spiegarvi un JSON, non ci pensate troppo. Ci succede spesso. Uomini che hanno buone intenzioni ma finiscono per spiegare cose banali perché siamo ragazze e siamo così poco comuni in questo campo che sentono di doverci aiutare un po’ di più, anche se a volte diventa un po’ offensivo. Sono fortunata ad essere stata accolta con nient'altro che rispetto nel mio posto di lavoro, ma ho sentito alcune storie dell'orrore.

Probabilmente non voleva dire niente di male, ma molto probabilmente erano solo le sue insicurezze che trasparivano un po’ e forse si sentiva come se dovesse mettersi alla prova insegnandovi qualcosa.

Io consiglierei la pazienza. Ho assistito a conversazioni tra persone con la migliore formazione e con decenni di esperienza, discutendo di una situazione di programmazione in cui si partiva dal punto di vista del quadrato 1 assoluto. Che dobbiamo rappresentare un'entità del mondo reale nel software, che una struttura di dati è stata creata per essere quella rappresentazione, che questi dati devono essere inviati in rete ad un altro sistema, ecc.

Quello che ho dedotto dal loro approccio è stato che prendendo un paio di minuti per rendere il maggior numero possibile di ipotesi esplicite e stabilire una catena di ragionamento condivisa, sono state gettate solide basi per lavorare insieme.

Può darsi che queste spiegazioni siano o meno un segno di mancanza di rispetto o di risentimento (o un tentativo di dimostrarvi la sua conoscenza), ma possono essere trasformate in un'opportunità per mettersi sulla stessa lunghezza d'onda e condividere prospettive per migliorare il rapporto di lavoro.

Se la cosa ti sfugge di mano o senti davvero il bisogno di dire qualcosa, ti suggerisco di fare una domanda che mostri il limite della tua comprensione.

“JSON è un formato per rappresentare le strutture di dati come testo”.

“Oh, JSON, stavo giusto leggendo delle diverse implementazioni, sai se c'è un esempio di riferimento di un parser costruito con lex e yacc per JSON?

Aprite la mente.

University insegna competenze che non troverete nei libri (a parte i libri di testo universitari) e che probabilmente vi mancano se siete autodidatti. Come faccio a saperlo? Ho studiato, ma alcune parti del campo non facevano parte del mio curriculum e sono autodidatta in questi campi. Quindi conosco entrambe le parti.

Probabilmente ha qualcosa da insegnarti, ma entrambi non vi rendete conto di cosa sia. Pensa di dover spiegare i concetti di base. Questo potrebbe essere o perché è condiscendente, socialmente goffa, arrogante, ha un complesso d'inferiorità o qualsiasi altra cosa in cui volete credere - o potrebbe essere perché vuole davvero sostenervi.

In dubio pro reo, quindi fino a prova contraria, assumete il meglio e accogliete le sue discussioni con una mente aperta. Tuttavia, una volta che vi rendete conto che sapete già cosa sta cercando di spiegarvi, ringraziatela e spiegatele che lo capite già. Chiedetele cos'altro ha da offrire, siete desiderosi di imparare e migliorare costantemente. Questo è il vantaggio di essere autodidatta: Capisci che l'apprendimento è un processo costante che non si conclude con l'esame o la tesi di master.

Usa questo vantaggio. Imparate da lei, questo può essere solo a vostro vantaggio.

E un giorno ci sarà qualcosa che voi sapete e lei no. Insegnatele in modo amichevole e non vincolante e voi due potreste partire per un rapporto di lavoro brillante e di reciproco sostegno.

L'ho visto molte volte come consulente nel corso degli anni. La risposta è semplice. Questo è un meccanismo di coping.

È uno dei due complessi e può essere una combinazione di entrambi.

• Complesso di Inferiorità

• Complesso di Superiorità

Entrambi sono un meccanismo di difesa.

Se siete l'unico bersaglio di tale comportamento, allora il soggetto è probabilmente minacciato dalle vostre abilità o capacità.

Se siete uno dei diversi bersagli di tale comportamento, allora è una generale sensazione di inferiorità all'interno del trasgressore.

In generale, vedrete una compensazione mista a grandiosità di qualche forma. Potrebbe essere semplice come essere eccessivamente orgogliosi del proprio grado. Nessuno è immune dall'essere un bersaglio. Per esempio, ho visto persone con gradi inferiori attaccare quelli con gradi superiori, come gli ingegneri. È un meccanismo di livellamento che cerca di aumentare la propria autostima diminuendo un'altra statura. Vediamo questo comportamento sul terreno da bambini.

Mentre potreste non voler attaccare qualcuno per un tale insulto, questo comportamento può essere un pericolo per voi e per gli altri, specialmente nella forza lavoro.

Probabilmente, c'è poco da fare per combattere questo senza farvi fare brutta figura. Il motivo è che la transazione è stata progettata non solo per indicare la superiorità, ma anche per sollecitare una risposta che faccia rispettare la superiorità.

In questo caso, sembra che il trasgressore abbia assunto il ruolo di genitore. Solo una risposta da parte di un adulto è sufficiente. Una risposta Genitore o Figlio significa che si perde. Questo può essere visto leggendo I’m OK, You’re OK e Games People Play . Entrambi si basano sull'Analisi Transazionale. Sarebbe utile leggere il primo libro. È relativamente semplice da capire e ti insegna a riconoscere i tre stati e come rispondere.

In parole povere, questa è l'analisi transazionale.

Sono riluttante ad offrire suggerimenti su come combattere verbalmente questo problema, poiché i consigli potrebbero essere potenzialmente dannosi. Questo deve essere combattuto al momento.

Per riferimento, l'Analisi Transazionale non è psicologia pop. È un vero e proprio strumento che deve essere compreso. Ho usato l'AT nella mia carriera di consulente ed è stato molto significativo per il mio successo come consulente IT. Mi ha permesso di affermarmi come l'adulto nella stanza, di esprimere il mio punto di vista e, si spera, di rendere efficaci le mie soluzioni.

Sono stato spesso chiamato per risolvere un problema o sostituire un sistema di cui qualcuno era responsabile. Spesso il potere veniva tolto all'individuo che ora era sulla difensiva. Battaglie come queste spesso riguardano il potere, la perdita o l'acquisizione di potere. L'obiettivo è quello di minimizzare la minaccia riducendo al minimo la perdita. Ad esempio, in un'azienda globale, Microsoft Mail stava invecchiando e doveva essere sostituita. Il dipendente responsabile teneva i regni in pugno e gestiva tutti i server che richiedevano la presenza in un unico luogo. Per una società di telecomunicazioni globale, questo è stato un disastro. La gente in Giappone doveva connettersi ai server in Virginia per leggere la posta elettronica. L'onere era enorme e le e-mail non sarebbero state consegnate entro 24 ore. Il dipendente aveva paura della tecnologia che non capiva o non conosceva ed era preoccupato per il suo lavoro con un sistema globale distribuito. La soluzione è stata quella di accompagnare il dipendente attraverso la formazione, l'installazione di test, il supporto di sistemi remoti e fargli capire che svolgeva ancora un ruolo fondamentale all'interno dell'organizzazione. Non stava perdendo potere, ma guadagnando potere. Tutto questo attraverso TA.

Okay. Bene e bene. La risposta breve che ho è capire i tre tipi di transazione e imparare a presentare una postura da adulto e a riconoscere il vero obiettivo della transazione che vi viene presentata. Si può rapidamente e facilmente cortocircuitare il problema senza che nessuno se ne renda conto e posizionarsi come leader in modo silenzioso ma efficace. L'effetto complessivo si vedrà.

La maggior parte delle risposte qui riguardano il confronto o la commiserazione con la vostra esperienza. Non credo che il confronto valga il vostro tempo o quello degli altri sviluppatori.

Invece vi consiglio un po’ di ingegneria sociale che è stata spesso praticata da Benjamin Franklin aka l'Effetto Benjamin Franklin :

Chiedete aiuto, consigli, suggerimenti. Chiedere un favore è un segno di intimità e fiducia.

Questa può sembrare un'iniziativa controproducente, ma se si fanno alcune domande puntuali su argomenti più delicati, farà sì che qualcuno riconosca subliminalmente che si comprende l'argomento fondamentale e quindi si ha più fiducia. Inoltre, li farà sentire più fiduciosi di voi perché siete venuti da loro per questo argomento “difficile”.

Questa è una soluzione rapida e non conflittuale che funzionerà nella maggior parte dei casi.

L'IT è un campo molto ampio.

Supponendo che qualcuno devesse conoscere JSON solo perché ha un totale di 4 anni di esperienza (o 40) sarebbe una cosa piuttosto stupida da fare da parte del vostro collega. Avreste potuto sviluppare applicazioni che non usano JSON, o framework che nascondono i dettagli di JSON.

Peggio ancora, avreste potuto imparare a usare JSON solo in parte (per esempio, modificando il lavoro di qualcuno che non è stato abbastanza attento); assegnarvi un JSON taks senza assicurarvi di sapere come JSON viene usato nella vostra organizzazione potrebbe portare a un prodotto scadente. Ad esempio, forse il vostro codice deve funzionare non solo per il successo, ma anche per mostrare un messaggio appropriato in caso di errore.

Dato che siete nuovi nella vostra posizione, uno dei mezzi del vostro collaboratore per garantire che il lavoro sia fatto correttamente è quello di rivedere le vostre conoscenze. Il metodo descritto sopra è uno dei disponibili, potrebbe in alternativa scegliere di interrogarvi o aspettare che il vostro compito sia finito e rivedere il codice. Non so se preferisci uno di questi metodi. Certamente, il solo fatto di lasciarti essere è rischioso (per te, per lei e per l'azienda) fino a quando non è sicura che tu sia all'altezza del tuo compito.

Nota che nulla di quanto sopra è legato alla tua mancanza di certificazione accademica.

E il punto “Ho superato il colloquio tecnico” non ti esonera dall'essere esaminato. Un colloquio tecnico dà solo una valutazione molto superficiale della vostra competenza; dice che potete scrivere codice che funziona ma non che potete scrivere del buon codice.

Ci sono molti aspetti importanti ma non possono essere esaminati facilmente:

• Capacità di capire i problemi.

• Capacità di leggere il codice di altre persone.

• Capacità di usare un'architettura adeguata.

• Capacità di scrivere un codice ben strutturato.

• Programmazione difensiva.

• Buone pratiche nell'uso degli strumenti (controllo di versione, test automatizzati).

E per la questione “laurea vs autodidatta”, accettate che la mancanza di una laurea significa che il vostro interlocutore può fare meno ipotesi su ciò che sapete o non sapete1. Specialmente in relazione ai punti sopra spiegati (molte persone autodidattate non sanno nemmeno dell'esistenza di questi fattori e basta andare al “Voglio fare un programma che fa X "2)

Qualcuno con una laurea può certificare una base minima di conoscenza3, la mancanza di una laurea rende più forte il fatto che il vostro interlocutore può essere insicuro del vostro livello fino a quando non dimostrate di essere voi stessi. Quindi, non mettetevi sulla difensiva se il vostro interlocutore sceglie di controllare due volte che le vostre conoscenze siano abbastanza complete per il compito da svolgere.

TL/DR Date a quel programmatore un po’ di tempo, in modo che possa controllare da sola le vostre capacità.

1Of course, questo non significa che qualcuno con un diploma accademico sia sempre in grado di scrivere del buon codice perché qualcuno gli ha spiegato "programmazione difensiva”. Ma la laurea assicura che almeno lui dovrebbe sapere cosa significa il concetto.

2Ora sto modificando un programma fatto

3In realtà, questa è fondamentalmente l'utilità delle lauree.

Parlane con lei.

La tua interpretazione del suo comportamento è che è perché ti considera inesperto. Molte delle altre risposte hanno dato suggerimenti per interpretazioni alternative del suo comportamento, e alcune danno suggerimenti su come chiudere il comportamento, il che, senza sapere perché lo fa, potrebbe inutilmente mettere ulteriore stress al rapporto.

L'unico modo per sapere perché lo fa è parlarne con lei. L'ideale sarebbe chiederglielo direttamente, farle sapere perché glielo chiedi e assicurarle che se non capisce qualcosa glielo chiederà.

La conosci meglio di tutti noi, quindi dovresti avere un'idea migliore di come reagirebbe, ma considera di iniziare con una cosa del genere:

Ehi Sue, so che non lavoriamo insieme da molto tempo e che stiamo ancora imparando cosa aspettarci l'uno dall'altra. Ho notato che quando parliamo di negozio spesso si cade in spiegazioni piuttosto elementari di quelli che io considero argomenti standard. Perché? Spero che sia perché X o Y (dare una o due delle interpretazioni più generose delle altre), ma spesso mi sembra di averti dato l'impressione di aver bisogno di una spiegazione di queste cose. Se è così, sembra che stiamo sprecando tempo prezioso che potrebbe essere utilizzato in modo più produttivo discutendo le caratteristiche richieste. Se non siete sicuri della mia esperienza su un argomento, potete chiedermi cosa ne so, e se la discussione tocca qualcosa al di fuori della mia esperienza confidate che ve lo chiederò.

All'inizio non la interromperei mentre è in una delle sue spiegazioni per avere questa discussione perché sembra più probabile che si presenti come reazionaria o difensiva. Meglio affrontarla separatamente.

Andando avanti da lì, a seconda di ciò che viene dalla discussione iniziale, quando e se succede di nuovo, si potrebbe interporre che questa è una di quelle spiegazioni di base, o iniziare ad applicare alcuni dei suggerimenti degli altri su come rispondere in linea.

** A parte:**

In un progetto l'anno scorso ho dovuto spiegare cos'era JSON ad un paio di membri del team. Entrambi hanno almeno un decennio (o due) di esperienza nel settore su di me, e in vari momenti della loro carriera entrambi hanno lavorato su progetti web. Non hanno mai lavorato con strutture o tecniche che fossero particolarmente rilevanti.

Nello stesso progetto, alcuni dei nostri colleghi di lavoro utilizzavano gli stessi due o tre termini che si riferiscono a due argomenti strettamente correlati ma (a quanto pare) distinti. Il significato di un determinato termine dipendeva da quale di essi lo utilizzava e in quale contesto. In realtà ci sono volute alcune iterazioni per farci capire. Fino a quel momento, non è mai stato detto chiaramente che ci fossero argomenti distinti. Più di recente, in una discussione su un'applicazione configurata in modo errato, ho chiesto a un membro del team di andare su una tangente per mezz'ora proponendo modifiche sbagliate al nostro framework di configurazione per evitare che venisse selezionato l'ambiente default sbagliato, quando il problema era che l'applicazione aveva il valore default sbagliato per un'impostazione individuale. (Il framework permette valori di fallback predefiniti nel caso in cui non venga sovrascritto per l'ambiente corrente, l'applicazione aveva quello che dovrebbe essere un valore di default impostato come solo produzione, quindi quando un ambiente di test non lo sovrascriveva…)

Qual è il punto? Quasi ogni campo professionale è abbastanza ampio che per ogni persona, indipendentemente dal livello di esperienza, è impossibile sapere tutto. Ognuno di noi avrà diversi buchi nella propria conoscenza ed esperienza, e potrebbero esserci sottoculture e specializzazioni con un gergo scontroso. Non si possono fare supposizioni su ciò che gli altri sanno, o intendono, o sul perché prendono certe decisioni.

È stata la mia esperienza, le supposizioni non dichiarate possono (e alla fine lo saranno) essere molto costose. Qualche minuto speso per assicurarsi che tutti siano sulla stessa lunghezza d'onda prima di iniziare qualsiasi discussione risparmierà molto nel lungo periodo.

In questo caso la tua supposizione che lei stia facendo questo perché ti viene insegnato da sola, e/o (se la tua supposizione è corretta) la sua supposizione che tu abbia bisogno dell'istruzione sta causando un danno al tuo rapporto di lavoro.

Lo sviluppatore con o senza laurea deve essere rispettato allo stesso modo sul posto di lavoro.

Ho letto tutte le risposte di cui sopra e la maggior parte di esse sottolineano che lei è gentile e che tu non ci pensi più.

Ma dalla tua domanda, non sembra proprio. Sembrava che ti sentissi insultato dal suo comportamento.

Secondo me, è il momento, devi mostrare le tue capacità. Può essere la sua percezione che la laurea sia ciò che fa un “Sviluppatore di software”, ma nella mia esperienza di lavoro su progetti in tempo reale e di risoluzione di scenari critici è ciò che fa un “Sviluppatore di software”. Non vantarti, ma partecipa alle discussioni tecniche in modo proattivo.

Per mettere in mostra senza vantarti, inizia ad aiutare i tuoi compagni, junior ecc. Il vostro lavoro, le vostre capacità e tutto il resto parleranno da soli.

Questo è un po’ più complicato di quanto non facciano apparire alcune delle risposte. Non dovresti uscire allo scoperto e dire che non hai bisogno di aiuto (arroganza), né dovresti continuare ad ascoltare in silenzio (è fastidioso!).

Il mio consiglio è di… abbagliarla con la tua conoscenza. Se capisci qualcosa che ti viene spiegato nell'industria dello sviluppo software, mostra alla persona che te lo sta spiegando che lo capisci, discutendone, e poi introducendo gradualmente la tua conoscenza avanzata dell'argomento per mostrargliela. Quando qualcuno si limita ad ascoltare, molte persone, e soprattutto gli ingegneri, sono inclini a pensare che l'ascoltatore non sia in grado di impegnarsi nella discussione perché non capisce.

Case and point, quando qualcuno vi sta spiegando qualcosa di ovvio nell'industria, state in silenzio, è probabile che lo spieghi di nuovo in un modo leggermente diverso… più volte con una frustrazione incrementale. Rispondete, mostrate che lo sapete, e che tendono a lasciarvi in pace, o a trovare qualcosa di meglio di cui discutere.

Per fermare completamente il tormento tecnico, mostrate che sapete PIÙ di quanto la persona che cerca di insegnarvi e che imparerà rapidamente a non farvi la predica e se qualcosa vi viene in mente con delle domande.

Ora, se vi stanno spiegando JSON perché avete commesso un errore critico, o avete appena dimostrato un concetto architettonico mancato, è qui che state zitti e ascoltate.

Solo la mia opinione su ciò che ha funzionato per me in passato, tutti sono un po’ diversi, però.

Attenzione: Questo funziona solo con alcune persone in alcune situazioni; YMMV. Questa risposta non ha alcuna garanzia.

Quello che farei in questo caso è interromperli con un riassunto dell'argomento. Per esempio, con JSON:

Loro: JSON è JavaScript Object Notation, che è un modo di rappresentare - Me: Oggetti simili a dizionari e, erm, array e primitive e, primitive JavaScript voglio dire, in un formato serializzato.

Questo rappresenta la seguente situazione:

Them: JSON è JavaScript Object Notation, che è un modo di rappresentare - Me: Qualsiasi oggetto in JavaScript come stringa. Them: No, perché non può memorizzare funzioni, o oggetti che hanno proprietà nascoste; è una rappresentazione molto semplice di…

Interromperli con “sì, lo so” in questo caso porterebbe a problemi in seguito, quando ho scoperto di non sapere cosa fosse in realtà JSON, quindi ha causato problemi nel codice con le mie supposizioni.

Il tuo collega sta probabilmente solo cercando di assicurarsi che tu sappia tutto ciò che è necessario. Se sei “autodidatta”, allora significa che potresti avere delle lacune che la maggior parte delle persone penserebbe che tu abbia colmato, dato che conosci le “cose più difficili” (anche se la maggior parte degli istituti di istruzione insegna queste cose in un ordine molto strano!) e questo tipo di supposizioni può portare a problemi sottili e difficili da trovare a causa di false supposizioni.

*: vedi la parte superiore della risposta.

Non ha menzionato il settore, che farà una bella differenza.

Lavoro in una grande azienda di alta tecnologia e spesso assumo giovani sviluppatori (0-2 anni di esperienza). La scuola che hanno frequentato e la loro laurea non fa la minima differenza per me.

Recentemente ho rifiutato due candidati della migliore scuola del paese per assumerne uno da una scuola di cui non ricordo nemmeno il nome. La differenza tra loro era che i primi due erano bravi e il terzo era brillante, anche perché era un autodidatta. Era ovvio che dopo 5 minuti sarebbe andato alla grande.

Che cosa significa questo nel contesto della tua domanda? Probabilmente che potresti essere più adatto in un settore che dà più importanza alla conoscenza rispetto alla scuola.

A seconda del paese questo può essere più o meno difficile, poiché diversi paesi considerano le loro scuole con diversi livelli di deferenza (la Francia è l'estremo in cui si indossa quasi la biancheria intima blasonata con la tua scuola, se sei di quella giusta - non è una cosa negativa a seconda del tipo di lavoro)

Credo si possa dire - conosco già un po’ (enfasi su poco) di JSON. Quindi, possiamo saltare JSON per ora? Ma, se c'è qualcosa che non so di JSON, posso chiederti aiuto più tardi?

Diciamo al tuo esempio che tu non manipoli JSON. Si prende JSON, lo si converte in un oggetto modello, si manipola l'oggetto modello e lo si riconverte in JSON. Scommetto che se il vostro collega cerca di manipolare JSON direttamente, ci saranno dei bug perché JSON è semplice, ma non quello semplice.

Ora, se è così intelligente, stampate una copia di questo documento https://www.ics.uci.edu/~dan/pubs/LenLimHuff.pdf che riguarda il calcolo dei codici Huffman ottimali con lunghezze di codice limitate (i codici Huffman con lunghezze di codice illimitate sono semplici) e chiedetegli di spiegarvi questo algoritmo. Molto probabilmente non sarà in grado di farlo, nel peggiore dei casi lo farete tacere per un bel po’. (I codici Huffman di lunghezza limitata sono importanti, perché consentono decodificatori molto più efficienti). PS. Se lui o lei può spiegarvi l'algoritmo, allora lui o lei è bravo. Ne dubito.

A parte questo, se qualcuno cerca di spiegarti JSON, gli chiedi cosa sta cercando di ottenere lì? Pensa che JSON sia qualcosa di difficile che non si può capire senza una laurea in scienze naturali? Sul serio? Non pensa che sia un po’ pieno di sé? Il suo comportamento è offensivo, quindi gli si restituisce il bene che si merita.

Gli sviluppatori autodidatti saranno spesso esperti in tecnologie in cui hanno esperienza pratica, ma a volte il problema è che non sanno quanto non sanno. Per esempio, ho incontrato spesso sviluppatori autodidatti che hanno inventato un nuovo algoritmo per risolvere un problema quando c'è un noto algoritmo standard, che spesso è molto meglio.

Cerca di ricordare che se tu fossi un idraulico o un elettricista, figuriamoci un medico o un avvocato, non ti sarebbe permesso di esercitare senza qualifiche formali. La programmazione, infatti, è piuttosto unica nel permettere a coloro le cui competenze sono interamente autodidatta di esercitare la professione. E molti di coloro che lo fanno, fanno un lavoro eccellente. Ma cercate di riconoscere che coloro che hanno fatto una laurea in Scienze Motorie hanno imparato cose che voi non avete imparato, e siate aperti ad imparare da loro.

Per inciso, una laurea in Scienze Motorie non vi insegnerà molto su JSON. Vi insegnerà, però, a quale classe di grammatica JSON appartiene, e quindi quale classe di parser è necessaria per elaborarlo: vi insegnerà ad evitare l'errore di cercare di analizzare JSON usando espressioni regolari, perché la teoria vi dice che non si può fare. Basta seguire StackOverflow per qualche settimana per vedere quanti programmatori non sono a conoscenza di tali fondamenti.