Programowanie to sztuka? Prawdy i mity na temat pracy programisty

Mity rodzą się z niewiedzy i często ze złudnych przekonań, że coś jest bardzo trudne albo bardzo łatwe. Tak jest też w przypadku prawd i mitów na temat pracy programisty, które krążą po sieci i często wprowadzają w błąd. Dlatego zebrałem najczęściej powtarzane mity i postanowiłem zmierzyć się z nimi.

Jacek Spólnik. Lead Software Engineer w Revolut. Dołączył do Revolut w listopadzie 2018 roku i w ramach nowych obowiązków odpowiada za rozwój platformy Revolut i rekrutacje inżynierów w Krakowie. Łączy umiejętności miękkie z umiejętnościami technicznymi, co pozwoliło mu stworzyć i kierować wieloma zespołami programistów. W latach 2017-2018, jako lider technicznego zespołu pomagał sukcesywnie tworzyć i usprawniać platformę UBS Neo, na bazie której dziesiątki zespołów tworzą rozwiązania dla klientów UBS.

1. Najlepiej znać jak najwięcej frameworków i języków programowania, żeby być wszechstronnym.

I tak, i nie. Zdecydowanie zgadzam się, że znajomość wielu języków programowania pomaga dobrać odpowiednie narzędzie do rozwiązania danego problemu. Z drugiej strony, zarówno dogłębne poznanie języka programowania, jak i jego kultury, zajmuje naprawdę sporo czasu. Nie mówiąc już o frameworkach, które zmieniają się szybko — czasem idąc za modą — gdzie nowszy wypiera starszy i nasza wiedza nie jest już taka użyteczna.

Dlatego uważam, że poza aktualnymi trendami, cenniejsza jest wiedza jak tworzyć oprogramowanie wysokiej jakości w dowolnym języku, jak skalować systemy komputerowe. Ponadto, zrozumienie podstawowych koncepcji takich jak sieci, działanie różnych protokołów, algorytmów i struktur danych. Znajomość wszystkich tych narzędzi pozwala szybciej rozwiązywać konkretne wyzwania biznesowe i efektywniej rozwijać produkt.

2. Po co uczyć się starych języków programowania, skoro są nowe?

Języki takie jak JavaScript, C, Assembly są wszechobecne. Bez ich znajomości — pomimo nowoczesnych alternatyw, jak TypeScript, Java/Kotlin/C#/Scala — nie będziemy w stanie poznać niektórych aspektów świata oprogramowania. Przykładowo, Assembly ułatwia zrozumienie działania procesorów, alokowania pamięci czy wykonywania instrukcji w komputerach na najniższym poziomie. Pozwoli zrozumieć między innymi działania arytmetyczne na liczbach oraz ograniczenia z tym związane. Podobnie jest z językiem C, w którym napisana jest spora część nowoczesnych systemów operacyjnych, jak i systemów typu embedded.

Zobacz też

growth hacks Jak dostarczyć klientowi wersję beta aplikacji napisanej w React Native

3. Studia to strata czasu. Przez te kilka lat więcej nauczę się sam.

Nie do końca jest to prawda. Już podczas rekrutacji do Revolut jesteśmy w stanie znaleźć różnice między kandydatami, którzy mają studia kierunkowe — a tymi, którym ich brak. Zwykle deweloperzy bez studiów mają wiedzę opartą na realizacji konkretnych projektów w pracy, lub własnych. Ich doświadczenie często ogranicza się do elementów potrzebnych do realizacji danego zadania. Tymczasem przy projektach na większą skalę, kluczowa jest szersza wiedza na temat funkcjonowania sieci; jak dokładnie działają bazy danych oraz jak nasze ich użytkowanie wpływa na możliwe rozwiązania; jakie języki programowania stosować do konkretnych problemów, aby tworzyć wartość biznesową przy zmniejszonych nakładach technologicznych.

4. Dobry programista to taki, który szybko pisze kod.

Szybkie pisanie na klawiaturze na pewno jest zaletą, ale nie jest jedynym elementem definiującym dobrego programistę. Zwykle porównuję to do jazdy na motocyklu — jeśli jedziesz szybciej, niż jesteś w stanie ocenić sytuację na drodze, przewidzieć różne zagrożenia — możesz skończyć naprawdę źle. Podobnie jest z programowaniem, jeśli tworzysz oprogramowanie szybciej, niż jesteś w stanie zapewnić jego jakość — poprzez testy jednostkowe, integracyjne, analizę domeny, jakości kodu czy zrozumienie słabych punktów architektury. Na etapie produkcji szybko może się okazać, że owszem wszystko działa, ale przy mniejszym ruchu klientów, gdy popularność serwisu rośnie wraz ze skomplikowaniem domeny można dojść do punktu, gdzie projekt dalej się nie rozwija, a wtedy szybkość kodowania nie ma znaczenia.

5. Im więcej programistów w projekcie, tym szybciej zostanie zrealizowany.

Niestety przy projektach związanych z tworzeniem oprogramowania ta zasada się nie sprawdza. O ile, na samym początku, może mieć sens przypisanie większej grupy ludzi do projektu, o tyle zwykle efektywne zespoły nie przekraczają 5-10 programistów. Dlaczego tak jest? Zwykle jest to związane z komunikacją i synchronizacją działań, zwłaszcza kiedy zespół pracuje nad tym samym repozytorium kodu tworząc nowe funkcjonalności. Ponadto każda nowa osoba potrzebuje wprowadzenia do projektu — jak on działa, jakie technologie stosujemy czy jak przebiega komunikacja. Wdrażanie nowych pracowników jest osobnym, często czasochłonnym zajęciem, który trzeba odpowiednio zaplanować w grafiku całego zespołu. Jak już wspomniałem wyżej, jeżeli zależy nam na czasie i efektywności działań, lepiej sprawdzają mniejsze zespoły.

Oferty pracy z

6. Szybko zostaje się Programistą10k. Wysokie zarobki to tylko kwestia czasu.

Oczywiście, jeśli tylko włożysz odpowiednio dużo czasu w poznanie podstaw inżynierii oprogramowania (sieci, bazy danych, systemów operacyjnych, różnych języków i paradygmatów programowania) oraz napiszesz odpowiednio dużo kodu tak, aby móc sprawnie rozwiązywać problemy w późniejszej pracy nad aplikacją. Równolegle warto rozwijać tzw. umiejętności miękkie, jak na przykład tworzenie oprogramowania open source, budowania własnej marki i komunikacji w zespole. Wtedy, jak najbardziej, można szybko zostać Programistą10k.

7. Programista nie musi znać się na testowaniu, od tego są testerzy.

Jeśli mamy szczęście mieć testerów w swoim teamie — oni powinni być odpowiedzialni za weryfikację zmian kodu przez programistów. W Revolut działamy według zasady czterech oczu, gdy dwie osoby weryfikują ewentualne błędy. Ponadto dobrzy testerzy mają często szerszą wiedzę niż deweloperzy i mogą pomóc w przeglądaniu tworzonych testów, dawać konstruktywny feedback, jak i pokazywać pominięte corner casy. A wracając do programistów — naszym obowiązkiem jest dostarczyć oprogramowanie, które działa i spełnia wszystkie wymogi odnośnie jakości. Nie da się tego osiągnąć bez automatycznych testów, czy to jednostkowych, czy integracyjnych. Jeśli chcesz się dobrze wyspać po releasie nowych zmian — upewnij się, że napisałeś dobre testy automatyczne.

8. Po ośmiu godzinach pracy nie myślę o programowaniu, a już na pewno nie uczę się, bo wszystkiego dowiedziałem się realizując zadania w pracy.

Moim zdaniem to bardzo ograniczające podejście do pracy programisty. W innych zawodach, lekarze, prawnicy i inni specjaliści stale rozwijają swoją wiedzę, by być na bieżąco z nowymi trendami. Biorąc pod uwagę, że dynamika naszej branży jest dużo większa — nie wyobrażam sobie efektywnego rozwiązywania zadań w naszej pracy, jeśli ograniczamy się tylko do wiedzy podstawowej — bez poszerzania swoich horyzontów, wiedzy na temat nowych podejść do tworzenia oprogramowania, współpracy w zespole, czy języków programowania. Bez tego, istnieje ryzyko, że zostaniemy technologicznym dinozaurem z ograniczonymi możliwościami rozwoju w zawodzie programisty.

9. Na rynku brakuje programistów, więc rekruterzy rzucą się na moją kandydaturę.

Oczywiście, jeżeli masz dobre kompetencje, jest szansa, że dużo rekruterów będzie zainteresowanych kontaktem z Tobą. Jednak sam fakt braku specjalistów na rynku, nie jest gwarancją zatrudnienia. Najważniejsze są wiedza i umiejętności programowania.

10. Programowanie to sztuka, a każda linijka kodu to dzieło.

Programowanie to temat nauk ścisłych — i tutaj nie ma o czym nawet dyskutować. Prawdą jest jednak, że niektóre jego elementy mają więcej wspólnego ze sztuką — na przykład, dojście do perfekcji w pisaniu tzw. clean code. Każdy z naszych deweloperów ma własny styl kodowania, czy nanoszenia zmian w kodzie. Dlatego w Revolut często robimy przeglądy kodu, aby wychwycić indywidualne rozwiązania, na korzyść wspólnych zasad tworzenia oprogramowania, łatwych do zrozumienia i śledzenia zmian. Dodatkowo jest wiele narzędzi, które pozwalają reorganizować kod automatycznie lub robić refactoringi.

Traktowanie każdej linijki kodu jako dzieła sztuki niesie niebezpieczeństwo tzw. over-engineeringu, gdzie tak naprawdę „dziełem” możemy raczej nazwać działającą funkcjonalność jako całość, a jest to złożony element składający się z kodu implementującego funkcjonalność, testu sprawdzającego oraz skryptów deployment’owych, które pozwalają nam wrzucić zmiany na środowiska produkcyjne.

Zobacz też

growth hacks Kapituły, czyli jak stworzyć samorganizujące się działy IT

Zdjęcie główne artykułu pochodzi z internetvibes.net.