Inżynier 10x

Ostatnio na twitterze dużo mówiło się o inżynierze 10x, który rozpoczął wielką debatę o tym, co czyni dobrego inżyniera. Niektóre naprawdę głupie rzeczy zostały wspomniane, takie jak „10x inżynierowie nienawidzą spotkań” i „10x inżynierowie przychodzą późno do biura” i „10x inżynierowie tło laptopa jest zazwyczaj czarne”. Ogólnie rzecz biorąc, wydaje się, że niektórzy ludzie myślą, że jeśli jesteś wystarczająco inteligentny, to dobrze jest być dupkiem.

W Wix staramy się zostawić dupków za drzwiami. Wierzymy, że inżynierowie 10x to nie tylko ludzie, którzy mogą tworzyć 10x szybciej niż większość ludzi, nawet więcej, to ludzie, którzy mogą uczynić cały zespół 10x lepszym poprzez wywieranie pozytywnego wpływu na każdego, z kim pracują.

Wiele osób spędza dużą część swojej kariery, aby stać się tym, co uważamy za porządnego inżyniera. Oznacza to, że jesteś dobrym koderem, który potrafi rozwiązywać problemy i biegle posługiwać się narzędziami, które są do Twojej dyspozycji, takimi jak IDE, debugger, usługi i frameworki. Ten artykuł próbuje opisać to, co my, w Wix Engineering, wierzymy, że czyni przyzwoitego inżyniera inżynierem 10x.

Jedną z najważniejszych zdolności inżyniera jest zdolność do niezależnej pracy. W skrócie oznacza to, że zawsze wiesz, co musisz zrobić i rzadko znajdujesz się w sytuacji, w której czekasz, aż ktoś ci powie, co masz robić. Nie oznacza to, że jesteś w stanie zrobić wszystko samodzielnie, oznacza to tylko, że wiesz jak odblokować siebie i jak odblokować innych w swoim zespole w czysty sposób, który tworzy minimalny dług techniczny. Na przykład, jeśli zablokuje Cię jakiś problem, znajdziesz dla niego rozwiązanie, czy to poprzez uzyskanie pomocy od swoich kolegów, czy też samodzielne jego rozwiązanie. Niezależni inżynierowie mają możliwość przeprowadzenia projektu od pomysłu do produkcji przez wszystkie jego fazy. Są w stanie określić, jakie są rzeczy, których wymagają, aby być w stanie wykonać zadanie i wiedzą, kiedy podnieść flagę, jeśli potrzebują pomocy.

Planowanie

Najtrudniejszą rzeczą, z którą zmagają się mniej doświadczeni inżynierowie, jest zdolność do podjęcia dużego zadania i rozbicia go na mniejsze kroki. Jest to ważne nie tylko dlatego, że będziemy w stanie oszacować jak długo coś zajmie, jest to również krytyczna część budowania wysokiej jakości oprogramowania. Prawidłowe planowanie oznacza, że programista może wypuścić pierwszą wersję produktu tak wcześnie jak to możliwe i szybciej zacząć otrzymywać informacje zwrotne. Prawidłowe planowanie oznacza, że masz projekt systemu wcześnie i masz dobry obraz tego, co zamierzasz zrobić, zanim wskoczysz do wody. Prawidłowe planowanie oznacza, że nie ma dużych niespodzianek, które łamią twój projekt podczas rozwoju. Dobry inżynier powinien być w stanie rozbić zadanie, zdefiniować projekt i fazy wydania, i dostarczyć dokumenty projektowe i szacunki, aby pokazać swój plan.

Humility

To jest trudne. Nawet najsilniejsi inżynierowie wiele razy mają miejsce do wzrostu, jeśli chodzi o pokorę. Oznacza to, aby nie być zakochanym we własnych rozwiązaniach. Umieć słuchać i akceptować rozwiązania innych ludzi. Zakładać to, co najlepsze u swoich kolegów, a kiedy widzisz coś, co wydaje się błędem, starać się zrozumieć stojące za tym rozumowanie. Otwierać sprawy do dyskusji. Pozwól ludziom proponować ich własne rozwiązania. Dziel się swoimi pomysłami i nigdy nie martw się o to, czy dostaniesz za nie kredyt zaufania. Ważniejsze jest, aby wszyscy czuli się dobrze z danym pomysłem i mieli poczucie, że był to wysiłek zespołowy, niż aby wszyscy wiedzieli, że to był twój pomysł. Bądź szczery. Wyrażaj uznanie dla innych. Nigdy nie bój się powiedzieć, że nie miałeś racji lub przyznać, że ktoś inny ma rację. Ludzie szanują osoby, które potrafią zmienić swoje zdanie.

Reuse

Może to brzmieć banalnie, ale większość ludzi nie rozumie, że najlepszym sposobem na osiągnięcie postępu jest budowanie na bazie wcześniejszej pracy. Mniej doświadczeni inżynierowie zawsze mają zły nawyk myślenia, że najlepszym sposobem na szybki postęp jest zignorowanie wszystkiego, co już istnieje i rozpoczęcie od nowa. Dobrzy inżynierowie zawsze dokładnie sprawdzają, uczą się, pytają i rozumieją wszystkie istniejące już rozwiązania. Nawet jeśli istniejące rozwiązanie jest wybrakowane, spróbują zobaczyć, jak można je ulepszyć, zanim zdecydują się je zastąpić. Nigdy nie odrzucą istniejącego rozwiązania bez dogłębnego przyjrzenia się mu i bez rozmowy z właścicielem istniejącego rozwiązania.

Umysł infrastrukturalny

Jak opisano powyżej, ponowne wykorzystanie wcześniejszej pracy może mieć ogromny wpływ na ludzi. Oznacza to, że inżynierowie powinni być zawsze czujni, aby sprawdzić, czy mają możliwość stworzenia czegoś wielokrotnego użytku. Najłatwiejszą rzeczą, jaką można zrobić, gdy ma się taką okazję, jest zignorowanie jej. Tworzenie rzeczy wielokrotnego użytku zawsze kosztuje „twórcę” więcej niż tworzenie rzeczy nie wielokrotnego użytku, więc wielu krótkowzrocznych ludzi ignoruje korzyści, które oni i inne zespoły będą czerpać po drodze. Dobry programista zidentyfikuje możliwości tworzenia rzeczy wielokrotnego użytku, będzie wiedział, jak uczynić je wielokrotnego użytku w najlepszy sposób i zainwestuje w to wysiłek.

Panuj nad swoją domeną

Jedynym sposobem na wymyślenie dobrych rozwiązań jest dogłębne zrozumienie produktu, nad którym pracujesz. Dobrzy inżynierowie nie tylko mają głębokie zrozumienie produktu, który rozwijają. Rozumieją również wszystkie przypadki użycia, rozumieją motywację dla produktu i mogą łatwo prowadzić znaczące rozmowy z menedżerem produktu, kwestionować decyzje i proponować alternatywy. Wiedzą, jakie cechy są ważne, a jakie mniej ważne i wiedzą, jak nadać im priorytety, a w razie potrzeby zaproponować obejścia. Jest to ważne nie tylko dla produktu, nad którym pracujesz, ale także dla każdego produktu, z którym się integrujesz.

Curiosity

Dobrzy programiści muszą mieć zdrową ciekawość, która wykracza poza granice ich domeny. Jest to szczególnie prawdziwe w przypadku uczenia się, jak faktycznie działają technologie bazowe, ale równie ważne jest zrozumienie produktów, nad którymi pracują inne zespoły, ich architektury i sposobu, w jaki łączą się jako kompletny system. Posiadanie tego szerszego kontekstu może być bezcenne podczas rozwiązywania złożonych problemów i źródłem inspiracji.

Bez granic

Często widzimy, że źródłem złych rozwiązań i złej architektury są ludzie bojący się zmieniać rzeczy, które są poza granicami ich pudełka. Programista klienta będzie miał tendencję do rozwiązywania rzeczy na kliencie, nawet jeśli lepiej jest rozwiązać to na serwerze. Programista aplikacji będzie miał tendencję do rozwiązywania problemu lokalnie, nawet jeśli rozwiązanie należy do platformy lub infrastruktury. Powód tego jest prosty. Łatwiej jest nie podejmować dyskusji z innym zespołem, łatwiej jest traktować świat poza swoim zasięgiem jako czarną skrzynkę, łatwiej jest zajmować się diabłem, którego się zna. Ale dobrzy inżynierowie muszą wiedzieć, że są częścią jednego wielkiego systemu i że żadna część tego systemu nie jest tak naprawdę poza ich zasięgiem. Omawianie zmian w architekturze z innym zespołem jest zdrowe i pomocne i może wzbogacić twoją perspektywę. Zaoferowanie wkładu w zmianę, której potrzebujesz, jest świetne do budowania zaufania między zespołami. Dotykanie nowej domeny to doświadczenie, z którego możesz tylko skorzystać. Co najważniejsze, kiedy Twoje granice stają się bardziej elastyczne, oznacza to, że Twój wpływ rośnie. Ilekroć unikasz sięgania poza swoje granice, zdaj sobie sprawę, że to, co faktycznie robisz, to powstrzymywanie się od większego wpływu.

Odpowiedzialność / własność

Choć nie jest to od razu widoczne, bardzo często, jeśli zagłębisz się w pierwotną przyczynę tego, dlaczego jakiś projekt został opóźniony lub nie powiódł się, przekonasz się, że sprowadza się ona do własności i odpowiedzialności. Ludzie zawsze będą mieli tendencję do obwiniania swojego otoczenia: „Musiałem czekać na inny zespół, aby coś ukończyć”, „Miałem problem z systemem i nikt nie miał czasu, aby mi pomóc”, „Otrzymałem definicje zbyt późno”. Dobry inżynier wie, że te rzeczy są prawie zawsze wymówkami. Kiedy jesteś właścicielem zadania i odpowiedzialność za jego wykonanie spoczywa na Tobie, Twój sposób myślenia powinien być taki, że każdy problem, który napotykasz, jest czymś, co musisz rozwiązać. Jeśli jesteś blokowany przez inny zespół, idź i porozmawiaj z nim. Zaoferuj pracę w parach nad problemem i nie „zrzucaj” odpowiedzialności na kogoś innego. Jeśli nie dostałeś jeszcze definicji, przyjmij pewne założenia co do tego, jakie będą definicje. Lepiej jest zrobić jakiś postęp i później wprowadzić poprawki, niż siedzieć i czekać. Jeśli coś dużego Cię opóźnia, wiedz kiedy podnieść flagę i jak obejść ten problem, aby przynajmniej móc zrobić postęp na innym froncie. Nigdy nie bądź w sytuacji, w której ktoś inny jest odpowiedzialny za rozwiązanie twojego problemu, jest na odwrót – jesteś odpowiedzialny za dotarcie do mety i musisz radzić sobie z przeszkodami po drodze.

Komunikacja

To jest prawdziwy game changer i często najbardziej krytyczna rzecz, którą inżynier musi mieć, aby móc mieć ogromny wpływ na cały zespół. Zdolność do komunikowania się jest największą rzeczą, która pozwoliła ludzkości stać się tym, czym jest, oczywiście ta sama rzecz jest tak samo krytyczna dla każdego aspektu życia, włączając w to inżynierię oprogramowania. Dobrzy inżynierowie muszą być w stanie elokwentnie wyjaśnić swoje pomysły i opinie. Muszą być w stanie inteligentnie i z szacunkiem dyskutować ze swoimi rówieśnikami. Komunikacja nie polega tylko na mówieniu, jeszcze ważniejsza jest umiejętność słuchania. Nie każdy w zespole będzie w stanie wyrazić swoje pomysły tak dobrze, a dobry inżynier musi być cierpliwy i zadawać właściwe pytania, aby zrozumieć, co myślą inni i pomóc im zostać wysłuchanym. Wszystko to jest tak samo ważne w komunikacji werbalnej jak i pisemnej, a co ważniejsze nie jest to tylko rozmowa – życie deweloperów jest pełne ton form komunikacji: dokumentów, prezentacji, dokumentacji, komentarzy do kodu, wiadomości commit. Nawet pisanie czytelnego kodu i wybieranie dobrych nazw zmiennych jest formą komunikacji.

Praca zespołowa

To jedno z miejsc, w których nawet doświadczeni inżynierowie często zawodzą i nawet nie wiedzą, że tak się dzieje. Pomyśl o wszystkich przypadkach, w których mówiłeś „to jest zbyt skomplikowane, zostaw to mnie”. Pomyśl, ile razy mówiłeś „to zadanie jest jednoosobowe, dodanie kolejnych osób nie ułatwi tego zadania”. Pomyśl o wszystkich przypadkach, kiedy nie miałeś czasu, aby pomóc komuś innemu i nigdy nie podążyłeś za nim, lub poprawiłeś/refaktoryzowałeś czyjś kod bez pytania o jego recenzję, lub dokonałeś dużej zmiany bez konsultacji z zespołem. Przykładów jest mnóstwo. Rzecz w tym, że nawet dla doświadczonych inżynierów wydaje się to w danej chwili słuszne. Ale to jest myślenie taktyczne, które opłaca się tylko na krótką metę. Jeśli chcemy osiągnąć wielkie rzeczy, musimy upewnić się, że potrafimy współpracować jako zespół. Nie jest przypadkiem, że praca zespołowa pojawiła się zaraz po komunikacji. To są rzeczy, które czynią nas najbardziej efektywnymi, to podstawowa biologia. Wspaniali inżynierowie nie tylko współpracują, konsultują się, uczą się od, pomagają, dobierają w pary i szanują swoich kolegów, ale także mentorują, wskazują na problemy, znajdują zainteresowanie i uczą się ze wszystkiego, co dzieje się w zespole i proaktywnie starają się być pomocni nawet w sprawach, które ich bezpośrednio nie dotyczą. Niesamowici inżynierowie wiedzą, kiedy i jak wymyślać projekty, które ułatwią wielu ludziom współpracę nad rzeczami, w których oczekuje się wiele pracy.

Keep it simple

Złożoność rozwiązania może być jednym z cichych zabójców zdolności zespołu do posuwania się naprzód i adaptacji. To jest jak wysokie ciśnienie krwi. Dla niewprawnego oka wydaje się, że wszystko jest w porządku i wszystko działa zgodnie z oczekiwaniami, ale tak naprawdę, głęboko w środku, coś, co nie ma bezpośredniego wpływu na żadną główną funkcjonalność, powoli Cię zabija. Dobrzy inżynierowie tworzą pragmatyczne rozwiązania i czytelny kod, nawet jeśli napiszesz więcej linii kodu. Nie pokazuj jaki jesteś „mądry” wykorzystując wszystkie możliwości języka, tworząc nadmiarowe poziomy abstrakcji lub pisząc w jednej linijce funkcję, której nikt inny nie jest w stanie zrozumieć lub zdebugować. Nie bądź purystą, nie przeprojektowuj rozwiązań tam, gdzie nie jest to absolutnie konieczne i nigdy nie bój się wziąć czegoś, co jest już złożone i spróbować to uprościć.

Priorytetyzacja

Nie możemy zrobić wszystkiego. Nie możemy rozwiązać wszystkich problemów. Nie możemy wygrać wszystkich debat. Nie możemy uczynić wszystkiego doskonałym. Mamy ograniczony czas i ograniczone zasoby i musimy je mądrze wykorzystać. Oznacza to, że musimy być w stanie rozróżnić, co musimy upierać się przy robieniu, co możemy odłożyć na później, a co powinniśmy zignorować. Programiści podejmują takie decyzje dziesiątki razy każdego dnia. Kiedy zastanawiamy się, czy zbadać błąd, kiedy zastanawiamy się, czy zrobić jakiś refaktoring, kiedy zastanawiamy się, czy obsłużyć jakiś przypadek użycia lub przypadek brzegowy, kiedy zastanawiamy się, czy zrobić objazd od zaplanowanego zadania, a nawet kiedy inwestujemy czas w przekonanie kogoś do naszego zdania. Dobrzy inżynierowie wiedzą, że należy być nieugiętym w naprawianiu, badaniu, dociekaniu lub naleganiu, aby przedstawić swój punkt widzenia na rzeczy, które są naprawdę ważne. Wiedzą, by zrobić notatkę i wrócić do czegoś później, jeśli jest to ważne, ale nie pilne. I wiedzą, aby zostawić coś w spokoju lub przyjąć czyjąś opinię, nawet jeśli są niezadowoleni z niego, gdy nie jest to naprawdę tak ważne.

Zarządzanie czasem

Jak wspomniano powyżej, smutna prawda o naszej egzystencji jest to, że jesteśmy związani przez czas. Produkty, które tworzymy, muszą w końcu wejść na rynek, mamy terminy, szacunki i cele do osiągnięcia. Dobrzy programiści muszą rozwinąć nie tylko intuicję do szacowania, ile czasu zajmują ich zadania, ale także muszą być sprytni w tym, jak rozbijają i porządkują swoje zadania na jeszcze mniejsze części. Muszą mądrze zarządzać przerwaniami i przełączaniem kontekstu. Ta intuicja szacowania czasu jest nieodłączną częścią zdolności do ustalania priorytetów, jak opisano powyżej. Na przykład, jeśli coś jest wystarczająco krótkie, to może być warte zrobienia, nawet jeśli nie jest super ważne. A jeśli jest zbyt długie, może lepiej odłożyć to na później lub skonsultować się z rówieśnikami lub menedżerem.

Wnioski

Jak już wspomnieliśmy wcześniej, wierzymy, że inżynierowie, którzy są ekspertami we wszystkich powyższych dziedzinach, mogą uczynić zespół 10x lepszym poprzez wpływanie i inspirowanie swoich rówieśników. Wspaniali inżynierowie muszą zawsze pamiętać, że jest to część ich codziennej pracy: wpływać i inspirować. Oznacza to, że musisz znaleźć czas nie tylko na wykonywanie swojej pracy, ale także na pomaganie innym w wykonywaniu ich pracy. Przyjmuje to wiele form: mentorowanie ludzi w zespole, tworzenie zasobów edukacyjnych, upewnianie się, że wszystko jest dobrze udokumentowane, bycie zawsze otwartym na wyjaśnienia i współpracę z ludźmi i wiele innych. Bycie dobrym mentorem i wychowawcą oznacza, że nie tylko pomagasz członkom swojego zespołu w rozwoju, ale także pogłębiasz swoje zrozumienie wszystkiego, co robisz, i daje ci nową perspektywę na jasność rzeczy, złożoność systemu i miejsca, w których rzeczy mogą się poprawić.

To są cechy inżynierów 10x, nie tylko w ich indywidualnym wpływie, ale także w ich wpływie na wszystkich innych. Zawsze zadawaj sobie pytanie, co możesz zrobić, aby zwiększyć swój wpływ, zawsze jest więcej miejsca do rozwoju.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.