Techlead Skyeng Kirill Rogovoy () wygłasza prezentację na konferencjach, podczas której opowiada o umiejętnościach, które każdy dobry programista powinien rozwijać, aby stać się najlepszym. Poprosiłem go, aby podzielił się tą historią z czytelnikami Habry, oddaję głos Cyrylowi.
Mitem o dobrym programiście jest to, że:
- Pisze czysty kod
- Zna wiele technologii
- Szybsze kodowanie zadań
- Zna wiele algorytmów i wzorców projektowych
- Potrafi refaktoryzować dowolny kod za pomocą Clean Code
- Nie marnuje czasu na zadania niezwiązane z programowaniem
- 100% mistrz Twojej ulubionej technologii
Tak właśnie HR postrzega idealnych kandydatów i wakaty też tak wyglądają.
Jednak moje doświadczenie mówi, że nie jest to do końca prawdą.
Na początek dwa ważne zastrzeżenia:
1) moje doświadczenie to zespoły produktowe, tj. firmy posiadające własny produkt, a nie outsourcing; w outsourcingu wszystko może wyglądać zupełnie inaczej;
2) jeśli jesteś juniorem, to nie wszystkie rady będą się przydać, a na twoim miejscu na razie skupiłbym się na programowaniu.
Dobry programista: rzeczywistość
1: Lepszy niż przeciętny kod
Dobry programista wie, jak stworzyć fajną architekturę, napisać fajny kod i nie robić zbyt wielu błędów; Generalnie radzi sobie lepiej niż przeciętnie, ale nie należy do górnego 1% specjalistów. Większość najfajniejszych programistów, jakich znam, nie jest aż tak świetnymi programistami: są świetni w tym, co robią, ale nie potrafią zrobić nic nadzwyczajnego.
2: Rozwiązuje problemy, zamiast je tworzyć
Wyobraźmy sobie, że musimy zintegrować usługę zewnętrzną z projektem. Dostajemy specyfikację techniczną, przeglądamy dokumentację, widzimy, że coś tam jest nieaktualne, rozumiemy, że trzeba przekazać dodatkowe parametry, dokonać pewnych poprawek, spróbować to wszystko jakoś zaimplementować i sprawić, by jakiś kręty sposób zadziałał poprawnie, w końcu po kilku dni rozumiemy, że nie możemy tak dalej postępować. Standardowym zachowaniem programisty w tej sytuacji jest powrót do biznesu i powiedzenie: „Zrobiłem to i tamto, to nie działa w ten sposób, a tamto w ogóle nie działa, więc przemyśl to sam. ” Firma ma problem: musisz zagłębić się w to, co się stało, skontaktować się z kimś i spróbować jakoś go rozwiązać. Zepsuty telefon zaczyna mówić: „ty mu powiedz, ja do niej napiszę, zobacz, co odpowiedzieli”.
Dobry programista w obliczu takiej sytuacji sam znajdzie kontakty, skontaktuje się z nim telefonicznie, omówi problem, a jeśli nic nie wyjdzie, zbierze odpowiednich ludzi, wszystko wyjaśni i zaproponuje alternatywy (najprawdopodobniej jest inne rozwiązanie) usługa zewnętrzna z lepszym wsparciem). Taki programista widzi problem biznesowy i rozwiązuje go. Jego zadanie zostaje zamknięte, gdy rozwiąże problem biznesowy, a nie wtedy, gdy na coś wpadnie.
3: Próbuje włożyć minimalny wysiłek, aby uzyskać maksymalne rezultaty, nawet jeśli oznacza to pisanie o kulach
Rozwój oprogramowania w firmach produkujących produkty jest prawie zawsze największą pozycją wydatków: programiści są kosztowni. A dobry programista rozumie, że firma chce uzyskać maksymalną ilość pieniędzy, wydając minimum. Aby mu pomóc, dobry programista chce przeznaczyć minimalną ilość swojego kosztownego czasu, aby uzyskać maksymalny zysk dla pracodawcy.
Są tu dwie skrajności. Jednym z nich jest to, że ogólnie można rozwiązać wszystkie problemy o kulę, bez zawracania sobie głowy architekturą, bez refaktoryzacji itp. Wszyscy wiemy, jak to się zwykle kończy: nic nie działa, piszemy projekt od nowa. Inna sytuacja ma miejsce, gdy ktoś próbuje wymyślić idealną architekturę dla każdego przycisku, poświęcając godzinę na zadanie i cztery na refaktoryzację. Efekt takiej pracy wygląda świetnie, jednak problem w tym, że od strony biznesowej skompletowanie przycisku zajmuje dziesięć godzin, zarówno w pierwszym, jak i drugim przypadku, po prostu z różnych powodów.
Dobry programista wie, jak balansować pomiędzy tymi skrajnościami. Rozumie kontekst i podejmuje optymalną decyzję: w tym problemie odetnę kulę, bo to kod, którego dotyka się raz na pół roku. Ale w tym przypadku będę się trudzić i robić wszystko tak poprawnie, jak to możliwe, ponieważ od tego, co mi się uda, będzie zależeć sto nowych funkcji, które jeszcze nie zostały opracowane.
4. Posiada własny system zarządzania przedsiębiorstwem i potrafi pracować w nim nad projektami o dowolnej złożoności.
Praca na zasadach – kiedy zapiszesz wszystkie swoje zadania w jakimś systemie tekstowym, nie zapomnij o żadnych ustaleniach, naciskaj wszystkich, pojawiaj się wszędzie na czas, wiesz, co jest w danym momencie ważne, a co nie, nigdy nie tracisz zadań. Ogólną cechą takich ludzi jest to, że kiedy się z nimi na coś zgadzasz, nigdy nie martwisz się, że zapomną; i wiesz też, że oni wszystko spisują i nie będą wtedy zadawać tysiąca pytań, na które odpowiedzi zostały już omówione.
5. Zadaje pytania i wyjaśnia wszelkie warunki i wstępy
Tutaj także mamy do czynienia z dwiema skrajnościami. Z jednej strony można być sceptycznym wobec wszelkich informacji wprowadzających. Ludzie przed Tobą proponowali pewne rozwiązania, ale Ty uważasz, że możesz zrobić lepiej i zacząć na nowo omawiać wszystko, co było przed Tobą: projektowanie, rozwiązania biznesowe, architekturę itp. To marnuje dużo czasu zarówno programisty, jak i jego otoczenia, a także negatywnie wpływa na zaufanie w firmie: inni ludzie nie chcą podejmować decyzji, bo wiedzą, że ten facet wróci i wszystko zepsuje. Druga skrajność ma miejsce wtedy, gdy programista postrzega wszelkie wstępne, techniczne specyfikacje i życzenia biznesowe jako coś wyrytego w kamieniu i dopiero w obliczu nierozwiązywalnego problemu zaczyna zastanawiać się, czy w ogóle robi to, co robi. Dobry programista również znajduje tutaj złoty środek: stara się zrozumieć decyzje podjęte przed nim lub bez niego, zanim zadanie przejdzie do fazy rozwojowej. Czego chce biznes? Czy rozwiązujemy jego problemy? Projektant produktu wymyślił rozwiązanie, ale czy rozumiem, dlaczego rozwiązanie będzie działać? Dlaczego kierownik zespołu wymyślił tę konkretną architekturę? Jeśli coś nie jest jasne, musisz zapytać. W trakcie tego wyjaśniania dobry programista może zobaczyć alternatywne rozwiązanie, które po prostu nikomu wcześniej nie przyszło do głowy.
6. Usprawnia procesy i ludzi wokół ciebie
Wokół nas zachodzi wiele procesów - codzienne spotkania, spotkania, scrumy, przeglądy technologii, przeglądy kodu itp. Dobry programista wstanie i powie: słuchaj, co tydzień spotykamy się i omawiamy to samo, nie rozumiem po co, równie dobrze moglibyśmy tę godzinę spędzić na Contrie. Albo: przy trzecim zadaniu z rzędu nie mogę wejść w kod, nic nie jest jasne, architektura jest pełna dziur; Może nasz kod recenzji jest kiepski i musimy dokonać refaktoryzacji, refaktoryzujmy spotkanie co dwa tygodnie. Albo podczas przeglądu kodu ktoś widzi, że któryś z jego kolegów nie wykorzystuje danego narzędzia wystarczająco efektywnie, co oznacza, że musi przyjść później i doradzić. Dobry programista ma ten instynkt; robi takie rzeczy automatycznie.
7. Doskonale radzi sobie z zarządzaniem innymi, nawet jeśli nie jest menadżerem
Umiejętność ta dobrze wpisuje się w temat „raczej rozwiązywania niż tworzenia problemów”. Często w tekście ogłoszenia o pracę, o którą aplikujemy, nie jest napisane nic o zarządzaniu, ale wtedy, gdy stajesz przed problemem, na który nie masz wpływu, nadal musisz w ten czy inny sposób zarządzać innymi, osiągnąć coś od nich, jeśli zapomniałem - pchnij, upewnij się, że wszystko zrozumieli. Dobry programista wie, kto czym jest zainteresowany, potrafi zwołać spotkanie z tymi ludźmi, spisać umowy, wysłać ich na luz, przypomnieć im w odpowiednim dniu, upewnić się, że wszystko jest gotowe, nawet jeśli nie jest bezpośrednio odpowiedzialny za tego zadania, ale jego wynik zależy od jego realizacji.
8. Nie postrzega swojej wiedzy jako dogmatu, jest stale podatny na krytykę
Każdy pamięta kolegę z poprzedniej pracy, który nie potrafi pójść na kompromis w sprawie swojej technologii i krzyczy, że za jakieś złe mutacje wszyscy będą się smażyć w piekle. Dobry programista, jeśli przepracuje 5, 10, 20 lat w branży, rozumie, że połowa jego wiedzy jest zgniła, a w pozostałej połowie nie wie dziesięć razy więcej niż wie. I za każdym razem, gdy ktoś się z nim nie zgadza i proponuje alternatywę, nie jest to atak na jego ego, ale okazja, aby się czegoś nauczyć. Dzięki temu może rosnąć znacznie szybciej niż otaczające go osoby.
Porównajmy mój pomysł na idealnego programistę z ogólnie przyjętym:
Ten obrazek pokazuje, ile punktów opisanych powyżej jest związanych z kodem, a ile nie. Rozwój w firmie produktowej to tylko jedna trzecia programowania, pozostałe 2/3 ma niewiele wspólnego z kodem. I chociaż piszemy dużo kodu, nasza efektywność w dużej mierze zależy od tych „nieistotnych” dwóch trzecich.
Specjalizacja, generalizacja i zasada 80-20
Kiedy dana osoba uczy się rozwiązywać pewne wąskie problemy, uczy się długo i ciężko, ale potem rozwiązuje je łatwo i prosto, ale nie ma wiedzy w pokrewnych dziedzinach, jest to specjalizacja. Generalizm polega na tym, że połowę czasu szkoleniowego inwestuje się w obszar własnych kompetencji, a drugą połowę w obszary pokrewne. Zatem w pierwszym przypadku jedną rzecz robię doskonale, resztę słabo, a w drugim wszystko robię mniej więcej dobrze.
Zasada 80-20 mówi nam, że 80% wyniku wynika z 20% wysiłku. 80% przychodów pochodzi od 20% klientów, 80% zysków pochodzi od 20% pracowników i tak dalej. W nauczaniu oznacza to, że 80% wiedzy zdobywamy w ciągu pierwszych 20% spędzonego czasu.
Jest taki pomysł: programiści powinni tylko kodować, projektanci powinni tylko projektować, analitycy powinni analizować, a menedżerowie powinni tylko zarządzać. Moim zdaniem ten pomysł jest toksyczny i niezbyt się sprawdza. Tu nie chodzi o to, żeby każdy miał być żołnierzem uniwersalnym, chodzi o oszczędzanie zasobów. Jeśli programista choć trochę rozumie zarządzanie, projektowanie i analitykę, będzie w stanie rozwiązać wiele problemów bez angażowania innych osób. Jeśli potrzebujesz stworzyć jakąś funkcję, a następnie sprawdzić, jak użytkownicy z nią pracują w określonym kontekście, co będzie wymagało dwóch zapytań SQL, to świetnie jest móc nie rozpraszać tym analityka. Jeśli potrzebujesz osadzić przycisk analogicznie do istniejących i rozumiesz ogólne zasady, możesz to zrobić bez angażowania projektanta, a firma Ci za to podziękuje.
Łącznie: możesz spędzić 100% swojego czasu na studiowaniu umiejętności do granic możliwości lub możesz spędzić ten sam czas na pięciu obszarach, zdobywając poziom do 80% w każdym. Kierując się tą naiwną matematyką, możemy zdobyć czterokrotnie więcej umiejętności w tym samym czasie. To przesada, ale ilustruje ideę.
Powiązane umiejętności można wytrenować nie w 80%, ale w 30-50%. Po spędzeniu 10-20 godzin zauważalnie poprawisz się w pokrewnych obszarach, zyskasz duże zrozumienie procesów w nich zachodzących i staniesz się znacznie bardziej autonomiczny.
W dzisiejszym ekosystemie IT lepiej mieć jak najwięcej umiejętności i nie być ekspertem w żadnej z nich. Bo po pierwsze te wszystkie umiejętności szybko zanikają, zwłaszcza jeśli chodzi o programowanie, a po drugie dlatego, że w 99% przypadków posługujemy się nie tylko podstawowymi, ale na pewno nie najbardziej wyrafinowanymi umiejętnościami, a to wystarczy nawet w kodowaniu, nawet w fajne firmy.
I wreszcie, szkolenie jest inwestycją, a dywersyfikacja jest ważna w inwestycjach.
Czego uczyć
Czego więc uczyć i jak? Typowy programista w silnej firmie regularnie korzysta z:
- Komunikacja
- samoorganizacja
- planowanie
- projekt (zwykle kod)
- a czasem zarządzanie, przywództwo, analiza danych, pisanie, rekrutacja, mentoring i wiele innych umiejętności
I praktycznie żadna z tych umiejętności nie krzyżuje się z samym kodem. Trzeba ich osobno uczyć i doskonalić, a jeśli tego nie zrobimy, pozostaną na bardzo niskim poziomie, co nie pozwala na ich efektywne wykorzystanie.
W jakich obszarach warto się rozwijać?
-
Umiejętności miękkie to wszystko, co nie dotyczy wciskania przycisków w edytorze. Tak piszemy wiadomości, tak zachowujemy się na spotkaniach, tak komunikujemy się ze współpracownikami. Wszystko to wydaje się być rzeczą oczywistą, jednak bardzo często jest niedoceniana.
-
System samoorganizacji. Dla mnie osobiście stał się on w ciągu ostatniego roku niezwykle ważnym tematem. Spośród wszystkich fajnych pracowników IT, których znam, jest to jedna z najbardziej rozwiniętych umiejętności: są super zorganizowani, zawsze robią to, co mówią, dokładnie wiedzą, co będą robić jutro, za tydzień, za miesiąc. Konieczne jest zbudowanie wokół siebie systemu, w którym zapisywane będą wszystkie sprawy i pytania, co znacznie ułatwia samą pracę i znacznie ułatwia interakcję z innymi ludźmi. Czuję, że przez ostatni rok rozwój w tym kierunku poprawił mnie znacznie bardziej niż doskonalenie umiejętności technicznych, zacząłem wykonywać znacznie więcej pracy w jednostce czasu.
-
Proaktywność, otwartość i planowanie. Tematy są bardzo ogólne i istotne, nie tylko IT, i każdy powinien je rozwijać. Proaktywność oznacza nieczekanie na sygnał do podjęcia działania. Jesteś źródłem wydarzeń, a nie reakcji na nie. Otwartość umysłu to umiejętność obiektywnego traktowania każdej nowej informacji, oceny sytuacji w oderwaniu od własnego światopoglądu i starych nawyków. Planowanie to jasna wizja tego, jak dzisiejsze zadanie rozwiąże problem na tydzień, miesiąc, rok. Jeśli widzisz przyszłość poza konkretnym zadaniem, znacznie łatwiej jest zrobić to, czego potrzebujesz i nie bać się, że po pewnym czasie zorientujesz się, że poszło na marne. Ta umiejętność jest szczególnie ważna w karierze: możesz z powodzeniem osiągać wyniki przez lata, ale w niewłaściwym miejscu i ostatecznie stracić cały nagromadzony bagaż, gdy stanie się jasne, że zmierzasz w złym kierunku.
-
Wszystkie powiązane obszary do poziomu podstawowego. Każdy ma swoje specyficzne obszary, ale ważne jest, aby zrozumieć, że poświęcając 10-20 godzin na podnoszenie poziomu „obcych” umiejętności, możesz odkryć wiele nowych możliwości i punktów kontaktowych w codziennej pracy, a godziny te mogą wystarczy do końca kariery.
Co czytać
Jest mnóstwo książek o samoorganizacji, to cała branża, w której jacyś dziwni goście piszą zbiory porad i zbierają szkolenia. Jednocześnie nie jest jasne, co sami osiągnęli w życiu. Dlatego warto nałożyć filtry na autorów, przyjrzeć się kim są i co za sobą kryją. Na mój rozwój i perspektywy największy wpływ miały cztery książki, a każda z nich w taki czy inny sposób dotyczyła doskonalenia opisanych powyżej umiejętności.
1. Dale Carnegie „Jak zdobyć przyjaciół i zjednać sobie ludzi”. Kultowa książka o umiejętnościach miękkich, jeśli nie wiesz od czego zacząć, wybór jej jest opcją korzystną dla obu stron. Jest zbudowany na przykładach, jest łatwy w czytaniu, nie wymaga dużego wysiłku, aby zrozumieć to, co czytasz, a nabyte umiejętności można natychmiast zastosować. Ogólnie rzecz biorąc, książka porusza temat komunikacji z ludźmi.
2. Stephen R. Covey „7 nawyków skutecznego działania”. Mieszanka różnych umiejętności, od proaktywności po umiejętności miękkie, z naciskiem na osiągnięcie synergii, gdy trzeba zamienić mały zespół w ogromną siłę. Jest również łatwy do odczytania.
3. Ray Dalio „Zasady”. Odsłania wątki otwartości i proaktywności, bazując na historii zbudowanej przez autora firmy, którą zarządzał przez 40 lat. Wiele ciężko zdobytych przykładów z życia pokazuje, jak uprzedzony i zależny może być człowiek i jak się tego pozbyć.
4. David Allen, „Załatwianie spraw”. Lektura obowiązkowa, aby nauczyć się samoorganizacji. Nie jest łatwy do odczytania, ale zapewnia kompleksowy zestaw narzędzi do organizowania życia i spraw, szczegółowo bada wszystkie aspekty i pomaga zdecydować, czego dokładnie potrzebujesz. Z jej pomocą zbudowałem własny system, który pozwala mi zawsze robić to, co najważniejsze, nie zapominając o reszcie.
Musisz zrozumieć, że samo czytanie nie wystarczy. Można połknąć przynajmniej jedną książkę tygodniowo, ale efekt utrzyma się kilka dni, po czym wszystko wróci na swoje miejsce. Książki należy traktować jako źródło porad, które należy natychmiast sprawdzić w praktyce. Jeśli tego nie zrobisz, jedyne, co dadzą, to poszerzenie twoich horyzontów.
Źródło: www.habr.com