FYI, większość uniwersytetów nie uczy o takich rzeczach jak JSON. Uczą rzeczy takich jak deep-first tree traversal, które teoretycznie można by zastosować w tworzeniu własnej biblioteki JSON, ale cokolwiek bardziej praktycznego niż to wszystko wszyscy są samoukami lub uczyli się w pracy.

Spróbuj się nie bronić. Wyjaśnianie praktycznych technologii takich jak JSON jest czymś, co od czasu do czasu musimy zrobić nawet dla absolwentów uniwersytetu. Ktoś z lepszymi umiejętnościami społecznymi zapytałby, czy najpierw się z tym zapoznasz. Jeśli nie zapytają, możesz po prostu przerwać i powiedzieć.

Nie ma powodu, dla którego nie możesz wskazać, że Twój kolega udziela zbędnych informacji podczas dyskusji technicznych.

Hej Współpracowniku, pozwól pominąć trywialne szczegóły i dotrzeć do sedna sprawy. Nie jest to zbyt efektywne wykorzystanie naszego czasu.

Może po prostu ma tendencję do przesadnego wyjaśniania rzeczy lub odchodzenia od tematu, ale dobrą umiejętnością do rozwijania w każdej chwili interakcji z innymi programistami jest grzeczne, ale stanowcze utrzymywanie interakcji zwięzłych i na temat, tak aby każdy mógł efektywnie spędzić czas.

Szczerze mówiąc, mam całkiem niezłe referencje i miałem byłego przełożonego, który robił to ze mną cały czas. Wziąłem udział w zajęciach z CS na temat projektowania baz danych, zbudowałem wszystkie rodzaje aplikacji bazodanowych i pracowałem profesjonalnie przez lata, a on wciąż miał czelność wyjaśniać mi (przed wszystkimi) zasady projektowania baz danych dla początkujących.

Ale nie jestem pewien, czy robił to celowo. Prawda jest taka, że potrzeba dużo energii umysłowej, aby postawić się w czyjejś sytuacji i mówić do ich poziomu. Widzisz to cały czas: eksperci czasami będą rzucać w ciebie bezsensownym żargonem, albo inni będą z tobą rozmawiać. Ale niekoniecznie mają to na myśli - po prostu nie poświęcają wystarczająco dużo energii, aby dowiedzieć się, jak dobrze się komunikować.

Z mojego doświadczenia wynika, że to była najtrudniejsza rzecz w nauczaniu CS. Musiałam nie tylko dogłębnie zrozumieć materiał, ale także wykorzystać kilka cykli mózgowych, próbując dostać się do wnętrza głowy moich uczniów i dowiedzieć się, co myślą. Ale nie każdy praktykuje to w swobodnych rozmowach.

Więc nie bądźcie zbyt szybcy, by zaklasyfikować to jako złośliwość. To może być po prostu ich własne społeczne niezręczności. Powiedziałbym ci, jak nie brać tego do siebie, ale nadal sam nad tym pracuję. Ja też nie mogę tego znieść…

Jest to podobne do innych odpowiedzi, ale z kilkoma konkretnymi przykładami.

Jeżeli prosisz o pomoc / wy dwoje dyskutujecie o zadaniu, które masz pod ręką

Gdy jestem na drugim końcu. Naprawdę trudno jest wiedzieć, jaką wiedzę posiada ktoś w tle, kiedy coś wyjaśnia.

Pod wyjaśnieniami i nad wyjaśnieniami są zarówno złe. Rozwiązaniem jest zakomunikowanie tego, co robisz/nie wiesz skutecznie i szybko.

W twoim przykładzie zanim zanurkuje zbyt głęboko w wyjaśnianie JSON'a, przerwij (politycznie), żeby mogła to zaznaczyć na swojej “liście rzeczy do wyjaśnienia”.

Oh, mam to, czym jest JSON. To czego nie wiem, to jak zdeserializować go do obiektu w C#. Jak to zrobić?

Albo w dyskusji. Na przykład, jeśli ktoś zaproponował użycie JSON'a jako formatu, a ty masz obawy. Wciąż byś przerywał, bo chcesz szybko dostać się do odpowiedniej części rozmowy.

Znam JSONa. Myślę, że XML może być lepszym wyborem, ponieważ nasze usługi wyższego szczebla już teraz oczekują go w XML.

Jeśli jesteś brany do zadań za to, że czegoś nie robisz. Wtedy podążasz tym samym wzorcem.

Her: Mogłeś użyć X. X to -

You (interrupting): Tak, znam X. Użyłem Y, bo X ma tę wadę. Rozważałem również Z, ale zdecydowałem się również przeciwko niemu.

Ona: Co z A, które jest a -

You (przerywając): Ah tak, ja też rozważałem A. Ale to nie zadziałało z powodu UZASADNIENIA.

Ona: Jeśli połączysz A z Z, możesz rozwiązać UZASADNIENIE.

Ty: Yea that could work. Przyjrzę się temu.

Zwykle przedrostek “Yea” jest bardziej przyjemną krótką formą “Yes I’m aware of that”, która zdejmuje z ciebie przewagę.

Tak długo, jak w ogóle zachowujesz neutralny ton, nie wyjdziesz z tego, że nie słuchasz krytyki.

Również pewnego dnia będziesz się mylić. Upewnij się tylko, że kiedy jesteś, jesteś podobnie otwarty i szczery.

Jeśli rozmawiasz ogólnie

Teraz jesteśmy w obszarze grzecznej etykiety rozmowy. Nie do końca moja mocna strona, ale oto jak bym sobie z tym poradził.

W wielu przypadkach po prostu kiwam głową i czekam aż skończą. Po czym powiem coś w stylu “Ach tak, znam JSON'a”. Użyłem w X. I po prostu kontynuuj rozmowę.

Jeśli mam gdzieś być, nie ma wyboru, muszę przerwać. Co jest trudniejsze w zwykłej rozmowie. Ale w zasadzie po prostu mówię “tak” i kiwam głową, kiedy oni rozmawiają. I jak tylko się zatrzymają, nawet trochę, mówię linię z poprzedniego akapitu.

Caveat

Zastrzegam to wszystko: Czasami i tak dobrze jest słuchać, bo możesz odebrać coś, czego nie wiedziałeś. Tak naprawdę często każę ludziom tłumaczyć pojęcia tak, jakbym nic o nich nie wiedział.

Disclaimer: Nie jestem programistą

Zalecałbym, abyś nie zakładał, że jest ona celowo protekcjonalna. Może być tak, że ona uważa, iż twój brak wyższego wykształcenia oznacza, że nie masz wiedzy o podstawowych koncepcjach programowania, ale nie masz na to dowodów, więc lepiej, żebyś nie myślał o tym. Często wyjaśniam podstawowe koncepcje podczas spotkań planistycznych, ponieważ pomaga mi to owinąć sobie głowę wokół pewnych problemów i zapewnia, że wszyscy śledzą mój proces myślowy, a nie dlatego, że myślę, że inni ludzie na sali są idiotami.

Oprócz @Link0352 i @JeffO’s doskonałych odpowiedzi, tam gdzie to możliwe, polecam tylko delikatnie poprowadzić rozmowę z powrotem do poziomu, na którym powinna być produktywna dyskusja.

Pewnie, moglibyśmy manipulować JSON'em, ale to może prowadzić do problemu X. W tym przypadku polecam manipulowanie obiektem bezpośrednio (lub cokolwiek innego).

(Zakładam, że ta interakcja miała miejsce podczas spotkania technicznego i współpracownik nie tylko podszedł do Twojej kostki i zaczął grzechotać o JSON'ie. Jeśli tak jest, to moja odpowiedź tak naprawdę nie ma zastosowania).

Oprócz innych odpowiedzi, moje ogólne rozwiązanie dla osób wyjaśniających ci oczywiste rzeczy:

Kiedy skończą, wróć tabelę. Zacznij wyjaśniać bardziej dogłębną wiedzę na temat ostatniego tematu lub wyjaśnij inną bardzo oczywistą rzecz, np.

inna osoba : Json jest świetny dla … i możesz zrobić … you (uśmiechnięty/przyjazny): Dokładnie! To co również lubię w Jsonie to to, że możesz ….

lub jeśli chcesz być trochę wredny

inna osoba : Json jest świetny dla … i możesz zrobić … you (uśmiechnięty/przyjazny): Dokładnie! Czy kiedykolwiek słyszałeś o XML? To jest [wyjaśnienie czegoś bardzo oczywistego]

From another female dev

I’m a university educated developer and have worked for a while now. Muszę powiedzieć, że nie mam nic poza podziwem dla samouczących się deweloperów. Szczerze mówiąc, jest tak wiele rzeczy, których się nauczyłam, że po prostu nie mogę uwierzyć, że udało wam się nauczyć samych siebie. A ja uwielbiam dyskutować z tymi, którzy są samoukami, ponieważ zazwyczaj macie zupełnie inny rodzaj umiejętności, niż tłum ludzi z uni. Jest to inspirujące i dość kiepskie tbh.

A co do pani, która zaczęła tłumaczyć ci JSONa, nie zastanawiaj się nad tym zbytnio. Wiele nam się to przytrafiło. Mężczyźni, którzy mają dobre intencje, ale kończą wyjaśniając prozaiczne rzeczy, ponieważ jesteśmy dziewczynami i jesteśmy tak rzadko spotykani w tej dziedzinie, że czują, że muszą nam pomóc trochę bardziej, nawet jeśli czasami staje się to trochę obraźliwe. Mam szczęście, że w moim miejscu pracy spotkałyśmy się tylko z szacunkiem, ale słyszałam już kilka horrorów.

Prawdopodobnie nie miała nic złego na myśli, ale najprawdopodobniej była to tylko jej własna niepewność, która przebiła się trochę i może poczuła, że musi się wykazać, ucząc cię jakichś rzeczy.

Radziłbym cierpliwość. Byłem świadkiem rozmów ludzi z najlepszym wykształceniem i wieloletnim doświadczeniem w omawianiu sytuacji programowej, w której zaczęli od absolutnego kwadratu 1. Że musimy reprezentować w oprogramowaniu rzeczywisty byt, że struktura danych została stworzona, aby być tą reprezentacją, że dane te muszą być przesłane przez sieć do innego systemu, itd.

Z ich podejścia wywnioskowałem, że poprzez poświęcenie kilku minut na sformułowanie jak największej ilości założeń i ustanowienie wspólnego łańcucha rozumowania, stworzono solidne podstawy do wspólnej pracy.

Może i nie jest tak, że te wyjaśnienia są oznaką braku szacunku lub urazy (albo próbą udowodnienia Ci swojej wiedzy), ale mogą zostać przekształcone w okazję do wejścia na tę samą stronę i podzielenia się perspektywami, aby uczynić związek zawodowy lepszym.

Jeśli kiedykolwiek wymknie się to spod kontroli lub naprawdę poczujesz potrzebę powiedzenia czegoś, proponuję zadać pytanie, które pokazuje granice Twojego zrozumienia.

“JSON jest formatem do reprezentowania struktur danych jako tekstu.”

“Oh, JSON, właśnie czytałem o różnych implementacjach, czy wiesz, czy istnieje przykład referencyjny parsera zbudowanego z lex i yacc dla JSON?”

Otwórz swój umysł.

Uniwersytet uczy umiejętności, których nie znajdziesz w książkach (poza podręcznikami uniwersyteckimi) i których prawdopodobnie Ci brakuje, jeśli jesteś samoukiem. Skąd mam wiedzieć? Studiowałem, ale niektóre części tej dziedziny nie były częścią mojego programu nauczania i jestem samoukiem w tych dziedzinach. Więc znam obie strony.

Pewnie ma cię czegoś do nauczenia, ale oboje nie zdajecie sobie sprawy, co to jest. Ona myśli, że musi wyjaśnić podstawowe pojęcia. Może to być albo dlatego, że jest protekcjonalna, niezręczna społecznie, arogancka, ma kompleks niższości albo cokolwiek innego, w co chcesz wierzyć - albo dlatego, że naprawdę chce cię wspierać.

In dubio pro reo, więc dopóki nie udowodni się, że jest inaczej, zakładajcie najlepsze i witajcie jej dyskusje z otwartym umysłem. Kiedy jednak zdasz sobie sprawę, że wiesz już, co ona stara się wyjaśnić, podziękuj jej i wyjaśnij, że już to rozumiesz. Zapytaj ją, co jeszcze ma do zaoferowania, jesteś chętny do ciągłego uczenia się i doskonalenia. To jest zaleta bycia samoukiem: Rozumiesz, że uczenie się jest ciągłym procesem, który nie kończy się egzaminem lub pracą magisterską.

Wykorzystaj tę przewagę. Ucz się od niej, to może być tylko Twoja korzyść.

I pewnego dnia, będzie coś, co wiesz, a ona nie. Nauczcie ją w przyjazny, nieskrępowany sposób, a wy dwoje będziecie mogli nawiązać wspaniałą, wzajemnie się wspierającą relację w pracy.

Widziałem to wiele razy jako konsultant przez lata. Odpowiedź jest prosta. Jest to mechanizm obronny.

Jest to jeden z dwóch kompleksów i może być kombinacją obu.

• Kompleks nadrzędności

• Kompleks nadrzędności

Oba są mechanizmem obronnym.

Jeśli jesteś jedynym celem takiego zachowania, wtedy podmiot jest prawdopodobnie zagrożony twoimi umiejętnościami lub umiejętnościami.

Jeśli jesteś jednym z kilku celów takiego zachowania, wtedy jest to ogólne poczucie niższości u przestępcy.

Ogólnie rzecz biorąc, zobaczysz odszkodowanie zmieszane z wielkością jakiejś formy. To może być tak proste, jak bycie zbyt dumnym z ich stopnia. Nikt nie jest odporny na bycie celem. Na przykład, widziałem ludzi z niższym stopniem naukowym, którzy atakowali tych z wyższym stopniem naukowym, takich jak inżynierowie. Jest to mechanizm wyrównujący, który próbuje podnieść swoją samoocenę poprzez obniżenie innej rangi. Widzimy to zachowanie na p!ay gruncie jako dzieci.

Chociaż możesz nie chcieć kogoś zaatakować za taką obrazę, to zachowanie to może być niebezpieczne dla Ciebie i innych, szczególnie w pracy.

Prawdopodobnie niewiele możesz zrobić, aby z tym walczyć bez robienia z siebie źle. Powodem jest to, że transakcja ma na celu nie tylko wskazanie wyższości, ale również uzyskanie odpowiedzi, która wymusi tę wyższość.

W tym przypadku wydaje się, że sprawca przejął rolę rodzica. Tylko reakcja osoby dorosłej może to zrobić. Odpowiedź rodzica lub dziecka oznacza, że przegrałeś. Można to zobaczyć czytając I’m OK, You’re OK i Games People Play . Oba są oparte na Analizie Transakcyjnej. To by pomogło w przeczytaniu pierwszej książki. Jest ona stosunkowo prosta do zrozumienia i uczy rozpoznawania trzech stanów i reagowania na nie.

Mówiąc prosto, to jest przykładowa gra.

Niechętnie oferuję sugestie jak konkretnie walczyć z tym werbalnie, ponieważ rady mogą być potencjalnie szkodliwe. Trzeba z tym walczyć w tej chwili.

Dla przypomnienia, Analiza Transakcyjna nie jest psychologią pop. Jest to prawdziwe narzędzie, które powinno być zrozumiałe. Korzystałem z TA w mojej karierze konsultingowej i miałem duże znaczenie dla mojego sukcesu jako konsultant IT. Pozwoliło mi to ugruntować swoją pozycję jako osoby dorosłej w pokoju, przedstawić swoje uwagi i, miejmy nadzieję, skutecznie uzasadnić swoje rozwiązania.

Często wzywano mnie do naprawienia problemu lub zastąpienia systemu, za który ktoś był odpowiedzialny. Często zabierano mi władzę od osoby, która była teraz defensywna. Bitwy takie jak te często dotyczą władzy, albo jej utraty, albo odebrania. Celem jest zminimalizowanie zagrożenia poprzez zminimalizowanie strat. Na przykład, w globalnej firmie Microsoft Mail starzeje się i musiał zostać zastąpiony. Odpowiedzialny pracownik ściśle trzymał panowanie i zarządzał wszystkimi serwerami wymagającymi, aby znajdowały się one w jednym miejscu. Dla globalnej firmy telekomunikacyjnej była to katastrofa. Ludzie w Japonii musieliby łączyć się z serwerami w Wirginii, aby odczytywać pocztę. Obciążenie było ogromne i poczta elektroniczna nie została dostarczona w ciągu 24 godzin. Pracownik obawiał się technologii, której nie rozumiał ani nie znał i martwił się o swoją pracę w rozproszonym systemie globalnym. Rozwiązaniem było przeprowadzenie pracownika przez szkolenia, instalacje testowe, wsparcie systemów zdalnych i uświadomienie mu, że nadal odgrywa kluczową rolę w organizacji. Nie tracił władzy, ale ją zyskiwał. Wszystko to przez TA.

Okay. Dobrze i dobrze. Krótka odpowiedź, którą mam, to zrozumienie trzech typów transakcji i nauczenie się, jak przedstawić postawę dorosłego człowieka i jak rozpoznać prawdziwy cel transakcji, którą się przedstawia. Możesz szybko i łatwo zwinąć problem, nie zdając sobie z tego sprawy i w sposób cichy, ale skuteczny zająć pozycję lidera. Ogólny efekt będzie widoczny.

Większość odpowiedzi na te pytania omawia konfrontację lub współczucie z twoim doświadczeniem. Nie wierzę, że konfrontacja jest warta waszego czasu lub tego czasu innych programistów.

Zamiast tego polecam trochę inżynierii społecznej, która była często praktykowana przez Benjamina Franklina aka efekt Benjamina Franklina :

Zapytaj o pomoc, o radę, o sugestie. Prośba o przysługę jest oznaką intymności i zaufania.

Może się to wydawać kontrinicjatywą, ale jeśli zadasz kilka ostrych pytań na trudniejsze tematy, to podświadomie sprawią, że ktoś przyzna, że rozumiesz podstawową tematykę, a tym samym dadzą ci więcej zaufania. To również sprawi, że poczują się oni bardziej zaufani przez Ciebie, ponieważ przyszedłeś do nich na ten “trudny” temat.

Jest to szybkie, niekonfrontacyjne rozwiązanie, które będzie działać w większości przypadków.

IT jest bardzo szerokim polem.

Zakładając, że ktoś _ musi wiedzieć_ JSON tylko dlatego, że ma w sumie 4 lata doświadczenia (lub 40) byłoby raczej głupią rzeczą do zrobienia przez twojego współpracownika. Mogłeś rozwijać aplikacje, które nie korzystają z JSON'a, lub frameworki, które ukrywają szczegóły JSON'a.

Co gorsza, mógłbyś po prostu częściowo nauczyć się korzystać z JSON'a (np. modyfikując pracę kogoś, kto nie był wystarczająco ostrożny); przypisanie Ci JSON'a bez upewnienia się, że wiesz jak JSON jest używany w Twojej organizacji mogłoby doprowadzić do powstania produktu poniżej standardu. Na przykład, być może Twój kod musi działać nie tylko w celu osiągnięcia sukcesu, ale również w celu pokazania odpowiedniego komunikatu w przypadku błędu.

Biorąc pod uwagę, że jesteś nowy na swoim stanowisku, jednym ze sposobów, aby upewnić się, że praca jest wykonywana prawidłowo, jest sprawdzenie Twojej wiedzy. Opisana powyżej metoda jest jedną z dostępnych, może ona alternatywnie zdecydować się na zadawanie Ci pytań lub poczekać, aż Twoje zadanie zostanie ukończone i przejrzeć kod. Nie wiem, czy wolałbyś któryś z tych sposobów. Oczywiście, samo pozostawienie cię w spokoju jest ryzykowne (dla ciebie, dla niej i dla biznesu), dopóki nie będzie pewna, że jesteś do pracy.

Zauważ, że żadne z powyższych nie jest związane z brakiem certyfikacji akademickiej.

A punkt “Zdałem rozmowę techniczną” nie zwalnia cię z poddania się badaniu. Wywiad techniczny daje tylko bardzo powierzchowną ocenę Twoich kompetencji; mówi, że możesz napisać kod, który działa, ale nie, że możesz napisać dobry kod.

Istnieje wiele aspektów, które są ważne, ale nie mogą być łatwo zbadane:

• Umiejętność rozumienia problemów.

• Umiejętność czytania kodu innych ludzi.

• Umiejętność używania właściwej architektury.

• Umiejętność pisania dobrze skonstruowanego kodu.

• Programowanie defensywne.

• Dobre praktyki w używaniu narzędzi (kontrola wersji, zautomatyzowane testowanie).

A w kwestii “stopień a samouczenie” zaakceptuj fakt, że brak stopnia oznacza, że Twój rozmówca może przyjmować mniej założeń co do tego, co wiesz lub czego nie wiesz1. Szczególnie w związku z powyższymi wyjaśnieniami (wiele osób uczących się samodzielnie po prostu nie wie o istnieniu tych czynników i po prostu przejdź do “Chcę zrobić program, który robi X "2)

Ktoś ze stopniem naukowym może poświadczyć minimalną bazę wiedzy3, brak stopnia sprawia, że Twój rozmówca może być niepewny Twojego poziomu _dopóki nie udowodnisz, że jesteś sobą. Więc nie bądź defensywny, jeśli twój rozmówca zdecyduje się sprawdzić, czy twoja wiedza jest wystarczająca do wykonania danego zadania.

TL/DR Daj programiście trochę czasu, aby mógł sam sprawdzić swoje możliwości.

• * 1Oczywiście, nie oznacza to, że ktoś ze stopniem akademickim jest zawsze w stanie napisać dobry kod, ponieważ ktoś wyjaśnił mu "defensywne programowanie”. Ale stopień naukowy zapewnia, że przynajmniej powinien wiedzieć, co to pojęcie oznacza.

2Właśnie teraz modyfikuję program zrobiony

3W rzeczywistości jest to w zasadzie użyteczność stopni naukowych.

Talk to her about it.

Your interpretation of her behaviour is that it is because she thinks of you as inexperienced. Wiele innych odpowiedzi dało sugestie dla alternatywnych interpretacji jej zachowania, a niektóre dają sugestie jak zamykać zachowanie, które, nie wiedząc dlaczego ona robi to może po prostu niepotrzebnie umieścić dodatkowy nacisk na związek.

Jedynym sposobem, aby wiedzieć dlaczego ona robi to jest rozmawiać z nią o tym. Najlepiej byłoby po prostu zapytać ją bezpośrednio, dać jej znać, dlaczego pytasz i zapewnić ją, że jeśli czegoś nie rozumiesz, zapytasz.

Znasz ją lepiej niż ktokolwiek z nas, więc powinieneś mieć lepszy pomysł, jak by zareagowała, ale zastanów się, czy nie zacząć od czegoś takiego:

Hej Sue, wiem, że nie pracujemy razem zbyt długo i wciąż uczymy się, czego się od siebie nawzajem oczekiwać. Zauważyłam, że kiedy rozmawiamy o sklepie, często wpadasz na całkiem podstawowe wyjaśnienia tego, co uważam za standardowe tematy. Why is that? I’m hoping it is because X or Y (give one or two of the more generous interpretations from the others), but it often feels like I’ve given you the impression that I need these things explained. Jeśli tak jest, to wydaje się, że marnujemy cenny czas, który mógłby być wykorzystany bardziej produktywnie, omawiając wymagane cechy. Jeśli nie masz pewności co do mojego doświadczenia z danym tematem, możesz zapytać, co wiem na jego temat, a jeśli dyskusja dotyczy czegoś, co wykracza poza moje doświadczenie, zaufaj mi, że zapytam.

Początkowo nie przerywałbym jej, gdy jest w jednym z jej wyjaśnień, aby przeprowadzić tę dyskusję, ponieważ wydaje się bardziej prawdopodobne, że okaże się ona reakcyjna lub defensywna. Lepiej podejść do niej oddzielnie.

Idąc dalej, w zależności od tego, co wyniknie z początkowej dyskusji, kiedy i jeśli powtórzy się, możesz wtrącić się, że jest to jedno z tych podstawowych wyjaśnień, lub zacząć stosować niektóre z sugestii innych, jak reagować na bieżąco.

Na marginesie:

W zeszłym roku w projekcie musiałem wyjaśnić, czym JSON był dla kilku członków zespołu. Oboje mają na mnie co najmniej dekadę (lub dwie) doświadczenia w branży, a w różnych momentach swojej kariery oboje pracowali nad projektami internetowymi. Po prostu nigdy nie pracowali z żadnymi ramami ani nie potrzebowali technik, które byłyby szczególnie istotne.

W tym samym projekcie mieliśmy kilku ludzi biznesu, z którymi pracowaliśmy zamiennie używa tych samych dwóch lub trzech terminów odnoszących się do dwóch ściśle powiązanych, ale (jak się okazuje) różnych tematów. Temat, który dany termin oznaczał, zależał od tego, który z nich go używał i w jakim kontekście. Tak naprawdę zajęło nam to kilka iteracji, aby się nimi zająć. Do tego momentu nigdy nie było jasne, że istnieją nawet odrębne tematy. Założyliśmy, że wiemy i założyliśmy, że wszystkie odnoszą się do tego samego.

Ostatnio w dyskusji o źle skonfigurowanej aplikacji, miałem członka zespołu, który przez pół godziny wychodził na styczną, proponując błędne zmiany w naszym frameworku konfiguracyjnym, aby zapobiec wybraniu niewłaściwego środowiska domyślnego, gdy problemem było to, że aplikacja miała niewłaściwą wartość domyślną dla indywidualnego ustawienia. (Framework pozwala na domyślne wartości awaryjne w przypadku, gdy nie jest nadpisany dla bieżącego środowiska, aplikacja miała to, co powinno być wartością produkcyjną ustawioną jako domyślną, więc gdy środowisko testowe nie nadpisało jej…)

Jaki jest sens? Prawie każda dziedzina zawodowa jest na tyle szeroka, że dla każdej osoby, bez względu na poziom doświadczenia, nie można wiedzieć wszystkiego. Każdy będzie miał inne dziury w swojej wiedzy i doświadczeniu, a mogą istnieć subkultury i specjalizacje o zderzającym się żargonie. Nie można po prostu zakładać, co inni ludzie wiedzą lub myślą, lub dlaczego podejmują pewne decyzje.

To było moje doświadczenie, nieprzedstawione założenia mogą (i w końcu będą) być bardzo kosztowne. Kilka minut spędzonych na upewnieniu się, że wszyscy są na tej samej stronie przed rozpoczęciem jakiejkolwiek dyskusji, zaoszczędzi wiele na dłuższą metę.

W tym przypadku Twoje założenie, że ona to robi, ponieważ jesteś samoukiem, i/lub (jeśli Twoje założenie jest prawidłowe) jej założenie, że potrzebujesz instrukcji, szkodzi Twojemu związkowi zawodowemu.

Przeczytałem wszystkie powyższe odpowiedzi i większość z nich wskazuje na to, że jest życzliwa, a ty się nad tym zastanawiasz.

Ale z twojego pytania nie wynika, że tak jest. Wydawało się, że czujesz się obrażony jej zachowaniem.

W mojej opinii, to jest ten czas, musisz pokazać swoje umiejętności. To może być jej pogląd, że stopień jest tym, co czyni ‘Software Developer’, ale z mojego doświadczenia wynika, że praca nad projektami w czasie rzeczywistym i rozwiązywanie krytycznych scenariuszy jest tym, co czyni ‘Software Developer’. Nie chwal się, ale bierz udział w dyskusjach technicznych proaktywnie.

Aby zaprezentować się bez chwalenia się, zacznij pomagać kolegom, juniorom itp. Twoja praca, zestaw umiejętności i wszystko inne będzie mówić za siebie.

Jest to trochę trudniejsze, niż niektóre odpowiedzi sprawiają, że tak się dzieje. Nie powinieneś po prostu wychodzić i mówić, że nie potrzebujesz pomocy (arogancja), ani słuchać po cichu (to irytujące!).

Moja rada to… olśnić ją swoją wiedzą. Jeśli rozumiesz coś, co jest Ci wyjaśniane w branży tworzenia oprogramowania, pokaż osobie, która Ci to wyjaśnia, że to rozumiesz, omawiając to, a następnie stopniowo wprowadzaj swoją zaawansowaną wiedzę na ten temat, aby pokazać Ci, że to rozumiesz. Kiedy ktoś po prostu słucha, wielu ludzi, a zwłaszcza inżynierowie są skłonni myśleć, że słuchacz nie jest w stanie zaangażować się w dyskusję, ponieważ nie rozumieją.

Przypadek i punkt, kiedy ktoś wyjaśnia Ci coś oczywistego w branży, milczeć, są szanse, że wyjaśni to ponownie w nieco inny sposób … kilka razy z narastającą frustracją. Odpowiedz, pokaż, że to wiesz, a oni mają tendencję do zostawienia cię w spokoju, lub znaleźć coś lepszego do omówienia.

Aby zatrzymać techniczne badgering całkowicie, pokazać, że wiesz WIĘCEJ niż osoba próbuje nauczyć cię i szybko nauczą się nie pouczać i jeśli coś przyjdzie do ciebie z pytaniami.

Teraz, jeśli tłumaczą Ci JSON'a, ponieważ popełniłeś krytyczny błąd, lub właśnie zademonstrowałeś nieudaną koncepcję architektoniczną, to właśnie tam się zamykasz i słuchasz.

Tylko moje dwa centy na to, co pracowało dla mnie w przeszłości, każdy jest jednak trochę inny.

Ostrzeżenie: To działa tylko z niektórymi osobami w niektórych sytuacjach; YMMV. Ta odpowiedź nie ma gwarancji.

• *

To, co bym zrobił w tym przypadku, to przerwanie ich podsumowaniem tematu. Na przykład, z JSON:

Them: JSON to JavaScript Object Notation, który jest sposobem reprezentacji - Me: obiekty podobne do słowników i, erm, tablice i prymitywy oraz, JavaScript prymitywy mam na myśli, w formacie szeregowym.

To odpowiada następującej sytuacji:

Them: JSON jest JavaScript Object Notation, który jest sposobem reprezentacji - Me: Dowolny obiekt w JavaScript jako łańcuch. Them: Nie, ponieważ nie może przechowywać funkcji, ani obiektów, które mają ukryte właściwości; jest to bardzo prosta reprezentacja…

Przerwanie ich “tak, wiem” w tym przypadku prowadziłoby do problemów później, kiedy okazało się, że tak naprawdę nie wiem, czym był JSON, więc powodowało problemy w kodzie z moimi założeniami.

Twój kolega jest prawdopodobnie po prostu próbuje upewnić się, że wiesz wszystko, co musisz. Jeśli jesteś “samoukiem”, oznacza to, że możesz mieć luki, które większość ludzi założyłaby, że wypełniłeś, ponieważ znasz “trudniejsze rzeczy” (choć większość placówek edukacyjnych uczy takich rzeczy w prawdziwie dziwnej kolejności!), a takie założenie może prowadzić do subtelnych, trudnych do znalezienia problemów z powodu fałszywych założeń.

• *

*: zobacz na górze odpowiedzi.

Nie wspomniałeś o branży, która będzie miała duże znaczenie.

Pracuję w dużej firmie high-tech i często zatrudniam młodych programistów (0-2 lata doświadczenia). Szkoła, do której uczęszczali i ich stopień naukowy nie robi mi najmniejszej różnicy.

Niedawno odrzuciłem dwóch kandydatów z najlepszej szkoły w kraju, aby zatrudnić jednego ze szkoły, której nazwy nawet nie pamiętam. Różnica między nimi polegała na tym, że dwaj pierwsi byli dobrzy, a trzeci był genialny, także dlatego, że był samoukiem. To było oczywiste po 5 minutach, że zrobiłby to wspaniale.

Co to oznacza w kontekście twojego pytania? Prawdopodobnie, że lepiej nadajesz się w branży, która daje większą wagę wiedzy niż szkoła.

W zależności od kraju może to być trudniejsze, ponieważ różne kraje traktują swoje szkoły z różnymi poziomami szacunku (Francja jest skrajna, gdzie prawie nosi się bieliznę emblazonowaną wraz ze szkołą, jeśli jesteś z właściwego kraju - to nie jest złe w zależności od rodzaju pracy)

Chyba można powiedzieć - ja już wiem trochę (akcent na trochę) o JSONIE. Więc, możemy na razie pominąć JSON'a? Ale jeśli jest coś, czego nie wiem o JSON'ie, czy mogę poprosić cię o pomoc później ?

Powiedzmy na przykład, że nie manipulujesz JSON'em. Bierzesz JSON'a, konwertujesz go na obiekt modelu, manipulujesz obiektem modelu i konwertujesz go z powrotem na JSON'a. Założę się, że jeśli twój kolega będzie próbował manipulować JSONem bezpośrednio, to pojawią się błędy, ponieważ JSON jest prosty, ale nie that prosty.

Teraz, jeśli jest taki sprytny, wydrukuj kopię tego artykułu https://www.ics.uci.edu/~dan/pubs/LenLimHuff.pdf , który dotyczy obliczania optymalnych kodów Huffmana z ograniczoną długością kodu (kody Huffmana z nieograniczoną długością kodu są proste) i poproś go, aby wyjaśnił ci ten algorytm. Najprawdopodobniej nie będzie w stanie tego zrobić, w najgorszym razie zamknij go na jakiś czas. (Kody Huffmana o ograniczonej długości są ważne, ponieważ pozwalają na znacznie bardziej wydajne dekodery). PS. Jeśli on lub ona _ może_ wyjaśnić ci algorytm, to on lub ona jest dobry. Wątpię.

Poza tym, jeśli ktoś próbuje Ci wytłumaczyć JSON, pytasz go, co próbuje tam osiągnąć? Czy on myśli, że JSON jest czymś trudnym, czego nie możesz zrozumieć bez stopnia CS? Poważnie? Czy nie uważa, że jest trochę pełen siebie? Jego zachowanie jest obraźliwe, więc oddajesz tak dobrze, jak na to zasługuje.

Twórcy samouków często są ekspertami w zakresie technologii, w których mają praktyczne doświadczenie, ale czasami problem polega na tym, że nie wiedzą, jak wiele nie wiedzą. Na przykład, często spotykam samouków programistów wymyślających nowy algorytm do rozwiązania problemu, gdy istnieje dobrze znany standardowy algorytm, który jest często znacznie lepszy.

Spróbuj pamiętać, że gdybyś był hydraulikiem lub elektrykiem, nie mówiąc już o lekarzu lub prawniku, nie mógłbyś wykonywać zawodu bez formalnych kwalifikacji. Programowanie w rzeczywistości jest dość wyjątkowe, gdyż pozwala na pracę w zawodzie tym osobom, których umiejętności są całkowicie samoukiem. A wielu z tych, którzy to robią, wykonuje doskonałą pracę. Ale spróbuj rozpoznać, że ci, którzy zrobili stopień CS nauczyli się rzeczy, których ty nie zrobiłeś, i być otwartym na uczenie się od nich.

Nawiasem mówiąc, stopień CS nie nauczy cię wiele o JSON. Nauczy Cię jednak, do jakiej klasy gramatyki należy JSON, a co za tym idzie, do jakiej klasy parsera trzeba go przetworzyć: nauczy Cię uniknąć błędu, jakim jest próbowanie parsowania JSONa za pomocą wyrażeń regularnych, ponieważ teoria mówi, że nie można tego zrobić. Wystarczy śledzić StackOverflow przez kilka tygodni, aby zobaczyć, ilu programistów nie jest świadomych takich podstaw.