3 rzeczy, których nauczyłem się po stażu w Amazonie

Zbliżam się do końca mojego 2-miesięcznego stażu w "najbardziej zorientowanej na klienta firmie na świecie". Mam to szczęście, że mogłem spędzić lato, poznając kulturę pracy w jednej z największych firm. Tego nauczyłem się w ciągu tych 2 miesięcy w Amazonie.

Uwaga: Chociaż artykuł dotyczy mojego czasu pracy spędzonego w Amazonie, nie odzwierciedla on poglądów ani postawy mojego pracodawcy. Staram się również trzymać z dala od ujawniania rzeczy, które są potencjalnie poufne, więc nie będę mówił o wewnętrznych narzędziach ani o tym, co dokładnie robiłem, tylko o doświadczeniach, które za nimi stoją.

1. Świat jest pełen naprawdę mądrych i życzliwych ludzi

Mógłbym zatytułować ten punkt „Amazon jest pełen naprawdę inteligentnych ludzi”, ale akurat śmiało mogę powiedzieć, że dziedzina, jaką jest inżynieria oprogramowania — przyciąga po prostu niezwykle inteligentnych ludzi.

Nie byłem stażystą po raz pierwszy, ale to mój pierwszy staż w firmie FAANG. Nie sądzę, aby cokolwiek mogło mnie przygotować na skalę, której miałem być świadkiem: wszystko w Amazonie było ogromne i zbudowane w skali planety. Narzędzia wewnętrzne mają więcej użytkowników, niż kiedykolwiek będzie miało wiele startupów SaaS.

Za tak ogromną skalą kryje się wiele złożoności. Oczywistym jest, że nikt nie chce, abyś radził sobie z tą złożonością sam. Za każdym razem, gdy potrzebowałem pomocy z jakimś narzędziem lub oprogramowaniem, mój zespół był o jedno kliknięcie ode mnie. I uwierzcie mi, byli cholernie dobrzy w tym, co robili.

Były takie momenty, że kiedy zadawałem pytanie, dostawałem wręcz błyskawiczną odpowiedź. Te chwile były naprawdę imponujące, ale jeszcze bardziej imponujące były momenty, kiedy pytałem kolegę o problem, którego nie mogłem rozgryźć, a on od razu zabierał się do debugowania. Ich metody były szybkie, skuteczne, natychmiastowe, konkretne i bezwzględnie logiczne.

Ponieważ tak jak wspomniałem, nie był to mój pierwszy staż, nie było mi obce zadawanie wielu pytań i otrzymywanie feedbacku. Każda osoba, z którą pracowałem, czy to w Amazonie, DAIS, czy w społeczności open source, była człowiekiem o wybitnym charakterze. Choć oczywiście występują wyjątki od reguły, dziękuję Wam drodzy inżynierowie oprogramowania! I nie tylko w Amazonie, ale wszędzie! Za bycie wspaniałymi, pomocnymi ludźmi.

2. AWS jest ogromny

Wchodząc do Amazona, myślałem, że nauczyłem się już całkiem sporo o AWS i narzędziach, które oferuje. Nadrobiłem nieco w EC2, poświęciłem trochę czasu na nauczenie się RDS i Aurora, zapłaciłem z własnej kieszeni za API gateway, a nawet miałem krótki epizod z Texttract.

Lista narzędzi AWS, z których wcześniej korzystałem, była "mała" w porównaniu z ilością narzędzi, z których mój zespół, niewielka część firmy, korzysta na co dzień.

Są również pewne serwisy, których się uczyłem, i są prawie tożsame: AWS CDK i Cloud Formation są niesamowite i będę ich używał w przyszłości w osobistych projektach. I nawet tych mniejszych, bo, IaaC i elastyczność, jaką daje AWS CDK, to też niezrównana siła.

Inne serwisy były mniej używane, ale nadal znajdują się w zestawie narzędzi wielu inżynierów. Jednym z tych narzędzi, które jest bardzo przydatne w odpowiednim kontekście, jest Step Functions. Szereg działań (głównie lambdas, ale także inne serwisy, takie jak Glue Jobs), które mają być aktywowane w serii, pozwalają na rozbicie złożonych zadań i monitorowanie małych elementów dużej układanki.

Nie bez powodu AWS jest infrastrukturą internetu. Ogromna ilość narzędzi i aplikacji dla każdego przypadku użycia jest naprawdę wygodna.

Jeśli używasz jakiegoś oprogramowania, to jest ono dostępne w AWS. A jeśli nie, to wkrótce będzie.

3. Wbrew powszechnemu przekonaniu, struktury danych i algorytmy nie są używane tylko do odsiewania kandydatów

Jest to bardziej niszowy i kontrowersyjny punkt, ale jest to podejście, które moim zdaniem ma konkretną wartość.

Myślę, że większość społeczności programistycznej nie lubi pytań w stylu Leetcode. Nie, żebym hołdował tu jakoś firmom FAANG, ale sam lubię takie pytania — w najgorszym wypadku to niezła metryka wysiłku włożonego w to, żeby dostać się do takiej firmy, co przekładało się na dobrze skalowalny mechanizm rekrutacyjny.

Będę jednak pierwszym, który przyzna, że całkowita ilość przypadków, w których znajomość optymalnej ilości monet do stworzenia określonej ilości reszty okazała się przydatna, była dość niewielka. Jednak... przechodziłem przez proces rozmowy kwalifikacyjnej Amazona, a co za tym idzie, spędziłem wiele godzin na ćwiczeniu Leetcode’u.

Kiedy dostałem pracę w Amazonie, zacząłem drążyć w kodzie w obszarze aplikacji. Tylko w moim projekcie miałem okazję używać stert, list, map. Nie sądzę, że mój projekt byłby możliwy do utrzymania gdybym przewrotnie nie użył programowania obiektowego. Przestrzeń problemów była po prostu zbyt złożona, aby można było ją skutecznie rozwiązać bez dobrego programowania.

Nie znaczy to oczywiście, że starałem się wymyślić, jak sprawić, by mój program zmieścił się w jednej linii. Czytelność i łatwość utrzymania zawsze były i będą ważniejsze niż zwyczajna, sucha wydajność (w większości przypadków! Amazon jest tak wielki, że zawsze znajdzie się jakieś odstępstwo), jednak wiele razy byłem w stanie zoptymalizować mój kod dla lepszego UX, używając znienawidzonych DSA i odpowiednich technik kodowania.

Czy uważam, że inżynierowie powinni siedzieć godzinami, próbując rozgryźć programowanie dynamiczne w 3D? Nie. Czy uważam, że niektórzy programiści spędzają tyle czasu nienawidząc DSA, że nie dostrzegają ich praktycznych zastosowań? Właśnie tak.

Podsumowanie

I to by było na tyle! Oto 3 wnioski z mojego letniego stażu.

Jeśli masz jakieś pytania lub wątpliwości, albo nie zgadzasz się ze mną w którymś punkcie, nie wahaj się zostawić komentarza! Dzięki za przeczytanie!

Oryginał tekstu w języku angielskim przeczytasz tutaj.