10 punktów, które składają się na prawdziwych „10x inżynierów”

Może widzieliście wątek krążący ostatnio po Twitterze na temat „10x inżynierów”. Jeśli nie, możesz go przeczytać w całej okazałości:

Shekhar Kirani @Accel

@skirani

10x inżynierów
Założyciele Jeśli kiedykolwiek natkniecie się na tę rzadką rasę inżynierów, chwytajcie ich. Jeśli masz inżyniera 10x jako część swoich pierwszych kilku inżynierów, znacznie zwiększasz szanse na sukces swojego startupu.
OK, oto trudne pytanie.
Jak rozpoznać inżyniera 10x?

13:02 PM – 11 Jul 2019

Podsumowanie tego jest takie, chyba że pasujesz do jakiegoś super wąskiego i stereotypowego widoku bycia deweloperem, nie jesteś „inżynierem 10x”.

Wielu powie, że „10x inżynier” nie istnieje, ponieważ bycie 10x lepszym w czymś od kogoś/większości ludzi byłoby cholernie trudne. Nawet jeśli ta osoba nie ma dosłownie na myśli „10x”, to nadal próbuje powiedzieć, że jest ktoś znacznie lepszy we wszystkim.

Personalnie nienawidzę terminu „10x inżynier”. Podobnie jak „rockstar developer”, są to słabe opisy i definicje tego, czym są wielcy deweloperzy.

Byłoby nieuczciwe powiedzieć, że wszyscy deweloperzy są równi. Już po kilku minutach patrzenia na różnych deweloperów na Twitterze, widzę wielu deweloperów, którzy wiedzą o wiele więcej niż ja. To powiedziawszy, mówienie o tym „10x inżynierze”, jakby mogli znacząco zwiększyć szanse na sukces twojej firmy, jest dość śmieszne.

Dość o obalaniu tego okropnego stereotypu „10x inżyniera”, porozmawiajmy o rzeczach, które naprawdę sprawiają, że świetni deweloperzy (aka prawdziwy „10x inżynier”).

1. Są inteligentni, ale znają swoje ograniczenia

Bez względu na to, że nie jest to jakaś trywialnie mała baza kodu, nie znają każdej linii kodu, która trafiła do produkcji. Jasne, że mogą rozwiązać wiele problemów samodzielnie, ale wiedzą, kiedy utknęli i wiedzą, kiedy poprosić o pomoc.

Nie ma nic złego w proszeniu o pomoc, bez względu na poziom umiejętności!

2. Silny niezależnie, ale nadal tworzyć kick-ass zespół

Są czasy na programowanie niezależnie i są czasy na programowanie w zespole. Ci deweloperzy nie tylko biorą zadanie i uciekają w kąt, aby pracować nad nim w silosie do wszystkich innych. Rozwój poza najmniejszą skalą wymaga ciągłej współpracy z zespołem – czy to będzie programowanie w parze, przeglądanie kodu, dzielenie się pomysłami, pomoc w debugowaniu itp.

Nie oznacza to, że świetny programista nie czuje się bardziej komfortowo pracując samemu nad niektórymi zadaniami, ale rozwój na dużą skalę jest praktycznie niemożliwy bez silnej współpracy.

3. Pomagają innym w rozwiązywaniu problemów

Czy kiedykolwiek poprosiłeś kolegę o pomoc, a on to zrobił? Gratulacje, może być świetnym programistą. Możemy szukać pomocy w dokumentacji lub nawet na Stack Overflow, ale czasami faktycznie potrzebujemy pomocy od kogoś, kto zna naszą bazę kodu. Jeśli jesteś programistą, który wie coś, co może pomóc koledze, pomóż mu!

4. Są mili i wyrozumiali

Bycie świetnym developerem nie polega na byciu mądrym dupkiem, popisywaniu się swoim intelektem, lekceważeniu spotkań, ponieważ jest się lepszym od tych ludzi. Bycie świetnym programistą polega również na byciu dobrym w sprawach nietechnicznych. Jeśli „pomagasz” koledze krzycząc na niego i krytykując jego kod, po prostu przestań.

5. Rzucają ci wyzwanie (we właściwy sposób)

To może brzmieć kontrowersyjnie, ale świetny programista nie będzie dawał ci odpowiedzi przez cały czas. To może brzmieć w sprzeczności z #2 i #3 jednak to nie jest przeznaczone do trzymania czegoś nad tobą. Świetny programista to ktoś, kto może dać Ci wystarczająco dużo, abyś sam mógł to rozwiązać. Te małe wyzwania pomogą Ci stać się lepszym programistą i pozwolą Ci zrozumieć, o jakich rzeczach możesz potrzebować dowiedzieć się więcej.

6. Rozumieją, że „nowe świecidełka” nie są rozwiązaniem dla wszystkiego

Nie mówię, że ci programiści nie sprawdzają nowych narzędzi i języków (mogą robić co chcą w tej kwestii), ale rozumieją, że nowe narzędzia nie rozwiążą magicznie każdego problemu.

James Hickey 🇨🇦👨💻

.

@jamesmh_dev

Mamy obsesję na punkcie poznawania kolejnych narzędzi i języków!
Jeśli twoja architektura jest zła, rozwiązujesz niewłaściwe problemy, twój klient nie rozumie, kiedy próbujesz mu wszystko wytłumaczyć… to błyszczące narzędzia nie pomogą.
A są one fundamentalne dla sukcesu twojej firmy!

18:54 PM – 27 Jun 2019

7. Wiedzą, że nie ma znaczenia, kiedy programujesz i jakiego motywu edytora używasz

Stereotypy programistów na bok, dlaczego czas, w którym programujesz miałby robić różnicę? Programuj w środku nocy, jeśli chcesz/jesteś dopuszczony przez firmę i nie rób tego, jeśli nie chcesz. Jedynym powodem, dla którego czas powinien wchodzić w grę jest to, że programowałeś zbyt długo i nie spałeś! Faktyczna pora dnia nie ma znaczenia, chyba że ma to wpływ na twój zespół (np. pracujesz o północy programując, aby celowo uniknąć wszystkich).

Tak samo jest z tematami edytorów, dlaczego ciemny motyw miałby właściwie uczynić cię lepszym? Dam ci wskazówkę, nie czyni. Ciemne motywy mają swój cel, ale to na pewno nie jest to.

8. They don’t go out of their way to make something more complex

This might be obvious but there was another Twitter thread the previous week talking about programming something complexly like that is a good thing to do. Kiedy utrudnianie naszej pracy i pracy naszych kolegów było dobrą rzeczą?

Na pewno zdarzają się sytuacje, w których możemy skończyć z programowaniem złożonego rozwiązania, jak być może nie rozumiemy (jeszcze) w pełni problemu. Może się to zdarzyć przy pierwszej próbie zaprogramowania rozwiązania, to właśnie wtedy zazwyczaj słyszy się ludzi mówiących o refaktoryzacji kodu lub nie będących „dumnymi” z kodu, który napisali w poprzednim tygodniu/miesiącu/roku.

9. Nie myślą o „mnie” w „zespole”

Bez względu na to, że sami napisali każdą linię kodu źródłowego od kompilatora aż po całą logikę biznesową, wiedzą, że był to wysiłek zespołowy. Nie próbują zabierać światła reflektorów nikomu innemu w zespole – podkreślają cały wkład, który sprawił, że projekt zakończył się sukcesem.

Gdy projekt nie idzie dobrze, nie idą naprzód i nie obwiniają wszystkich. Projekty zespołowe zawodzą jako zespół, a nie jako jednostki (chyba że w złych zamiarach). Pomagają całemu zespołowi uczyć się na błędach i zapobiegać ich ponownemu wystąpieniu.

10. Faktycznie chcesz z nimi pracować

Na koniec dnia, ci wspaniali programiści to ludzie, z którymi faktycznie lubisz pracować. Pojawiasz się w pracy (lub zdalnie) i cieszysz się, że pracujesz z tak niesamowitym zespołem.

Jeśli znasz deweloperów, którzy brzmią w ten sposób, powiedz im, jacy są niesamowici i jak bardzo cieszysz się, że z nimi pracujesz 🙂

.