Postaram się odpowiedzieć z perspektywy firmy. Nie jestem tą firmą, więc mogą być rzeczy, których nie widzę, ale widziałem to już wcześniej w mojej własnej firmie.
Zbyt wiele pytań
Większość twojego zamieszania wydaje się wynikać z faktu, że nie rozumiesz, że zadawanie pytań jest niebezpieczną grą. To jest!!!
Kiedy zadajesz pytanie, przyznajesz się, że nic nie wiesz, **i że nie możesz tego zrozumieć. Jako twórca oprogramowania, jednym z twoich zadań jest rozgryzienie tego. Obrażasz “obecny” zespół devów pytając: “Więc napisałeś tu taki gówniany kod, że nie mogę się dowiedzieć jak go przeczytać, ani co robi, więc musisz mi to wyjaśnić”
Teraz najtrudniejsze jest to, że czasami tak właśnie jest i powinieneś zadawać pytania. Ważne jest tylko, aby pamiętać, że bez względu na wszystko, istnieje negatywna strona tych pytań.
Kolejną rzeczą, którą myślę, że wyczuwam w twoim programie operacyjnym, jest to, że zadajesz pytania o wiele za wcześnie. Jest absolutnie w porządku, żeby nowy programista siedział tam czytając i badając przez cały dzień, żeby napisać 2 linie kodu. W rzeczywistości, z 14-letnim doświadczeniem, wciąż to robię. W pisaniu profesjonalnego kodu nie chodzi o to, “ile” jest zrobione, ale o to, “jak dobrze” jest zrobione, i o to, że można powtórzyć ten sukces. Wątpię, żeby ktokolwiek się na ciebie uwziął, że robienie dziesiątej części pracy jako wyszkolony i uznany programista zajmuje 100 razy więcej czasu. W rzeczywistości, kiedy kogoś zatrudniam, odpisuję pierwszy miesiąc jako nie spodziewający się żadnej prawdziwej pracy, a pierwsze sześć miesięcy jako nie spodziewający się wiele.
Nie spędzasz wystarczająco dużo czasu sam
To jest biggie!!!!! Kiedy prosisz członka zespołu o pomoc, zmniejszasz również jego wydajność. Wywierasz wpływ na ich proces i jednocześnie obrażasz ich (patrz wyżej). Nie ma możliwości, abyś wygrał, jeśli będziesz musiał poprosić o pomoc. Pomyśl o każdej prośbie, jako o przegranej walce. Wciąż możesz wygrać wojnę, ale przegrałeś tę walkę.
Jest kilka rzeczy, które możesz zrobić, aby złagodzić ten problem:
- Pytaj w mailu, nigdy osobiście ani na czacie. Czat może być preferowanym sposobem, aby zrobić to “oficjalnie”, ale e-mail jest milszy, ponieważ odbiorca może poradzić sobie z nim w swoim czasie.
- Podejdź do niego z “niższej” pozycji. Ty jesteś tu petentem. Zrób trochę grymasienia. W porządku. Trochę ci nie zaszkodzi i pokaże odbiornikowi, że zależy ci na jego czasie, tzn. Kiedy dostaniesz kilka chwil, możesz mi pokazać, czego mi brakuje?“ To pokazuje, że jesteś w błędzie, nie oni. To ważne.
- Wymień kroki, które podjąłeś na własną rękę. "Dokument API mówi, aby przejść w sznurku reprezentującym identyfikator użytkownika. Próbowałem przekazać własność user.id i nazwę użytkownika, ale nie zadziałało.” To pokazuje, że przynajmniej próbowałeś czegoś, i ogólnie rzecz biorąc, zaczynasz “dostawać” produkt.
Bardziej wiarygodny osąd Przy zadawaniu pytań
To, dla mnie, brzmi jak “jęczenie” kogoś, i nie miał miłego sposobu na powiedzenie, “Denerwujesz wszystkich swoimi kiepskimi pytaniami. Przestań!” Inaczej mówiąc, myślę, że to nie jest sprawa. Kiedy poprawisz swoje inne sprawy, to zniknie.
Dokumentacja błędu
Ahem! To kolejna osobista zniewaga. Nigdy tego nie mów. NIGDY!!!!! Po raz kolejny mówisz, że jakość ich kodu jest tak słaba, że nie możesz tego zrozumieć. Ich odpowiedzią zawsze będzie “działa dla każdego innego, więc ty musisz być idiotą, nie ja!”
Również, to jest trochę “witaj w prawdziwym świecie”. W prawdziwym świecie klienci płacą za pracujące aplikacje, a nie za kod czy dokumentację (przez większość czasu), więc bardzo często zdarza się, że dokumentacja ulega degradacji w czasie.
Jeśli uważasz, że dokumentacja jest słaba i wymaga naprawy, to po cichu wspomnij o tym swojemu zespołowi. Niech oni zdecydują.
Powiem to jednak. Nieważne jak kiepska jest ta dokumentacja, z kodem źródłowym tuż przed Tobą, nie powinieneś jej potrzebować. To naprawdę miło mieć, nie zrozum mnie źle, ale ty _możesz pracować bez niego.
Being Late
Oczywiście, nie spóźnij się. To nie ma sensu. Właściwie to w twojej sytuacji teraz, bądź 30 minut. Wcześnie! Żadnych wymówek. Niszczysz każdą nadzieję na znalezienie następnej pracy z tym. Gdybym zadzwonił tam do działu kadr i zapytał o twoją obecność, a oni powiedzieliby: “Często się spóźniał” albo “Był pisany za spóźnienie”, to byłaby to natychmiastowa czerwona flaga. Wspominam o tym, ponieważ bez względu na to, czy utrzymasz tę pracę, czy zdobędziesz nową, to bardziej niż cokolwiek innego powstrzyma Cię przed znalezieniem następnej pracy.
Kod niskiej jakości
To prawdopodobnie prawda. Biorąc pod uwagę problem z pytaniem, prawdopodobnie nie piszesz dobrego kodu. Jesteś jednak nowy, a tego należy się spodziewać. Uważam, że uczelnie nie uczą o cholernej rzeczy o prawdziwe kodowanie świata. Nigdy nie zatrudniłem kogoś prosto z college'u i nie dostałem “dobrego programisty”. To nie znaczy, że nie byli dobrymi programistami. Oni po prostu nie zaczynają w ten sposób. Pisanie dobrego kodu oznacza bycie na bieżąco z najnowszymi trendami i technikami. Ciągle się uczysz. Moment, w którym się zatrzymujesz jest momentem, w którym zaczynasz ssać.
W podsumowaniu
Ten post był szorstki, ale chciałem pokazać, jasno, jaka może być postawa firmy. Często zdarza się, że oni (firmy) zawijają swoje komentarze w tak wiele “wypowiedzi menedżerów”, że może być to trudne do zrozumienia. Starałem się ograniczyć wypowiedzi menadżerów na tym stanowisku tak bardzo, jak tylko mogłem, ale to oznacza, że jest ono nieco szorstkie.
Twoje najważniejsze kroki, aby naprawić swoją upadającą karierę:
- POKAŻ SIĘ DO PRACY WCZEŚNIE!!!! (Nie mogę tego wystarczająco podkreślić)
- Zadawaj pytania z nastawieniem, że już obrażasz osobę, którą pytasz.
- Pokaż swoją pracę. Zadając pytanie powiedz wyraźnie, co już zrobiłeś.
- Spędzaj więcej czasu na samodzielnej nauce. Ważne jest, aby spędzać znacznie więcej czasu na badaniu rzeczy niż na zadawaniu pytań. Szczerze mówiąc, 3-4 dni szukania czegoś na własną rękę, będzie bardziej szanowane niż 30 sekundowe pytanie.