Jakie są najważniejsze rzeczy, których programista oczekuje od starszego programisty?

41

Niedawno przeczytałem 5 następujących rodzajów bossów i jak sobie z nimi radzić , które opisują stroje najgorszego bossa. Właśnie zacząłem kierować małym zespołem programistów.

Chciałbym wiedzieć, jakie są najważniejsze rzeczy, których programista oczekuje od starszego programisty, oraz jakich rzeczy powinniśmy unikać kierując zespołem.

Chciałbym również wiedzieć, jak zapewnić programistom satysfakcję i stworzyć środowisko produktywne i kompletne dla mojego zespołu.

Awatara
źródło
19
joelonsoftware.com Przeczytaj tyle jego bloga, ile masz czasu.
P.Brian.Mackey,
@ P.Brian.Mackey niesamowity link!
Avatar
2
Że starszy programista ma Miyazaki związane awatar to chyba nie musi, ale na pewno duży plus :-)
leonbloy
1
Ciekawe ... Mój szef zdobył 4 na 5 punktów w tym teście ... Powinienem powiadomić go o dobrych wiadomościach;)
Aeo

Odpowiedzi:

79

Rzeczy, które wydają mi się dobrze działać:

  • Daj sensowną pracę i zachęcaj do własności - nawet jeśli pojawi się problem, nie rozwiązuj go, porozmawiaj o nim i daj osobie wgląd, aby mógł rozwiązać go samodzielnie.
    • edytuj - dodawaj - miało to również obejmować - nie zwracaj uwagi na szczegóły. Załóżmy, że Twoi ludzie wiedzą wystarczająco dużo, aby wykonać zadanie bez mikrozarządzania lub wymogu ciągłej odprawy. Zbuduj zestaw wskazówek dotyczących tego, kiedy powinni się zameldować - co powinno mieć miejsce tylko wtedy, gdy praca jest wykonywana lub tak naprawdę pomieszana, że ​​poważna interwencja jest potrzebne. Jeśli to możliwe, trzymaj się z daleka od konieczności bycia na bieżąco w kwestiach dotyczących wsparcia między drużynami.
  • Szczerze mówiąc - ma kilka następstw:
    • Bądź szczery o sobie - „nie będę miał czasu do wtorku”, „Nigdy tego nie zrobiłem, oto moje najlepsze przypuszczenie” itp.
    • Szczerze mówiąc o zespole i miejscu, w którym mieszczą się w firmie - jeśli wiesz coś o sprawach biznesowych, powiedz im, jeśli możesz, i powiedz im to, co znasz jako proste fakty.
    • Bądź szczery, udzielając informacji zwrotnej - nie miel słów ani nie naciskaj pedału, jeśli masz negatywną opinię. Różni się to od „brutalnie uczciwego” - nadal możesz mieć współczucie, ale jeśli coś jest nie tak, powiedz tak.
    • Bądź szczery, gdy wiesz, że praca polega bardziej na nagrywaniu niż na wykonywaniu czegoś sensownego. W życie każdego spadnie jakaś bezsensowna praca. Nie udawaj, że to ma sens. Nazwij to tak, jak jest, abyś mógł skupić się na ominięciu tego i przejściu do czegoś pożytecznego.
  • Słuchać . Co najmniej 50% twojej pracy to słuchanie, a może więcej. Nagle staliście się odpowiedzialni nie tylko za prace techniczne, ale także za ludzi, którzy to robią. Musisz posłuchać, aby dowiedzieć się nie tylko o problemach zespołu, ale także o tym, jak twoi ludzie podchodzą do problemu i jakie są wady zespołu jako grupy.
    • Ważna konsekwencja - słuchanie może bezpośrednio prowadzić do punktu 1 - dawanie znaczącej pracy - inżynierowie świetnie wymyślają sposoby ułatwienia rozwoju. Nie możesz zatwierdzić wszystkiego, ale jeśli pomysł jest dobry, powierz inżynierowi zadanie, a oni zasadniczo wykonali dla ciebie pracę - stworzyli znaczącą pracę i powiedzieli dokładnie, co to jest.
  • Powiedz „dziękuję” . Wiem, wydaje się to oczywiste. Chociaż wszyscy kochamy pieniądze, lepsze narzędzia, przyjemniejsze środowisko pracy i promocje - drogą do tych rzeczy jest seria dobrych starań, z których każda zasługuje na „dziękuję”. „Dziękuję” jest całkowicie darmowe, nigdy ich nie zabraknie, a wiedza, że ​​Twój menedżer widział i doceniała twoją ciężką pracę, zdecydowanie motywuje.
  • Spędź czas na dużym obrazie , nawet jeśli oznacza to poświęcenie części codziennej pracy, która zapewniła ci pozycję. Prawdopodobnie to prawda, że ​​możesz kodować lepiej niż niektórzy z twoich ludzi, ale jeśli nie spędzasz przyzwoitego zestawu czasu na dużym obrazie - zespół, ogólny kierunek projektu, stan twojej bazy kodów, wydajność procesów , środowisko Twojego zespołu - wtedy nie będziesz wykonywać pracy, do której są zobowiązani.
  • Naucz się być buforem dla swojego zespołu . Zespoły inżynieryjne działają najlepiej, gdy mają czas na ... inżynierię. Biurokracja korporacyjna to nie inżynieria. Wszystko, co możesz zrobić, aby wziąć irytujące 1 spotkanie rocznie / miesiąc / tydzień z ludźmi zewnętrznymi, jest lepsze. UWAGA: Nie oznacza to zwinnych spotkań z interesariuszami - to inżynieria, twój zespół musi tam być. Mam na myśli spotkanie z placówkami, które chcą umieścić głośny, wrzeszczący kawałek maszyny w pobliżu twojego zespołu lub grupą procesową, która chce, aby Twój zespół wypełnił dokumenty w trzech egzemplarzach, zanim jakikolwiek kod zostanie sprawdzony. Jesteś systemem pochłaniania uderzeń.
  • Załóżmy, że ludzie problemowi nie są źli , to ludzie, którzy chcą czynić dobro, ale jeszcze nie wymyślili, jak to zrobić. Nie będziesz w stanie naprawić wszystkich, ale często kilka pierwszych kompletnych wpadek jest zarówno czynnikiem nieudanej komunikacji, jak i niekompetencji lub umyślnej złośliwości. Jeśli zaczniesz od założenia, że ​​ludzie nie są źli, masz przyzwoitą nadzieję na uniknięcie szeregu archetypów złych bossów z powyższej listy.

I chyba najważniejszy ... szacunek . Jeśli szczerze nie możesz szanować członków swojego zespołu, musisz pracować nad zmianą tego (czy to uczy ludzi, czy zmieniasz liczbę pracowników). Daj szacunek pierwszego dnia, a otrzymasz go z powrotem, traktuj ludzi z brakiem szacunku, a nigdy nie otrzymasz szacunku w zamian.

Reasumując, jeśli robisz większość tych rzeczy, przez większość czasu twój zespół daje ci wątpliwości, kiedy pokazujesz, że jesteś człowiekiem i całkowicie coś spieprzysz. :) Każdy szef ma swoje wady, i tak samo chodzi o wypracowanie relacji ze swoim zespołem, w którym mogą pomóc ci zrekompensować twoje słabości, tak jak pomagasz im z ich.

bethlakshmi
źródło
1
świetna odpowiedź, dodałbym do tego, by dać im wolność . Nic gorszego niż mikrozarządzanie lub prośba o pozwolenie na każdy najmniejszy szczegół.
agradl
3
Naprawdę niesamowite .. Chciałbym, aby StackExchange mógł zapewnić wsparcie następującym użytkownikom (krótka uwaga dla Joela i Jeffa) :)
PrinceCoder
2
WAAOW !! ... to była jedna z najlepszych odpowiedzi, jakie kiedykolwiek spotkałem @Stackexchange
odkrywca
wow i wow. i ponieważ muszę wpisać kilka dodatkowych znaków, aby przesłać ten komentarz, wow.
Amir Afghani,
2
@PrinceCoder każdy użytkownik ma swój kanał, możesz to śledzić w niektórych czytnikach RSS.
svick
12

Jedną z największych rzeczy do nauczenia jest to, że bardzo często nie będziesz w stanie zapewnić im szczęścia, ponieważ po prostu nie będziesz w stanie dać im tego, czego chcą.

Najlepsi menadżerowie, dla których pracowałem, to najbardziej uczciwi faceci, którzy będą bronić swojego zespołu przed wszystkimi bzdurami, które starają się rzucić na nich kierownictwo, a przede wszystkim SŁUCHAJĄ swojego zespołu.

ozz
źródło
2
Istnieje duża różnica między menedżerem a starszym programistą. Nie spotkałem jeszcze menedżera takiego jak ty. Powiedz mi, gdzie mogę je znaleźć ;-)
fretje,
To prawda, tak mówi tytuł, ale pytanie dotyczy bossów. W swojej karierze miałem wielu dobrych menedżerów / liderów.
ozz
+1 @James ktoś zredagował tytuł. Przez pytania stoi o potencjalnych klientów / menedżerów. Słowo „szef” wygląda ostro, więc wybrałem słowo starszy programista.
Awatar
6

Mocno wierzę, że jedną z najważniejszych kwestii bycia seniorem lub ołowiu jest dostępność dla osób młodszych. Seniorzy i potencjalni klienci często mają zadania, które tylko oni mają prawo wykonywać (na przykład nie dajemy juniorom prawa do pisania scenografii i dźgania). Ponadto znaczną częścią pracy jest mentoring młodszych osób, co oznacza odpowiadanie na pytania, a nie ignorowanie ich. Im wyższy jesteś, tym bardziej prawdopodobne jest, że przeszkadzają ci inni, którzy czegoś od ciebie potrzebują. Musisz porzucić znak „nie przeszkadzać” i nauczyć się pracować z przerwami.

Słuchanie jest ważne.

Proszę i dziękuję, jesteś ważny i nic nie kosztuje.

Nie oczekuj więcej niż jesteś gotów dać. Jeśli chcesz, żebym pracował do 3 nad ranem, to lepiej, żebyś był obok mnie i pracował. Nie ma nic bardziej zniechęcającego niż praca dla kogoś, kto codziennie wychodzi na czas natychmiast po tym, jak wykonasz zadanie, które należy wykonać do godziny 7 rano.

Być uczciwym. Nie odtwarzaj ulubionych (szczególnie nie odtwarzaj ulubionych, dając swojej dziewczynie lub chłopakowi najlepsze rzeczy). Traktuj wszystkich pracowników z szacunkiem (nawet osoby, których osobiście nie lubisz).

Być stanowczym. Nie pozostawiaj decyzji zawieszonych, aby nikt nie mógł postępować ani gorzej zmieniać co pięć minut.

W obronie swojego ludu. Nie wygrasz ich wszystkich, ale ludzie przejdą przez ogień dla kogoś, kto je wspiera.

W razie potrzeby bądź gotów być złym facetem. Jedno złe jabłko może zniszczyć zespół deweloperów, nie trzymaj się tej osoby, ponieważ nie chcesz skonfrontować jej złego zachowania (dotyczy to w większym stopniu potencjalnych klientów i oficjalnych przełożonych). Kiedy masz złe wieści, powiedz drużynie, nie trzymaj tego w tajemnicy (w końcu się dowiedzą, a potem będą wściekli zarówno z powodu złych wiadomości, jak i tajemnicy). Nie jesteś popularny, ale po to, aby wykonać zadanie. Każdy, kto zajmuje stanowisko kierownicze lub quasi-kierownicze, musi być skłonny do niepopularności.

Naucz się sprzedawać pomysły wyższym awansom i naucz je tych twórców.

Zrozum znaczenie domeny biznesowej i zostań ekspertem w tej dziedzinie, a także programowaniu.

HLGEM
źródło
3

Tymi słowami kluczowymi są zaufanie i odpowiedzialność.

Musisz tylko zaufać, że członkowie twojego zespołu są kompetentni i skoncentrowani na wykonywaniu swoich zadań. Nie wtrącając się zbytnio, zasadniczo pozwalasz im „ponosić” odpowiedzialność za swoją pracę.

IMHO, to samo czyni cuda w tworzeniu zdrowej atmosfery.

Jas
źródło
2
Pod warunkiem, że wystarczająco kompetentni i zmotywowani. Jeśli zespół jest odziedziczony w takim stanie, nie jest to niestety dane. Jeśli sam wybierałeś członków, to oczywiście inna historia.
Péter Török,
1
Cóż, moim zdaniem, nawet ci, którzy nie są zbyt kompetentni, kiedy otrzymają pełną odpowiedzialność, czyli „własność” części projektu, zrobią wszystko, co trzeba, aby wykonać swój kawałek. Nie dbam nawet o to, czy część kodu jest gromadzona przez zadawanie pytań na forach i forach, o ile zadanie zostanie wykonane.
Jas
niestety spotkałem kontrprzykłady :-( W najgorszym przypadku, jaki widziałem, programista nie wyprodukował absolutnie nic, kiedy otrzymał wolność i pełną odpowiedzialność przez około dwa miesiące - jak się okazało, nawet nie przyszedł do pracy. Niektórzy ludzie po prostu nie podnoszą ciężaru w zespole, a jeśli pozwolisz im biegać swobodnie bez ścisłej kontroli, tylko pogorszysz sytuację. Jeśli nie pozbędziesz się tych ludzi na czas, mogą zaszkodzić całej drużynie.
Péter Török
@ Péter Török - jasne, każdy zna kilka takich osób w każdej firmie (właściwie czytając to, myślałem, że znasz tego samego faceta jak ja :). Ale z mojego doświadczenia wynika, że ​​większość ludzi koncentruje się i stara się dać z siebie wszystko.
Jas
Zgadzam się, większość ludzi stara się dać z siebie wszystko. (Czy powinienem powiedzieć, że każdy stara się zrobić co w jego mocy - tylko dla niektórych „najlepsze” nie osiąga progu zauważalności? :-) Należy zachować czujność, aby zauważyć wyjątki na czas - ponieważ wyjątki. Podobnie jak w kodzie produkcji, musi obsługiwać przypadki błędów poprawnie, chociaż są one rzadkie w normalnych okolicznościach.
Péter Török
3

Cóż, IMO oczekuję, że starszy programista / lider / cokolwiek poprowadzi zespół deweloperski przeciwko idiotycznym terminom, brakom zasobów, ale spodziewam się, że zbuduje Rzym, zleci nadgodziny itp. Wszystkie rzeczy, które zmniejszają produktywność i sprawiają, że ludzie są niezadowoleni.

Najważniejszą rzeczą, której IMO powinna unikać, jest bycie „tak-człowiekiem” dla wyższej kadry kierowniczej i zawsze zgadzanie się bez względu na to, co powiedzą (innymi słowy całuje w dupę)

Wayne Molina
źródło
+1: Racja. A jeśli znajdziesz się w „Tak-Człowieku”, odejdź jak najszybciej.
Jim G.
1
Niestety, istnieje wiele środowisk, w których starszy / główny / główny programista jest niczym innym, jak Tak-Manem (lub jak wolę nazywać je „Smithers”), a najgorsze jest to, że przez większość czasu nie będziesz o tym wiedział aż do momentu podjęcia pracy.
Wayne Molina
3

Umiejętności ludzi. Czasami ludzie otrzymują tytuł „Senior” i zapominają, że nie są wszechwiedzący. Uważają, że promocja jest komentarzem do ich najwyższych umiejętności technicznych i ukrytego geniuszu. W rzeczywistości są teraz menedżerami na bardzo niskim poziomie. Powinni zrozumieć, jak i kto motywować, kim pozwolić, jak iść na kompromis i kiedy słuchać.

Własność. Najgorsi starsi programiści nie biorą na siebie odpowiedzialności za to, na czym byli „starsi”. Opierają się na taktyce unikania pracy i obwiniania gier, która doprowadziła do ich awansu (bardziej niż prawdopodobne podczas tańca na grobie osoby, którą rzucili pod autobus). Teraz muszą zrozumieć, że to ich tyłek na temblaku i że są odpowiedzialni za posiadanie projektu, planu i dużej części pracy.

Doświadczenie. Oczekuję, że starsi programiści widzieli wszystko dwa razy. Powinni zrozumieć domenę i technologię. Powinni agresywnie atakować ryzyko i być w stanie zauważyć czas marnujący czerwone śledzie.

nsfyn55
źródło
2

Spójność jest jedną z najważniejszych rzeczy. Jeśli programiści potrafią przewidzieć, jak będziesz postępować, będą szczęśliwsi. Nawet jeśli ciągle jesteś narzędziem kompletnym, lepiej jest czasem być fajnym, a czasem narzędziem. Mówiąc to, nie bądź narzędziem.

Erin
źródło
2

Wiedza i komunikacja. Znając źródło i, o wiele , co ważniejsze, będąc w stanie wyjaśnić to każdemu, w sposób, który zrozumieją i zachowają.

Covar
źródło