Pytanie:
Problemy młodszego programisty: jak komunikować się z kierownictwem?
Michel12
2019-04-30 01:40:24 UTC
view on stackexchange narkive permalink

Uczyłem się programowania w domu i byłem genialnym absolwentem bootcampu (to znaczy według standardów tego bootcampu, który z pewnością nie jest tak dobry jak topowe bootcampy w USA *), dość łatwo znalazłem pracę, biorąc pod uwagę, jak ciężko to myślę powinien był być. Wywiad poszedł naprawdę dobrze.

Teraz pracuję dla firmy technologicznej, która w zasadzie ma jedno główne oprogramowanie, które pisze dla innych bardzo dużych firm, i stwarza to kilka wyzwań: 1) trudno mi zrozumieć, co wszystko działa (piszą / aktualizują to oprogramowanie od lat), 2) widzę kod napisany w sposób, do którego nie jestem przyzwyczajony, i wreszcie 3) nie rozumiem całego kodu na pierwszy rzut oka, czasami wcale. Moim głównym zadaniem na najbliższe 6 miesięcy będzie pisanie testów jednostkowych, a następnie testów integracyjnych, ponieważ „trzeba się przyzwyczaić do naszego oprogramowania”, co moim zdaniem ma sens, chociaż moja rozmowa nie miała z tym nic wspólnego. Większość ludzi jest naprawdę miła i przyjazna, a atmosfera w tej firmie jest bardzo dobra.

Mój problem polega na tym, że muszę pisać testy dla metod, których przez większość czasu nie rozumiem, nie zawsze rozumiem, jakie parametry muszą przyjąć, jakie zwracają, nie wiem wiem, z czego mam kpić, aby moja metoda była testowalna jednostkowo, i nie zawsze rozumiem otrzymane instrukcje. Po dwóch tygodniach mogę z całą pewnością stwierdzić, że najwyraźniej nie stworzyłem wartości dla tej firmy, a inni programiści, którzy mi pomogli, mogli wykonywać swoją pracę zamiast spędzać ze mną czas.

Jestem dość sfrustrowany, ponieważ jestem dość głodny nauki, jednak to nie oglądanie filmów w Pluralsight / czytanie artykułów pozwoli mi lepiej radzić sobie z wyzwaniami (a może się mylę?), więc nie mogę nawet ćwiczyć w domu. Myślę, że zawstydzam się za każdym razem, gdy zadaję pytanie, więc często utknę, wpatrując się w ekran i próbując zrozumieć, co czytam. Czuję się jak oszust otoczony ludźmi, którzy to „rozumieją”, i szczerze mówiąc, moja pewność siebie mocno ucierpiała (z prawdopodobnie najlepszego w swojej klasie stałem się zdecydowanie najgorszym w firmie). W złych chwilach czasami łapię się na tym, że zastanawiam się, czy zajęcie się tworzeniem oprogramowania było dobrym pomysłem i czy nie jestem ofiarą błędu utopionych kosztów (na przykład „Spędziłem zbyt dużo czasu, ucząc się tego, żeby teraz rzucić palenie”).

Moje pytania:

  1. Czy to normalne?

  2. Co mogę zrobić lepiej?

  3. Jak mogę to wyrazić (lub jego część) kierownictwu i współpracownikom, nie dając się oszukać?

Edytuj:

Pracowałem tam tylko 2 tygodnie, to moja trzecia praca. Poprzednie prace trwały 7 miesięcy. & 1,5 roku.

* Nie było jasne i nie chciałem wyglądać na aroganckiego; Nie sądzę, żeby ten bootcamp był wyjątkowy, więc bycie w nim genialnym prawdopodobnie nie oznacza wiele na rynku pracy, w przeciwieństwie do czołówki amerykańskiego bootcampu. Ten bootcamp ma siedzibę w Europie i powiedziałbym, że jest średni. Co więcej, uważam, że głównym powodem, dla którego odniosłem sukces, był fakt, że uczyłem się programowania przez 1 rok, a ludzie obok mnie nie mieli pojęcia, czym jest `` zmienna '', więc miałem ogromną przewagę i ogólnie było to znacznie mniej przytłaczające niż dla moich kolegów.

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (https://chat.stackexchange.com/rooms/93055/discussion-on-question-by-michel12-junior-developer-struggles-how-to-communicat).
Aby wyjaśnić, Twoje wcześniejsze prace nie były związane z technologią / programowaniem?
Cześć @Michel12 Pisanie testów to świetny sposób na zrozumienie kodu i dodanie wartości do bazy kodu, której nie znasz.Dzięki temu poznasz różne sposoby pisania kodu przez ludzi w Twojej firmie.Robisz i myślisz to samo, co my wszyscy.:)
Chcę tylko wtrącić się i powiedzieć, że są to zmagania, z którymi boryka się każdy młodszy programista w każdej dużej organizacji.To jest tak powszechne.Po prostu dław się i bądź pozytywny i intelektualnie uczciwy, a wszystko będzie dobrze.
Wiem, jak się czujesz.Jestem programistą od niespełna 2 lat, w dużym zespole nad starym produktem i są dwie rzeczy, które powiedzieli mi ludzie z tego zespołu. Po pierwsze, jeśli czujesz, że nie dajesz wystarczająco dużo: „W dużym zespole, przy starym produkcie, spodziewamy się, że będziesz tracić czas na zadawanie pytań i nie oczekujemy, że będziesz mieć netto wkładu w zespole, dopóki nie będziesz tu przez około 3 lata” A jeśli kiedykolwiek martwisz się o zawstydzenie siebie zadając pytania: „Jeśli nie zadajesz pytań, zakładamy, że nie pracujesz”. Wstydzasz się, jeśli tego nie robisz, więc pytaj :)
Wygląda na to, że masz przypadek zespołu oszusta https://en.wikipedia.org/wiki/Impostor_syndrome.Witaj w zawodzie, a bardziej będziesz w tej dziedzinie, przyzwyczaisz się, że b / c ten zawód rozwija się bardzo szybko.Nie zamykaj się, jeśli nie rozumiesz kodu: poproś innych programistów, aby byli chętni do pomocy (tak, ludzie piszą podstępny kod).Jeśli nie rozumiesz, dlaczego dzieje się w ten sposób, możesz porozmawiać z ludźmi biznesu, aby wyjaśnili ci, co jest z perspektywy świata rzeczywistego.W ten sposób możesz przyspieszyć działanie.
Osiem odpowiedzi:
dan.m was user2321368
2019-04-30 02:42:29 UTC
view on stackexchange narkive permalink

Po dwóch tygodniach mogę z całą pewnością stwierdzić, że najwyraźniej nie stworzyłem wartości dla tej firmy i innych programistów, którzy mi pomogli, mogłem wykonać swoją pracę zamiast spędzać ze mną czas.

Nie będziesz tworzyć „dodatniej wartości netto” dla firmy znacznie dłużej (nawet jeśli zatrudniam starszych programistów, zakładam, że nie są one dodatnie netto przez 6 miesięcy).

Wszystko, o czym wspomniałeś w swoim pytaniu, to w rzeczywistości dobre znaki - wygląda na to, że tworzą interesujące i nietrywialne oprogramowanie, co oznacza, że ​​masz wiele okazji do nauki, a to oznacza, że ​​inwestują w Ciebie - dając Ci czas i przestrzeń, aby przyspieszyć.

Pisanie testów jednostkowych i testów integracyjnych jest dość powszechnym sposobem wdrażania nowych młodszych pracowników. Poznasz IDE, system kontroli źródła, proces kompilacji i wszystkie różne formalne i nieformalne przepływy pracy związane z tworzeniem oprogramowania, koncentrując się na stosunkowo niewielkich fragmentach pracy. Dowiesz się również dużo o funkcjach biznesowych, jakie zapewnia ich oprogramowanie.

1 - Czy to normalne?

Tak. Nie jesteś oszustem i nie ma powodu, by sądzić, że wejście w tę dziedzinę było złym pomysłem. Właściwie z tego, że cię zatrudnili i chcą w ciebie zainwestować, wydaje się, że to był dobry pomysł. Najważniejszą rzeczą jest przezwyciężenie naiwnego przekonania, że ​​tylko dlatego, że byłeś „prawdopodobnie najlepszy” na swoim obozie, oznaczało to, że byłeś przygotowany na wejście do sklepu deweloperskiego pierwszego dnia i rozpoczęcie tworzenia wartości. Kurs zapewnił Ci podstawowe podstawy programowania - bycie profesjonalnym programistą to dużo, dużo więcej, czego możesz się nauczyć tylko w pracy.

2 - Co można Robię lepiej?

Myślę, że są w tym dwa „zakresy”. Pierwsza to rzeczy, które możesz zrobić samodzielnie. Zainwestuj swój własny czas w naukę języka, w którym programujesz - drobne punkty, zaawansowane funkcje itp. Nawet jeśli kurs był w tym samym języku, nad którym teraz pracujesz, jest wiele do nauczenia się (byłem programowanie w tym samym języku podstawowym przez ponad 10 lat i wciąż uczę się nowych rzeczy każdego dnia). Jeśli którekolwiek z innych używanych przez nich narzędzi jest publicznie / bezpłatnie dostępne (IDE, narzędzie do kontroli źródła), przećwicz je również. Poświęć również czas na naukę podstaw informatyki (algorytmy, struktury danych). Nawet jeśli nie wykorzystasz tej wiedzy od razu, zawsze okaże się pomocna.

Druga, choć nie jest ściśle związana z testami, które przeprowadzasz, może być wykonana jako część tej pracy. Ma to na celu rozwinięcie umiejętności „analizowania” fragmentu kodu. Wykonaj najprostszy test, jaki możesz znaleźć, testując najprostszy fragment kodu i spróbuj określić przepływ kontroli tego fragmentu kodu. Uruchom go przez debugger, zatrzymując się w każdej linii i zobacz, co faktycznie robi. Zmodyfikuj nieco test i zobacz, jak zachowuje się inaczej. Spróbuj wymyślić test, który przetestuje inną gałąź if (itp.). Użyj narzędzia do kontroli źródła IDE i spójrz na najnowsze zatwierdzenie, które zmieniło ten kod. Sprawdź, czy możesz zrozumieć, co spowodowała ta zmiana (szczególnie przydatne, jeśli możesz podać link do zgłoszenia, które dokumentuje tę zmianę). Przejdź do nieco bardziej złożonego testu i powtórz. Teraz weź fragment kodu, który chcesz, abyś przetestował, i przeprowadź wcześniej analizę. Użyj tego, aby napisać swój pierwszy test.

Jeśli potrzebujesz pomocy, poproś autora testu lub kodu, którego szukasz, o przedstawienie przeglądu.

3 - Jak mogę to wyrazić (lub jego część) kierownictwu i współpracownikom, nie dając się zwieść?

Nikt się nie rodzi, kto wie, jak programować. Dlatego twoi koledzy i menedżerowie zaczynali w podobnym miejscu jak ty. O ile nie są palantami (a ty już powiedziałeś, że nie są), wiedzą i oczekują, że poprosisz ich o pomoc.

Oczywiście musisz znaleźć odpowiednią równowagę między zadawać zbyt wiele pytań i nie prosić o pomoc wystarczająco wcześnie. Często mówiłem moim juniorom "nie trać 3 godzin na wymyślanie czegoś, w czym mogę ci pomóc w 5 minut". I odwrotnie, nie marnuj moich 5 minut, jeśli nie spędziłeś trochę czasu na próbach samodzielnego rozwiązania.

Jeśli jeszcze nie masz zaplanowanego, poproś swojego kierownika o cotygodniowe 30 minutowe spotkanie. Cytując inną odpowiedź, którą napisałem tutaj:

zadaniem twojego kierownika jest [to] zrobienie wszystkiego, co w jego mocy, aby dać ci szansę odniesienia sukcesu - może się to zdarzyć tylko wtedy, gdy oboje macie regularne i częste rozmowy, a jeśli podczas tych rozmów jesteś otwarty i szczery co do tego, gdzie masz trudności, gdzie potrzebujesz wsparcia, gdzie utkniesz i gdzie dowiadujesz się, czego oczekuje od ciebie.

Jedną z najważniejszych rzeczy, o które należy zapytać, jest „od czego zacząć” i „kogo powinienem zawracać sobie głowę pomocą”

Powodzenia!

FWIW, jedną z najlepszych sugestii w tej wspaniałej odpowiedzi jest użycie debugera.Nie ma innego sposobu, aby naprawdę wyczuć fragment kodu, niż uruchomić go, ustawić kilka punktów przerwania i przejść przez kod, w głąb wnętrzności, patrząc na zmienne, obserwując zmiany.Na początku będzie to przytłaczające, ale jeśli będziesz się go trzymać, zrozumiesz kod znacznie głębiej niż nawet pierwotni autorzy.Pamiętasz, napisanie tego kodu zajęło LATA, a obawiasz się, że nie dostaniesz go po dwóch tygodniach?Daj sobie spokój.
+1.Sugerowałbym również, że jeśli jeszcze tego nie zrobiłeś, poświęć trochę czasu na dokładne zapoznanie się z jakimkolwiek systemem kontroli źródła używanym w firmie.Możesz nawet założyć własne repozytorium i walczyć z jego uruchomieniem.Wiem, że kiedy zaczynałem pracę w swojej firmie, nie miałem żadnego doświadczenia z kontrolą źródła ani jej nie rozumiałem, a nabranie pewności siebie zajęło mi dłuugo czasu.To zaufanie przyszło tylko dlatego, że nauczyłem się (metodą prób i błędów oraz wielu wyszukiwań w Google), co mogę, a czego nie mogę zrobić z naszym systemem kontroli źródła i co psuje.
** Najważniejsza ** część tej odpowiedzi: „Jedną z najważniejszych rzeczy, o które należy zapytać, jest„ od czego zacząć ”i„ kogo mam zawracać sobie głowę pomocą ”„.
Joe Strazzere
2019-04-30 01:59:38 UTC
view on stackexchange narkive permalink

Pracowałem tam tylko 2 tygodnie

Musisz poświęcić dużo więcej niż 2 tygodnie.

  • Każdy trochę się czuje przytłoczony, gdy początkowo rozpoczynają pracę programistyczną.
  • Twoje pierwsze kilka tygodni / miesięcy będzie wymagało oduczenia się wielu rzeczy, których uczono Cię w szkole / bootcampie i nauczenia się, jak wygląda prawdziwa praca z oprogramowaniem. > Na pierwszy rzut oka nikt nie rozumie całego kodu. Czasami istniejący kod jest słabo komentowany i nieczytelny dla wszystkich poza oryginalnym autorem.

Rób rzeczy stopniowo. Prawie na pewno przekonasz się, że każdy tydzień jest nieco wygodniejszy niż poprzedni.

Skorzystaj z miłej i przyjaznej kultury. Poproś o pomoc, kiedy jej potrzebujesz.

I nie bądź dla siebie taki surowy. Jeśli nauczyłeś się programowania samodzielnie, a potem byłeś genialny na bootcampie, najprawdopodobniej wystarczy trochę cierpliwości i ciężkiej pracy.

W moim najlepszym wydaniu (lata i lata mojej kariery) zajęło co najmniej miesiąc, zanim zacząłem faktycznie tworzyć materialne materiały, które przyniosły korzyści projektowi.Nie ma się czym martwić o dwa tygodnie.Jedyny raz, kiedy poszło mi lepiej, to kiedy właśnie wyszedłem z projektu, który był materialnie identyczny (te same narzędzia i podobne zadania) z tym, do którego przystępowałem z nową firmą.W tym przypadku nie znałem zbyt wiele podstawy kodu, ale znałem najlepsze praktyki lepiej niż istniejący zespół i mogłem wnieść swój wkład na tym poziomie.
Ta odpowiedź była również moją intuicją.I to nie tylko programowanie.Każda praca w jakiejkolwiek dziedzinie, poza pracą niewykwalifikowaną, będzie wymagać pewnego stopnia onboardingu.Pracodawca nie oczekuje, że wejdziesz do drzwi i dodasz wartość kilka minut później, wie, że zajmie ci to tygodnie / miesiące, zanim zaczniesz działać - kosztem.I, co ważne, (przynajmniej dla poczucia własnej wartości) ** fakt, że Cię zatrudnili, oznacza, że są skłonni dokonać tej inwestycji. **
„Nikt na pierwszy rzut oka nie rozumie całego kodu. Czasami istniejący kod jest słabo komentowany i nieczytelny dla wszystkich z wyjątkiem oryginalnego autora”.jeśli masz szczęście, jeśli nikt nie może tego zrozumieć, są szanse, że autor też nie może po jakimś czasie
Czasami kod jest tak przerażający, że _ nikt_ go nie rozumie.(Patrzy na swój kod z przeszłości, wzdryga się). Jeśli tam wejdziesz i go odszyfrujesz, dodasz _istotną_ wartość do firmy!
Keith
2019-04-30 01:59:26 UTC
view on stackexchange narkive permalink

Witamy w dżungli. :)

Tak. To normalne. Jesteś młodszy. Oczekuje się, że nie będziesz miał pojęcia i dlatego każą ci robić to, co robisz.

Zadawaj pytania. Zrozum. Zapytaj, co możesz przeczytać w wolnym czasie, aby pomóc ci w zrozumieniu. Bądź gotów ciężko pracować, nawet spędzając kilka godzin poza pracą. Martwiłbym się młodszym programistą, który NIE zadawał pytań. Założę się, że każdy z twoich współpracowników, którzy są seniorami, zaczynał tak, jak ty.

Zadawaj pytania i ucz się. Z czasem nie będziesz musiał zadawać pytań. Po prostu kliknie i dostaniesz.

Rób notatki także, gdy otrzymasz odpowiedź.
@Jay To najważniejsza rada.Zawsze chętnie pomogę w każdym problemie * raz *.Zadaj mi to samo pytanie po raz drugi, a otrzymasz (mentalne) punkty minus.Dodatkowe pytania są rzeczywiście mile widziane.
Stig Hemmer
2019-04-30 13:55:59 UTC
view on stackexchange narkive permalink

Jak wszyscy mówią, dwa tygodnie to nic. Zajmie ci to znacznie więcej czasu, aby przyspieszyć. Twój kierownik i koledzy tego oczekują.

Chciałbym chwycić jedno zdanie do skomentowania:

Mój problem polega na tym, że muszę napisać testy metod, których nie stosuję przez większość czasu nie rozumiem, nie zawsze rozumiem, jakie parametry muszą przyjąć, jakie zwracają, ...

Jak widzę, jest to błąd dokumentacja . Co jest również strasznie powszechne. W idealnym świecie powinien istnieć opis wszystkiego, co jest dostępne, ale bardzo często go nie ma.

Więc pierwszym pytaniem powinno być, jeśli przegapiłeś jakąś dokumentację. Najbardziej prawdopodobna odpowiedź brzmi „nie”, ale warto ją zapytać.

Sugerowałbym napisanie tej dokumentacji przed wykonaniem testów jednostkowych. Dzięki temu można zapytać „czy poprawnie zrozumiałem cel tej funkcji?” Sama dokumentacja będzie cenna dla firmy, a testy jednostkowe z większym prawdopodobieństwem przetestują to, co powinny.

Zebranie się na odwagę, by przerwać zajętemu koledze pytanie, które jest prawdopodobnie trywialne. Jak powinno być, przerwy są do dupy.

Zamiast tego powinieneś zaplanować spotkanie. W ten sposób jest to tylko jedna przerwa zamiast wielu. Jeśli masz pytanie, które blokuje twoją pracę, odłóż je na bok i znajdź inne zadanie.

Przygotuj się na spotkanie. Miej listę pytań, dokładne odniesienia do odpowiednich źródeł lub dokumentów, itp.

Na początku będziesz potrzebować wielu takich spotkań, ale sytuacja będzie się poprawiać, gdy będziesz lepiej zaznajomiony ze wszystkim.

Porozmawiaj także z kodem wiersz po wierszu.(Wyszukaj „debugowanie gumowej kaczuszki”.) W każdym wierszu omawiaj wyrażenia za pomocą wyrażenia lub operację za pomocą operacji.Kiedy już zrozumiesz, jak działa ta linia, przejdź do następnej.* Nie * po prostu siedzieć i czytać bez zrozumienia i wpatrywać się w ekran szklanymi oczami.
To więcej niż błąd dokumentacji.Testowalność kodu jest funkcją myślenia o tym, jak uczynić go testowalnym * podczas jego pisania. * Nawet jeśli nie praktykujesz ściśle TDD, programista, który pierwotnie napisał kod, powinien był napisać testy jednostkowe przed scaleniem.Pisanie testów jednostkowych długo po fakcie jest szalone.Przydzielanie zadania młodszemu deweloperowi, który jest nowy w projekcie, jest potrójnym szaleństwem.
AnoE
2019-04-30 16:12:01 UTC
view on stackexchange narkive permalink

1 - Czy to normalne?

Tak. Siedzenie tam, wpatrywanie się w zdezorientowany kod obcych i zadawanie sobie pytań, co robisz, jest normalne na wszystkich poziomach, nawet po dziesięcioleciach doświadczenia. Jakie zmiany to sposób, w jaki sobie z tym radzisz.

2 - Co mogę zrobić lepiej?

Trzymaj się tego. Dwa tygodnie to naprawdę nie ma się czym martwić. Kiedyś byłem kierownikiem zespołu / głównym deweloperem aplikacji takiej jak Twoja, a nowym ludziom zajęło nawet dwa miesiące , aby osiągnąć nieco produktywność, czasami zajmowało to lata. Ludzie mogą potrzebować tygodnia lub więcej, aby zainicjować swoje środowisko programistyczne, skompilować źródło na starszych aplikacjach i kolejne tygodnie, aby uruchomić je na swoim laptopie. I tak dalej.

3 - Jak mogę to powiedzieć (lub jego części) kierownictwu i współpracownikom, nie dając się oszukać?

Nie mówisz o tym, jak czujesz się oszustem; mówisz obiektywnie o wykonywanym zadaniu. Spróbuj wypracować możliwe rozwiązania, a jeśli sam nie możesz się zdecydować, wtedy zapytaj swojego szefa lub głównego programistę. Jeśli to oznacza, że ​​musisz pytać swojego kolegę przez cały dzień, każdego dnia, niech tak będzie. Jeśli i kiedy twój kolega daje ci wrażenie, że to za dużo, zapytaj swojego szefa, kogo jeszcze może zapytać lub czy ma inne źródła informacji, lub czy nie przeszkadza mu to, że poświęcasz dużo czasu na ciemny.

Bądź przejrzysty; upewnij się, że Twoi „interesariusze” wiedzą, co robisz. (Sztuką jest robić to w taki sposób, aby nie denerwować wszystkich - może temat na inne pytanie; jednym ze sposobów byłoby utrzymywanie jednego strony na bieżąco i wysyłanie go raz w tygodniu lub co drugi tydzień, czy coś w tym stylu. To też naprawdę zależy od kultury Twojej firmy.)

To jest dwukierunkowa ulica. Rzucenie nowego gościa w nieudokumentowany kod źródłowy jest przyjemnym ćwiczeniem, aby „płynąć sokami”, ale na koniec dnia nikt nie spodziewałby się, że wydarzy się tu magia.

Jeśli masz konkretne pytania techniczne, lepiej zadaj je na jednej z bardziej technicznych giełd.

„mów obiektywnie o wykonywanym zadaniu” to najlepsza rada, powtarzanie sobie, że nie rozumiesz, jest nieproduktywne w najgorszy sposób.Jedynym sposobem na zrozumienie obcego kodu (uwielbiam tę frazę) jest omówienie go, a kiedy myślisz, że go rozumiesz, udaj się do autora, wyjaśnij, co Twoim zdaniem robi lub jak działa i wysłuchaj ich opinii.Nie bój się też używać papieru do rysowania diagramów, które tylko Ty rozumiesz, próbując rozwiązać problem.
Andy Dent
2019-05-01 03:48:34 UTC
view on stackexchange narkive permalink

Pracowałem na ogromnych i starożytnych bazach kodu (3D CAD w C ++, z których część została automatycznie wygenerowana przez FORTRAN) i jestem głównie programistą od ponad 35 lat. Wszystko, co negatywne, co powiem poniżej, pochodzi z uczuć i sytuacji, w których byłem!

Jak powiedzieli inni, nie jesteś sam. Mam podobną radę do Stiga, ale z kilkoma ważnymi niuansami.

Po pierwsze, ważne jest, aby Twoja samoocena i być może dla Twojej pracy pokazać, że nie siedzisz tam i wpatrujesz się w kod, czując się zagubiony.

Istnieją trzy rzeczy, które możesz napisać, aby pokazać, co robisz:

  1. Pisz dziennik, nawet jeśli nie jest on nikomu pokazywany. Jeśli myślisz, że będziesz pokazywać ludziom swój pamiętnik, zachowaj prywatny, w którym opiszesz swojemu przyszłemu ja, jak się zgubiłeś lub czy coś zrozumiałeś tego dnia.
  2. Pisz aktualne testy, nawet jeśli są głupie, trywialne, które ćwiczą trochę kodu. Jeśli nie rozumiesz ograniczeń parametrów, zrób coś, aby uruchomić test i udokumentuj te ograniczenia. Upewnij się, że testy zawierają plik readme lub dokument centralny, aby ktoś inny mógł je uruchomić.
  3. Jak sugerowali inni, napisz dokumentację. W zależności od języka, powinieneś być w stanie uzyskać jakieś narzędzie do automatycznej dokumentacji, takie jak Doxygen, które generuje ogólne callgraphy. Jeśli nie możesz, zacznij od fragmentu kodu i prześledź, gdzie jest używany. Jeśli możesz uruchomić kod i wywołać debuger, użyj punktów przerwania, aby zobaczyć stos wywołań do tego punktu. Jeśli musisz wyszukiwać ręcznie, wybierz coś z unikalnymi nazwami, aby przeszukać całą bazę kodu.

Czego należy unikać

Nie krytykuj ich istniejących praktyk w zakresie dokumentacji. Jest to obszar często bardzo kontrowersyjny. Ludzie mogą mieć własne mocne opinie i mogli je odrzucić. Byłbyś zdumiony , jak głębokie mogą być uczucia związane z praktykami dokumentacyjnymi (i sposobem pisania testów).

Nie proś nikogo o radę i zdawaj się ją ignorować. Jeśli ktoś daje ci radę, a nie rozumiesz, jak ją zastosować, pomyśl o tym i przynajmniej napisz kilka uwag o tym, jak próbowałeś ją zastosować.

Nie próbuj wszystkiego zrozumieć. Po prostu nie rób tego . Jest to prawdopodobnie największa słabość ograniczonego kodu, na który ludzie są narażeni w edukacji (nie tylko podczas bootcampów). Bardzo niewiele miejsc uczy Cię programowania bez oczekiwania, że ​​wszystko zrozumiesz. To po prostu niemożliwe w dużych programach. Niech ta potrzeba zrozumienia odejdzie.

Twój ostatni akapit to świetna rada, której każdy programista musi się nauczyć.
Pamiętam bardzo doświadczonego programistę, który był częścią zespołu, w którym uczyłem C ++ i OO GUI w 1996 roku. Wszedłem do jego biura i zastałem go prawie we łzach z CAŁYMI diagramami klas frameworkowych MFC i PowerPlant OO, które dosłownie zaklejały jego ściany.Ta rada nie jest przeznaczona tylko dla początkujących, ale większość doświadczonych ludzi nauczyła się już tej lekcji.
Robin Bennett
2019-04-30 18:04:27 UTC
view on stackexchange narkive permalink

Myślę, że zawstydzam się za każdym razem, gdy zadaję pytanie, więc często utknę, wpatrując się w ekran i próbując zrozumieć, co czytam.

Myślę, że to jedyne miejsce, w którym się mylisz. Nowi ludzie muszą zadawać wiele pytań, a doświadczeni faceci mogą w łatwy sposób ocenić, co musisz wiedzieć dalej.

Kiedy zauważysz, że gapisz się na ekran - napisz e-maila (lub luźną wiadomość , lub cokolwiek). Potraktuj to jak pytanie przepełnienia stosu; opisz problem i to, co zrobiłeś, i pokaż, że włożyłeś w to trochę wysiłku. W połowie przypadków może to sugerować coś, czego nie próbowałeś lub temat, który możesz zbadać, i nie będziesz musiał wysyłać e-maila. Jeśli nie, wyślij go i przejdź do innego problemu, czekając na odpowiedź.

E-mail umożliwia innym osobom odpowiadanie, kiedy jest to dla nich wygodne - ale poproś ich, aby zadzwonili, kiedy będzie to dla Ciebie wygodne podejdź do ich biurka, a potem idź i porozmawiaj z nimi. W ten sposób zdobędziesz więcej informacji i zbudujesz ważne relacje.

Nie marnuj czasu jednej osoby, zamiast marnować czas jednej osoby, i poproś innych, aby pokazali Ci, jak podejdą do rozwiązania problemu. niż tylko „odpowiedź”. Powinieneś także zapytać ludzi, ile czasu zajęło im nauczenie się systemu i ile go znają. To powinno cię przekonać, że robisz dobrze.

Ponadto, gdy znajdziesz słabo udokumentowaną funkcję i spędzisz trochę czasu na jej poznawaniu, powinieneś zapisać, czego się nauczyłeś. Mogą to być komentarze w kodzie, oficjalna dokumentacja, wiki zespołu lub nieoficjalna notatka (w tej kolejności). Następnie dodajesz wartość i pomagasz następnemu facetowi. Możesz także robić notatki na temat obszarów, które są zaległe do refaktoryzacji, oraz wszelkich znalezionych błędów.

user90842
2019-04-30 23:58:56 UTC
view on stackexchange narkive permalink

2 - Co mogę zrobić lepiej?

Całkowicie zgadzam się z innymi odpowiedziami, 2 tygodnie to w zasadzie nic, więc przestań się tym martwić. Ale jest jedna rzecz, w której możesz i powinieneś zrobić lepiej:

Myślę, że zawstydzam się za każdym razem, gdy zadaję pytanie, więc często utknąłem, wpatrując się w ekran i próbując poczucie tego, co czytam.

TO jest tym, nad czym musisz popracować. Jest kilka rzeczy, które możesz wymyślić samodzielnie i oczywiście lepiej jest to zrobić, jeśli to możliwe. Ale są też inne rzeczy, takie jak historyczne powody pewnych zwrotów kodu, których nie możesz zrozumieć. Musisz pytać o te rzeczy bez spędzania dni na patrzeniu na nie.

Teraz nie mówię, że maszerujesz po biurze jak komar brzęczący do wszystkich na twojej drodze. Kiedy napotkasz taki problem, zanotuj go. Poproś kogoś (zazwyczaj swojego przełożonego), aby powiedział ci, kto jest ekspertem w tej czy innej sprawie. Następnie spróbuj znaleźć moment, w którym im nie przeszkadzasz (np. Umówić się na spotkanie?) I przejrzyj z nimi listę odpowiednich pytań. Nie będą irytować, jak ciągły strumień pytań, ale nadal będziesz mieć szansę, aby nabrać tempa.



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 4.0, w ramach której jest rozpowszechniana.
Loading...