Odzyskiwanie zaufania starszego programisty [zamknięte]

Mój szef odkrył, że nie jestem tak mądry, jak myślał.

Przykład z mojego doświadczenia:

Jestem młodszym programistą i pracuję w zespole dwóch osób, mojego szefa (starszego programisty) i siebie.

Miałem za zadanie opracować wewnętrzną aplikację internetową dla firmy, w której pracujemy. Napisałem back-end do frontonu (projekt bazy danych był już na miejscu i wybrano technologię serwera). Okresowo sprawdzał moje postępy, obserwując działającą aplikację internetową i był zadowolony, że nadchodzi. Kiedy skończyłem aplikację internetową, był zadowolony z tego, jak dobrze wyszedł produkt końcowy.

Kilka dni temu zainteresował się kodem, więc powiedziałem mu, z jakich technologii korzystam (w interfejsie), i właśnie tam poszedł na południe. W interfejsie aplikacji korzystałem z frameworka JavaScript (Backbone.js). Zapytany, dlaczego miałbym to zrobić. Moja odpowiedź była taka, że ​​czułem, że framework całkiem dobrze pasuje do tej aplikacji i pomógłby mi lepiej ustrukturyzować kod, niż gdybym napisał go od zera… „Cóż, to było rozczarowujące” to była jego odpowiedź.

Biorąc pod uwagę ten przykład, moje pytanie brzmi:

Jeśli jesteś starszym programistą i straciłeś zaufanie do zdolności swojego młodszego programisty, co chciałbyś zobaczyć od swojego młodszego programisty, aby odzyskać pewność siebie?

EDYCJA : Dziękuję wszystkim za wspaniałe odpowiedzi i wsparcie!

Jeśli podobał mu się produkt, który zbudowałeś, ale zależy ci na użyciu kręgosłupa, obaj musicie porozmawiać o pożądanym stosie technologii.

Jako programiści powinniśmy używać narzędzi, które są łatwo dostępne, a tym samym płynnie przesuwać nasz przepływ pracy. Jeśli spodziewał się, że zbudujesz front-end od zera, powinien był być wyraźny i mieć dobry powód.

Fakt, że początkowo podobał mu się ten produkt, jest wystarczającym dowodem na to, że dobrze się spisałeś i że jesteś wystarczająco „inteligentny”.

tl; dr Dobrze się spisałeś. Porozmawiaj ze swoim seniorem i zobacz, czego on od ciebie oczekuje.

Wydaje mi się, że nie jest zbyt „starszy”, by móc szybko zadzwonić. Zawsze staram się używać właściwego frameworka zamiast anty-wzoru „Reinvent the square wheel”. Gdyby był naprawdę starszy, zrozumiałby i znał wartość dobrych ram. W najlepszym razie spodziewałbym się, że zakwestionuje wybór Backbone.js w stosunku do innej struktury JavaScript MVC i znacznie wcześniej. Nie udało mu się odpowiednio mentorować i sprawdzać cię jako juniora i pomagać ci na właściwej ścieżce rozwoju (w jego umyśle).

Wygląda na to, że dokonałeś właściwego wyboru przy opracowywaniu projektu, biorąc pod uwagę brak ukierunkowania z jego strony (założenie) i pracujesz nad byciem bardziej kompetentnym programistą. Sądzę, że wyjaśnienie mu wyboru frameworka może mieć wartość, dlaczego uważasz, że frameworki są odpowiednie, i zwróć uwagę, że projekt został wykonany, a jego satysfakcja częściowo wynika z zastosowania dobrze udokumentowanych i wspieranych frameworków. Jeśli nie możesz zrobić postępu, być może nie ma sensu wyglądać lepiej w jego oczach. Tylko Ty możesz na to odpowiedzieć.

Większość odpowiedzi i komentarzy ma właściwy pomysł, ponieważ ty i senior musielibyście przeprowadzić jakąś dyskusję i że może być ważne, abyście podnieśli i bronili swoich decyzji, nawet jeśli senior nie zgadza się z waszymi wyborami .

Aby odpowiedzieć na pytanie dotyczące tego, co chciałbym widzieć jako starszy:

Chciałbym zobaczyć, czy moi młodsi programiści mogą wstać i obronić jego decyzje, nawet jeśli będą słabym rozczarowaniem. Gdybym był zadowolony z produktu, ale nie z wdrożenia, oczekiwałbym, że juniorzy podkreślą, że powinienem być bardziej szczegółowy w moich specyfikacjach, podając im produkt. Chciałbym, aby byli w stanie przetrwać, ale także przyznać, że w takim przypadku mogliby nie dokonać właściwego wyboru.

PS: Muszę wspomnieć, że jestem seniorem, który uwielbia udowodnić, że się myli na poziomie zawodowym, ponieważ daje mi to możliwość nauczenia się czegoś nowego. I lubię być świadomy tego, jak inni w moim zespole robią rzeczy, aby nie było żadnych niespodzianek na końcu zadania / sprintu.

Przede wszystkim myślę, że należy to postrzegać jako szansę, a nie porażkę. Oczywiste jest niedopasowanie oczekiwań i nie jest jasne, skąd się bierze, co musi się stać, aby wszystko wróciło na właściwe tory i tym podobne.

Po drugie, jeśli potraktujesz to jako bieżącą awarię lub nie jesteś tak mądry, jak myślisz, że tworzy relacje mocy, których nie chcesz. Więc jeśli podejmujesz decyzje, które uważasz za możliwe do obrony, musisz być gotowy do ich obrony do pewnego momentu.

Chociaż zgadzam się z niesamowitym, że chcesz rozmawiać, to nie wystarczy. Musisz być przygotowany do wejścia, przedyskutowania pomysłów na projekt, wyjaśnienia, dlaczego zrobiłeś to, co zrobiłeś i obrony uzasadnienia. Musisz także zaakceptować fakt, że nie ma tylko jednej poprawnej odpowiedzi i że starszy programista może mieć uzasadnione powody, by preferować inny projekt i dlatego chcesz być chętny do wysłuchania tych powodów, nie przyznając, że twoje decyzje były złe na temat tego, co wiedziałeś (chyba że zdecydujesz, że powinieneś był wiedzieć lepiej, a to inna sprawa).

Pamiętaj, że projektowanie to zazwyczaj kwestia kompromisów. Chcesz być chętny do dyskusji na temat kompromisów i zobacz, co oboje możecie zrobić, aby mieć pewność, że będzie można omówić kompromisy projektowe w przyszłości. Może oboje oczekujesz, że jesteś na tej samej stronie bardziej niż ty? Może twój szef jest idiotą (może się czasem zdarzyć)? Może naprawdę podjąłeś błędną decyzję, biorąc pod uwagę to, co wiesz o wymaganiach? Wejdź jednak z otwartym umysłem i pewnością siebie i bądź gotów naprawdę o tym porozmawiać.

Edycja: Chcę dodać coś o byciu inteligentnym. Najmądrzejsi ludzie, których znam, to ludzie, którzy uważają, że mają coś do nauczenia się od wszystkich. Ludzie, którzy są zamknięci i wierzą, że istnieje tylko jeden właściwy sposób, nie podejmują wyobraźni dobrych decyzji w obszarach takich jak projektowanie i nie mogą łączyć rzeczy w sposób, w jaki ludzie, którzy chcą uczyć się od wszystkich, mogą. Wchodzenie i chęć dzielenia się pomysłami, a nawet odrzucania ich w obie strony, jest oznaką zarówno bycia inteligentnym, jak i pewnym siebie. Różnice w projekcie niekoniecznie stają się kwestią tego, że jedno jest lepsze od drugiego. Zakładając kompetentnych projektantów, różne projekty będą różnie zoptymalizowane.

Mam ogólną opinię, że nie zrobiłeś nic złego. Jako starszy programista powinien był zainteresować się tworzeniem aplikacji, a także jej wynikami. Przyjście po zakończeniu projektu i powiedzenie, że nie podoba mu się jego realizacja, nie jest z jego strony bardzo profesjonalne.

Ale, aby odpowiedzieć na twoje główne pytanie: w jaki sposób odzyskujesz opinię seniora po tym, jak mogła zostać utracona? Przede wszystkim zapytaj, jak się czują, że powinieneś to zrobić. Zadawaj pytania, jeśli nie rozumiesz i robisz notatki. Pokaż, że chcesz się uczyć.

Po drugie, jeśli masz coś, co zostało pominięte w opisie, wymyśl swoje pomysły, a następnie uruchom je przez starszego programistę. Nie spiesz się z pytaniem, jak to zrobić, b / c to nie pomoże ich opinii o tobie. Ale jeśli wpadniesz na swoje własne pomysły i własne rozwiązania, zapytaj ich, czy jesteś na dobrej drodze, pokaże im, że próbujesz i że masz umiejętności niezbędne do wykonania pracy. Może to być tak proste, jak szybki e-mail z informacją: „Hej, planuję używać x podczas robienia y . Wszelkie myśli?”

Po trzecie, kiedy wpadną do głowy, aby zobaczyć, jak się masz, nie pozwól im odejść, nie patrząc na kod.

Zasadniczo otwórz linie komunikacji. Wygląda na to, że twój starszy programista nie jest typem ciebie lub twojego kodu, więc musisz się zwiększyć i być osobą, która się komunikuje. Dla wszystkich zaangażowanych lepiej jest dowiedzieć się, że coś nie jest pierwotnie sądzone wcześniej niż później.

Jedną rzeczą, którą musisz od razu dowiedzieć się od nietoperza, jest to, czy jest on zniechęcony, ponieważ nie mógłbyś dać kompleksowej obrony wybranemu przez siebie frameworkowi, czy też dlatego, że użyłeś szkieletu.

W pierwszym przypadku ważne jest, abyś nauczył się oceniać i wybierać kod strony trzeciej do włączenia do projektu oraz że umiesz przekazać swoją decyzję przełożonym i przygotować się do jej uzasadnienia. Jest to trudna umiejętność do nauczenia się, ale wiąże się z doświadczeniem. Jest to również dobra umiejętność do nauczenia się, ponieważ gdy tylko włączysz bibliotekę strony trzeciej do projektu, wprowadzasz komponent, który może nie być w pełni zrozumiany przez innych programistów, że nie mają oni pełnej kontroli i mogą zawierać błędy, dziury w zabezpieczeniach i inne rzeczy, o których powinni wiedzieć.

Jeśli jest rozczarowany, ponieważ nie napisałeś go od zera, to zupełnie inna sprawa. Być może ma on dobry powód, aby zniechęcać do korzystania z frameworków (takich jak te, które opisałem powyżej), a może istnieje polityka firmy wobec nich lub ograniczenie wyboru frameworków, które możesz stworzyć. Tak czy inaczej, powinien był ci to przekazać, a także fakt, że nie oznacza to niepowodzenia z jego strony. Z drugiej strony może on mieć tylko przypadek uprzedzeń ramowych, ponieważ pomimo problemów, które mogą prowadzić do ram, mają one również znaczące korzyści, jak jestem pewien. Może po prostu pomyśleć, że powinieneś zrobić wszystko sam, nawet jeśli oznacza to ponowne wykonanie pracy, która została już wykonana i udostępniona publicznie z powodu zespołu „Not Invented Here”.

To, że nie wyjaśnił, dlaczego jest tobą rozczarowany, że używasz frameworka, jest z pewnością jego skuteczną komunikacją. Porzucił cię, zastanawiając się, co zrobiłeś źle, skoro odpowiedź może brzmieć „nic”. Zmusił cię również do zadawania sobie pytań, a to sprawi, że będziesz mniej skłonny do korzystania z własnej inicjatywy w przyszłości. Jeśli jest jedna cecha, na którą dobry programista nie może sobie pozwolić, to brak inicjatywy. I chociaż jestem pewien, że to niezamierzone, jego postawa szkodzi morale, gdy nagle wycofał się z pochwały za dobrze wykonaną pracę nad jednym drobnym szczegółem tego, jak wykonałeś to zadanie.

To, że jest on starszym programistą, nie czyni go nieomylnym.

Twój komentarz uzupełniający, że szef jest zdenerwowany, musi nauczyć się czegoś nowego ...

Jeśli nie ma w tym nic więcej, o czym nie wspomniałeś, byłbym na niego zirytowany.

Uczenie się nowych technologii jest ważną częścią naszej pracy i każdy zespół powinien obejmować naukę i samodoskonalenie.

ALE, kierownictwo ma inne rzeczy do zmartwienia. Mają terminy do dotrzymania, mają ograniczony budżet szkoleniowy lub nie mają go wcale.

Z punktu widzenia zarządzania ludźmi może to być ktoś inny, kto pracuje nad drugą fazą projektu zamiast ciebie. Twój szef może wyznaczyć kogoś innego do wykonania tej pracy, a on wie, że ta osoba ma teraz krzywą uczenia się dla czegoś nowego.

A teraz ALE na poprzednim ALE ...... to wina twojego szefa. Jeśli jesteś nowy i młodszy, powinien udzielić przynajmniej wskazówek. W mniejszym stopniu mogłeś poprosić o wskazówki dotyczące technologii, z której chcesz skorzystać.

Jeśli jesteś starszym programistą i straciłeś zaufanie do zdolności swojego młodszego programisty, co chciałbyś zobaczyć od swojego młodszego programisty, aby odzyskać pewność siebie?

Biorąc pod uwagę, że powiedziałeś, że nie chciał nauczyć się korzystać z frameworka, którego użyłeś, myślę, że pytanie powinno brzmieć: „ Jeśli jesteś starszym programistą i straciłeś umiejętność uczenia się od swojego młodszy programista, co powinieneś zrobić, żeby się załatwić? ”

Jako profesjonalny programista nie przestajesz się uczyć. Zawsze. Jeśli to zrobisz, popadniesz w stagnację. I może być dobrze w niektórych obszarach. Bankowość ma wiele działających systemów, które wymagają konserwacji, więc znajomość starych systemów, które poruszają się bardzo wolno, jest w porządku. Mój przyjaciel redagował COBOL dla banku, aby dowiedzieć się, że poprawiony przez niego kod źródłowy nie został dotknięty przez około 30 lat (a oryginalnym autorem był nasz wykładowca COBOL na uniwersytecie) ... To powiedziawszy, wciąż musi uczyć się nowych rzeczy, ponieważ stare systemy muszą zostać zintegrowane z nowymi systemami.

Wróć do swojego starszego programisty. Powiedziałeś „ był zdenerwowany tym, że musiał nauczyć się czegoś nowego ”, i moim zdaniem jest to bardzo głośne dzwonki alarmowe.

Zawsze się uczę. Chociaż naprawdę chciałbym, aby mój pracodawca co roku odbierał mój rachunek edukacyjny, rzadko zdarza się, aby wydawali coś zbliżonego do tego, co czuję, że naprawdę potrzebuję, ale wiem, że muszę zachować zatrudnienie, więc wydaje mi się, że gdzieś w okolicy 2000 GBP Co roku GBP (około 3000 USD) z własnej edukacji.

Jeśli twój senior nie uczy się nowych rzeczy, zacznie podejmować złe decyzje (być może już są), a jakość kodu, z którym masz do czynienia, spadnie, ponieważ utknęły w rutynie i nie czują potrzeby z tej koleiny.

Jednym z najlepszych programistów, z którymi kiedykolwiek współpracowałem, był młodszy programista, który znał różne rzeczy, na które nigdy nie miałem okazji spojrzeć. Przyniósł tak wiele do stołu, że często byłem przytłoczony. Ale doceniałem jego wysiłki i nigdy nie byłem „rozczarowany” żadnym z nich. Byłem zadowolony, że poświęcił czas, aby docenić wszystkie możliwości i przedstawić je zespołowi. Teraz kieruje zespołem i ciągle mi mówi o programistach, którzy wprowadzają rzeczy do stołu i czego się od nich uczy.

Twój starszy programista musi się uczyć. Muszą nauczyć się nie używać emocjonalnych słów (takich jak „zniechęcające”), aby ukryć swoje niedociągnięcia, ponieważ to podważy zaufanie innych. Muszą nauczyć się nowych ram (nawet jeśli nie są w stanie nauczyć się wszystkiego, dowiedzieć się, jak to działa i jak rozwiązuje problem, a jeśli będą go potrzebować w przyszłości, mogą poświęcić czas na głębszą naukę). Muszą się nauczyć, że są w pracy, w której będą musieli się cały czas uczyć.