Jak radzić sobie z nieprofesjonalnym zachowaniem stażystów?

Nie sądzę, żeby śmiech był właściwym podejściem. Muszą się dowiedzieć, że nie ma ich już w szkole. Biorąc to pod uwagę, nie sądzę, abyś posunął się za daleko również w drugą stronę.

Zalecałbym, abyś był z nim stanowczy i powiedział coś w związku z tym:

Powodem, dla którego przesadziliśmy z nazewnictwem konwencji jest to, że są one bardzo ważne. Ten kod musi być możliwy do utrzymania w przyszłości. Wiele osób w okolicy ciężko pracowało, aby dotrzeć tam, gdzie są, i mogą nie doceniać tego typu żartów. Proszę powstrzymać się od używania tego typu nazw w przyszłości, ponieważ może to spowodować, że ludzie będą kwestionować Twój profesjonalizm.

Po pierwsze, wydaje się to być żart, który został umieszczony w kodzie, że są świadomi, że nie zostanie użyty do niczego lub przeczytać kiedykolwiek ponownie. Wydaje mi się, że zbytnio się w to wtajemniczasz. Ważną rzeczą jest to, że powiedziałeś im o konwencji nazewnictwa i nie ignorowali cię, używali dłuższych i bardziej opisowych nazw (choć sarkastycznie).

Po obejrzeniu ten film Widzę, że pracownicy chcą 3 rzeczy:

1. Autonomia
2. Opanowanie
3. Cel

To, o co prosisz, nie jest autonomiczne, dla niektórych z nich jest prawdopodobnie trywialne i nie służy niczemu w ich oczach.

Napraw zadanie, a pracownicy pójdą za nim.

Niektóre przykłady:

1. Oto ten projekt, pracuj razem i zleć jego wykonanie ___, daj mi znać, jeśli utkniesz.

2. Wiem, że nie wydaje się to ważne, ale aby ocenić twoje umiejętności i przydzielić ci pracę, która naszym zdaniem pomoże ci się rozwijać, potrzebujemy cię do ukończenia tego zadania.

TL;DR : Sprzeciwiam się nazwie metody, bo to (moim zdaniem!) głosy pogardy dla szefa i/lub “zasad” (tutaj: wytyczne stylu). W miejscu pracy oczekuję, że ludzie będą przestrzegać zasady “kochaj to, zmień to lub zostaw”. W tym przypadku stażysta, który wydaje się być zdania, że wytyczna jest niepotrzebna, powinien albo po prostu ją zaakceptować, albo kontynuować dyskusję na jej temat, albo przestać robić to, co robi. Nie należy wkładać do toalety ekwiwalentu jakiegoś rozmazania. Nie miałbym nic przeciwko naprawdę zabawnej, twórczej nazwie metody. Jeśli (OP) uważasz, że nazwa metody jest po prostu zabawna i nie “zła” jak ja, to zignoruj tę odpowiedź, proszę._

• *

W przeszłości nadzorowałam kilku bardzo inteligentnych i (samo)zmotywowanych stażystów i nigdy nie było pytania, czy zachowują się profesjonalnie czy nie. Wprowadzanie głupoty na poziomie szkolnym do miejsca pracy jako stażysta jest tak dalece nie do przyjęcia, że sugerowałbym nie wygłupiać się. Dla własnego dobra, a zwłaszcza dla ich dobra.

Chciałabym wiedzieć, jak właściwie poradzić sobie z taką sytuacją.

Po pierwsze, zapomnij o konwencjach kodowania. Problem nie dotyczy komputerów i programowania.

• Nie kłam. Nie baw się słowami, nie śmiej się, bo to naprawdę nie jest śmieszna sprawa.
• Nie rób z tego sprawy osobistej. To nie jest nie o _you OP, ani o twoim związku z nimi. Tu chodzi tylko i wyłącznie o ich zachowanie.
• Wyjaśnij rzeczy takimi, jakimi są. Absolutnie możesz powiedzieć sprawcy, że w pewnym sensie rozumiesz, jak wpadł na pomysł, aby zrobić to, co zrobił, i że nie jesteś na niego osobiście zły (trzymaj emocje z dala), ale że postrzegasz staż jako pokaz tego, kogo wziąć na pokład później.

Jeśli chcesz przekazać jakieś emocje na ten temat, trzymaj się z dala od gniewu. Możesz okazać lekki smutek (i szczerze mówiąc, to byłoby dokładnie to, co ja bym naprawdę czuł) i pokazać im, że byłeś dość rozczarowany.

Jednak ich występ podczas stażu wpłynie na ich szanse na zatrudnienie i takie sytuacje mogą odegrać rolę później.

Absolutnie! Nie krępuj się, że “może zagrać rolę później”. Zachowanie takie jak to może, powinno i będzie miało zerową szansę na otrzymanie oferty po zakończeniu stażu. Możesz powiedzieć, że w jakikolwiek sposób normalnie z nimi rozmawiasz, jasno i wyraźnie.

Spróbuj znaleźć pierwotną przyczynę. Jeśli dowiesz się, że albo…

• …oni są tutaj wbrew swojej wolnej woli (może ich rodzice, albo ich szkoła lub cokolwiek innego, sprawiło, że wybrali jakiś staż i tak się złożyło, że wybrali Twoją firmę)…
• …oni w ogóle nie są zainteresowani rozwojem oprogramowania w stylu “biznesowym”…

…wtedy złożenie oferty przerwania stażu nie byłoby najgorszym, co mógłbyś zrobić. Problemem nie jest to, że twoja ilość czasu jest zmarnowana (w każdym razie przeznaczyłeś mnóstwo czasu na nadzorowanie ich, tak naprawdę nie pogorszyli tego dla Ciebie), problemem jest to, że twoja ilość czasu jest zmarnowana.

Albo powinienem im powiedzieć coś w tym stylu, aby byli bardziej zmotywowani do tego, aby się czegoś naprawdę nauczyć?

Zadałbym pytanie “każdy człowiek może się uczyć, ale żadnego człowieka nie można nauczyć”. Myślę, że będzie Ci trudno zmotywować tę osobę do uczenia się o użyteczności konwencji kodowania, ponieważ już wcześniej pokazała, że nie jest nimi zainteresowana. Możesz uczyć tych, którzy są zainteresowani tym, co masz do powiedzenia; ale jeśli ktoś jest bezinteresowny, nie ma nic, co możesz zrobić, naprawdę.

Jeśli naprawdę chcesz pomóc tej osobie “zobaczyć światło”, to poproś ją, aby spróbowała się bawić dla własnego dobra, może nauczy się doceniać to, co możesz zaoferować, później. Staże są wymianą wszelkich ograniczonych usług, które mogą zaoferować, w porównaniu z doświadczeniem pracy w rzeczywistym miejscu pracy. Jeśli nie są zainteresowani przyswajaniem tego doświadczenia, to naprawdę nie ma sensu. Prawdopodobnie twoja firma nie jest uzależniona od posiadania swojej “męskiej siły” dla jakiegoś prawdziwego projektu.

Wszyscy nienawidzimy tego robić, ale czasami trzeba po prostu naprawić problemy, wykorzystując władzę. Zadzwoń do stażystów na spotkanie i poproś o informację, dlaczego nie przestrzegano konwencji nazewniczych.

Wyjaśniłem, jakie konwencje nazewnicze miały być przestrzegane na naszym poprzednim spotkaniu. Natknąłem się na kilka przypadków, w których konwencja nazewnicza nie była przestrzegana. Na przykład, convertToMillilitersBecauseIAmUsingSuchCleanCode. Czy mógłbyś wyjaśnić, dlaczego wybrano tę nazwę?

Ich “odpowiedź” jest nieistotna, to powinno wystarczyć jako “pierwsze ostrzeżenie”, że pójście wbrew wskazówkom ich przełożonego (którym, jak przypuszczam, jesteś) i robienie żartów na jego koszt jest nie do przyjęcia w środowisku zawodowym. To nawet dobrze pasuje do jednego celu stażu, którym jest pokazanie uczniom, jak pracować w środowisku zawodowym.

Jeśli kontynuują oni swoje dziecinne zachowanie, to dobrze, myślę, że doszliście do wniosku, że:

Niektórzy stażyści zostaną zatrudnieni w firmie w przyszłości na podstawie ich wyników.

Oh, kupa przekrętów, eh?

Weź trochę kodu roboczego i zrób coś, żeby go celowo złamać. Następnie przepuść go przez okulary, które zmieniają wszystkie nazwy klas, zmiennych i metod na takie rzeczy jak “a__1318798\” i “xy23_7a963”; lub co gorsza, nazwy zmiennych z dużą ilością liter O, litery I, liczby 0, i liczby 1 w nich. Zrób z tego ich zadanie, aby udokumentować, co robi kod, i napraw to.

To wyleczy ten żart.

Wiem, że to chyba nic wielkiego, ale to mój pierwszy raz, kiedy pomagam stażystom i chciałabym wiedzieć, jak sobie z tym poradzić. Jednak ich występy podczas stażu wpłyną na ich szanse na zatrudnienie i takie sytuacje mogą odegrać rolę później. Czy może powinienem powiedzieć im coś w tym stylu, aby byli bardziej zmotywowani do nauki?

Kiedy napotkasz na taką głupotę podczas recenzji kodu, śmiej się, przestań recenzować kod i powiedz im, żeby wrócili, kiedy już usuną humor.

Zakładam, że nie są głupi i już wiedzą, że zbyt długa nazwa jest niestosowna, nawet jeśli mają z tego chuckle. Jeśli nie, wyjaśnij dlaczego za jednym razem.

Miejmy nadzieję, że śledzisz ich występy i możesz zauważyć, jak często się to zdarza.

Miałabym serce do serca z każdym z nich, prywatnie, w szczerym i poważnym, ale nie surowym tonie, coś w rodzaju:

“Stażystko, widziałam twoją metodę żartów. Rozumiem, dlaczego to zrobiłaś, ale ja sama nie myślałam, że to wszystko jest takie zabawne. Więc przyszło mi do głowy, że pytam cię, co tu robisz? Co chciałbyś osiągnąć?”

Jeśli stażysta mówi, że jest tam tylko po to, żeby się pieprzyć, to porozmawiaj z kierownictwem, żeby zakończyć staż. Marnujesz swój czas.

Jeśli mówi, że jest tam, aby się uczyć, to powiedz coś takiego:

“Zdaję sobie sprawę, że może być trudno wziąć na poważnie coś, co, jak wiesz, nie zostanie wykorzystane w produkcji. Ale proszę, zdaj sobie sprawę, że nie tylko zabierasz swój czas, ale także mój. Staż, który zapewniła ci firma, jest w zasadzie rodzajem rozmowy kwalifikacyjnej. Jedyną rzeczą, która powstrzymuje go przed byciem jawnie charytatywnym z naszej strony jest nadzieja na znalezienie dobrych kandydatów. Więc warto poświęcić swój czas, ale tylko wtedy, gdy traktujesz to poważnie”

“Jeśli nie możesz traktować tego poważnie i pracować tak, jakbyś pisał ważny kod produkcyjny, jak możemy Cię właściwie ocenić i zdecydować, czy zaoferować Ci pracę? A nawet jeśli nie zaproponujemy Ci pracy, jeśli nadal nie będziesz jej traktował poważnie, jak inaczej zdobędziesz te umiejętności i będziesz mógł ćwiczyć pod cennym kierownictwem kogoś z większym doświadczeniem niż Ty?”

“Gdybym był Tobą, zrobiłbym wszystko, co w mojej mocy, aby podążać za wskazówkami ludzi, którzy, nieco charytatywnie, zabierają nierentowny czas ze swojej pracy i inwestują w Ciebie. Weź pod uwagę, że skorzystasz na tym stażu, niezależnie od tego, czy cię zatrudnimy, czy nie! Osobiście byłbym wdzięczny, gdybyś potraktował to trochę poważniej. Zrób to dla siebie! Jeśli nie chcesz tego robić dla siebie, zrób to z szacunku, lub po prostu z wdzięczności, za czas, który zabrałem z mojej normalnej, produktywnej pracy, aby zainwestować w Ciebie i Twoją przyszłość”

Prawdopodobnie właściwe jest nieco bezpośrednie zajęcie się samym zachowaniem i tym, dlaczego robisz z niego coś wielkiego. Możesz rozważyć coś takiego:

“Za to, co jest tego warte, takie działanie jest uważane za brak szacunku, a nawet wyśmiewanie się, w świecie korporacji. Jestem pewien, że nie miałeś tego na myśli w ten sposób [nawet jeśli w to nie wierzysz, powiedz to], ale proszę, po prostu podążaj za moimi wskazówkami w przyszłości, bez wkładania w kod snarky things.”

Dając “out” stażyście mówiąc “oh, yeah, I meant no disrespect” pozwala mu uratować twarz i naprawić związek w sposób najbardziej bezbolesny z możliwych. Nie ma potrzeby wyciągać z niego zeznania, że mówił to z lekceważeniem, ani zbierać ogromnych przeprosin. Nie chodzi tu o władzę, ale o udany staż.

Jeśli po tym wszystkim negatywne zachowanie będzie kontynuowane, można zająć się nim bardziej bezpośrednio. Nie ma powodu, dla którego nie możesz dać stażyście celu wydajności, tak jak zrobiłbyś to z pracownikiem mającym problemy, lub użyć jakiejkolwiek innej strategii, którą zastosowałbyś w przypadku zwykłego pracownika. Pamiętaj jednak, że stażyści nie są doświadczeni w świecie pracy i powinni mieć przerwę lub dwie, a Ty delikatnie, ale stanowczo, przyzwyczajaj ich do standardów profesjonalnego świata pracy.

Stażyści, o których mowa, marnują twój czas i cierpliwość. Twój czas i cierpliwość są drogie i ograniczone zasoby dla firmy i stażystów czerpiących korzyści z inwestycji firmy w nie.

Ich gotowość do niepotrzebnego marnowania zasobów firmy jest istotną częścią ich oceny wyników i może prowadzić do przedwczesnego zakończenia stażu, aby wydać zasoby firmy tylko na tych stażystów, którzy są rzeczywiście zainteresowani nauką, jak być wartościową, odpowiedzialną i rzetelną częścią miejsca pracy, którym można powierzyć zarówno zadania jak i instrukcje.

Powiedziałbym to wszystkim stażystom, pokazując jakiś przykładowy kod, nie wspominając o jego autorze, nie spędzając na nim więcej niż 2 minuty, a jeśli kod zostanie później naprawiony i podobne incydenty się nie powtórzą, nie wspominając o nim ponownie.

Jeśli strzał ostrzegawczy nie zostanie zauważony, następnym krokiem jest otwarta rozmowa tylko z danym stażystą i ewentualnie z twoim przełożonym (upewnij się jednak, że jest w twojej łodzi). Następnie musisz zdecydować, czy jesteś winien innym stażystom usunięcie tego, który sabotuje ich szanse na udany staż.

Wygląda na to, że są tu dwie główne kwestie: 1) Są irrewerentne i 2) Nazwa funkcji jest wciąż do bani, mimo że jest teraz dłuższa.

Poniżyć ich za żarty prawdopodobnie nie sprawi, że będą bardziej szanować Twój autorytet, więc skupiłbym się na tej kwestii, jakby to była jakaś inna źle nazwana funkcja. Nie koniecznie grałbym głupka i udawał, że nie zdaję sobie sprawy z tego, że to żart, ale zapytałbym ich, dlaczego wybrali nazwę, którą zrobili:

“Wydaje się, że w nazwie tej funkcji jest kilka zbędnych słów, które nie pomagają wyjaśnić, co ta funkcja robi.”

W ten sposób, jest to dla nich okazja do nauki o tym, co czyni dobrą nazwę funkcji i nie konfrontujesz się z nimi bezpośrednio. Jako dodatkowy bonus, mogą się przyznać do tego, że tylko się wygłupiały i mogą czuć się trochę zawstydzone, że marnują każdy swój czas.

Jeżeli musisz przypominać ludziom, że to ty rządzisz, to nigdy nie byłeś.

Lepiej byłoby przeprowadzić spacer po kodeksie, gdzie deweloper musi wyjaśnić swój kodeks tym, którzy rządzą.

1. Wiąże się to z osobistą odpowiedzialnością za wynik projektu
2. Dostarcza natychmiastowych profesjonalnych informacji zwrotnych
3. Daje deweloperowi poczucie pilności w ukończeniu projektu

Wykorzystaj swoje przywództwo jako część zespołu do utrzymania standardów Twojej organizacji. Następnie pomóż młodszym pracownikom spełnić te standardy i unikaj wstydu związanego z przedstawianiem pracy niespełniającej standardów.

Po prostu powiedz przestępcy (osobiście lub przez e-mail), że staż nie jest odpowiednim miejscem dla takich żartów i że musi traktować je poważnie, jeśli chce rozpocząć karierę.

Poproś ich o naprawienie kodu, lub (jeśli chcesz pokazać jakiś autorytet) po prostu cofnij ich zmiany w kontroli wersji.

Oczywiście, trzeba ich powstrzymać, ale powiedzenie im, żeby nie zademonstrowali dlaczego.

Wiem, że 80 znaków na linię nie jest żadną trudną i szybką zasadą, ale próba trzymania się jej jest dobrą praktyką, więc posiadanie 48 znakowej nazwy zmiennej jest dość głupie.

Sugerowałbym, żeby spróbowali podążać za tą zasadą od teraz, ale także nie pozwolili im zmienić wybranej nazwy zmiennej.

Stażyści, którzy nie rozumieją dlaczego długie zmienne nazwy są złe, wkrótce dowiedzą się, że nie są tak mądrzy jak myśleli.

Dla bardziej doświadczonych programistów jest oczywiste, dlaczego convertToMillilitersBecauseIAmUsingSuchCleanCode jest szczególnie zły, ale zamiast mówić im “to jest złe”, zmuszają ich, aby dowiedzieli się dlaczego. Założę się, że napotkasz znacznie mniej słownych nazwisk, a przy odrobinie szczęścia, mniej przyszłych prób bycia snarkiem.

Nie musi to być “Jeden rozmiar pasuje do wszystkich”. Wszystkie rozmiary pasują do niektórych:

Każde z proponowanych podejść może się sprawdzić i może być najlepszym podejściem w zależności od okoliczności. Oto moja odpowiedź na każde z pytań:

Should I react by

• laughing it off (“Yeah, it’s funny but please remove it”)

To świetny pomysł kiedy: You have an excellent rapport with these co-workers, who have become good friends with

• just asking uprzejmie to remove it

This is a great idea when: Chcesz być bezpośredni, żeby nie było nieporozumień

• mówiąc, że nie lubię, gdy ktoś marnuje mój czas i powinien poważniej potraktować recenzję kodu

To świetny pomysł, gdy Ty chcesz komunikować irytację, i trzymać się autorytarnego podejścia.

(I’m inclined to think you might be able to combine all those approaches into a non-offensive, polite, funny way that does communicate there is a bit of actual iryance. “Ten rodzaj rzeczy musi się skończyć, bo to po prostu sprawia, że idę [mock-scream] ” tylko może być humorystyczny sposób, aby to osiągnąć.)

Osobiście lubię przyjazną metodę. Wierzę w ten sposób robienia rzeczy. Jednak chętnie przyznam, że są chwile, kiedy takie podejście jest mniej skuteczne.

Ale co jest najlepsze? Twoje podstawowe pytanie brzmi: “Jak powinienem na to zareagować?”

W zasadzie to pytanie sprowadza się do powiedzenia: “Muszę się gdzieś dostać. Czy powinienem korzystać z roweru jednokołowego, pogostick'a, roweru czy autobusu?”

Każde z tych podejść transportowych może być najlepsze. Podobnie, aby odpowiedzieć na pytanie, jak powinieneś zareagować: Twoja najlepsza reakcja może nie być moją najlepszą reakcją.

Jest to kluczowy powód, dla którego, mimo że różne odpowiedzi wydają się być zgodne, że zachowanie stażystów nie jest odpowiednie dla wyników produkcyjnych, różne odpowiedzi wydają się sprzyjać różnym podejściom. Jak zauważono, możemy nie mieć jednego, uniwersalnego podejścia, które będzie najlepsze dla wszystkich.

Mamy tu do czynienia z ludźmi, więc to, co sprawdza się najlepiej w niektórych scenariuszach, może nie działać tak dobrze jak w innych. Jednym z kluczowych czynników jest Ty. Czy można być surowym bez palenia mostów? Czy możesz się z nimi zaprzyjaźnić, będąc lekkim sercem, a jednocześnie zapewniając im wystarczającą zgodność i inspirację, aby uzyskać pożądane rezultaty? To, co dla mnie najlepsze, może działać okropnie strasznie dla ciebie. Ostatecznie, musisz dokonać oceny, które z tych podejść zastosować.

Elastyczne nauczanie: Nie zobowiązuj się do jednego podejścia.

Po prostu wybierz metodę, z którą czujesz się najbardziej komfortowo. Upewnij się, że nie przesadzasz (zły/obrzydliwy humor lub tworzenie niewygodnego otoczenia, starając się być surowym).

Bez względu na to, które z Twoich doskonałych sugestii zdecydujesz się kontynuować, uważaj na wyniki.

Bardzo możliwe jest, abyś dokonał oceny, która nie sprawdzi się tak, jak się spodziewałeś. Tak długo, jak nie spowodujesz żadnych poważnych problemów, może to być bardzo możliwe do odzyskania, jeśli zostanie to przeprowadzone pozytywnie i szybko. Jest to jeden z powodów, dla których nie powinieneś się zbytnio martwić o podjęcie najdoskonalszej decyzji. Jeśli sprawy nie idą dobrze, twoja sytuacja może się udać. Ludzie są inni, a uczenie się może być nieprzewidywalne i nie trzeba się wstydzić pierwszego podejścia, które wymaga modyfikacji. Tak długo, jak szybko wyzdrowiejesz, może to być nieistotne.

Kluczem jest wprowadzenie zmian, gdy tylko zaczniesz znajdować niepożądane rezultaty. Przewiduje się, że trzeba będzie szybko adaptować. Kiedy jakieś podejście nie działa, bądź bardzo gotowy do szybkiej modyfikacji podejścia, lub nawet wyrzuć je całkowicie przez okno. Jeśli to co robisz nie działa, określ, czy jesteś na skraju przełomu, czy też musisz spróbować czegoś innego. (Uzyskanie informacji zwrotnej pomoże w tym ustaleniu.) Jeśli musisz spróbować czegoś innego, to zrób to. Postępuj tak dopóki nie uzyskasz wyników pracy.

Tak długo, jak długo będziesz działać szybko (zanim zaczniesz odczuwać długotrwałe uczucia goryczy), drobne niedoskonałości mogą być łatwo usuwane na bok jako nieistotne w porównaniu z pozytywnymi wynikami, które osiągasz ogólnie. (Tylko upewnij się, że jeśli sprawy idą niedoskonale, problemy są niewielkie. Poważne błędy mogą być nieco trudniejsze do zapomnienia. Na przykład, próba humoru może być niebezpieczna.)

Na przykład, jeśli zauważysz, że zaczynają cię nienawidzić, straszyć środowisko, itp., upewnij się, aby wyjaśnić wszelkie nieporozumienia. Upewnij się, że jesteś po ich stronie. Zachęć ich do pożądanego zachowania, itp.

Dwa lata temu byłem w podobnej sytuacji jak stażyści w twojej firmie. Mogę sobie wyobrazić scenariusz, w którym zrobiłabym coś podobnego. Myślę, że niektórzy stażyści mają problem z twoim autorytetem; bycie pedantycznym i nieprofesjonalnym. Wynika to głównie z braku szacunku, jaki moje pokolenie ma do starszych i tych na wyższych stanowiskach. Spróbowałabym następujących metod rozwiązania tej sytuacji.

• Zdobądź szacunek stażystów poprzez przechytrzenie “lidera”, “alfa”.

• Użyj nazwy funkcji pedantycznej jako lekcji dla wszystkich, optymalna długość nazwy funkcji: strefa goldilock'a.

• Zwróć uwagę na wadę funkcji “convertToMillilitersBecauseIAmUsingSuchCleanCode” i zasugeruj zmianę nazwy na coś odpowiedniego (/demeaning)

• Nie zwracaj uwagi, ignoruj nazwę funkcji; skup swój czas na osobach, które chcą się uczyć.

Na wszelki wypadek zanotowałbym nazwiska nieprofesjonalnych stażystów.

Should I react by

• laughing it off (“Yeah, it’s funny but please remove it”)
• just asking uplyly to remove -elling that I don’t like when someone wast my time and they should take the code review more seriously

How about “ *Understanding why they did this? *”

Kiedy ktoś robi coś, czego się nie spodziewasz lub nie chcesz, możesz albo zareagować na to, aby zrobić to, co chcesz, albo spróbować zrozumieć, dlaczego to zrobił.

Przydałoby się zrozumieć, dlaczego to zrobił. Jeśli są z natury zabawni, ale nie dają się zwieść swojej frustracji, to właśnie w ten sposób ktoś może im to przekazać. Wszyscy możemy się zgodzić, że nie jest to pozytywny sposób, aby to przekazać.

Inne podejście

Więc co to jest pozytywny sposób, aby przekazać frustrację i zabawę? Pracowałem w firmach, w których ludzie czasami projektowali 10% czasu, jak np. programowanie mikrokontrolera, aby zabrać się za samodzielność z dslr. Nie tylko dostali za to darmowe rządy, ale także otrzymali odpowiedzialność za przekształcenie tego w produkt nadający się do wysyłki. Od jednodniowego hackatonu do przykładów kodu, które są teraz publikowane na stronie internetowej firmy. Ludzie mogą wziąć ten przykład i zamienić go w pilota do kamer głębinowych, który można włączyć za pomocą jednego kliknięcia.

Chodzi mi o to, że takie psikusy jak ten _ mogą być_ wskazaniem niewykorzystanego potencjału. Jeśli chcesz, aby stażyści odpowiadali standardowi, jaki masz w swojej firmie, ten potencjał nie jest dla Ciebie i w takim przypadku rozważ możliwość zwolnienia ich. Jednakże, jeśli widzisz wartość wstrząsania rzeczami, nakłonić tych żartownisiów do stworzenia czegoś użytecznego w ich wybrykach. Ostatecznie, to zależy od ciebie. Kim chcesz, by byli ci stażyści?

Jako profesjonalista od prawie 30 lat, powiedziałbym, że wysoko oceniane odpowiedzi w większości mają rację.

Jednakże, jako profesjonalny twórca oprogramowania od prawie 30 lat, powiem, że wytyczne dotyczące kodowania są prawie zawsze ** ponad nakazowe**. Co gorsza, często jest to podchwytywane przez ludzi bardziej dbających o swoją Autoritah niż o tworzenie czytelnego kodu. Ten rodzaj pasywno-agresywnego zachowania młodszych inżynierów jest dokładnie tym, co zwykle widzisz, kiedy to się dzieje.

Umieszczanie głupich rzeczy w komentarzach do kodu, a nawet nazywanie identyfikatorów, jest naprawdę uhonorowaną tradycją wśród twórców oprogramowania. Oto przykład zaindukowanego przez standardy nazewnictwa protestu z moje własne junior days (który otrzymał 48 głosów w górę).

Jeśli jest tu jakiś problem, to powinien on być taki, że istnieją uzasadnione problemy z czytelnością/utrzymaniem ich kodu źródłowego w Twoim środowisku. Nie twierdzę, że najlepsze odpowiedzi są tu błędne. Nie są. Ale kiedy widzisz tego typu zachowanie wielu młodych inżynierów, po oczyszczeniu ciał powinieneś naprawdę sprawdzić czy jest jakiś powód dla którego twoje kanarki wciąż umierają.

Celem końcowym musi być jakość kodu. Wytyczne do kodowania powinny być po prostu narzędziem pomagającym im się tam dostać, zbudowanym przez deweloperów dla deweloperów, a nie jakimś autorytarnym programem do pisania programów.

Brzmi to tak, jakbyś miał bardzo dobry przykład, aby pokazać im, dlaczego używanie tego typu konwencji kodowania jest niewłaściwe, nawet w przypadku małych projektów, takich jak ten.

You saw it.

Nawet jeśli ich projekt nie jest bezpośrednio wykorzystywany przez firmę, ma on służyć jako ocena ich umiejętności, a częściowo jako doświadczenie edukacyjne dla tych stażystów, którzy chcą wejść do Twojej firmy.

Nie byłbym dla nich zbyt surowy - w końcu to _jest dla nich tylko próba - ale na pewno zwróciłbym uwagę, że w przyszłości takie praktyki kodowania mogą sprawić im kłopoty, zwłaszcza jeśli ich następny szef nie będzie z nimi tak cierpliwy jak ty.

Po pierwsze, nie sądzę, żeby to było złe. Umieszczają w kodzie żart o temacie (konwencji nazw), którego prawdopodobnie nie do końca rozumieją. Umieszczenie w kodzie kilku wewnętrznych żartów nie jest czymś nowym. Mogą też uznać kod za “wewnętrzny arkusz”.

Nie zgadzam się też z poglądem, że marnują na to swój czas. Jeśli zobowiązują się tylko do zmiany nazwy metody, to tak, marnują Twój czas, a zmiana powinna zostać odrzucona. Ale jeśli potrzebowaliby nowej metody i wybraliby kiepską nazwę, czas na recenzję byłby podobny z każdą nazwą. Nie wiem, czy recenzjujesz pre-commit, czy post-commit, ale kiedy ktoś chce mieć kod zatwierdzony/mieszany, to co robi, tak naprawdę działa przeciwko sobie, ponieważ po prostu dodaje roundtrips, aby faktycznie uzyskać kod zaakceptowany.

Jest również trywialne dla Ciebie, aby oceniać negatywnie błędne nazwy, bez faktycznego patrzenia na to, co robi kod. Problem polega na tym, że czujesz się wkurzony na te nazwy.

Teraz, przybijając się do właściwego pytania o to, co robić, polecam wspomnieć, że mieli pewne problemy z konwencjami nazw i poprosić ich o przejrzenie pracy z zeszłego tygodnia, aby sprawdzić, czy używają właściwych nazw i zastanowić się, czy zrozumieliby to łatwo w ciągu kilku lat / jeśli weszliby do tego projektu. Niech przygotują krótki raport na temat funkcji, które dodali w tym tygodniu i wkrótce to uzasadnią.

Idealnie byłoby, gdyby chodziło o linię na funkcję, np.

convertGalToml: Konwertuje Gallony do Milliliterów. Camel case nie został użyty na skrót Milliliters, aby uniknąć pomylenia go z megalitrami.

Oczekuje się, że przeglądając kod, mogą zauważyć nowe problemy lub wymyślić lepszą nazwę, np. zmienić nazwę convertGalToml na convertGal2ml.

Podejrzewam, że twój żartowniś dostanie punkt i po cichu zmienić nazwę.

Chodzi o to, że nazwy funkcji są dokumentacją. Chociaż jest to bardziej techniczna publiczność niż np. podręcznik użytkownika, powinni oni być wygodni, uzasadniając swój wybór przed swoimi rówieśnikami.

Zaczynając od założenia dobrej wiary, moje jelito mówi mi, że stażyści zrobili to, ponieważ naprawdę nie widzą żadnego problemu z nazwiskami takimi jak convert. Założyłbym się o małą sumę pieniędzy, że sarkastyczne nazwy nie pochodzą z chęci bycia buntowniczym, ale z frustracji, że nie wiedzą jak wymyślić better nazwę, tylko dłuższe imię. I to jest w pewnym sensie to, co im powiedziałeś, prawda? Krótka zła, długa dobra.

Jeśli chcesz, żeby te osoby się poprawiły, po prostu musisz przedyskutować, w codziennym spotkaniu, dokładnie dlaczego convert to kiepskie imię, a convertInchesToCentimeters to lepsze imię. Jeśli masz przykład z Twojego doświadczenia z wyborem złej nazwy, który powoduje problemy, to im pomoże. To “dlaczego” pozwoli im od teraz wybierać dobre imiona - niezależnie od tego, czy te dobre imiona są długie czy krótkie.

Daj im również znać, że można poprosić Ciebie lub ich kolegów o pomoc lub skonsultować się z nimi w rozsądku, że nie jest to test, w którym każdy musi pracować sam, jest to współpraca. (Mam nadzieję, że to prawda!) Może to pozwoli im zadawać pytania i rozmawiać ze sobą, i rozwiązywać frustracje wcześnie, zamiast czekać, aż takie bierno-agresywne rzeczy pojawią się w recenzji kodu.

Tylko wtedy, gdy takie zachowanie będzie kontynuowane uważam, że konieczne jest wyjaśnienie, tak, nie jest to prawdziwe zastosowanie, ale to ćwiczenie i wytyczne stylu powinny być traktowane poważnie z wielu powodów:

• Warto poświęcić swój czas na ten wysiłek, kiedy będę mógł pracować nad “prawdziwymi” aplikacjami, więc proszę, daj z siebie wszystko
• To ćwiczenie przygotowuje Cię do pracy nad prawdziwym projektem, który jest poważny i w którym musisz przestrzegać wytycznych stylu
• To ćwiczenie pozwala nam zdecydować, który z Was, jeśli w ogóle, rozszerzyć oferty pracy na po zakończeniu Twojego stażu

Choć nie do końca się mylę, myślę, że oskarżenie ich o brak szacunku, itp. w tym momencie prawdopodobnie uciszy zachowanie, ale też nie pomoże im zrozumieć dlaczego potrzebują lepszych nazwisk lub jak wymyślić lepsze. Jeśli pójdziesz tą drogą, może się okazać, że wymyślają tylko dłuższe złe imiona i unikają twojego stalowego spojrzenia.

Nie jesteś ich menadżerem, to nawet nie ma znaczenia, czy przeprowadzasz z nimi wywiad, czy nie. Jesteś inżynierem jak ja,

Więc wiesz co robić, Porozmawiaj ze swoim menedżerem, a następnie zaproponuj podgląd kodu. Następnie doradzaj im, aby nie pisali takiego kodu przez taki system jak współpracownik kodu. Nie musisz nawet wysyłać do nich e-maili, wchodzić z nimi w interakcję lub brać tych rzeczy osobiście. Wprowadź system oceniania oparty na tym przeglądzie kodu. Nie próbuj ich kontrolować, być ich menadżerem, ani próbować zarządzać ludźmi. To nie Twoja sprawa.

Porozmawiaj ze swoim przełożonym i zachowaj ten przywilej, aby odrzucić lub zatwierdzić zobowiązania po recenzji dla siebie. Załóżmy, że każdy stażysta ma początkowe 10 punktów i powinien zarobić 100 punktów w Twojej ocenie, a jeśli naprawdę chce dołączyć do Twojego zespołu, będzie miał motywację, aby je zdobyć. Nie trać żadnych punktów.

Jeśli byłem stażystą i pracuję pod twoim kierownictwem, a ty jesteś tylko starszym inżynierem, nawet ja nienawidzę, gdy zajmujesz się zarządzaniem moimi ludźmi. To nie jest twoja praca.

Brzmi dla mnie, że posunąłeś się za daleko i wymknęło się to spod kontroli. Naucz się tej lekcji jako inżynier. Jesteś inżynierem, a nie ich menadżerem, żeby ludzie nimi zarządzali.

Chociaż zachowanie stażystów może być nieprofesjonalne, to dla kierownictwa jest również nieprofesjonalne, aby nie uważać, że mogą być w błędzie. Najwyraźniej convert może być zbyt krótki w wielu kontekstach, ale convertGallonsToMilliliters jest zbyt długi dla nazwy identyfikatora. Zamiast narzucać arbitralne wymagania dotyczące nazewnictwa, powinieneś rzucić wyzwanie swoim stażystom, aby uzasadnili, kiedy imię, które wybrali jest naprawdę niejednoznaczne (czego nie będą w stanie zrobić) i wymyślili coś rozsądnego, co poprawi czytelność programu, a nie będzie jej utrudniać.

To naprawdę czuje się jak przypadek powszechnego wzorca “dlaczego moi podwładni mnie nie szanują?” naprawdę jest to kwestia “co z moim własnym nastawieniem jest takie, że ludzie nie szanują mojej pozycji?