Myślę, że @Neo dostarczył solidnej odpowiedzi, jeśli chodzi o dokumentowanie i skupianie się na faktach, ale myślę również, że możesz pójść o krok dalej. Po prostu udokumentowanie / wskazanie, że implementacje Roberta nie działają, może pomóc ci się zabezpieczyć, ale nie rozwiązuje ostatecznego problemu (kod Roberta jest uszkodzony).

Zasadniczo masz możliwość wsparcia Roberta i przekształć to w doświadczenie edukacyjne dla was obojga.

Twój szef polecił Ci pomóc Bobowi, gdy poprosi Cię o pomoc. Ostatecznie oznacza to, że pomaganie Bobowi jest częścią Twojej pracy. Dajesz Bobowi rozwiązania, a jego implementacje nie działają. Do pewnego stopnia masz pewną odpowiedzialność, aby pomóc mu odnieść sukces. Jest kilka rzeczy, które możesz zrobić, aby zaradzić tej sytuacji:

1. Zanim dasz Bobowi rozwiązanie, upewnij się, że rozumiesz prawdziwy problem. Często mniej utalentowani programiści skoncentruj się na symptomie, a nie na głównym problemie. Jeśli daje ci symptom do rozwiązania, upewnij się, że oboje zgadzacie się co do pierwotnej przyczyny, zanim rozpocznie się dyskusja na temat rozwiązania.
2. Gdy masz już na myśli rozwiązanie, upewnij się, że ” dajesz mu to w sposób, który pomoże mu odnieść sukces. Jeśli jest mniej utalentowany od ciebie, możesz brać za pewnik rzeczy, o których on nie wie - jak zbudować lub wdrożyć rozwiązanie, jak skonfiguruj, przetestuj itp. Upewnij się, że Twoje instrukcje są wyraźne i kompletne. Dzięki temu odniesie sukces, zamiast nieustannie ponosić porażki, zanim natknie się na właściwą poprawkę.
3. Po wypróbowaniu Twojego pomysłu aktywnie pomóż mu przetestować go, zanim będzie miał szansę narzekać, że jest źle. Dzięki temu będziesz mógł „wyłapać” wszelkie problemy, zanim będzie mógł powiedzieć dyrektorowi technicznemu, że Twoje rozwiązanie jest bezwartościowe. Ten krok może obejmować przegląd kodu lub inny przegląd implementacji, ale zdecydowanie powinien obejmować przynajmniej weryfikację, czy rzeczywisty problem został naprawiony.
4. W ramach sekcji zwłok, gdy rozwiązanie jest już gotowe i działa, omów cały proces z Bobem. Omów, co zadziałało, a co nie podczas implementacji. Udokumentuj powody, dla których musieliście spróbować 5 lub 6 razy, zanim wszystko zadziałało. Udokumentuj swoje rozwiązanie i dlaczego je wybrałeś. Następnym razem, gdy przyjdzie do ciebie po pomoc, możesz zacząć od przejrzenia ostatnich rozwiązań - pomoże to wam obojgu uniknąć ciągłego popadania w te same problemy.

To wszystko może brzmieć jak dużo pracy , ale ogólnie rzecz biorąc, na dłuższą metę łatwiej / lepiej jest robić rzeczy „właściwie” w sposób, który pomaga ludziom uczyć się na błędach, niż po prostu uderzać w najszybsza / najłatwiejsza naprawa. Podsumowując: Jeśli ktoś poprosi Cię o pomoc, upewnij się, że Twoja pomoc jest rzeczywiście pomocna, zamiast po prostu rzucać mu pomysł na kolana i iść dalej.

Czy ktoś może mi zasugerować, jaka byłaby dobra strategia radzenia sobie w tej sytuacji?

Dokument, dokument, dokument .

Za każdym razem, gdy musisz posprzątać bałagan Boba, udokumentuj go i skopiuj CTO. To może nie wydawać się najmilszą rzeczą do zrobienia, ale w tym momencie byłbym bardziej zaniepokojony moją reputacją w firmie , aw szczególności wrażeniem dyrektora ds. Technologii o tobie, ponieważ wydajesz się być tym jedynym CTO się złości.

Pamiętaj, dokumentując tego typu działania, tylko zgłaszaj fakty. Nie ma potrzeby upiększania, CTO może połączyć 2 + 2. Robiąc to, szybko zobaczy, kto dodaje więcej wartości, a kto więcej „mówi”.

Nie jest to przyjemne, ale nie widzę innego skutecznego sposobu radzenia sobie z nim.

Teraz, gdy napotyka problem, nasz CTO sugeruje, że powinien się ze mną skonsultować. W 80 do 90 procentach czasu jestem w stanie naprawić jego problem i informuję dyrektora ds. Technicznych, że dostarczyłem mu rozwiązanie.

...

Słuchając go, CTO zawsze się na mnie złości i za każdym razem daje mi solidną naganę.

To naprawdę się nie zgadza i myślę, że oznacza to, że źle interpretujesz, co jest z ciebie sfrustrowane CTO o. Zgadzam się z twierdzeniem dwizuma, że ​​„pomaganie Bobowi jest częścią twojej pracy”, ale poszedłbym o krok dalej. W rzeczywistości jesteś liderem Boba. Twój dyrektor techniczny nie chce po prostu udzielić Bobowi porady i odejść. Chce, abyś wziął odpowiedzialność za upewnienie się, że praca zostanie wykonana poprawnie. Jestem całkiem pewien, że nadal kieruje Boba do ciebie. Gdyby CTO myślał, że to Ty jesteś problemem, nie zrobiłby tego.

Pomyśl o tym z perspektywy CTO. Bob wchodzi i mówi, że ma jakiś problem. CTO nie ma czasu dla Boba. Wysyła go do ciebie po pomoc. Daj mu jakąś pomoc, Bob jej nie łapie i wraca do CTO. CTO chciałby tylko, żebyś miał do czynienia z Bobem i przejrzał sprawy. Nie chce rozmawiać z Bobem o swoich problemach. Chce tylko, żeby praca została wykonana.

Myślę, że powinieneś szczerze porozmawiać z CTO o tej sytuacji. Zasadniczo są tutaj dwie ścieżki. 1. Bob jest sam. Udaje mu się lub przegrywa na własnych zasługach. 2. Jesteś właścicielem wyniku i jesteś odpowiedzialny za upewnienie się, że to, co robi Bob, jest słuszne. Wydaje się, że CTO chce tej drugiej opcji, ale nie przekazał ci tego jasno. Jeśli ty i Bob jesteście rówieśnikami, może to być dobry moment, aby porozmawiać o awansie. Jeśli jesteś liderem, powinieneś być przynajmniej za to uznany i możesz spodziewać się rekompensaty. Założę się, że już otrzymałeś wyższe wynagrodzenie niż Bob.

Czy podczas sprawdzania kodu pracy Roberta nie zauważyłeś problemów? Dokonałeś przeglądu kodu, prawda?

Czy podczas testowania pracy Roberta testy wykryły awarie? Wykonałeś zautomatyzowane testy, prawda?

Nic nie trafia do produkcji - ani nawet do testowania, gdzie może to zobaczyć każdy spoza zespołu programistów - dopóki kod nie zostanie sprawdzony . Zaimplementuj proces przeglądu kodu i trzymaj się go . Kiedy Bob robi coś, o czym nie mówiłeś, dowiadujesz się podczas przeglądu kodu i albo ty, albo on, przerabia to, aż będzie to akceptowalne.

Powiedz też Bobowi, że chociaż nadzorujesz, nie odpowiedzialny za jakość swojej pracy; on jest. Każdy programista powinien umieć krytycznie ocenić jakość swojej pracy. Obwinianie cię za coś, co zrobił źle, jest nieprofesjonalne.

Jest tu już kilka świetnych pomysłów, które warto rozważyć. Oto inna myśl. Kiedy wymyślisz rozwiązanie dla Boba, zamiast je przekazać i zająć się innymi rzeczami, możesz usiąść z Bobem i przez godzinę lub dwie programować z nim w parach. Może to być po prostu sposób na upewnienie się, że dobrze się rozpoczął, lub może się okazać, że w trakcie tego procesu samemu dochodzisz do głębszego zrozumienia problemu.

Organizacje często unikają programowania w parach ponieważ uważają, że praca dwóch inżynierów nad tym samym fragmentem kodu jest marnotrawstwem. Istnieją jednak statystyki wskazujące, że oszczędności wynikające z unikania błędów przewyższają koszt „marnowania” czasu jednego inżyniera. Jeśli myślisz, że możesz to zrobić, możesz przejrzeć literaturę dotyczącą programowania w parach, aby przedstawić argumenty przemawiające za tym z CTO.

Masz już tutaj świetne odpowiedzi. Mam kilka drobnych dodatków:

Podczas nauczania lub dostarczania Bobowi rozwiązań pamiętaj, że nie wszyscy komunikujemy się ani nie uczymy się w ten sam sposób, więc jest to coś, czego uczysz w sposób, który Twoim zdaniem byłoby to zrozumiałe, może nie być zrozumiałe dla Boba. Dobrym sposobem, aby się tego dowiedzieć, jest poproszenie Boba o powtórzenie wszelkich instrukcji lub informacji, które mu przekazałeś, własnymi słowami, aby upewnić się, że dobrze Cię zrozumiał.

Inną rzeczą, która może być dobrym pomysłem, byłaby aby zaangażować stronę trzecią, najlepiej kogoś, kto może być bezstronny lub bezstronny i działać jako mediator lub doradca Bob i Ciebie. Jeszcze lepiej byłoby, gdyby osoba trzecia została uznana za profesjonalistę na równi z Bobem, aby Bob czuł się bardziej komfortowo.

Dynamika grupy byłaby zupełnie inna niż to, co Ty i Bob macie, kiedy jesteście tylko we dwoje. W tej chwili jesteś dawcą i on jest biorcą lub jesteś nauczycielem i on jest uczniem - tak czy inaczej, to nie jest przepis na bliskość, więź czy komfort, a może nawet powodować niezręczność, która jest wystarczająco silna, aby uniemożliwić mu słuchanie razy, gdy jest zajęty w swojej głowie.

W grupie Bob ma szansę zidentyfikować się z osobą trzecią, a nawet wziąć od niej kilka wskazówek. Otwiera to możliwość dla strony trzeciej podania przykładów zadawania pytań, parafrazowania tego, czego nauczono, a nawet teoretyzowania na temat kreatywnych sposobów wykorzystania nowo zdobytej wiedzy, aby pokazać, w jaki sposób może być pomocna.

Moja dwójka centów.

Jako menedżer na poziomie C, jeśli to potrwa zbyt długo, zwolnię was obu. Wszyscy pracownicy firmy muszą być jako grupa zaangażowani w realizację celów firmy. CTO dba o osiągnięcie celów firmy i poprosił cię o pomoc Bobowi, więc chce, abyś pomógł Bobowi i rozwiązał problem, i oczekuje, że jesteś w stanie to zrobić. Nie obchodzi go, kto jest winny. Jest zły, ponieważ problem nie został rozwiązany i zamiast tego, żebyście go rozwiązali, tracicie jego czas na swoje drobne kłótnie. Dotyczy to was obojga, więc rozwiążcie to między sobą jako dorośli.