Skąd menedżerowie wiedzą, czy dana osoba jest dobrym czy złym programistą?

49

W większości firm, które tworzą zespoły i działy programistyczne, są programiści, którzy projektują i piszą kod, oraz menedżerowie, którzy ... no cóż, zajmują się zarządzaniem. Oprócz tego, że nie piszą kodu, menedżerowie zwykle nawet nie patrzą na kod opracowywany przez zespół i mogą nawet nie mieć zainstalowanego odpowiedniego IDE na swoich komputerach roboczych.

Mimo to menedżerowie muszą oceniać, czy dana osoba działa dobrze, czy powinna ona być za coś odpowiedzialna, czy też konkretny programista powinien zostać przypisany do zadania o najwyższym znaczeniu i odpowiedzialności. I wreszcie: menedżerowie zwykle przyznają kwartalne premie!

Aby skutecznie to zrobić, menedżer powinien wiedzieć, czy dana osoba jest dobrym programistą - oczywiście wśród innych cech. Pytanie brzmi: jak oni to robią? Nawet nie patrzą na kod, który piszą ludzie, nie mogą bezpośrednio ocenić jakości komponentów, które opracowują programiści ... ale ich szacunki dotyczące tego, kto jest dobrym koderem, a kto nie jest tak dobry, są jednak poprawne w większości przypadków!

Jaki jest sekret?

P Shved
źródło
24
Świetne pytanie. Większość menedżerów, dla których pracowałem, uważa najgorszych programistów (naprawdę zły kod i projekt) za najlepszych w zespole, ponieważ zawsze dostarczają na czas. Potem inni w zespołach zamiatają i utrzymują po nich. Menedżerowie powinni od czasu do czasu czytać kod ...
Martin Blore,
18
Należy pamiętać, że to, co czyni „dobrym programistą” dla programistów, może nie być tym samym, co czyni „dobrym programistą” dla menedżera.
GrandmasterB,
11
Przez większość czasu nie.
biziclop,
1
Wydaje się, że odpowiedź na pytanie: Jak menedżerowie powinni wiedzieć, czy dana osoba jest dobrym czy złym programistą?
Jigar Joshi
2
Dlatego właśnie zawsze twierdzą, że menedżer rozwoju oprogramowania powinny być programistą, czy raczej być programistą. Ich zadaniem jest teraz zarządzanie, ale w celu skutecznego zarządzania muszą zrozumieć, czym zarządzają. Mogą to zrobić naprawdę dobrze tylko wtedy, gdy sami byli programistami w niezbyt odległej przeszłości (i nadal przynajmniej zapoznają się z nowymi technologiami tworzenia oprogramowania).
CraigTP

Odpowiedzi:

31

Zazwyczaj patrzy na to menedżer

  • Czy programista załatwia sprawy?
  • Co myślą o nich ich koledzy? Kod, który piszą?
  • Czy programista komunikuje się wyraźnie z menedżerem?
  • Czy programista lubi uczyć się nowych rzeczy? Czy dobrze mentują innych?
  • Czy potrzebują dużo uwagi kierownictwa, aby załatwić sprawę?
  • Czy programista wydaje się czerpać przyjemność ze swojej pracy?

Prawdą jest, że zwykle nie widzą (lub często nie rozumieją) kodu pracowników, ale dla nich powyższe służy jako rozsądny wskaźnik do pomiaru, jak dobrze pracownik pasuje do roli programistycznej narzuconej mu przez pracodawcę. Jeśli ktoś nie załatwia sprawy, dostaje niskie oceny od swoich kolegów, nie może dobrze się komunikować, denerwuje się inną technologią, to jest przyzwyczajony, zawsze wymaga nadzoru i zawsze jest niezadowolony, to dobra wskazówka, że ​​nie są T dobrze pasuje do tej pracy. *

* Być może jednak w innym kontekście i otoczeniu byliby bardzo szczęśliwi i entuzjastyczni. Może jej po prostu , że rodzaj programatora, że sprzeciwił się, a może robią bardzo dobrze programowania w innym kontekście. „Programista” może oznaczać bardzo różne zadania w różnych miejscach. Ale kierownik dba przede wszystkim o rolę „programisty” i to, jak dobrze pasuje pracownik.

Doug T.
źródło
Myślę, że najważniejszym z tych tematów jest to, czy programista załatwia sprawy? - Uzupełniam to tylko dodając Czy programista wykonuje zadania zgodnie z harmonogramem ?
Herberth Amaral
2
Małe zastrzeżenie dotyczące „komunikuje się wyraźnie z kierownikiem”: zależy to bardziej od tego, czy kierownik uważa, że zrozumiał, czy nie, niż od tego, czy naprawdę zrozumiał, czy nie; dlatego na końcu musisz sprawdzić, co zrozumiał, ponieważ pomimo jego pozytywnego nastawienia mógł zrozumieć coś zupełnie innego.
wildpeaks
4
Herberth: „Wykonaj zadanie” (na czas lub nie) niekoniecznie wystarcza, ponieważ inni członkowie zespołu mogą nabrać luzu.
Cercerilla,
2
Ważne jest też „załatwianie spraw” bez wielu błędów. Innymi słowy, czy oni zawsze wracają i naprawiają rzeczy, czy też raz coś się robi?
Czwartek,
23

Nie zgadzam się z twierdzeniem, że menedżerowie nie patrzą na kod. Kiedy zarządzałem zespołami, sprawdzałem wyniki każdego inżyniera - a dużym jest kod. Ale nie jedyny - e-maile, dokumenty projektowe, oficjalne dokumenty - wszystko to ma wpływ.

Ale to zdecydowanie nie jedyny czynnik. Jeśli jeden facet siedzi w kącie i pisze genialny kod, ale jest bestią do rozmowy, nie odpowiada na pytania, nie dzieli się statusem i nie idzie na kompromis, gdy pojawią się problemy z rozwojem - nie jestem pewien, czy jest zasób dla zespołu. Zwłaszcza w porównaniu z facetem, który pisze umiarkowanie przyzwoity kod, ale potrafi wykonać wszystkie powyższe czynności.

Oto kilka rzeczy, na które patrzę, kiedy jestem w stanie rozdawać nagrody, ale z ogromnym zastrzeżeniem, że jest to absolutnie reakcja jelit, ponieważ żadnej z tych rzeczy nie da się określić ilościowo:

  • Status - czy jest to jasne, dokładne i aktualne? Czy w omawianej sprawie osoba ma status lub jest nieco rozmyta w bieżących kwestiach? Czy osoba ma właściwy osąd, aby podnieść czerwoną flagę, gdy coś się zapali?
  • Rozwiązywanie problemów - ważne jest zarówno pytanie, jak i odpowiedź. Czy dana osoba wie, kiedy poprosić o pomoc lub gdzie bez końca kręci się kołami? Jeszcze lepiej, gdy inni mają problemy, czy dana osoba pomaga znaleźć rozwiązanie lub staje się częścią problemu? Nawet dobry rozsądek, aby się wycofać, gdy problem nie leży w obszarze Twojej specjalizacji, jest wart kilku punktów. Są też punkty za wyjście poza grupę lub firmę i przejście do takich stron lub innych odpowiedzi internetowych.
  • Uwaga na proces - zwykle jest to dość oczywiste - nawet w firmie, która nie zachowuje się analnie, jeśli ktoś oszukuje system, widać to w chaosie, który po sobie zostawiają. Jeśli inne osoby usuwają funkcje innej osoby, ponieważ nie stosują się do wskazówek lub architektury, mamy problem. Dodatkowe punkty iść do tych, którzy dowiedzieć się sposobów, aby spójność i jakość łatwiejsze .
  • Wskaźniki ukończenia a błędy i złożoność - zrób rzeczy, ale zrób to dobrze. Każdy ma kilka błędów, ale jeśli facet szybko załatwi sprawę i będzie miał problemy, mamy problem. Generalnie uważam, że nie jest to coś, co można ocenić w codziennym sensie - musi to być spojrzenie na wydanie, fazę lub kwartał podatkowy.

I wkład innych ludzi. Często byłem na stanowisku, w którym różni inżynierowie byli odpowiedzialni za różne części projektu. Czasami kieruje zespołem, a czasem tylko właściciele danego produktu (np. „Facet od kompilacji”). Ludzie uwielbiają rozmawiać o skrajnościach - aktach heroizmu lub frustracji problematycznych dzieci. Zazwyczaj w trakcie rozwiązywania tych problemów dowiaduję się dużo o OBU imprezach.

Jest tu również czynnik związany z zarządzaniem ludźmi . Żaden inżynier nie jest dokładnie taki jak każdy inny. Więc nie wszystkie świecą w tym samym świetle. Jeden pisze genialny kod wolny od błędów, ale inny pomaga rozwiązywać problemy przekrojowe, które łamią kod każdego. Jeden jest świetny osobiście, drugi jest lepszy w pisaniu. Jeden jest niespójny o 9:00, jeden jest stąd przed 15:00. Istnieje pewna potrzeba wycofania się, ustalenia, co jest najbardziej korzystne dla zespołu i co może być czynnikiem osobistego uprzedzenia (na przykład chęć zabicia tego faceta o 4:00 rano, tylko dlatego, że nie mogę funkcjonować do 11: 00 rano).

bethlakshmi
źródło
2
Wydaje się, że odpowiedź na pytanie: Jak menedżerowie powinni wiedzieć, czy dana osoba jest dobrym czy złym programistą?
Jigar Joshi
Z mojego doświadczenia w organizacjach, w których pracowałem, menedżerowie niestety nie mają przepustowości, aby spojrzeć na każdy kod programisty.
Doug T.
@Jarar Joshi - nie wiem, jak to robi każdy menedżer - oto, co zrobiłem, gdy poproszono mnie o wykonanie recenzji wydajności lub sformułowanie rekomendacji.
bethlakshmi
@pythagras - moim kontratakującym pytaniem byłoby „który menedżer?” Kierownik 40 osób - nie, oczywiście, że nie. Menedżer 10 osób - prawdopodobnie nie zabiłby cię, aby się przekraść w ciągu 1 godziny na osobę, skanując kod w obszarach o krytycznym znaczeniu. Łatwo wykonalna jest 1 godzina na 10 pracowników w ciągu 6 miesięcy.
bethlakshmi
12

Różni się to znacznie w zależności od wiedzy technicznej menedżera.

  • W większości prawdopodobnie oceniają cię na podstawie tego, jak się komunikujesz . Jak komunikujesz się z menedżerem i jak widzisz komunikację z kolegami.
  • Jeśli masz szczęście, że masz wiodącego programistę, który jest bliżej menedżera, menedżer może poprosić o informacje od głównego programisty.
  • Pamiętaj, że głównym obowiązkiem menedżera jest załatwienie sprawy . Musi zobaczyć, jak generuje różne wyniki i cele, aby zrealizować biznesplan. Jeśli więc możesz wyglądać, jakbyś miał bezpośredni wpływ na wynik , dobrze ci to wróży.
Jonathan Khoo
źródło
2
Wiesz, hipoteza „głównego programisty” przypomina mi teorię egzogenezy, która głosi, że życie na Ziemi zostało stworzone przez kosmitów. Tak, menedżer rzeczywiście może polegać na spostrzeżeniach głównego dewelopera, ale to właśnie on sprawił, że ten programista stał się „liderem”! To prowadzi nas z powrotem do problemu: skąd kierownictwo wie, kto ma przewodzić?
P Shved
@Pavel: Zwróciłeś uwagę na interesujący (jeszcze osobny problem). Zakładając, że został wyznaczony główny programista: większość kierownictwa ufa i wierzy w swoją decyzję (tj. Kogo wybrał).
Jonathan Khoo
if you're somehow able to look like you've having a direct influence on the outcome. Jest to rzecz, która jest najczęściej wykorzystywana przez dobre zarabianie bonusów, ale przez złe programistów.
IsmailS,
7

Na ogół nie.

Dlatego programowanie jest „rynkiem cytryn”. http://en.wikipedia.org/wiki/The_Market_for_Lemons

Kod się psuje i na ogół nie trwa to 2-3 lata, zanim się zorientujesz. Programiści zwykle pozostają 18 miesięcy, więc nigdy nie widzisz winowajców po awarii.

Menedżerowie muszą wierzyć, że na przykład wydanie zajmuje cztery miesiące i sto iteracji. Może edytujesz ręcznie wiele plików wdrażania i odczytujesz ręcznie pliki dziennika pod kątem błędów pomieszanych ze statusem? Nie wiedzą, że można to zrobić lepiej.

Więc bądź uczciwy i profesjonalny i staraj się poprawić. Z doświadczeniem kierownik zacznie dostrzegać wzorce dobrych i złych zachowań.

Tim Williscroft
źródło
Jeśli chodzi o mój komentarz do samego pytania o to, czy menedżerowie są (lub byli) sami programistami. To, co opisujesz w odpowiedzi, jest dokładnie tym, czego doświadczyłem, gdy miałem menedżera, który sam nie jest lub nigdy nie był programistą. Niestety jest wielu takich menedżerów.
CraigTP,
5

Skąd menedżerowie wiedzą, czy dana osoba jest dobrym czy złym programistą?

Zacznę od rażącego uogólnienia: większość menedżerów nie może odróżnić „dobrego” programisty od „złego” programisty.

Poza tym to, co większość menedżerów (których spotkałem lub pracowałem) uważa za „dobre” u programisty, nie jest tym samym zestawem umiejętności, który inny programista uznałby za „dobry”.

jak oni to robią?

Menedżer zorientowany na wyniki będzie szukał takich rzeczy, jak „inteligentny” i „załatwia sprawy”. Nie będą się przejmować, jeśli przyjdziesz do pracy w spodniach dresowych, o ile wykonasz zadania na czas i zgodnie z budżetem.

Menedżer zorientowany na proces jest bardziej zainteresowany „tym, jak się to robi”. Oznacza to dotarcie do pracy na czas, noszenie odpowiedniej odzieży i czy masz odpowiedni arkusz tytułowy w raporcie TPS.

osoba działa dobrze, jeśli ona lub ona powinna być za coś odpowiedzialna

Bycie „odpowiedzialnym” wymaga innych umiejętności niż pisanie kodu. Jeśli dana osoba posiada umiejętności potrzebne do kierowania zespołem, należy ją wykorzystać. Jeśli awansujesz ludzi na podstawie kluczowych elementów stanowiska, które obecnie wykonują, ostatecznie osiągną poziom, na którym są teraz niekompetentni. Nazywa się to zasadą Piotra .

Tangurena
źródło
Nigdy nie słyszałem o oddzieleniu menedżerów zorientowanych na wyniki od procesów. +1 za to.
mwilcox,
4

Oczywiście zawsze pomaga posiadanie umiejętności programistycznych, którzy potrafią czytać kod, a co ważniejsze, zagłębić się w system śledzenia błędów i zrozumieć, co się dzieje, wiedz, że nie wszystkie błędy są równe, a samo dostarczanie złego kodu na czas się nie liczy. za dużo.

Ale to idealny przypadek. Dla menedżera, aby uzyskać miarę programisty z nietechnicznej perspektywy, mam kilka sugestii.

  • Czy szybko / regularnie / konsekwentnie zwracają uwagę na to, gdzie występują problemy z wykonaniem zadań w celu spełnienia aktualnie określonych wymagań ... i są z tego powodu bardzo denerwujące (w końcu jest to tworzenie oprogramowania, jeśli nie jest wystarczająco skomplikowane, aby mieć takie problemy, to nie jest prawdziwy projekt rozwojowy).
  • Jeśli nie są czegoś pewni, od razu to mówią - tylko programista pewny swoich umiejętności faktycznie by to zrobił (i wie, że jeśli ci się nie spodoba, może łatwo dostać inną pracę). I odwrotnie, ktoś, kto wie, że są naprawdę poza swoją głębokością, ma tendencję do ukrywania się i szukania schronienia.
  • Co inni programiści w zespole mówią / sugerują o innych programistach? Jeśli jesteś w połowie przyzwoitym menedżerem, jesteś w okopach ze swoim zespołem programistycznym - szczególnie podczas testów integracyjnych / naprawiania błędów. Więc jeśli nie otrzymujesz tego rodzaju informacji zwrotnych, ktoś inny powinien wykonywać Twoją pracę.
  • I moje ulubione: to, co nazywam programistą „tomcat”. Jeśli po jakimś czasie ciągle zauważasz, że różni programiści zawsze kręcą się wokół tego samego biurka programisty (zakładając, że wykonują pracę i dyskutują o niektórych problematycznych kwestiach, a nie rezydenta znajdującego fajne i zabawne strony internetowe) ... to istnieje powód, dla którego inni programiści grawitują na biurku tej osoby. Jeśli nie są jeszcze liderem zespołu, prawdopodobnie powinni zostać jak najszybciej postawieni.

Jeśli którekolwiek lub wszystkie z nich mają zastosowanie, prawdopodobnie masz dobrego programistę na rękach. Zauważ, że przez dobrego programistę nie tylko oceniam ich zdolność kodowania, ale także inne przydatne rzeczy, takie jak możliwość komunikowania się z innymi ludźmi ;-)

nomaderWhat
źródło
rany dzięki ... jeśli tak, to byłby mój pierwszy mem. W przypadku, gdy dla nikogo nie jest to oczywiste, wywodzi się z analogii „pasterskich kotów”.
nomader Co
3

Menedżer może nie wiedzieć, kiedy kod, który piszesz, jest genialny, czy też może zostać ulepszony przez ogromny czynnik, ale wie, że: czy dotrzymałeś terminu z działającym kodem? Czy jesteś osobą, której można zaufać w rozwiązywaniu problemów, które stwarzają inni ludzie? Czy klient lub użytkownik zauważył problem, który został eskalowany do jego menedżera? Czy na twoim zegarku wystąpiła poważna katastrofa (usunąłeś tabelę użytkowników, zapomniałem skonfigurować kopie zapasowe, wysłałem e-mail do klientów z zastrzeżonymi danymi innego klienta, których nie powinni byli widzieć itp. Czy ktoś pochwalił twoją pracę dla niego (szczególnie na piśmie) )? Czy ludzie mówią za tobą dobre lub złe rzeczy?

HLGEM
źródło
1
Brzmi dla mnie jak polityka i przypomina mi o jednej z moich poprzednich firm.
IsmailS,
2
  1. W większości przypadków, gdy twój kod nie jest oceniany przez twojego menedżera, jest oceniany przez twoich rówieśników (formalnie lub nieformalnie, gdy próbują pracować z twoim kodem). Twój szef do pewnego stopnia wykorzysta opinie twoich rówieśników (ponownie formalne lub nieformalne).
  2. Twoja ogólna niezawodność oraz szybkość wykonywania zadań i ich wykonywania jest często bardzo ważnym czynnikiem, niezależnym od umiejętności kodowania.
  3. Porozumiewanie się. Jeśli robisz dużo i robisz to dobrze, Twój menedżer musi o tym wiedzieć! (Oczywiście unikaj przechwalania się). Naucz się „zarządzać swoim menedżerem”, a nie po prostu być pasywnym. Pomóż swojemu szefowi wiedzieć, jak pracujesz.
Matthew Read
źródło
2

Menedżerowie sami są programistami i dlatego, po prostej obserwacji, mogą dowiedzieć się, czy programista jest dobry, czy nie.

Jeśli twoi menedżerowie nie są programistami (a zajmujesz się oprogramowaniem), masz problemy.

wegetarianin
źródło
2

Jako menedżer, oto kilka rzeczy, na które patrzyłem, oceniając moich programistów:

  • Wzajemna opinia. Poprosiłem programistów z mojego zespołu oraz programistów z innych zespołów o przesłanie opinii na temat moich ludzi.

  • Szacunek rówieśników . Kiedy moi programiści napotkali problem, którego nie potrafią rozwiązać, mówią „chodźmy poprosić o radę takich i innych”.

  • Wykonuje zadania . Mówię „chcę X”, a następnego dnia X jest skończone.

  • Sprawia, że ​​wszystko jest inteligentne . Mówię „chcę X” i następnego dnia X jest nie tylko gotowe, ale wszystkie rzeczy podobne do X zostały rozwiązane i nie wymagają dalszej uwagi.

  • Rozwiązuje mnie . Mówię „chcę X”, a programista mówi „X nie ma racji, powinniśmy zrobić Y, i oto dlaczego”.

Nie ma tam wielu dobrych menedżerów (patrz powiązane pytanie: skąd programiści wiedzą, czy dana osoba jest dobrym czy złym menedżerem?). Dobre zarządzanie ludźmi jest trudne i wymaga dużo czasu i ciężkiej pracy. Gdy tylko zarządzałem 5 osobami, prawie nie miałem czasu na programowanie. Kiedy zarządzałem ponad 8 osobami, nie mogłem nimi zarządzać tak dobrze, jak na to zasłużyli.

Jay Bazuzi
źródło
1

Myślę, że przesłanka twojego pytania jest nieco błędna, ponieważ zapewnia, że ​​menedżerowie tak naprawdę nie patrzą na kod. Pracowałem w wielu sytuacjach, w których moi menedżerowie byli współpracownikami i aktywnie uczestniczyli w przeglądach kodu.

Zdecydowanie jednak istnieje wiele sytuacji, w których inżynierowie oprogramowania zajmują się osobami nietechnicznymi i nie są oni w stanie polegać na własnej wiedzy i doświadczeniu.

W takich przypadkach odpowiedzialni menedżerowie zwrócą się do inżynierów o poradę. Poprosą osoby nietechniczne w organizacji, z którymi inżynier wchodzi w interakcję, o sprawdzenie, czy ma dobre umiejętności ludzi, które są zgodne ze zwiększoną odpowiedzialnością.

Te nieodpowiedzialne po prostu pójdą ze swoimi „jelitowymi” reakcjami, używając jakichś ogólnie nieobsługiwanych „wskaźników”.

To bzdura, ale zawsze możesz zrezygnować i mieć nadzieję na coś lepszego gdzie indziej.

Adam Crossland
źródło
1

Kiedy pracuję, kiedy pojawiają się oceny pracowników, kierownicy wysyłają nieformalne, anonimowe pytania do tych, którzy regularnie wchodzą w interakcje z pracownikiem; zarówno deweloperzy, jak i klienci. Daje to innym programistom możliwość wniesienia wkładu w wydajność jako programista, którego menedżerowie mogliby przeoczyć.

Mike Clark
źródło
1

Kierownik musi spojrzeć na mierzalne. Jakie aspekty pracy są mierzalne pod względem wykonywanej pracy, jakości pracy. Mogą nie wiedzieć, czy wykonujesz dobrą pracę, chyba że wygenerujesz wiele błędów lub nie pozwoli użytkownikowi końcowemu zrobić tego, co powinien.

Twoja praca kosztuje kierownika kosztami, dlatego musisz być opłacalny, aby kontynuować zatrudnienie.

Crosenblum
źródło
1

Nie twierdzę, że to najlepszy sposób, aby to zrobić, ale mogliby opierać się na zadowoleniu klientów. Jeśli podoba im się aplikacja, zaakceptuj liczbę błędów i poczujesz, że dodajesz nowe funkcje w odpowiednim czasie, czy twoi programiści naprawdę mogą być tacy źli?

Oczywiście, że mogli. Są w stanie brutalnie naciskać na kodowanie, ponieważ 10 osób wykonuje pracę dwojga. Lub klienci są zadowoleni, ponieważ sprzedajesz swoją aplikację tak tanio.

Innym problemem związanym z tym podejściem jest to, że musisz poczekać, aż aplikacja zostanie prawie ukończona, zanim nietechniczny menedżer będzie mógł uzyskać opinie klientów. Zbuduj aplikację tylko na rok, aby ją wydać i nikomu się nie spodoba.

Życie byłoby prostsze, gdybyś mógł polegać na mówieniu ludziom: „Po prostu spraw, aby działało”. Kiedy zrozumiesz i zmusisz ludzi do przestrzegania właściwego procesu, wyeliminujesz wiele problemów. Możesz mieć wymagające terminy, które są realistyczne. Każdy głupiec może wymyślić nierealistyczne wymagania i ryzykować utratę utalentowanych ludzi.

JeffO
źródło
1

Myślę, że większość z nas w zespole technicznym wie, kto rządzi, a kto jest do bani. Chyba że masz ogromny obrót, krem ​​wznosi się do góry, a ciężar własny spada. Crummy Devs zawsze mają jakieś kłopoty - zapominają przetestować swój kod, zanim go sprawdzą, więc kompilacja się psuje, zawsze mają pretekst, gdy coś nie jest zrobione i tak dalej.

SnoopDougieDoug
źródło
1

Myślę, że nie wiem, czy ktoś jest dobry programista , beucase nie mają umiejętności, aby to zrobić. Sprawdzają, czy ktoś jest dobrym programistą . Programowanie jest działaniem rozwojowym, ale rozwój ma wiele innych. Sprawdzają więc, czy zdążysz na czas, czy twoje oceny są dobre, czy w systemie śledzenia błędów jest wiele usterek, twoje umiejętności miękkie, zaangażowanie, komunikacja itp.

To, co niektórzy guru czasami zapominają i denerwują, to fakt, że nasza praca to nie tylko programowanie, mamy wiele innych rzeczy do zrobienia, które są również bardzo ważne. Chociaż Twój menedżer nie przyjrzy się temu, jak wygląda Twój kod (ponieważ jest to dla niego zupełnie nieważne), sprawdzi, czy jesteś graczem zespołowym, odpowiedzialny, pełen szacunku i ogólnie wykonujący dobrą pracę .

Czasami myślę, że kod jest przereklamowany.

JSBach
źródło
0

Myślę, że jest bardzo mało osób (nie mówiąc już o menedżerach), którzy nie mają dobrego ogólnego zrozumienia kolejności dziobania dla programistów. Wszyscy myślą, że są programistami najwyższej klasy, jedynymi ludźmi, którzy nie wiedzą, kim są źli programiści, sami są ci źli programiści. W każdym razie, jeśli miałbyś się rozejrzeć i poprosić kogoś o ocenę programistów, z którymi współpracuje, jestem pewien, że dla większości osób byłoby to łatwe zadanie. Więc nie ma magii w określaniu, kto osiąga bardzo dobre wyniki, a kto osiąga wyniki średnie, czy złe itp. Jedyną przeszkodą, z którą deweloperzy i menedżerowie się nie zgadzają, są ci sprzedawcy, głośni, którzy brzmią, jakby wiedzieli, o czym mówią o, ale naprawdę nie. Większość menedżerów jest przez nich oszołomionych, ale nie są to programiści.

Następnie to ranking twojego menedżera określa uprzedzenia twojego menedżera. Dla niektórych kodowanie jest zadaniem na poziomie podstawowym, więc chociaż możesz być doskonały w kodowaniu, nie dostarczy ci promocji, której szukasz. Inni uważają, że najważniejsze są aspekty projektowe lub architektoniczne. Inni uważają, że najważniejsze jest zdefiniowanie i zebranie wymagań (tj. Analiza biznesowa). Jeśli chcesz wiedzieć, co jest ważne dla swojego menedżera, a nie uzyskałeś rankingu najlepszych wyników, zapytaj go, co muszę zrobić, aby uzyskać ranking najlepszych wyników? Dowiesz się, co jest dla nich ważne w tej odpowiedzi, a następnie od Ciebie zależy, czy osiągniesz cel w tych ważnych obszarach.

Maczać
źródło