FYI, de meeste universiteiten geven geen les over dingen als JSON. Ze onderwijzen dingen zoals diep-eerste-boom-traversal die je theoretisch zou kunnen toepassen in het creëren van je eigen JSON-bibliotheek, maar alles wat praktischer is dan dat.

Probeer niet defensief te worden. Het uitleggen van praktische technologieën zoals JSON is iets wat we af en toe verwachten te moeten doen, zelfs voor universitair afgestudeerden. Iemand met betere sociale vaardigheden zou vragen of je er eerst mee vertrouwd bent. Als ze het niet vragen, kun je ze gerust onderbreken en het hen vertellen.

Er is geen enkele reden waarom je niet kunt aangeven dat je collega overbodige informatie verstrekt tijdens technische discussies.

Hey Coworker, laten we de triviale details overslaan en tot de kern van de zaak komen. Dit is geen erg effectief gebruik van onze tijd.

Ze heeft misschien gewoon de neiging om dingen te overbelasten of om van het onderwerp af te komen, maar een goede vaardigheid om elke keer dat je met andere ontwikkelaars communiceert te ontwikkelen is om beleefd, maar stevig de interacties beknopt te houden en op het onderwerp te blijven, zodat ieders tijd efficiënt wordt besteed.

Om eerlijk te zijn, ik heb vrij goede referenties en ik heb een voormalige toezichthouder dit de hele tijd laten doen. Ik volgde een diepgaande CS les over databaseontwerp, had allerlei databasegestuurde applicaties gebouwd, en had jarenlang professioneel gewerkt, en hij had nog steeds het lef om me (in het bijzijn van alle anderen) beginnende databaseontwerp principes uit te leggen.

Maar ik ben er niet zeker van dat hij het expres deed. De waarheid is dat het veel mentale energie kost om jezelf in de schoenen van iemand anders te schuiven en op hun niveau te spreken. Je ziet het de hele tijd: experts gooien soms zinloos jargon naar je toe, of anderen praten tegen je neer. Maar ze bedoelen het niet per se - ze besteden gewoon niet genoeg energie om uit te vinden hoe je goed kunt communiceren.

In mijn ervaring was dat het moeilijkste aan bijles geven aan CS. Niet alleen moest ik het materiaal diepgaand begrijpen, ik moest ook heel wat hersencycli gebruiken om in de hoofden van mijn studenten te komen en uit te zoeken wat ze dachten. Maar niet iedereen oefent dat in een informeel gesprek.

Dus wees niet te snel met het bijschrijven van kwaadwilligheid. Het kan heel goed gewoon hun eigen sociale onhandigheid zijn. Ik zou je zeggen hoe je het niet persoonlijk opneemt, maar ik ben er zelf nog steeds mee bezig. Ik kan er persoonlijk ook niet tegen…

Dit is vergelijkbaar met andere antwoorden, maar met een paar concrete voorbeelden.

Als je om hulp vraagt / jullie twee bespreken de taak waar het om gaat

Als ik aan de andere kant van de lijn zit. Het is echt moeilijk om te weten welke achtergrondkennis iemand heeft bij het uitleggen van iets.

Onder uitleggen en over uitleggen zijn beide slecht. De oplossing is om effectief en snel te communiceren wat je wel/niet weet.

In jouw voorbeeld voordat ze te diep in het uitleggen van JSON duikt, onderbreken (politely) zodat ze dat uit haar ‘lijst van uit te leggen dingen’ kan aanvinken.

Oh ik heb wat JSON is. Wat ik niet weet is hoe ik het kan deserialiseren naar een object in C#. Hoe doe je dat?

of in de discussie. Bijvoorbeeld als iemand voorstelde om JSON als formaat te gebruiken en u zich zorgen maakt. Je zou nog steeds onderbreken omdat je snel naar het relevante deel van het gesprek wilt gaan.

Ik ben bekend met JSON. Ik denk dat XML misschien een betere keuze is omdat onze upstream-diensten het al verwachten in XML.

Als je op de proef wordt gesteld omdat je iets niet doet. Dan volg je hetzelfde patroon.

Her: Je had X kunnen gebruiken. X is een -

You (onderbreken): Ja, ik ben bekend met X. Ik heb Y gebruikt omdat X dit nadeel heeft. Ik heb ook aan Z gedacht, maar heb er ook tegen besloten.

Her: Wat dacht je van A, dat is een -

You (onderbreken): Ah ja ik heb ook aan A gedacht. Maar het werkte niet vanwege REASONS.

Her: Als je A met Z combineert kun je REASONS.

You oplossen: Ja, dat zou kunnen werken. Daar zal ik naar kijken.

Ik prefixeer meestal met ‘Yea’ als een prettigere korte vorm van ‘Yes I’m aware of that’ en het haalt het randje eraf.

Zolang je in het algemeen een neutrale toon aanhoudt kom je er niet uit alsof je niet naar kritiek luistert.

Ook zul je het op een dag mis hebben. Zorg er gewoon voor dat je, wanneer je dat bent, net zo open en eerlijk bent.

Als je in het algemeen praat

Nu zijn we op het gebied van beleefde conversatie etiquette. Niet precies mijn forte maar hier is hoe ik het zou aanpakken.

In veel gevallen knik ik gewoon en wacht tot ze klaar zijn. Waarna ik iets zeg als ‘Ah ja, ik ben bekend met JSON. Ik heb gebruikt in X.’. En ga gewoon door met het gesprek.

Als ik ergens moet zijn, is er geen keus, ik moet onderbreken. Wat moeilijker is in een normaal gesprek. Maar eigenlijk zeg ik gewoon ‘Ja’ en knik terwijl ze praten. En zodra ze ook maar een beetje pauzeren zeg ik de regel uit de vorige paragraaf.

Caveat

zou ik al het bovenstaande willen voorbehouden: Soms is het toch goed om te luisteren, want je zou iets kunnen oppikken wat je niet wist. In feite vraag ik vaak vraag mensen om concepten uit te leggen alsof ik er niets van wist.

Disclaimer: Ik ben geen software ontwikkelaar

Ik raad je aan om niet aan te nemen dat ze opzettelijk neerbuigend is. Het kan heel goed zijn dat ze denkt dat je door je gebrek aan hoger onderwijs geen kennis hebt van basisprogrammeringsconcepten, maar dat je daar geen bewijs voor hebt, dus je kunt het beter niet denken. Ik leg vaak basisconcepten uit bij het plannen van vergaderingen omdat het me helpt om mijn hoofd om bepaalde problemen heen te draaien en ervoor zorgt dat iedereen mijn denkproces volgt, niet omdat ik denk dat de andere mensen in de kamer idioten zijn.

Naast @Link0352 en @JeffO ‘s uitstekende antwoorden, zou ik aanraden om het gesprek gewoon voorzichtig terug te sturen naar het niveau dat het nodig heeft voor een productieve discussie.

Zeker, we zouden de JSON kunnen manipuleren, maar dit zou kunnen leiden tot probleem X. In dit geval zou ik aanraden om het object direct te manipuleren (of wat dan ook).

(Ik neem aan dat deze interactie plaatsvond tijdens een technische vergadering en de medewerker niet zomaar naar je kubus zwierf en begon te rammelen over JSON. Als dat het geval is, is mijn antwoord niet echt van toepassing).

In aanvulling op andere antwoorden, mijn generieke oplossing voor mensen die je voor de hand liggende dingen uitleggen:

Als ze klaar zijn, draai de tabel. Begin met het uitleggen van meer diepgaande kennis over het recente onderwerp of leg een ander zeer voor de hand liggend onderwerp uit, bijv.

andere persoon : Json is een geweldige voor … en je kan … jou (lachend/vriendelijk): Precies! Wat ik ook leuk vind aan Json is dat je ….

kunt doen of als je een beetje gemeen wilt zijn

andere persoon : Json is een geweldige voor … en je kunt … je (lachend/vriendelijk): Precies! Heb je ooit gehoord van XML? Het is een [verklaring van iets heel vanzelfsprekends]

Van een andere vrouwelijke dev

ben ik een universitair opgeleide ontwikkelaar en heb ik al een tijdje gewerkt. Ik moet zeggen dat ik niets dan bewondering heb voor autodidactische ontwikkelaars. Eerlijk gezegd is er zoveel dat ik moeite heb gehad om te leren dat ik gewoon niet kan geloven dat jullie er zelf in geslaagd zijn om les te geven. En ik hou ervan om te discussiëren met degenen die autodidactisch zijn, omdat jullie meestal een heel ander soort vaardigheden hebben dan het universitaire publiek. Het is inspirerend en vrij badass tbh.

En wat betreft de dame die een JSON aan je begon uit te leggen, denk er niet te veel over na. We hebben dit veel met ons meegemaakt. Mannen die goedbedoeld zijn, maar uiteindelijk alledaagse dingen uitleggen omdat we meisjes zijn en we zo ongewoon zijn op dit gebied dat ze het gevoel hebben dat ze ons een beetje meer moeten helpen, ook al wordt het soms een beetje beledigend. Ik heb het geluk dat ik niets anders dan respect heb gekregen op mijn werk, maar ik heb wat horrorverhalen gehoord.

Ze bedoelde er waarschijnlijk niets slechts mee, maar het was waarschijnlijk gewoon haar eigen onzekerheden die een beetje doorschijnen en misschien voelde het alsof ze zichzelf moest bewijzen door je wat dingen te leren.

Ik adviseer geduld te hebben. Ik ben getuige geweest van gesprekken tussen mensen met de beste opleiding en decennialange ervaring in het bespreken van een programmeersituatie waarbij ze begonnen zijn vanaf het begin. Dat we een echte wereldentiteit in de software moeten vertegenwoordigen, dat er een datastructuur is gecreëerd om die representatie te zijn, dat deze gegevens over het netwerk naar een ander systeem moeten worden gestuurd, etc.

Wat ik uit hun aanpak afleidde was dat door een paar minuten de tijd te nemen om zoveel mogelijk aannames expliciet te maken en een gezamenlijke keten van redeneringen op te zetten, een solide basis werd gelegd voor het samenwerken.

Het kan zijn dat deze verklaringen een teken zijn van gebrek aan respect of wrok (of een poging om haar kennis aan u te bewijzen), maar het kan worden omgezet in een kans om op dezelfde pagina te komen en perspectieven te delen om de werkrelatie beter te maken.

Als het ooit uit de hand loopt of als je echt de behoefte voelt om iets te zeggen, stel ik voor om een vraag te stellen die de grens van je begrip aangeeft.

“JSON is een formaat om gegevensstructuren als tekst weer te geven.”

“Oh, JSON, ik was net aan het lezen over de verschillende implementaties, weet je of er een referentievoorbeeld is van een parser gebouwd met lex en yacc voor JSON?”

Open je geest.

University leert vaardigheden die je niet in boeken vindt (afgezien van universitaire leerboeken) en die je waarschijnlijk mist als je autodidactisch bent. Hoe ik dat weet? Ik heb gestudeerd, maar sommige delen van het vakgebied maakten geen deel uit van mijn curicculum en ik ben autodidact in die vakgebieden. Dus ik ken beide kanten.

Ze heeft je waarschijnlijk iets te leren, maar jullie beseffen allebei niet wat dat is. Ze denkt dat ze basisbegrippen moet uitleggen. Dit kan zijn omdat ze neerbuigend is, sociaal onhandig, arrogant, een minderwaardigheidscomplex heeft of waar je ook in wilt geloven - of het kan zijn omdat ze je oprecht wil steunen.

In dubio pro reo, dus tot het tegendeel is bewezen, neem het beste aan en verwelkom haar discussies met een open geest. Echter, als je je realiseert dat je al weet wat ze probeert uit te leggen, bedank haar dan en leg uit dat je dit al begrijpt. Vraag haar wat ze nog meer te bieden heeft, je staat te popelen om voortdurend te leren en te verbeteren. Dat is het voordeel van autodidactisch zijn: Je begrijpt dat leren een constant proces is dat niet eindigt met het examen of de masterscriptie.

Gebruik dat voordeel. Leer van haar, dat kan alleen maar in je voordeel zijn.

En op een dag zal er iets zijn dat je weet en zij niet. Leer haar op een vriendelijke, niet aflatende manier en jullie twee kunnen een briljante, wederzijds ondersteunende werkrelatie aangaan.

Ik heb dit in de loop der jaren vele malen als consultant gezien. Het antwoord is eenvoudig. Dit is een copingmechanisme.

Het is een van de twee complexen en kan een combinatie zijn van beide.

• Inferiority Complex

• Superiority Complex

Beide zijn een verdedigingsmechanisme.

Als je het enige doelwit bent van dergelijk gedrag, dan wordt het onderwerp waarschijnlijk bedreigd door je vaardigheden of vermogen.

Als je een van de verschillende doelwitten van dergelijk gedrag bent, dan is het een algemeen gevoel van minderwaardigheid binnen de dader.

Over het algemeen zie je compensatie gemengd met grandioosheid van een of andere vorm. Het zou zo simpel kunnen zijn als te trots zijn op hun graad. Niemand is immuun om een doelwit te zijn. Ik heb bijvoorbeeld gezien dat mensen met een lagere graad mensen met een hogere graad aanvallen, zoals ingenieurs. Het is een nivellerend mechanisme dat probeert zijn eigenwaarde te verhogen door een ander kaliber te verminderen. We zien dit gedrag op de p! ay grond als kinderen.

Hoewel je misschien niet iemand wilt aanvallen voor zo'n belediging, kan dit gedrag een gevaar zijn voor jou en anderen, vooral in de beroepsbevolking.

Waarschijnlijk is er weinig wat je kunt doen om dit te bestrijden zonder jezelf er slecht uit te laten zien. De reden hiervoor is dat de transactie niet alleen bedoeld is om de superioriteit aan te geven, maar ook om een reactie te vragen die de superioriteit afdwingt.

In dit geval lijkt het erop dat de dader de rol van de ouder heeft overgenomen. Alleen een antwoord van een volwassene is voldoende. Een Ouder of Kind antwoord betekent dat je verliest. Dit kan worden gezien door het lezen van [ I’m OK, You’re OK (https://en.m.wikipedia.org/wiki/I%27m_OK_%E2%80%93_You%27re_OK) en Games People Play . Beide zijn gebaseerd op transactieanalyse. Het zou helpen om het eerste boek te lezen. Het is relatief eenvoudig te begrijpen en leert je de drie staten te herkennen en hoe je moet reageren.

Simpel gezegd is dit gamesmenship.

Ik ben terughoudend om suggesties te doen over hoe je dit specifiek verbaal kunt bestrijden, omdat het advies mogelijk schadelijk kan zijn. Dit moet op dit moment worden bestreden.

Ter referentie, Transactionele Analyse is geen poppsychologie. Het is een echt instrument dat begrepen moet worden. Ik heb TA gebruikt in mijn adviescarrière en was zeer belangrijk in mijn succes als IT-consultant. Het stelde me in staat om mezelf te laten gelden als de volwassene in de kamer, mijn punten te maken, en hopelijk een effectieve case te maken voor mijn oplossingen.

Ik werd vaak ingeschakeld om een probleem op te lossen of een systeem te vervangen waarvoor iemand verantwoordelijk was. Vaak werd de macht ontnomen aan het individu dat nu defensief was. Dit soort gevechten gaat vaak over macht, ofwel het verlies van of het verwerven van macht. Het doel is om de dreiging te minimaliseren door het verlies te minimaliseren. Bij een wereldwijd opererend bedrijf was Microsoft Mail bijvoorbeeld aan het verouderen en moest het worden vervangen. De verantwoordelijke medewerker hield de regeerperiodes strak in de hand en beheerde alle servers die zich op één locatie moesten bevinden. Voor een wereldwijde Telecom was dit een ramp. Mensen in Japan zouden verbinding moeten maken met servers in Virginia om e-mail te kunnen lezen. De last was enorm en e-mail zou niet binnen 24 uur worden afgeleverd. De werknemer was bang voor technologie die hij niet begreep of kende en maakte zich zorgen over zijn werk met een gedistribueerd wereldwijd systeem. De oplossing was om de werknemer door middel van training, testinstallaties, het ondersteunen van systemen op afstand te laten lopen en hem te laten inzien dat hij nog steeds een centrale rol speelde binnen de organisatie. Hij verloor geen macht, maar won aan macht. Dit alles door middel van TA.

Oké. Goed en wel. Het korte antwoord dat ik heb is om de drie transactionele types te begrijpen en te leren hoe je een volwassen houding kunt presenteren en hoe je het echte doel van de transactie die je wordt gepresenteerd kunt herkennen. Je kunt het probleem snel en gemakkelijk kortsluiten zonder dat iemand het ooit beseft en jezelf op een stille maar effectieve manier als leider positioneren. Het algehele effect zal zichtbaar zijn.

De meeste van de antwoorden hier bespreken confrontatie of medeleven met uw ervaring. Ik geloof niet dat de confrontatie je tijd of die andere ontwikkelaars tijd waard is.

In plaats daarvan raad ik een beetje social engineering aan die vaak werd beoefend door Benjamin Franklin aka de Benjamin Franklin Effect :

Vraag om hulp, om advies, om suggesties. Vragen om een gunst is een teken van intimiteit en vertrouwen.

Dit lijkt misschien een tegengesteld initiatief, maar als je een paar puntige vragen stelt over lastige onderwerpen zal het er subliminaal toe leiden dat iemand erkent dat je het fundamentele onderwerp begrijpt en je dus meer vertrouwen geeft. Het zal hen ook meer vertrouwen geven omdat je naar hen toe kwam voor dit “moeilijke” onderwerp.

Dit is een snelle niet-confronterende oplossing die in de meeste gevallen zal werken.

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.

Praat er met haar over.

Uw interpretatie van haar gedrag is dat het is omdat ze aan u denkt als onervaren. Veel van de andere antwoorden hebben suggesties gegeven voor alternatieve interpretaties van haar gedrag, en sommige geven suggesties om het gedrag af te sluiten, wat, zonder te weten waarom ze het doet, de relatie onnodig extra kan belasten.

De enige manier om te weten waarom ze het doet is om er met haar over te praten. Idealiter zou je haar gewoon direct kunnen vragen, haar laten weten waarom je het vraagt, en haar verzekeren dat als je iets niet begrijpt, je het wel zult vragen.

Je kent haar beter dan ieder van ons dus je zou een beter idee moeten hebben hoe ze zou reageren, maar denk er eens over na om met zoiets als dit te beginnen:

Hé Sue, ik weet dat we nog niet zo lang samenwerken en dat we nog steeds leren wat we van elkaar kunnen verwachten. Ik heb gemerkt dat als we praten shop je vaak valt in vrij fundamentele verklaringen van wat ik beschouw als standaard onderwerpen. Waarom is dat? Ik hoop dat het is omdat X of Y (geef een of twee van de meer genereuze interpretaties van de anderen), maar het voelt vaak alsof ik je de indruk heb gegeven dat ik deze dingen uitgelegd moet worden. Als dat het geval is, lijkt het erop dat we kostbare tijd verspillen die meer productief gebruikt zou kunnen worden bij het bespreken van de benodigde functies. Als je niet zeker bent van mijn ervaring met een onderwerp, kun je vragen wat ik ervan weet, en als de discussie iets raakt dat buiten mijn ervaring valt, vertrouw je erop dat ik het zal vragen.

Ik zou haar in eerste instantie niet onderbreken terwijl ze in een van haar verklaringen zit om deze discussie te voeren, omdat het waarschijnlijker lijkt dat het overkomt als reactionair of defensief. Beter is het om haar apart te benaderen.

Verdergaan vanaf daar, afhankelijk van wat er van de eerste discussie komt, wanneer en als het weer gebeurt, zou je kunnen interrumperen dat dit een van die basisverklaringen is, of beginnen met het toepassen van een aantal van de suggesties van de anderen over hoe in-line te reageren.

** Terzijde:**

In een project van vorig jaar moest ik uitleggen wat JSON was voor een paar teamleden. Ze hebben allebei minstens een decennium (of twee) ervaring in de industrie met mij, en op verschillende momenten in hun carrière hebben ze allebei aan webprojecten gewerkt. Ze werkten gewoon nooit met een raamwerk of hadden technieken nodig waar het bijzonder relevant was.

In hetzelfde project hadden we een aantal van de zakenmensen waar we mee werkten door elkaar heen dezelfde twee of drie termen gebruikt die verwijzen naar twee nauw verwante, maar (zo blijkt) verschillende onderwerpen. Welk onderwerp een bepaalde term betekende, hing af van welk van hen het gebruikte en in welke context. Het kostte ons eigenlijk een paar iteraties om het te begrijpen. Tot op dat moment was het nooit duidelijk dat er zelfs verschillende onderwerpen waren. Ze namen aan dat we het wisten, en we namen aan dat ze allemaal naar hetzelfde verwezen.

Meer recentelijk, in een discussie over een verkeerd geconfigureerde applicatie, liet ik een teamlid een half uur lang op een raakvlak afgaan met voorstellen voor foutieve wijzigingen in ons configuratieraamwerk om te voorkomen dat de verkeerde default-omgeving werd geselecteerd, terwijl het probleem was dat de applicatie de verkeerde default-waarde had voor een individuele instelling. (Het framework staat standaard fallback waarden toe in het geval dat deze niet worden overschreven voor de huidige omgeving, de applicatie had wat een standaard productiewaarde moet zijn, dus wanneer een testomgeving deze niet overschrijft…)

Wat heeft het voor zin? Bijna elk vakgebied is zo breed dat het voor elke persoon, ongeacht het ervaringsniveau, onmogelijk is om alles te weten te komen. Iedereen zal verschillende gaten hebben in zijn kennis en ervaring, en er kunnen subculturen en specialisaties zijn met botsende lingo. Je kunt niet zomaar aannames doen over wat andere mensen weten, of bedoelen, of waarom ze bepaalde beslissingen nemen.

Het is mijn ervaring geweest, onuitgesproken aannames kunnen (en zullen uiteindelijk) erg duur zijn. Een paar minuten om er zeker van te zijn dat iedereen op dezelfde bladzijde zit voordat je een discussie begint zal op de lange termijn veel besparen.

In dit geval is je veronderstelling dat ze dit doet omdat je zelf geleerd hebt, en/of (als je veronderstelling juist is) haar veronderstelling dat je de instructie nodig hebt schadelijk is voor je werkrelatie.

Ontwikkelaar met of zonder diploma moet evenzeer gerespecteerd worden op de werkvloer.

Ik heb alle bovenstaande antwoorden gelezen en de meeste wijzen erop dat ze aardig is en dat je er over nadenkt.

Maar uit je vraag blijkt het niet zo te zijn. Je leek je beledigd te voelen door haar gedrag.

Naar mijn mening is het is de tijd, dat je je vaardigheden moet laten zien. Het is misschien haar perceptie dat de graad een Software Developer maakt, maar in mijn ervaring is het werken aan real time projecten en het oplossen van kritische scenario’s wat een ‘Software Developer’ maakt. Niet opscheppen, maar proactief deelnemen aan de technische discussies.

Voor het showen zonder op te scheppen, begin je met het helpen van je medematen, junioren etc. Je werk, je vaardigheden en al het andere spreken voor zich.

Dit is een beetje lastiger dan sommige van de antwoorden. Je moet niet zomaar naar buiten komen en zeggen dat je geen hulp nodig hebt (arrogantie), noch moet je stilletjes blijven luisteren (het is vervelend!).

Mijn advies is om… haar te verblinden met jouw kennis. Als je iets begrijpt wat je wordt uitgelegd in de softwareontwikkelingsindustrie, laat de persoon die het uitlegt dan zien dat je het begrijpt, door het te bespreken, en dan geleidelijk aan je geavanceerde kennis van het onderwerp te introduceren om te laten zien dat je het begrijpt. Wanneer iemand gewoon luistert, zijn veel mensen, en vooral ingenieurs, geneigd te denken dat de luisteraar niet in staat is om de discussie aan te gaan omdat ze het niet begrijpen.

Case en punt, wanneer iemand je iets uitlegt dat voor de hand ligt in de industrie, zwijg dan, de kans is groot dat ze het weer op een iets andere manier uitleggen… meerdere keren met incrementele frustratie. Reageer, laat zien dat je het weet, en ze hebben de neiging je met rust te laten, of iets beters te vinden om te bespreken.

Om het technische gezeur volledig te stoppen, laat zien dat je MEER kent dan de persoon die je probeert te leren en ze zullen snel leren om je niet de les te lezen en als er iets naar je toe komt met vragen.

Als ze nu JSON aan je uitleggen omdat je een kritische fout hebt gemaakt, of net een gemist architectonisch concept hebt gedemonstreerd, dan is dat waar je je mond houdt en luistert.

Gewoon mijn twee centen op wat in het verleden voor mij heeft gewerkt, iedereen is echter een beetje anders.

Waarschuwing: Dit werkt alleen bij sommige mensen in sommige situaties; YMMV. Dit antwoord heeft geen garantie.

• *

Wat ik in dit geval zou doen is ze onderbreken met een onderwerp samenvatting. Bijvoorbeeld, met JSON:

Them: JSON is JavaScript Object Notation, wat een manier is om - Me: Woordenboek-achtige objecten en, erm, arrays en primitieven en, JavaScript primitieven bedoel ik, in een geserialiseerd formaat weer te geven.

Dit verklaart de volgende situatie:

Them: JSON is JavaScript Object Notatie, wat een manier is om - Me: Elk object in JavaScript voor te stellen als een string. Them: Nee, omdat het geen functies kan opslaan, of objecten die verborgen eigenschappen hebben; het is een zeer eenvoudige representatie van…

Onderbreken met “ja, ik weet het” zou in dit geval later tot problemen leiden als ik niet echt bleek te weten wat JSON was, dus veroorzaakte problemen in de code met mijn aannames.

Je collega probeert waarschijnlijk alleen maar te zorgen dat je alles weet wat je moet weten. Als je “zelflerend” bent dan betekent dat dat je gaten kunt hebben die de meeste mensen zouden veronderstellen dat je hebt opgevuld omdat je de “moeilijkere dingen” kent (hoewel de meeste onderwijsinstellingen zulke dingen ook in een echt vreemde volgorde leren!) en dat soort veronderstelling kan leiden tot subtiele, moeilijk te vinden problemen door valse aannames.

• *

*: zie de bovenkant van het antwoord.

U heeft de industrie niet genoemd, dat zal een groot verschil maken.

Ik werk in een groot high tech bedrijf en huur vaak jonge ontwikkelaars in (0-2 jaar ervaring). De school waar ze naartoe gingen en hun diploma maakt voor mij niet het minste verschil.

Ik heb onlangs twee kandidaten van de beste school van het land afgewezen om er een aan te nemen van een school waarvan ik de naam niet eens meer weet. Het verschil tussen hen was dat de eerste twee goed waren en de derde briljant was, ook omdat hij autodidact was. Het was duidelijk dat hij het na 5 minuten geweldig zou doen.

Wat betekent dit in de context van uw vraag? Waarschijnlijk dat je misschien beter geschikt bent in een industrie die meer belang hecht aan kennis dan aan de school.

Afhankelijk van het land kan dit meer of minder moeilijk zijn als verschillende landen kijken naar hun scholen met verschillende niveaus van respect (Frankrijk is het uiterste waar je bijna ondergoed draagt dat met je school is versierd, als je van de juiste soort bent – dit is niet slecht, afhankelijk van het soort werk).

Ik denk dat je zou kunnen zeggen - ik weet al een beetje (nadruk op een beetje) over JSON. Dus, kunnen we JSON voorlopig overslaan ? Maar, als er iets is wat ik niet weet over JSON, kan ik je dan later om hulp vragen ?

Laten we gewoon zeggen tegen je voorbeeld dat je niet JSON manipuleert. U neemt JSON, converteert het naar een modelobject, manipuleert het modelobject en converteert het terug naar JSON. Ik durf te wedden dat als je collega JSON rechtstreeks probeert te manipuleren, er bugs zullen zijn omdat JSON eenvoudig is, maar niet die eenvoudig.

Als hij nu zo slim is, print dan een kopie van dit papier https://www.ics.uci.edu/~dan/pubs/LenLimHuff.pdf dat gaat over het berekenen van optimale Huffman-codes met beperkte codelengtes (Huffman-codes met onbeperkte codelengtes zijn eenvoudig) en vraag hem om dat algoritme aan jou uit te leggen. Waarschijnlijk zal hij dat niet kunnen, in het ergste geval sluit je hem een tijdje op. (Lengtebeperkte Huffman-codes zijn belangrijk, omdat ze veel efficiëntere decoders mogelijk maken). PS. Als hij of zij kan het algoritme aan u uitleggen, dan is hij of zij is goed. Ik betwijfel het.

Afgezien daarvan, als iemand probeert JSON aan u uit te leggen, vraagt u hen dan wat ze daar proberen te bereiken? Denkt hij dat JSON iets moeilijks is dat je niet kunt begrijpen zonder een CS diploma? Serieus? Denkt hij niet dat hij een beetje vol van zichzelf is? Zijn gedrag is beledigend, dus je geeft zo goed als hij verdient terug.

Autodidactische ontwikkelaars zullen vaak experts zijn in technologieën waar ze praktische ervaring mee hebben, maar soms is het probleem dat ze niet weten hoeveel ze niet weten. Ik ben bijvoorbeeld vaak geconfronteerd met autodidactische ontwikkelaars die een nieuw algoritme uitvinden om een probleem op te lossen als er een bekend standaardalgoritme is, dat vaak veel beter is.

Probeer te onthouden dat als je een loodgieter of een elektricien was, laat staan een dokter of een advocaat, je niet zou mogen oefenen zonder formele kwalificaties. Programmeren is in feite vrij uniek in het toestaan van degenen die volledig autodidactisch zijn, om in het vak te werken. En veel van degenen die dat doen, doen uitstekend werk. Maar probeer te erkennen dat degenen die een CS-diploma hebben behaald, dingen hebben geleerd die jij niet hebt geleerd, en sta ervoor open om van hen te leren.

Overigens zal een CS-diploma je niet veel leren over JSON. Het zal je echter wel leren tot welke klasse van de grammatica JSON behoort, en dus welke klasse van parser je nodig hebt om het te verwerken: het zal je leren om de fout te vermijden dat je JSON probeert te parseren met reguliere uitdrukkingen, want de theorie zegt je dat dat niet kan. U hoeft StackOverflow maar een paar weken te volgen om te zien hoeveel programmeurs zich niet bewust zijn van dergelijke grondbeginselen.