Jako programista byłem zarówno na twoim, jak i u Dave'a. W zespołach programistycznych, które współpracowały ze sobą od dłuższego czasu, każdy kolega zaczyna opracowywać koncepcję tego, kto jest `` celem '' zdobycia wiedzy na temat konkretnego projektu lub systemu (zwłaszcza jeśli jest to coś tak ezoterycznego, że StackOverflow nie może pomóc !). To wspaniale, że Dave jest dobrze wykwalifikowany i szybko podchodzi do rzeczy, ale w przypadkach, gdy czas może być dla nich niekorzystny, kolega może po prostu odszukać tego, o którym wie na pewno , że ma doświadczenie z tym, czym byli utknąć. Nie dotyczy to tylko praktykantów lub młodszych programistów. Podczas jednej pracy, pomimo posiadania dwóch starszych programistów nade mną, moi koledzy zadawali mi pytania dotyczące problemów z C # tylko dlatego, że byłem „facetem od C #”. Z czasem musiałem im wyjaśnić, że inni też wiedzą o tym wystarczająco dużo.

Jednym z rozwiązań mogłoby być zwiększenie świadomości zespołu nad tym, nad czym pracuje Dave (nie tylko o osiągnięciach). Wygląda na to, że Twój kolega nie wiedział lub trzeba mu było przypomnieć, że Dave odbył w czymś odpowiedni kurs. Warto również poprosić Dave'a, aby na przykład śledził kolegę w zadaniu JavaScript po ukończeniu kursu JavaScript. Pomoże to Dave'owi zyskać większe uznanie w zespole, a także sprawi, że Twoi koledzy będą bardziej pewni, że jest kimś więcej niż tylko sprytnym książkami, a zatem chętniej poprosi o pomoc, gdy nadejdzie czas. Można to nawet zademonstrować, dając Dave'owi szansę pracy nad ważnym lub ważnym zadaniem (jeśli czujesz, że jest na to gotowy).

Im bardziej Dave integruje się z zespołem, tym bardziej będą przychodzić uznawać i polegać na jego wiedzy. Ponieważ Dave ma większe szanse na wykazanie się wiedzą, która może pochodzić tylko z pracy z zespołem programistów, tym większe jest prawdopodobieństwo, że zostanie poproszony o poradę.

Kiedy zaczynałem staż jako programista, byłem w podobnej sytuacji. Chociaż nie miałem żadnych kwalifikacji „na papierze”, miałem duże prywatne doświadczenie w tworzeniu oprogramowania. Po prostu nikt mi nie uwierzył. Zapytałem więc najbardziej szanowanego starszego programistę w zespole, nad czym pracuje i czy mógłbym się przyjrzeć. Następnie spędziłem następny dzień analizując kod źródłowy, szukając najgorszej części, jaką udało mi się znaleźć. Następnie podszedłem do niego i zapytałem:

Hej [starszy programista]. Sprawdziłem twój kod źródłowy i jest jedna rzecz, której nie rozumiem. Jaki jest powód, dla którego nie użyłeś tutaj [bardziej wydajnego rozwiązania]? Jestem pewien, że istnieje dobry powód, dla którego użyłeś [nieefektywne rozwiązanie]. Ale ja nie znam tej technologii tak dobrze, jak ty. Więc naprawdę chciałbym wiedzieć, dlaczego to zrobiłeś.

Teraz oczywiście nie miał powodu, aby robić to w nieefektywny sposób. Skuteczny sposób po prostu nie przyszedł mu do głowy. W tym momencie zrozumiał, że jestem o wiele bardziej zdolny, niż wskazywałby na to mój tytuł zawodowy, ale sposób, w jaki mu pokazałem, był uległy i niekonfrontacyjny, więc nie postrzegał mnie też jako wstrętnego znawcy wszystkiego. > Pięć lat później zdobyłem jego stanowisko. *

* _{nie, nie martw się. Nie odstraszyłem go. Dostał jeszcze lepiej płatną ofertę pracy w innym miejscu.}

Jedną rzeczą, o której powinieneś nauczyć Dave'a, jest znaczenie widoczności w miejscu pracy. Ludzie mogą go nie doceniać, ponieważ nie zdają sobie sprawy z jego talentów i po prostu oceniać go na podstawie stanowiska.

Do czego możesz go zachęcić:

• Organizuj prezentacje przed zespołem. Ukryj to jako ćwiczenie sprawdzające umiejętności prezentacji.
• Poszukaj wewnętrznych projektów, które są interesujące dla kierownictwa.
• Rozwiąż długotrwałe problemy, których każdy się boi.

Warto porozmawiać z managerem Dave'a i / lub kierownikiem zespołu deweloperskiego (jeśli są to różne osoby) konkretnie na ten temat, a nie tylko w swobodnej rozmowie.

Z Dev Team Managerem Powinieneś podkreślić tę kwestię, którą widziałeś i zasugerować, aby szukali okazji nie tylko dla niego, aby się rozwinąć i wnieść swój wkład, ale aby wziąć rzeczywistą, nazwaną odpowiedzialność za coś. Dużo trudniej będzie mu nieumyślnie odrzucić na bok, że ma do czynienia z określoną technologią lub zajmuje odpowiedzialne stanowisko w projekcie. Ma to również tę zaletę, że jest dla niego bardzo dobrym kolejnym krokiem w nauce.

W przypadku jego własnego menedżera może to być w formie informacji zwrotnej do jego następnej oceny, a być może nawet rekomendacji awansu / podniesienia tytułu podwyżka / premia / przemyślenie możliwości rozwoju kariery w świetle jego wyjątkowych postępów.

Powinieneś również zaoferować mu opiekę mentora, jeśli nikt inny nie jest.

W razie potrzeby możesz również zaproponuj / poproś go, aby przyłączył się do Ciebie w niektórych pracach jako sposób na trening crossowy, zdobycie szerszego doświadczenia, wniesienie wkładu tam, gdzie jest doceniony, i zdobycie szerszej ekspozycji.

Może niektórzy ludzie w zespole nie chcą bystrego praktykanta. Co powinien myśleć szef, jeśli praktykant robi coś lepiej niż tak zwani doświadczeni członkowie zespołu? I prawdopodobnie praktykant zarabia ułamek tego, co otrzymują eksperci.

Wygląda na to, że praktykant jest zbyt dobry dla tego zespołu. Chcą kogoś, kto nie jest dobry i nie uczy się szybko. Chcą kogoś, kto pyta ekspertów i kto nie ma dobrych pomysłów, których nie mają eksperci.

Myślę, że masz wybór, aby być po stronie zespołu lub po stronie praktykanta i przeciwko drużynie ...

Daj sobie czas

Chociaż jest wielu programistów, którzy starają się wyprzedzić grę, przyjmując nowe techniki, z mojego doświadczenia wynika, że ​​ogólnie:
Programiści, którzy nigdy / przez jakiś czas nie doświadczyli nowych informacji, takich jak status quo.

Nie przepadają za nowymi technikami / programami / metodami / ... wiedzą, jak te obecne zachowują się i jakie mają dziwactwa. Przejście na, powiedzmy, nowy styl programowania może wymagać sporo wysiłku, a IMO jeszcze więcej wysiłku ze strony starszych ludzi. A teraz wyobraź sobie, że jakiś przypadkowy nowy facet to mówi. Dostaje też za to całą pochwałę, gdzie utrzymują równowagę, której nigdy nie chwalą ¹ !

Nie lubię używać stereotypów, ale jest to sytuacja, w której szacunek ”trzeba sobie zapracować. Pierwszy pokaz, że gra w zespole, trochę bardziej pasywnie. Po chwili okaże się kompetentny, nawet bez pokazywania kodu. Po chwili, jeśli ma własne zadania, może dorzucić „hej, napisałem ten fragment, chciałbym, żebyś się o tym pomyślał”. W ten sposób może pokazać swój poziom i jednocześnie dowiedzieć się, jak działa reszta firmy (wszystkie nowe pomysły brzmią świetnie, ale czy pasują?).

Po pewnym czasie status quo dołącz go. Z mojego doświadczenia wynika, że ​​im bardziej naciskasz na zmiany, tym bardziej się odsuwasz. Znajdź przepływ, dołącz do niego, wpływaj na niego.

¹ Może być niepoprawne, ale trochę wyjaśnia emocje.

Ta odpowiedź jest oparta na moim doświadczeniu jako praktykanta.

Niedawno skończyłem szkołę z maturą. Dostałem stanowisko praktykanta w międzynarodowej firmie konsultingowej, przez większość czasu przeszliśmy wstępne szkolenie z których nie rozszerzył się znacząco na moją już istniejącą wiedzę samouka. Ale to zapewniło dostęp do mentorów, których rolą było udzielanie wskazówek, odpowiadanie na pytania techniczne i koncepcyjne i których wpływ zapewnił mi znaczny wzrost.

Po rozpoczęciu pracy w głównej firmie zostałem umieszczony w zespole „innowacji” było opracowywanych wiele ekscytujących rzeczy, w których mogliśmy uczestniczyć tylko w pobieżnym programie, ponieważ potrzebowaliśmy przejść przez „program szkoleniowy” zajęć z praktyk zawodowych &.

Kiedy tam się zapisałem do rozmów z szefem działu na temat onboardingu i otrzymał od nich zadanie opracowania prototypu aplikacji onboardingowej. Znalazłem kilku uczniów, którzy mogli to załatwić na boku i wszystko szło dobrze.

Po pewnym okresie rozwijania tego podczas moich wieczorów zdałem sobie sprawę, że prawdopodobnie brakuje mi pewnej wiedzy, która usprawni proces rozwoju, informacji technicznych dotyczących technologii tamtych czasów, takich jak Angular, z których korzystał zespół ds. innowacji codziennie. Zwróciłem się do głównego inżyniera zespołu o radę, powiedziano mi, że nie poświęci mi czasu, ponieważ jeszcze nie ukończyłem zajęć (które mnie nie interesowały, wolałbym kodować), a następnie przeprowadził wywiad z o tym, w jaki sposób przydzielono mi ten projekt, a nie cały zespół, nie rozumiał, dlaczego kierownik działu wybrał mnie do prowadzenia tego projektu i chciał zgłosić własność.

To znacznie mnie zdemoralizowało. Kontynuowałem bez wskazówek dotyczących rozwoju, ale nie wiedziałem, jak rozwiązać tę sytuację lub szukać pomocy gdzie indziej. Mniej więcej w tym czasie przeżywałem rozstanie z wieloletnim partnerem, co w połączeniu z przebywaniem poza domem i niewielkim wsparciem emocjonalnym oznaczało, że zacząłem spóźniać się do pracy (mimo że zawsze wychodziłam jako ostatni). Tydzień lub dwa z tego, nieudana wizyta u lekarza (zacząłem używać mojego obecnego stanu jako podpórki, aby wyjaśnić moje spóźnienia), sam zostałem wciągnięty na spotkanie HR i dano mi możliwość zwolnienia na miejscu lub podpisania list z rezygnacją, napisałem e-mail z rezygnacją w pokoju rozmów, ponieważ czułem, że nie mam innego wyboru i wyszedłem przed obiadem.

Mój menedżer, zespół, kierownik drugiego działu, nikt wiem, że ta akcja HR została podjęta przeciwko mnie, osoba z HR, która mi to zrobiła, została wkrótce potem zwolniona.

Krótko mówiąc, jeśli to możliwe, spróbuj go chronić, uświadomić jego sytuację wyższemu podnosi i rzuca światło na jego potencjał w organizacji w roli poza samą praktyką zawodową, wyjaśnia mu biurokrację i jak w niej istnieć, jednocześnie kierując go do mentorów i pamiętając o swojej sytuacji, prawdopodobnie jest pełen optymizmu i odwagę, ale między ekscytującym wyzwaniem przebiega cienka granica i pozostawiony do uschnięcia w korporacji bez wsparcia lub pielęgnowania jego talentów.

Ty i Dave powinniście być bardziej bezpośredni w oferowaniu pomocy.

Dave jest otoczony przez starszych inżynierów oprogramowania. Mówienie im „coś wiem” jest łatwo ignorowane (może z dumy, może dlatego, że szczerze nie widzą, jak Dave mógłby im pomóc). Mówienie im: „Musisz użyć X w ten sposób, a Y w inny sposób, aby osiągnąć Z” jest bardzo konkretne, udowadnia jego wiedzę i utrudnia odrzucenie.

To samo dotyczy ciebie. Pytanie starszego inżyniera „czy zapytałeś Dave'a” może być rozumiane jako

• „Weź Dave'a pod swoje skrzydła i spróbujcie razem rozwiązać problem” - co może wydawać się niezbyt rozsądne.
• „Czy próbowałeś przypadkowo poprosić swoich kolegów o pomoc?” - co zrobił, po prostu przypadkowo zapytał innego kolegę
• „Wiem, że Dave wie, jak ci pomóc”

Zamiast tego powiedz im „Dave wspomniał, że zna rozwiązanie twojego problemu.”

Chociaż zgadzam się z prawie wszystkimi odpowiedziami już tutaj, z następującymi radami:

• Daj sobie czas
• „Szacunek” zdobywa się z czasem
• Uczyń go średnim / starszym
• Przydzielaj większe / bardziej złożone zadania
• Poproś Dave'a o programowanie w parach z innymi / seniorami

Myślę, że czegoś brakuje. W swoim pytaniu wspominasz, że próbowałeś już tego i tamtego:

Próbowałem już wyjaśnić wszystkim, jaki jest dobry i jakie osiągnięcia osiągnął w tak krótkim czasie bezskutecznie. Naprawdę chce zrobić dobre wrażenie, aby pomóc mu w rozpoczęciu kariery, ale trudno mu powiedzieć, że go nie słuchano.

Wyróżniają się dwie rzeczy, z których jedna staje się pytanie:

1. „[...] rozpoczął karierę, ale trudno mu powiedzieć, że go nie słuchano”
2. Próbowałeś wyjaśnić - Jak długo to trwało?

Jeśli to jest „dość długie” (wpisz tę kwotę w sobie, jesteś najlepszym sędzią w tej sytuacji), skorzystam z tej rady:

Powiedz mu, żeby znalazł pracę gdzie indziej.

Mam na myśli to w najlepszym przypadku dla Dave'a. Jeśli wypróbowałeś powyższe i prawdopodobnie wypróbowałeś większość porad / odpowiedzi na twoje pytanie, powiedz mu, żeby po prostu wyszedł. Twórców oprogramowania brakuje, będąc gdzieś, gdzie nikt cię nie słucha, jest do bani. Ok ok, słuchasz, ale „reszta” nie, to jest do bani.

W każdym razie, to właśnie bym zrobił, gdybym miał stażystę, który stał się już nie tyle-stażystą, i sprawił, że tak się stało. Powiedziałbym mu również, żeby zapisał mnie jako punkt odniesienia i nie starał się już o pracę jako stażysta; minimum junior (w oparciu o ilość czasu w pracy, menedżerowie mają tendencję do przekręcania swoich majtek w porównaniu z „zbyt” młodymi mediami / seniorami)

Dlaczego Dave jest nadal młodszym zawodnikiem, skoro może prześcignąć kadrę seniora i szybko się tym zająć? Jedynym sposobem, w jaki widzę, aby to wymusić, jest uczynienie Dave'a deweloperem starszego lub średniego poziomu i przypisanie mu zgłoszeń błędów - zakładając, że używasz scrum lub kanban -.

Poza tym wystarczy poprawić swoją reputację dzięki rzeczom, które naprawdę mają znaczenie; osiągnięcia, a nie standardowe oceny z kursów standardowych.

Bycie starszym programistą lub liderem zespołu to nie tylko umiejętności programistyczne, ale także komunikacja, odpowiedzialność i odpowiedzialność za początkujących. Jako starszy programista, za który jesteś odpowiedzialny i jesteś bardziej skłonny do kontaktu z osobą (osobami). .. wszystko, zwykle nie można wybierać i wybierać.

Są też wzorce architektury / projektowania. W niektórych moich zespołach mam ludzi, którzy potrafią rozwiązać większość problemów technicznych (niektóre nie udało się), ale moment, w którym poprosisz ich o zaprojektowanie czegoś, jest momentem WTF, aby ładnie to ująć.

Więc co powinien zrobić Dave? Zrób wiele z problemów, które rozwiązuje, zademonstruj zrozumienie zamiast stwierdzać „gotowe” (co jest równoznaczne z „to było proste”), pokaż zrozumienie systemu i twórz kod z minimalną liczbą błędów.

Co powinieneś zrobić? Zachęć Dave'a, aby wyjaśnił pozostałym członkom zespołu sposób rozwiązania problemu. Ponadto, jeśli zdobył umiejętności, których według niego potrzebuje, powinieneś zachęcić go do ubiegania się o stanowisko nieuczelniane w tym lub innym miejscu.

Dave przydałby się efekt Bena Franklina ... wygląda na to, że jest teraz po złej stronie.

Chodzi o to, że lubimy wierzyć, że jesteśmy sprawiedliwi, więc jeśli robimy komuś przysługę, podświadomie racjonalizujemy, że musi to być dobra osoba, która zasłużyła na przysługę, i odwrotnie, jeśli wyrządzimy komuś krzywdę (nawet przez przypadek), próbujemy zracjonalizować, że w jakiś sposób zasłużyli na krzywdę.

Pułapki, na które należy uważać: Jeśli prosisz o zbyt wiele przysług lub zbyt wiele przysług, to nie zadziała. Jeśli zapobiegawczo robisz coś w zamian, to nie działa. A jeśli neutralna osoba trzecia prosi o przysługę w Twoim imieniu, to nie działa (i może być szkodliwe).

Wygląda na to, że ty i Dave należycie do kategorii drugiej i trzeciej. Ogromne zaległości w przysługach Dave'a, które wyświadczył innym, sprawiają, że czują, że są mu winni, co w rzeczywistości czyni go mniej popularnym. A twoje kibicowanie mu jako osoba trzecia czyni go mniej popularnym.

Z drugiej strony, jeśli Dave poprosi o pokazanie lub nauczenie czegoś, osoba pokazująca / nauczająca będzie 1) dobrze czuła się z Dave'em, ponieważ wyświadczyli mu przysługę, 2) czuli się dobrze, ponieważ mieli wiedzę, która była przydatna, i 3) może uważają, że Dave jest mądry, jeśli zadaje dobre pytania i szybko się uczy.

Niestety, Dave nie tutaj, ale moja rada jest taka, żebyś przestał tak głośno cheerleadować Dave'a - to znaczy przestań przynosić Dave'a za każdym razem, gdy ktoś potrzebuje pomocy. Jeśli Dave ci pomoże, to nie ma problemu, aby o tym wspomnieć, lub jeśli Dave naprawdę dobrze radzi sobie w solowym projekcie - ale na mniej więcej tym samym poziomie możesz wspomnieć o każdym innym członku zespołu.

Zamiast tego spróbuj przekonać Dave'a, aby rozmawiał z innymi członkami zespołu jako praktykant, a nie jako nauczyciel. Na przykład zawsze istnieje wiedza specyficzna dla domeny, która nie jest dostępna w pisemnych zasobach. Jeśli Dave napotka takie problemy, możesz wskazać mu kolegę, który jest zarówno kompetentny, jak i prawdopodobnie schlebia mu zadawanie pytań. („Powinieneś zapytać Sally i Boba - początkowo nad tym pracowali i znają wszystkie wybredne szczegóły dotyczące tego, dlaczego niektóre rzeczy są takie, jakie są”).

https: // pl. wikipedia.org/wiki/Ben_Franklin_effect#Uses

Zawsze planowałem, że powinienem po prostu przekonać najlepszych ludzi w branży - dyrektorów generalnych, dyrektorów technicznych, naukowców, konsultantów najwyższego szczebla, szefów sektorów rządowych potrzebujących zaawansowanej technologii i mniej więcej powiedzieć nic nie wiadomo co chcą powiedzieć. Wtedy miałbym startup i kiedy zacznę zarabiać (dużo), to powinno mówić samo za siebie.

Ale od tego czasu wszystko się zmieniło. Nadmierne kpiny podkopały wiarygodność moją i mojego produktu. Na początku byłem bardzo, bardzo przeciwny temu, by moja praca była pokazywana publicznie, ale uspokoiłem się, gdy stwierdziłem, że odpiera te fałszywe plotki o tym, o czym jest moja praca. Z tym, jak szybko się uspokoiłem, nawet nie zdawałem sobie sprawy, że tak bardzo mi przeszkadzało, że kwestionowano moje możliwości.

W tej chwili jest nawet duża szansa, że ​​przegram, a to zlikwiduje odstraszający. Ludzie, których zdenerwowałem, zrobiliby wszystko, co w ich mocy, aby powstrzymać mnie przed uruchomieniem mojego startupu.

O tych programach, które napisał „David”. Jeśli tych programów jest nie więcej niż kilkaset do tysięcy LOC, to wątpię, co on rozwiązał chwalebny problem. I żeby was rozczarować, to albo piszę spore oprogramowanie (ENR wciąż jest największym) jako produkty lub małe opakowania dla narzędzi Unix i tym podobne. Nie zawracam sobie głowy małym programem podpowiadającym wprowadzenie wartości przez CLI, wykonując drobne rzeczy.

Mam folder z moimi rozwiązaniami problemów kombinatronicznych - permutacja, kombinacje, rozwiązywane małymi funkcjami. Odpowiednie pliki testowe C funkcji to jedyne małe programy, które mam. Na samym początku tej podróży pomyślałem, że będę potrzebować tych funkcji. Okazało się, że tak nie jest. Cóż, i tak trzeba było to zapisać.