Nigdy nie przedstawiaj problemu.

Rzuciłem okiem na Twój profil i zauważyłem, że od jakiegoś czasu jesteś w społeczności StackExchange. Niewątpliwie zauważyłeś tutaj, że pytania, na które tutaj udzielono najlepszych odpowiedzi, to te, które przedstawiają problem i rozumowanie, które już przyjęli, próbując odpowiedzieć na to pytanie.

Życie zawodowe jest takie jak to. Jeśli zadajesz pytanie, pamiętaj, aby również poinformować ich, co zrobiłeś, aby spróbować samodzielnie odpowiedzieć na to pytanie. Jest to korzystne na wiele sposobów:

• Pokazuje, że nie pytasz niepotrzebnie. Jeśli ujawniasz swoje rozumowanie, dajesz tej osobie do zrozumienia, że próbujesz zadać pytanie, a nie tylko być leniwym.
• Prawdopodobnie otrzymasz informacje zwrotne, które przydadzą się Twojemu procesowi myślowemu. Jeśli ktoś przyjdzie do mnie z problemem i ujawnia, w jaki sposób próbowali odpowiedzieć na pytanie, nie tylko pomoże im pokierować właściwą ścieżką, ale także pomogę im zrozumieć, jak mogli pomyśleć o pytaniu, aby się tam dostać. Im bardziej ujawniasz swój proces myślowy i rozumowanie, tym bardziej inni ludzie mogą Ci pomóc w budowaniu na nich przyszłych problemów.

Jest tu kilka punktów do rozpakowania.

Zakładałem, że wszyscy w firmie technologicznej lubią rozmawiać o technologii ...

Nie koniecznie. Wiele osób technicznych będzie mówić o technologii, która jest odpowiednia dla zadania, które teraz wykonują, ale może absolutnie nie interesować się czymkolwiek innym.

Myślę, że można się pomylić między tym a:

Zostałem również skarcony za „pójście na złą ścieżkę”, gdy próbowałem rozwiązać problem, którego nie znałem, zamiast pytać kogoś, kto był.

Weź pod uwagę chłopca, który płakał wilk :) Jeśli spędzasz czas komuś na rozmowie o rzeczach, które nie mają związku z tym, co robią, to kiedy zadasz im odpowiednie pytanie, może się okazać, że czują, że stracili już wystarczająco dużo produktywności razem z tobą.

Prawie zawsze staram się rozwiązywać problemy samodzielnie przez przynajmniej godzinę. Czy to jest za krótkie?

W wielu przypadkach tak, jest za krótkie. O ile problem, który próbujesz rozwiązać, nie jest prosty, powinieneś poświęcić więcej czasu na wyszukiwanie i wypróbowywanie różnych permutacji. Jeśli problem jest prosty, to odpowiednie wyszukiwanie w sieci powinno dać prawidłowe wyniki.

Połącz to wszystko razem i widzę młodego programistę, który ma pewne problemy z oceną , co powiedział Ci pracownik HR. Nie jest to nie do pokonania, ale jest kilka rzeczy, o których musisz pomyśleć.

• Zapisz hipotetyczne pytania techniczne do jadalni. Nie jest to właściwe, chyba że dobrze znasz ludzi marnować czas swój i innych ludzi na nieistotne pytania.
• Dowiedz się, jak stosować lepsze hasła wyszukiwania w sieci. Jeśli powiedziano Ci, że zadajesz zbyt wiele pytań i zadawanie pytań zajmuje zbyt dużo czasu, więc najwyraźniej zadajesz niewłaściwe pytania.
• Zadając pytanie, pokaż, czego próbowałeś. Klasyczna mentalność przepełnienia stosu. Jeśli nie masz nic do pokazania jako wspólny wysiłek w celu rozwiązania problemu, oznacza to, że nie próbowałeś wystarczająco mocno. W rzeczywistości nie bój się korzystać z zasobów takich jak Stack Overflow, jeśli jest coś namacalnego, o co można zapytać, a może znajdować się w domenie publicznej. I na koniec;
• Zapisz pytania na pytania specyficzne dla biznesu. Nie pytaj o to, jak sterować narzędziem programistycznym, ale zrób pytanie o domenę- lub kwestie środowiskowe, które nie będą w domenie publicznej.

Jest tu wiele rzeczy, które możesz zrobić, aby poprawić. Może się okazać, że PIP może być bardzo cennym narzędziem, które pomoże ci stać się lepszym programistą :)

Problem polega na tym, że kiedy przerywasz komuś pracę, nie tylko traci on 5-15 minut, jakie zajmuje mu udzielenie odpowiedzi. Tracą znacznie więcej czasu, ponieważ muszą odzyskać koncentrację. A to może być dość frustrujące.

Byłem w sytuacji podobnej do Twojej. Zwykłem chodzić do ludzi i od razu zadawać im pytania. Nawet jeśli zrobili coś, co by mnie zablokowało. To mogło nawet przeszkodzić innym osobom w pobliżu.

Mój kierownik podał rozwiązanie: korzystaj z poczty e-mail i komunikatorów internetowych, nawet gdy osoba siedzi obok Ciebie. W ten sposób zastanowisz się więcej, jak sformułować pytanie, a podczas tego procesu możesz sobie odpowiedzieć. Druga strona może również odpowiedzieć, kiedy będzie miała trochę wolnego czasu.

Inną opcją jest zorganizowanie spotkania, na którym wszystko zostanie wyjaśnione.

Spróbuję odpowiedzieć z perspektywy firmy. Nie jestem tą firmą, więc mogą istnieć rzeczy, których nie widzę, ale widziałem to już wcześniej w swojej firmie.

Zbyt wiele pytań

Wydaje się, że większość Twojego pomieszania wynika z faktu, że nie rozumiesz, iż zadawanie pytań jest niebezpieczną grą. Jest !!!

Kiedy zadajesz pytanie, przyznajesz, że nic nie wiesz, i że nie możesz rozwiązać. Jednym z twoich zadań jako programisty jest rozwiązanie tego problemu. Obrażasz "obecny" zespół deweloperów pytając po prostu: "Więc napisałeś tutaj taki gówniany kod, że nie mogę dowiedzieć się, jak go czytać ani co robi, więc idę i muszę mi to wyjaśnić . ”

Teraz najtrudniejsze jest to, że czasami tak właśnie jest i powinieneś zadawać pytania. Ważne jest, aby pamiętać, że niezależnie od wszystkiego, te pytania mają swoją negatywną stronę.

Kolejną rzeczą, którą, jak sądzę, wyczuwam w twoim OP, jest to, że zadajesz pytania o wiele za wcześnie. Jest absolutnie w porządku, aby nowy programista siedział i czytał i szukał przez cały dzień, aby napisać 2 linie kodu. W rzeczywistości, mając 14 lat doświadczenia, nadal to robię. W pisaniu profesjonalnego kodu nie chodzi o to, „ile” zostało zrobione, ale o to, „jak dobrze” zostało to zrobione i aby móc powtórzyć ten sukces. Wątpię, czy ktoś będzie na ciebie krzyczał, że wykonanie jednej dziesiątej pracy jako wyszkolony i uznany programista zajmuje 100 razy więcej czasu. Tak naprawdę, kiedy kogoś zatrudniam, pierwszy miesiąc odpisuję jako nie spodziewając się żadnej prawdziwej pracy, a pierwsze pół roku jako mało oczekujący.

Za mało czasu na własną rękę

To wielka sprawa !!! Kiedy prosisz członka zespołu o pomoc, zmniejszasz również produktywność tej osoby. Wpływasz na ich proces i obrażasz ich (patrz wyżej) w tym samym czasie. Nie ma sposobu, abyś wygrał, jeśli musisz poprosić o pomoc. Pomyśl o każdym pytaniu jak o przegranej bitwie. Nadal możesz wygrać wojnę, ale przegrałeś tę bitwę.

Jest kilka rzeczy, które możesz zrobić, aby złagodzić ten problem:

1. Pytaj przez e-mail, nigdy osobiście lub na czacie. Czat może być preferowanym sposobem robienia tego „oficjalnie”, ale poczta elektroniczna jest przyjemniejsza, ponieważ odbiorca może sobie z tym poradzić w swoim czasie.
2. Podejdź do niego z „niższej” pozycji. Jesteś tu suplikantem. Płaszcz się trochę. W porządku. Trochę nie zaszkodzi i pokaże odbiorcy, że zależy Ci na jego czasie, np. „Wiem, że jesteś naprawdę zajęty, ale nie potrafię zrozumieć, jak zintegrować się z Twoim API. czy możesz mi za kilka chwil pokazać, czego mi brakuje? ” To pokazuje, że to ty jesteś w błędzie, a nie oni. To ważne.
3. Wypisz kroki, które wykonałeś samodzielnie. „Dokument API mówi, aby przekazać ciąg znaków reprezentujący identyfikator użytkownika. Próbowałem przekazać właściwość user.id i nazwę użytkownika, ale żadne z nich nie zadziałało”. To pokazuje, że przynajmniej coś próbowałeś i że generalnie zaczynasz „zdobywać” produkt.

Lepszy osąd przy zadawaniu pytań

Dla mnie brzmi to tak, jakbyś „jęczała” do kogoś, a oni nie mieli miły sposób na powiedzenie: „Denerwujesz wszystkich swoimi kiepskimi pytaniami. Przestań!” Innymi słowy, myślę, że to nie jest problem. Po rozwiązaniu innych problemów problem zniknie.

Zła dokumentacja

Ahem! To kolejna osobista zniewaga. Nigdy tego nie mów. ZAWSZE!!!! Znowu mówisz, że jakość ich kodu jest tak słaba, że ​​nie możesz tego rozgryźć. Ich odpowiedź zawsze będzie brzmiała: „Działa na wszystkich, więc musisz być idiotą, nie ja!”.

Poza tym to trochę „witamy w prawdziwym świecie”. W prawdziwym świecie klienci płacą za działające aplikacje, a nie za kod lub dokumentację (przez większość czasu), więc bardzo często dokumentacja ulega degradacji w czasie.

Jeśli uważasz, że dokumentacja jest słaba i należy się nią zająć, porozmawiaj o tym po cichu z kierownikiem zespołu. Niech zdecydują.

Ale powiem to. Nieważne, jak kiepska jest dokumentacja, z kodem źródłowym tuż przed tobą, nie powinieneś go potrzebować. Naprawdę fajnie jest mieć, nie zrozum mnie źle, ale możesz pracować bez tego.

Spóźnianie się

Oczywiście nie spóźnij się. To nie myślenia. W rzeczywistości w twojej obecnej sytuacji zajmij 30 minut. wcześnie!! Bez wymówek. Rujnujesz wszelkie nadzieje na znalezienie następnej pracy w tej. Gdybym zadzwonił do tamtejszego działu HR i zapytał o twoją obecność, a oni powiedzieli: „Często się spóźniał” lub „Został napisany za spóźnienie”, to byłaby natychmiastowa czerwona flaga. Wspominam o tym, ponieważ niezależnie od tego, czy zachowasz tę pracę, czy zdobędziesz nową, to bardziej niż cokolwiek innego powstrzyma Cię przed podjęciem następnej pracy.

Kod niskiej jakości

To prawdopodobnie prawda. Biorąc pod uwagę problem z pytaniem, prawdopodobnie nie piszesz dobrego kodu. Ale jesteś nowy i należy się tego spodziewać. Uważam, że uczelnie nie uczą cholernej rzeczy o kodowaniu w prawdziwym świecie. Nigdy nie zatrudniłem kogoś prosto ze studiów i nie dostałem „dobrego programisty”. Nie oznacza to, że nie zostali dobrymi programistami. Po prostu nie zaczynają się w ten sposób. Pisanie dobrego kodu oznacza śledzenie najnowszych trendów i technik. Ciągle się uczysz. Moment, w którym przestajesz, jest momentem, w którym zaczynasz ssać.

Podsumowując

Ten post był szorstki, ale chciałem jasno pokazać, jakie może być stanowisko firmy. Często (firmy) podsumowują swoje komentarze tak dużo „mową menedżera”, że może to być trudne do zrozumienia. Starałem się ograniczyć przemówienie menedżera w tym poście tak bardzo, jak tylko mogłem, ale to oznacza, że ​​jest to trochę szorstkie.

Najważniejsze kroki, aby naprawić swoją upadającą karierę:

1. POKAŻ, ABY PRACOWAĆ WCZESNIE !!!! (Nie mogę tego wystarczająco podkreślić)
2. Zadawaj pytania z nastawieniem, że już obrażasz osobę, którą pytasz.
3. Pokaż swoją pracę. Zadając pytanie, jasno powiedz, co już zrobiłeś.
4. Poświęć więcej czasu na samodzielną naukę. Ważne jest, aby spędzać więcej czasu na badaniu rzeczy niż zadawaniu pytań. Szczerze mówiąc, 3-4 dni na samodzielne szukanie czegoś będą bardziej szanowane niż 30-sekundowe pytanie.

Dowiedz się, jak przyjmować krytykę. Zdaję sobie sprawę, że jesteś typem inżyniera, więc radzisz sobie z dobrem i złem. Chcesz bronić swoich pytań. Zacznij od wskazania, że ​​przyjmiesz ich opinie i spróbuj zadać mniej pytań. Jeśli otrzymasz pozytywną odpowiedź (zwróć uwagę, jak reagują !!), możesz poprosić o wyjaśnienie, co jest dobre, a co złe. Pomyśl o sytuacji jak o pracy z technologią, która ma błąd. Możesz argumentować przez cały dzień, że twój kod powinien działać i nie ma potrzeby stosowania obejścia, ale to nie jest rzeczywistość. Rób to, co działa (i dotyczy to sytuacji, gdy myślisz, że jest błąd w technologii, ale sposób jej implementacji jest naprawdę zły).

Twoja sytuacja może być przykładem tego, że ludzie nie mają problemów i chodzenie za czyimś plecami zamiast oferowania opinii. Teraz może być za późno. Czy na pewno nikt ci nie mówił, żebyś przestał im przeszkadzać?

Gdy ktoś zada pytanie, mogą pojawić się problemy:

1. Mam coś do zrobienia, więc teraz nie czas. Idealnie byłoby, gdyby ludzie powiedzieli ci, kiedy jest dobra pora.
2. To jest coś, co powinieneś być w stanie samodzielnie zbadać. Niestety, łatwiej jest znaleźć w Google niejasne rozwiązania problemów z przestarzałymi technologiami, niż znaleźć zasady i procedury dla własnej firmy. Ludzie nie dokumentują. To smutne, ale prawdziwe.
3. Wciąż zadajesz to samo pytanie.
4. Twoje pytania są przesadnie krytyczne, a ludzie mają dość wyjaśniania / obrony, dlaczego robią coś pewien sposób. Jest to jeszcze trudniejsze w kontaktach z nowymi ludźmi. „Dlaczego używamy języka COBOL?” Ponieważ była to najlepsza technologia w tamtym czasie i działa od kiedy byłeś w pieluchach. Teraz wykonaj swoją pracę.

Opierając się na tym, co mówisz, nie otrzymałeś zbyt wielu opinii, dopóki nie zostałeś poddany okresowi próbnemu. Jaka szkoda. Wiele miejsc nie dysponuje środkami i praktykami, aby szkolić i udzielać porad dla nowych ludzi. Gdyby ktoś naprawdę troszczył się na tyle, by pomóc Ci odnieść sukces, powiedziałby ci coś.

Byłem w dokładnie takiej samej sytuacji.

Problem

To, co opisujesz, jest problemem, z którym boryka się większość świeżo upieczonych absolwentów. Większość uniwersytetów uczy tylko podstaw lub pojęć, podczas gdy w pracy praktycznej potrzebujesz o wiele więcej.

Większość firm zatrudniających świeżo upieczonych absolwentów ma plany szkoleniowe. rok lub więcej. Ale niektórzy ludzie są ciekawi, jeśli powiesz im proste zadanie naprawy małego komponentu w systemie, nie zrozumieją go, dopóki nie opanują całego systemu i myślę, że jesteś jednym z nich ...

Myślę, że zadajesz pytania, ponieważ

• Czujesz, że wykonanie zadania zajmuje więcej niż rozsądny czas, ponieważ nie rozumiesz jakiejś części systemu.

• Ciekawi Cię pełne zrozumienie systemu

• Twoja firma nie zapewniła Ci odpowiedniego przeszkolenia

Rozwiązanie”

Jeśli moje przypuszczenia są słuszne, przestań zadawać pytania, chyba że musisz (kropka - teraz)

• Zacznij spędzać więcej czasu na zrozumieniu systemu (nie tylko 8 godzin)

• Zamiast tego użyj SO lub innych powiązanych witryn (po wykonaniu części badawczej)

• Poproś firmę, aby odpowiednio przeszkoliła Cię w obszarach, w których potrzebujesz pomocy.

Postępowałem zgodnie z powyższym i teraz pracuję w tej samej firmie po 5 latach i mogę powiedzieć, że wiem więcej ktoś tutaj.

Chciałem się tym zająć z punktu widzenia zarządzania.

PIP to kompleksowa rzecz

Jest całkiem prawdopodobne, że poprawa wydajności jest zbiorem rzeczy, które podkreśliło twoje kierownictwo, wszystko zrobione razem. Podejrzewam, że gdybyś był osobą, która zadawała wiele pytań, ale przyszła wcześniej, została spóźniona i wykonała świetną robotę podczas pisania kodu, zespół potraktowałby zadane pytanie jako dziwactwo osobiste lub że jesteś wyjątkowo dokładny.

Ale kiedy zespół musi pomóc znaleźć i naprawić więcej błędów w kodzie, po udzieleniu odpowiedzi na więcej niż zwykle ilości pytań i widzi, że pracujesz mniej godzin lub spóźniasz się bez powiadomienia, zespół a menadżer będzie czuł, że nie przyczyniasz się do osiągnięcia poziomu, na którym musisz być, i nie poświęcasz dodatkowego czasu na przyspieszenie. Zadane pytanie zostało prawdopodobnie postawione w świetle innych problemów, ponieważ jeśli spróbujesz naprawić jakość kodu, zadając WIĘCEJ pytań, zespół będzie nie do utrzymania.

Liczy się każda godzina

Nowy absolwent college'u JEST inwestycją w czas zespołowy. Każdy menedżer, który mówi ci, że jest inny, albo nigdy nie zatrudnił nowego absolwenta college'u, albo kłamie, albo ma naprawdę wyjątkowych kierowników pracujących dla niego / niej. Każdy nowy pracownik to jakaś inwestycja, ale absolwenci szkół wyższych mają WIĘCEJ czasu. Zwykle jednak ten kompromis jest tego wart, ale pamiętaj, że absolwenci uczelni zadają więcej pytań niż bardziej doświadczeni programiści.

Jednak liczy się każda godzina. Zespół programistów zrobi więcej w danym tygodniu, gdy wszyscy są na bieżąco, znają kod i nie zadają wielu pytań. Ponadto zespół w tym zżelowanym stanie będzie w stanie bardzo szybko zadawać pytania i odpowiadać na nie - co również zwiększa produktywność.

Odpowiadanie na pytania zajmuje czas. Za każdym razem, gdy programista przestaje pisać kod i zaczyna odpowiadać na pytania, następuje zmiana kontekstu. Tak więc odpowiadanie na pytania oparte na przerwaniach jest o wiele bardziej zabijające produktywność niż siedzenie przez godzinę i odpowiadanie na zbiór pytań.

Byłbym bezpieczny argumentując, że KAŻDA zmiana kontekstu kosztuje 1 godzinę, więc nawet jeśli masz 5-minutowe pytanie, kosztowałeś zespół godzinę, gdy ktoś przestaje odpowiadać na Twoje pytanie. Oznacza to, że zajęcie 1 godziny bez uzyskania pomocy, a następnie poproszenie o pomoc faktycznie kosztuje więcej czasu niż zajęcie 2-4 godzin.

Nie ma czegoś takiego jak „zajmie to drugiemu tylko 5 minut oszczędź mi godzinę ”. Biorąc pod uwagę wskaźnik co najmniej godziny na przerwę, inny facet powinien zaoszczędzić Ci 2-4 godziny.

Wskazówki dotyczące zadawania pytań Dobrze:

• Zrozum i zadawaj pytania stosownie do pilności - jeśli absolutnie MUSISZ mieć problem rozwiązany w ciągu godziny, przerywając prawie każdemu, kto może ci pomóc, to dobry pomysł. Jeśli wyznaczono Ci 3-tygodniowy termin, lepszym pomysłem jest mniej przerywania i częstsze rozwiązywanie własnych problemów. Oznacza to, że w nagłych wypadkach ludzie często zadają wiele pytań, które w innym przypadku przeprowadziliby samodzielnie. Ponieważ absolutnie konieczne jest uzyskanie odpowiedzi tak szybko, jak to możliwe.
• Korzystaj z forów pytań do określonego celu lub intuicyjnie określaj cel na podstawie istniejących pytań / odpowiedzi. Na przykład giełdy stosów mają dość obszerny zestaw podstawowych zasad, które są dość dobrze udokumentowane, oraz szczególne oczekiwanie, że użytkownicy będą szukać wcześniejszych odpowiedzi przed zapytaniem. Inne forum może spodziewać się powtarzających się pytań, ale tylko dotyczących bardzo wąskiego obszaru.
• Zbadaj swoje pytanie. Spodziewaj się, że napisanie dobrego pytania może zająć tyle samo czasu, co udzielenie odpowiedzi - w wielu przypadkach opisujesz (zwięźle!) Kroki, które doprowadziły Cię do tego, że nie jesteś w stanie odpowiedzieć na problem. Prawdopodobnie będziesz także dokumentować wszystkie symptomy problemu.
• Skieruj swoje pytania - dowiedz się, kto faktycznie może odpowiedzieć na pytania, jeśli to możliwe, zamiast zadawać pytania wszystkim. Nie każde pytanie jest warte omówienia.
• Zbierz dużą liczbę pytań - zwłaszcza jeśli jesteś nowy, poświęć dzień na przejrzenie problemu i kodu. Zagreguj swoje pytania w wypunktowaną listę z zagregowanymi tematami. Następnie zapytaj mentora lub znajomego, gdzie się udać, aby uzyskać pomoc w tym zakresie. Jest całkiem prawdopodobne, że na większość pytań w godzinie # 1 zostanie udzielona odpowiedź do godziny # 6. Pytania, które nadeszły w ciągu 1-2 godzin, na które nie można było odpowiedzieć w godzinie 8., prawdopodobnie znajdują się na górze Twojej listy, ponieważ wiesz, że w ciągu 8 godzin nie będziesz w stanie ich rozgryźć.
• Kod nie jest „samodokumentowaniem”, ale wielu informacji można się nauczyć czytając go. Nauczyłem się wielu nieudokumentowanych systemów, siedząc z notatnikiem i rysując moją wersję projektu po drodze. Jeśli nie przeczytałeś kilku poziomów powyżej i kilka poziomów poniżej obszaru, w którym pracujesz, i nie przeczytałeś dokumentacji dotyczącej zewnętrznych interfejsów API, których używasz, to nie zbadałeś wystarczająco dobrze.
• Próbując znaleźć odpowiedź, bardzo dużo idzie, jeśli możesz zasugerować możliwości, zamiast prosić o odpowiedź. "Czy to byłby właściwy sposób, aby to zrobić?" jest lepsze niż „Jak to zrobić?” - nawet jeśli odpowiedź brzmi „robisz to całkowicie źle” - nadal możesz zapytać „dlaczego moja droga jest zła?” a tym bardziej meta "jak mam się nauczyć to robić dobrze wielokrotnie"? To jest podejście „naucz człowieka łowić ryby” - naucz się łowić, nie zadawaj pytań, które dają tylko 1 rybę.
• Unikaj pytań, które są jedynie uprzejmym sposobem na odmowę. Istnieje granica między „czy mój sposób na zrobienie tego działa?” vs. „Nie rozumiem (tj. nie zgadzam się z), dlaczego zrobiłeś to po swojemu”? To fajne rozmowy, ale lepiej je prowadzić nieformalnie po poznaniu ludzi.
• Umiarkowanie pytań ogólnych - zazwyczaj są to pytania „dlaczego”. Nowi ludzie mają pełne prawo zadawać wiele pytań „gdzie” & ”kto” (gdzie jest dokumentacja, gdzie jest proces, gdzie jest miejsce w kodzie, na które chciałbym spojrzeć? Kto może odpowiedzieć na to? Kto to robi? Zapraszam do recenzji?) I kilka pytań „jak” - czy tak mam do tego podejść? jak mogę uzyskać twoją zgodę? Ale „dlaczego”, np. „Dlaczego zbudowaliśmy go w ten sposób?”, „Dlaczego nie dokumentujemy więcej kodu?”, „Dlaczego nie jest to priorytetem?” - są uzasadnione, ale dopóki nie zdobędziesz większego doświadczenia w pracy i biznesie, nie są to najbardziej potrzebne pytania. Mogą być WIELKIE dla 1 na 1 z szefem, gdy nie masz innych pilnych problemów, ale jeśli „dlaczego” wypiera gdzie, kto i jak, wtedy nie koncentrujesz się na swojej pracy.

Tutaj jest już wiele odpowiedzi, ale chcę odpowiedzieć na kilka konkretnych części twojego pytania.

Chociaż zostałem również skarcony, że nie spędzam wystarczająco dużo czasu na próbach zrozumienia rzeczy samodzielnie, zanim poproszę innych o pomoc. Nie jest to jednak prawdą i mój menedżer nie miałby teraz możliwości określenia, ile czasu upłynęło od chwili, gdy napotkam problem, do chwili, gdy poproszę kogoś o pomoc . Prawie zawsze staram się samodzielnie rozwiązywać problemy przez co najmniej godzinę.

Czy to jest za krótkie? Ile czasu poświęcić na rozwiązywanie problemu przed zapytaniem współpracownika, który zna odpowiedź?

Podkreślenie moje.

Na początek tak, jedna godzina to prawdopodobnie za mało czasu. Mówię jednak, że prawdopodobnie ... to naprawdę zależy od problemu. Posiadanie limitu czasu jest dobre, ale powinieneś polegać bardziej na wskaźnikach, że stoisz przed ścianą, niż tylko na limicie czasu. Ale co ważne, kiedy jesteś gotowy do zadawania pytań, odbiorca twoich pytań powinien być w stanie zobaczyć badania, które włożyłeś w swój problem, po prostu przez rodzaj pytania, które zadajesz.

I to jest kiedy dojdziemy do pogrubionej części cytatu. Jesteś technicznie poprawny. Nikt oprócz Ciebie nie może dokładnie wiedzieć, ile czasu poświęcasz na problem, zanim zwrócisz się o pomoc.

Ale w oparciu o to, jakie pytanie zadajesz, jakie informacje podajesz w pytaniu, kontekst pytania i jak łatwo mogę znaleźć odpowiedź za pomocą prostego wyszukiwania w Google, mogę całkiem nieźle oszacować, ile wysiłku włożyłeś w rozwiązanie problemu samodzielnie.

Jeśli zadasz pytanie i pierwsze wyszukiwanie w Google, które próbuję, daje Twoje rozwiązanie jako wynik numer jeden, to w zasadzie dwa ostrzeżenia. Nie ma znaczenia, czy nad tym problemem spędziłeś 10 minut, czy 10 miesięcy. Powinieneś już zapoznać się z tą stroną i albo rozwiązała ona twój problem, albo mówisz mi o tej stronie i dlaczego nie rozwiązała twojego problemu.

Co więcej, jakie pytania zadajesz ? Czy prosisz o bezpośrednie rozwiązania? A może prosisz o mały krok we właściwym kierunku? Czasami ściana, przed którą stoisz, jest taka, że ​​jesteś całkowicie nieświadomy istnienia jakiejś biblioteki lub istniejącej części bazy kodu, która ułatwi rozwiązanie problemu.

Powiedziałbym, że dowiedziałeś się, czego ta firma oczekuje od szkoły ciężkich uderzeń. Pytania w tym miejscu są nie-nie.

Myślę, że Twoim głównym problemem jest widoczność . Wiele osób widzi zadawanie pytań na temat luzu; nawet jeśli nie czują się zmuszeni do odpowiedzi, może to wpłynąć na ich ocenę Ciebie. W międzyczasie, jeśli spędzisz dzień na wymyślaniu jednej funkcji przy biurku, nikt nie zobaczy, że kręci się to koło. Wygląda na to, że robisz coś źle, zamiast po prostu uderzać w klawisze w biurko, co wygląda na pracę. Jasne, być może w przeglądach tygodniowych, miesięcznych lub rocznych Twoja produktywność będzie słabo odzwierciedlona. Ale twoje luźne pytania są wyświetlane wiele razy dziennie, podczas gdy rzeczywista produktywność jest mierzona znacznie rzadziej.

Byłem w sytuacji podobnej do twojej. Zostałem zatrudniony do naprawiania błędów we właściwym CMS, podczas gdy główny (czytaj: tylko) programista próbował jak szalony dodawać funkcje dla klientów. Byliśmy mocno zalegani. Kod źródłowy nie był objęty kontrolą wersji, a każda strona miała swoją własną wersję na zamówienie. To był kompletny bałagan.

Naiwnie, pomyślałem, że lepiej poświęcić 10, 20 lub 30 minut na rozmowę z prowadzącym, aby mógł mi wszystko wyjaśnić, niż spędzać pół dzień, cały dzień, a nawet kilka dni, aby odtworzyć funkcję, aby dowiedzieć się 1. co ma zrobić, 2. jak to miało działać, i 3. jak naprawić błąd.

Okazało się, że kiedy mój szef (jeden z dwóch partnerów) dowiedział się o tym, pomyślał, że słabo pokazało mi, że nie jestem w stanie samodzielnie rozwiązać kodu i że biorę którykolwiek z naszych cenny czas wiodącego dewelopera. (Główny programista wydawał się lubić rozmawiać o tym, jak działa jego baza kodów - w każdym razie nie narzekał na to mojemu szefowi, jak mi powiedział.). Więc przestałem zadawać pytania, a moja produktywność spadła prawdopodobnie do 10%. Zostałem zwolniony około miesiąca później.

W każdym razie ta firma kiepsko wmawia, że ​​nie ceni sobie wydajności czasu i efektu ubocznego dokumentacji. Więc nie rób tego.

Poświęć dzień na próbę rozwiązania problemu. Spędź kilka dni - spędź tydzień! Kogo to obchodzi? Nie ta firma. Cokolwiek robisz, nie zadawaj pytań, ponieważ jest to coś, na czym im zależy . Niezależnie od tego, czy chodzi o kierownictwo, czy narzekanie rówieśników, nie ma to znaczenia. Firma powiedziała ci, jaką kulturę kultywuje.

Jeśli więc pomyślisz o swojej sytuacji, z opieszałością i kiepską jakością kodu, spadek produktywności może być zbyt duży. Zamiast czekać, aż topór spadnie, możesz poszukać miejsca, które lepiej pasuje do Ciebie i Twojego stylu. Na początek miejsce, w którym może są jakieś komentarze do kodu i dokumentacja.

Jak więc skończyła się moja historia? Po okresie bezrobocia dostałem nową pracę. Poza tym, że podstawa kodu jest znacznie lepsza (używamy standardowego CMS w branży, kontrolujemy wersje, mamy środowiska deweloperskie, tymczasowe i produkcyjne itp.), Moi koledzy są znakomici, a moja firma zachęca do nauki. Mamy wiki, gdzie dzielimy się naszymi informacjami i unikamy ponownego wymyślania kół. Cały dzień rozmawiamy na luzie, rozmawiamy o pracy, zadajemy pytania, burzę mózgów, dzielimy się wiadomościami, informacjami i odkryciami. Rozpoczynamy projekty usprawniające nasze procesy, takie jak agile, vagrant oraz wdrażanie ciągłej integracji. Uczymy się nawzajem i uczymy od siebie. Zachowujemy się jak koledzy i współpracownicy; nie konkurenci. Mamy on-boarding i orientację dla nowych pracowników i kontrahentów, których nie moglibyśmy mieć bez tej kultury. To dobrze, ponieważ w czasie, gdy tu byłem, urosliśmy z dwóch (łącznie ze mną) do ośmiu, a także wykonawców w okresach dużego obciążenia.

Nasza firma wysyła nas na szkolenia, konferencje i zachęca do poświęcenia czasu na zajęcia internetowe i castingi. Nauczyłem się tutaj więcej niż w jakimkolwiek innym okresie mojej kariery, szczególnie. w przedmiotach, w których specjalnie nie pracuję. To wspaniałe; Jestem tu od 4,5 roku i nie widzę żadnego powodu, by wyjeżdżać, poza nauką nowej technologii. Kultura w moim nowym miejscu jest naprawdę nastawiona na uczenie się, rozumienie i wdrażanie najlepszych praktyk, co prowadzi do produktywności. Jest to korzystne dla wszystkich.

Poważnie, są lepsze miejsca do pracy. To nie jest miejsce dla ciebie, a ty nie jesteś dla nich osobą.

Jeśli zadajesz pytania niezwiązane z pracą, może to zostać uznane za bezczynną pogawędkę, co jest złą rzeczą w oczach szefów, więc przestań to robić.

Jednak zadawanie pytań związanych z pracą to dobra rzecz, ponieważ pokazuje, że jesteś zainteresowany swoją pracą i chcesz się poprawić.

Jeśli oskarżono Cię o marnowanie czasu innych ludzi, zasugerowałbym, że powinni lepiej zarządzać swoim czasem i powiedzieć Ci są zajęci, zamiast odpowiadać na pytania, kiedy powinni robić inne rzeczy. Jednak bardziej pomocną odpowiedzią byłoby spytanie, czy mają czas odpowiedzieć na pytanie, zanim zadasz to pytanie.

Wydaje mi się, że twój szef jest trochę głupi, czy po prostu chce się go pozbyć z jakiegokolwiek powodu. Oni poniosą porażkę, ponieważ nie dokumentują rzeczy, które są receptą na katastrofę, gdy ich główny programista (e) odejdzie, był tam, robił to.

Rodzaje pytań zawodowych:

1. Jak zrobić coś, czego muszę się nauczyć, aby wykonać tę pracę.

2. Jak zrobić coś, czego muszę się nauczyć, ale już mi powiedziano.

3. Jak zrobić coś, o czym powinienem już wiedzieć.

4. Jak zrobić coś, co jest niezgodne z celem i wiem, że jest to niezgodne z celem.

5. Jak zrobić coś, co nie pasuje do mojej pracy i nie wiem, czy nie jest to cel.

6. Zabawne pytania i pogaduszki.

Więc ...

Możesz poprosić tyle osób nr 1, ile chcesz. Mogą pomyśleć, że jesteś denerwujący, ale jest to dobre / inteligentne irytujące. Nie zostałbyś za to napisany.

Jeśli pytasz numer 2, to myślą, że masz problem ze zrozumieniem. Lub po prostu lubisz zadawać pytania, ale nie słuchać. Jest to do pewnego stopnia znoszone i szybko się starzeje.

W zależności od twojej pozycji i tego, jakie dziwne rzeczy wnosisz do zespołu # 3, mogą być w porządku - dobrze znasz konkretny obszar, jesteś tani , cokolwiek. Jednak lepiej nie pytać # 2s po zadaniu # 3.

Nie ma wątpliwości, że cyfry czwarte nie są dobre. Możesz poprosić o niektóre z nich, ale nie jako nowy pracownik. Współpracownicy spodziewaliby się, że zapytasz # 1 (i niektóre # 2) zanim pomyślisz o # 4. Jeśli zadajesz wiele czwartych punktów, myślą, że jesteś wszędzie.

To jest najgorsze. Wystarczy poprosić o kilka pytań # 5, aby zniechęcić Cię do dowolnego członka zespołu. Oznacza to, że tego nie rozumiesz i prawdopodobnie nie masz na to ochoty.

Hmmm ... # 6 są zależne od osoby. Wiele osób może zapytać mnóstwo szóstek, czy są zabawne, czy śmieszne. Z drugiej strony, jeśli nie jesteś # 6, może być naprawdę źle, szczególnie jeśli pytasz # 2-5.

Jeśli myślisz sobie, dlaczego nie mogą po prostu być dla mnie mili i pomagać mi, jeśli mam problemy i cały czas pytam o punkty 2-5. Ponieważ mogą zatrudnić kogoś, kto wie więcej i nie zadaje głupich pytań. Na twoim miejscu zacząłbym zwracać większą uwagę, może nawet niosąc ze sobą notatnik przez cały czas, a kiedy ktoś na coś odpowie, upewniasz się, że masz 100% pewności, że to dostaniesz lub poprosisz o wyjaśnienie na miejscu.

Ta odpowiedź dotyczy tego, jak przyjmować informacje zwrotne (inne odpowiedzi już obejmują, jak bardzo dobrze zadawać pytania).

Chociaż zostałem również skarcony za „pójście złą ścieżką”, aby rozwiązać problem, którego nie znałem, zamiast zapytać kogoś, kto był. Kiedy zapytałem o sprzeczność, mój menedżer i dział HR powiedzieli, że muszę po prostu lepiej ocenić, kiedy zadawać pytania. Nigdy nie zdawałem sobie sprawy, że zadawanie pytań może być tak niebezpieczne.

To była zła reakcja z Twojej strony. Wyobraź sobie przez chwilę siebie na swoim miejscu. Wiesz, że niektórzy pracownicy radzą sobie słabo i mówisz im, co powinni poprawić. Nie zawracając sobie głowy myśleniem o tym, co im mówisz, nie okazując zainteresowania Twoją opinią, nie mówiąc już o przeprosinach za niespełnienie oczekiwań, pracownik ten błędnie twierdzi, że sobie zaprzeczasz.

Otrzymując informację zwrotną, w szczególności negatywną, należy najpierw jej wysłuchać, następnie starać się ją zrozumieć (w razie potrzeby zadawać wyjaśniające pytania), a dopiero następnie odpowiedzieć.

Dzieje się tak, ponieważ ty i twój szef nie jesteście zgodni co do tego, czy coś nam nie wyszło. Albo twój szef się myli, albo ty (lub oboje). Powinieneś rozważyć możliwość, że możesz to być ty, ponieważ jest bardzo mało prawdopodobne, że twój szef się całkowicie myli, a ty masz całkowitą rację - a nawet jeśli tak, możesz tylko przekonać szefa, że ​​się myli, pokazując mu gdzie się myli, a to też wymaga wysłuchania go.

Możesz również poprosić o radę, jak możesz zrobić coś lepszego.

Na przykład po wysłuchaniu że zadajesz zarówno za dużo, jak i za mało pytań, być może zadałeś:

Zadałem więc oba niepotrzebne pytania i nie udało mi się zadać niezbędnych pytań. Jak mam określić, które pytania są potrzebne? To znaczy, jakiego rodzaju pytań powinienem zadawać więcej, a jakich mniej?

Poniższa dyskusja na temat faktów prawdopodobnie ujawniłaby, co musisz zrobić w celu poprawienia.

Czy to normalne? Czy nowa osoba w firmie nie powinna być ciekawa lub zadawać pytania niezwiązane bezpośrednio z jej pracą?

W jakim stopniu zadawanie pytań jest oczekiwane lub pożądane, różni się w poszczególnych miejscach pracy. Możesz chcieć dostosować się do kultury swojego miejsca pracy, którą możesz odkryć, obserwując swoich rówieśników, zwracając uwagę na to, jak ludzie reagują na Twoje działania (czy są zirytowani Twoimi pytaniami lub zachwyceni?), Lub poprosić o ich opinię („Czy mogłem o to zapytać?”).

Myślę, że jeśli jesteś młody jak ja, myślisz, że musisz oszczędzić czas i znaleźć odpowiedź, a następnie przejść do następnego problemu. Jednak uważam, że starsze pokolenia nie są dla nich problemem ani priorytetem. Więc tak, poświęcenie godziny na rozwiązanie problemu jest zbyt krótkie dla kogoś starszego, jednak może wydawać się zbyt długie. Proponuję obserwować lukę pokoleniową i podążać za tym przykładem, nawet jeśli się nie zgadzasz. W końcu będziesz szybciej rozwiązywać problemy z większym doświadczeniem.

Jeśli chodzi o kłopoty z zadawaniem pytań, staram się wykorzystać wyjaśnienie, że chcę zobaczyć, jak należy to zrobić, lub postępować zgodnie ze standardami firmy. Ponownie zauważyłem, że u starszych pokoleń jest to z jakiegoś powodu irytujące. Myślę, że starsi ludzie mają skłonność do myślenia, że ​​rozwiązałem to sam i nie otrzymałem żadnej pomocy, więc są mniej chętni do pomocy. Oni również czują się przerwani. Tak jak ktoś wspomniany powyżej, spróbuj znaleźć odpowiedni czas, aby poprosić o pomoc, jednocześnie głaszcząc ego, tj. „Słyszałem, że byłeś tym facetem, do którego należało się zająć…” „Ktoś powiedział, że jesteś ekspertem… „miejmy nadzieję, że to sprawi, że przeoczą przeszkodę i będą bardziej skłonni do pomocy, ponieważ dałeś im coś do udowodnienia. Uważaj na tę ostatnią radę, ponieważ jestem pewien, że w niektórych przypadkach może przynieść odwrotny skutek.

Trudno mi to dokładnie zdefiniować, ale pracowałem z kilkoma młodszymi programistami i niektórzy z nich zadawali pytania, na które odpowiedź była bardzo satysfakcjonująca, a niektórzy nie. Odpowiadanie na pytania odwraca uwagę współpracowników od ich pracy i to jest w porządku, jeśli wyjdzie z tego coś dobrego, a firma odniesie korzyści w dłuższej perspektywie. Oznacza to, że musisz zadać odpowiednią osobę, zadać właściwe pytanie i dotrzeć do miejsca, w którym osiągnąłeś zrozumienie, które pozwoli Ci dokonać znaczących postępów. Jeśli masz do tego talent, ludzie poczują, że czas spędzony na pomaganiu Ci jest dobrze spędzonym czasem, a Ty jesteś cennym współpracownikiem. Jeśli nie, zamiast tego mogą cię denerwować.

Oczywiście, jeśli jest wiele rzeczy, których nie wiesz, stawia cię to w delikatnej sytuacji, ale nastawienie i umiejętności mają duże znaczenie. Nikt nie oczekuje, że będziesz wiedział wszystko, ale zależy im, jak sobie z tym poradzisz. Inni tutaj omówili już, co możesz zrobić, aby uzyskać jak największy zwrot z grosza, gdy zaszufladkujesz starszego programistę, więc nie powtórzę ich rady; Po prostu próbuję rzucić trochę światła na uczucia Twoich współpracowników, które doprowadziły do ​​tej sytuacji, abyś mógł to zrozumieć i uniknąć w przyszłości.

Jest to raczej sugestia dla twojego pracodawcy, ale być może mógłbyś sprawić, by zadziałała dla ciebie.

Czy na początku przydzielili ci mentora? Dobrym pomysłem jest powierzenie nowemu pracownikowi przypisanego mentora, kogoś, do kogo może zwrócić się ze swoimi pytaniami. To daje im kogoś już doświadczonego w firmie i zapobiega ciągłemu niepokojeniu wszystkich innych. :-)

Mentor będzie również wiedział, do jakich osób należy pytać i gdzie szukać takich rzeczy, jak dokumentacja. Na przykład, niektóre projekty mogą mieć dokumenty Google Doc, inne mają je na wewnętrznym serwerze plików, a trzeci ma je zatwierdzone w repozytorium źródłowym. Podczas gdy inne projekty w ogóle nie mają żadnych dokumentów.

Inną wskazówką jest to, że rozpoczynając pracę nad nowym projektem, poproś o wycieczkę. Solidny blok czterech godzin spędzonych z tobą i doświadczoną osobą może przyspieszyć Cię bez potrzeby tych czterech godzin, ponieważ przerwy rozłożone są na kilka miesięcy.

Jedna rzecz do zapamiętania: kod jest jak gramatyka. Ludzie mogą wiedzieć, że są do niczego, ale nie lubią, gdy im o tym mówi. Na przykład, gdybym zwrócił uwagę, że wielokrotnie błędnie zapisałeś „wyrok”, możesz być zirytowany, ponieważ tak naprawdę nie dodam niczego konstruktywnego. Cóż, i tak to zrobiłem :)

Ale w połączeniu z faktem, że wielu doświadczonych programistów ma skłonność do przyjmowania postawy diwy. To, co zamierzasz jako szczere pytania zakorzenione w logice, może być dla nich bardzo groźne. Pracowałem z niezliczonymi przykładami (i sam mogę nim być), które utrzymywały ten sam stary, kiepski kod, który nie był istotny od 15 lat. Wiedzą, że obecnie jest lepszy sposób na zrobienie tego, ale nie mają zainteresowania ani motywacji do uczenia się nowych rzeczy, więc sama Twoja obecność jako następnego pokolenia jest dla nich zagrożeniem. Kiedy wykonają akt prima donna, po prostu śmiej się z siebie i pamiętaj, że jesteś tym, który ma prawdziwą moc - masz przed sobą wiele lat, aby pracować z technologią przyszłości i ostatecznym kierunkiem, w którym podąża Twoja kariera wciąż jest w twoich rękach. Zwykle nie dotyczy to doświadczonych snobów.

Zgadzam się z innymi, którzy wspomnieli, że to nie brzmi jak dobry inkubator dla początkujących programistów. Jednak jest to powszechne. Potrzeba czasu i doświadczenia, aby zidentyfikować swoją niszę, znaleźć odpowiedniego pracodawcę i określić, co jest dla Ciebie najważniejsze. Więc spłacaj tam swoje składki, weź swoje bryły, zaplanuj swoją karierę i wyjdź po kilku latach solidnej pracy. Na razie po prostu skorzystaj z porady, co jest warte, nie martw się o PIP i przypominaj sobie, że twoja obecna sytuacja jest tylko środkiem do końca. Twoi przełożeni oczekują, że będziesz przychodzić i wychodzić na czas, tak jakbyś pracował w Wendy's. Nie tak musi być, nawet w przypadku niedoświadczonych nowych programistów, więc gdzie indziej może być o wiele jaśniejsza przyszłość.

Próbowałem im powiedzieć dokładnie to, co wam powiedziałem. Po prostu się na mnie wściekli, że kłóciłem się z nimi „zębami i pazurami” i nie przyjmowałem dobrze ich rad. Powiedziałem, że chciałem tylko wyrazić swój punkt widzenia… byli bardziej zirytowani.

Myślę, że mogę wyjaśnić, dlaczego byli zirytowani: po prostu nie chcą informacji zwrotnych. Twój menedżer nie zaprosił Cię do wyrażenia opinii, powiedział po prostu, stosując ten plan „potrzebnych ulepszeń”, że masz złe zachowanie i musisz je naprawić „dla własnego dobra”.

Kto decyduje, czym jest złe zachowanie? Tylko ludzie, którzy ci płacą i mogą cię zwolnić. Kiedy krytykujesz ich decyzje, denerwują się, ponieważ płacą ci za wykonywanie ich rozkazów, a nie kwestionowanie ich rozkazów. Nie są „bezstronnymi sędziami”, to oni ci płacą. A jeśli skrytykujesz ich w momencie, gdy dadzą ci poważne i formalne ostrzeżenie „zmień się lub wyjdź” (to, co nazywają „radą dotyczącą poprawy”), może to doprowadzić ich do wniosku, że nie masz odkupienia.