Wielu młodych ludzi, którzy dopiero zaczynają, w tym ja sprzed lat, wierzy w jedną niezmienną zasadę: dopóki moje umiejętności są wystarczające, jestem niezastąpiony.
Więc szaleńczo się rozwijamy. Uczymy się Javy, Go, Rust, przeglądamy kod źródłowy, zagłębiamy się w algorytmy, zajmujemy się mikroserwisami, wdrażamy chmurę. Dziś borykamy się ze Spring Cloud, jutro musimy nauczyć się Service Mesh, pojutrze AI i duże modele będą na topie, więc musimy szybko nauczyć się inżynierii promptów.
Myśleliśmy, że to się nazywa ambicją, w rzeczywistości to się nazywa cybergnoza.
Myślisz, że budujesz barierę technologiczną, w rzeczywistości pomagasz swojemu szefowi w weryfikacji wykonalności nowych technologii.
W branży internetowej tempo deprecjacji technologii jest szybsze niż spadek wartości twojego mieszkania, które kupiłeś. Poświęciłeś trzy lata na zgłębianie ram, a może Google czy Facebook wydadzą nową wersję lub zmienią koncepcję architektury, a twój dumny 'sposób na zabijanie smoka' nagle stanie się makulaturą.
Ale to nie oznacza, że nauka jest bezużyteczna, lecz że kierunek twoich wysiłków może być błędny. Zamiast gonić za ramami, które zmieniają się co trzy lata, lepiej skupić się na podstawowej logice, która nie zmieni się przez dziesięć lat. Na przykład, gdy ty nadal zastanawiasz się, czy użyć Spring Cloud, czy K8s, prawdziwi wielcy myśliciele rozważają spójność danych w systemach rozproszonych. Jeśli chcesz wydostać się z cyklu ram, polecam zająć się książką uznawaną za biblię backendu (Projektowanie systemów aplikacji intensywnie wykorzystujących dane) (DDIA wersja z komentarzem). Mówi ona o istocie systemów rozproszonych, baz danych i projektowania systemów. Zrozumienie tych kwestii sprawi, że niezależnie od tego, jaki framework będzie popularny jutro, będziesz w stanie dostrzec jego istotę.
Czy pamiętasz tych braci, którzy zajmowali się Flashem? Czy pamiętasz tych guru, którzy pisali systemy Symbian?
Czy oni nie pracowali ciężko? Czy oni nie byli mądrzy?
Kiedy czasy cię porzucają, nawet nie powiedzą ci 'do widzenia'.
Najstraszniejsze jest to, że nasza duma z szybkiej zdolności do nauki jest w rzeczywistości cechą, którą najbardziej lubi kapitał.
Ponieważ uczysz się szybko, jesteś tańszy.
Kiedyś stary chiński lekarz stawał się coraz cenniejszy, ponieważ jego doświadczenie było nie do skopiowania. A teraz? 35-letni stary programista, aby zarabiać więcej, ma niską wartość. 23-letni świeżo upieczony absolwent uczelni, wystarczy, że da mu dwie książki, żeby poszedł na GitHub i coś zmienił, a po miesiącu już będzie mógł pracować.
W tym momencie powiesz: 'Mam doświadczenie, mogę uniknąć pułapek.'
Nie żartuj. W większości przypadków, które są CRUD, w ogóle nie potrzebujesz tak zaawansowanej technologii. Co z tego, że kod jest niechlujny? Wystarczy dodać dwa serwery, prawda? Co z pamięcią, która przecieka? Wystarczy zrestartować ją codziennie o północy, prawda?
Dla szefa liczy się, żeby działało.
Twoje eleganckie kody, twoje wzorce projektowe, twoje myślenie architektoniczne, w oczach szefa są mniej wartościowe niż ten, który może z nim napić się dużej ilości alkoholu, narysować mu wielkie perspektywy i zrobić błyszczące PPT.
To jest mechanizm 'złej monety wypierającej dobrą'.
Kiedy odkrywasz, że twoje badania nad podstawowym kodem przez pół miesiąca są mniej wartościowe niż inżynier PPT z sąsiedniego zespołu, który codziennie krzyczy o 'wzmocnieniach', 'uchwytach', 'zamkniętych pętlach' i 'granulacji', czas, abyś się obudził.
Największą tragedią techników jest to, że zawsze jesteśmy zbyt daleko od pieniędzy.
Jesteśmy siłą roboczą, ale nie jesteśmy liderami w relacjach produkcyjnych.
Napisałeś niesamowity algorytm rekomendacji, który zwiększył retencję użytkowników. Czyja to zasługa? To zasługa operacji, to zasługa produktu, a nawet tej osoby, która załatwiła współpracę z kanałem.
Dlaczego?
Ponieważ w logice biznesowej technologia to tylko narzędzie.
Jak budowanie domu, jesteś tym, który przenosi cegły i buduje ściany. Niezależnie od tego, jak prosto budujesz ściany i jak szybko przenosisz cegły, ostatecznie to deweloperzy, sprzedawcy mieszkań, a nawet spekulanci na rynku nieruchomości zarabiają na sprzedaży domów, a nie ty, ten, który przenosi cegły.
A ponadto, technologia często jest tą, która ponosi winę.
System się zawalił, to ty ponosisz winę. Wprowadzono później, to ty ponosisz winę. Zbyt wiele błędów, to ty ponosisz winę.
Ale co, jeśli biznes się nie rozkręcił?
Menadżer produktu powie: 'Chcę to zrobić dobrze, ale technologia nie wspiera, ta funkcjonalność nie może być zrealizowana, harmonogram jest za długi.'
Zobacz, jak doskonała jest ta zamknięta pętla.