O czym w kontekście programowania mówi się za mało? Devdebata

Specjalizacja jest dobra, ale lepsza jest specjalizacja prowadząca do łatwiejszej współpracy. Za małą wagę przywiązujemy do kontaktu z użytkownikiem naszych aplikacji. Programowanie to nie tylko pisanie w jednym konkretnym języku i koniec, „reszta mnie nie interesuje”. Tak na pytanie postawione w tytule odpowiedzieli seniorzy, którzy zaprosiliśmy do devdebaty. Zobaczcie, co sądzą o współpracy, niestandardowych sposobach nauki i o największym booście w swojej karierze.

Na nasze pytania odpowiedzieli:

Paweł Komarnicki. Właściciel w Cubitoo. Absolwent Informatyki na Politechnice Wrocławskiej, zawodowo specjalizuje się w tworzeniu aplikacji internetowych od podstaw. Od 8 lat mieszka na stałe w Berlinie, aktualnie prowadzi własną agencję interaktywną oraz współtworzy startup wspierający psychologicznie osoby cierpiące na choroby przewlekłe. Zapalony gracz, kucharz i fotograf hobbysta. Więcej o jego ścieżce kariery dowiesz się z naszej rozmowy z Pawłem.

Paweł Kowalik. Architect .NET w Onwelo. Wcześniej przez sześć lat pracował jako Software Engineer w Mellon Poland. O sobie mówi, że jest programującym architektem. Zwolennik czystego kodu, który jest ostatecznym, wykonywalnym poziomem dokumentacji wiedzy biznesowej. Uważa, że proste rozwiązania łatwiej utrzymywać. Przeciwnik Time and Materials – jego zdaniem zniechęca ono zespoły do szybkiego dostarczania wartości klientowi. Prywatnie mąż. Czasem piłkarz.

Artur Kosta. Team Leader Senior Software Developer w Objectivity. Android developer w firmie Objectivity. Wcześniej pracował w ATSA SA, Grupie Allegro, HERE i w Nokia Siemens Networks. Absolwent Politechniki Wrocławskiej na kierunku Informatyka. Przygodę z programowaniem rozpoczął od stanowiska testera. Entuzjasta technologii wszelkiego rodzaju, od smartfonów po samochody elektryczne. Trenuje crossfit i bycie ojcem na pełny etat. W wolnych chwilach gracz konsolowy.

1. O jakich zagadnieniach związanych z programowaniem mówi się za mało?

Odpowiada Paweł Komarnicki, właściciel w Cubitoo:

Dla mnie jednym mało poruszanym tematem jest to, że programowanie nie odbywa się w próżni. Dobre produkty nie są dobre tylko dlatego, że ktoś napisał poprawny, efektywny kod, ale przez połączenie wielu różnych, często sprzecznych, podejść i perspektyw patrzenia na produkt. Graficy oraz projektanci interfejsów będą mieli inne podejście do produktu, tak samo marketing, czy Product Ownerzy. Spotkałem się z wieloma sytuacjami, kiedy brak świadomości i wrażliwości tworzyły pewien rodzaj “bastionu” w zespole, a zespoły zamiast korzystać ze swojego doświadczenia, starały się ”przechytrzyć” inne zespoły, pokazać, że wiedzą lepiej.

Drugi temat wynika z tego, że jestem programistą “full-stack”: tworzę zarówno back-end, jak i front-end aplikacji, często w tym samym czasie. Wielu programistów izoluje się od “tej drugiej specjalności”, utrudniając samym sobie współpracę, a przecież nie o to chodzi w programowaniu. Wiele problemów można rozwiązać poprzez dobrą, otwartą współpracę i jest to coś, o czym powinno mówić się częściej: specjalizacja jest dobra, ale lepsza jest specjalizacja prowadząca do łatwiejszej współpracy.

Odpowiada Paweł Kowalik, Architect .NET w Onwelo:

Według mnie za małą wagę przywiązujemy do kontaktu z użytkownikiem naszych aplikacji. Dążymy do perfekcji technicznej, co jest bardzo dobre. Dzieje się to jednak kosztem tak zwanych umiejętności miękkich. Ostatnio mówi się też, że nie powinniśmy dzielić ich na twarde i miękkie. Jednak według mnie, umiejętności te są od siebie diametralnie różne a sam podział jest bardzo trafny. Jeżeli już chcemy iść krok dalej to nazywajmy je poprawnie: umiejętności techniczne i interpersonalne. Obu z nich możemy i powinniśmy się uczyć. Dlatego proponuję rozwijać je równolegle, z naciskiem na tę słabszą. Jeżeli jesteś świetny technicznie, a nie wychodzi Ci rozmowa z tak zwanym biznesem, trenuj słuchanie. Jeżeli jesteś lepszym sprzedawcą, skup się na tym, aby tworzyć jeszcze bardziej przejrzysty kod.

Odpowiada Artur Kosta, Team Leader Senior Software Developer w Objectivity:

Programowanie to nie tylko pisanie w jednym konkretnym języku i koniec, „reszta mnie nie interesuje”. Wokół produktu narastają inne technologie i narzędzia. Środowisko CI, system budowania końcowego produktu (Gradle), testy automatyczne (nie tylko unit testy, ale też testy UI), systemy do zarządzania translacjami, systemy raportowania błędów, które trzeba czasem odwiedzić. Wszystko to składa się na szereg umiejętności nabytych poprzez doświadczenie. Spotkałem osoby, które zamykały się totalnie na pisanie w języku, całkowicie ignorując inne problemy. A przy tworzeniu pełnoprawnego produktu jest więcej aspektów. Stąd też model cross-funkcjonalnego zespołu – spotykałem je w zespołach „doświadczonych” lub odpowiednio kierunkowanych przez scrum mastera, ale nie czuję, że jest to powszechnie rozumiane zagadnienie.

2. Dlaczego wybrałeś/-aś właśnie tę, a nie inną ścieżkę kariery?

Odpowiada Paweł Komarnicki, właściciel w Cubitoo:

Komputery fascynowały mnie od dziecka, jako dzieciak w podstawówce zacząłem mniej lub bardziej skomplikowane programy i zdałem sobie sprawę, że programowanie to “robienie czegoś z niczego”: każdy projekt zaczyna się jako pusta kartka, i ode mnie zależy jak będzie wyglądał on na końcu. Jest to też kariera, która pozwala na pewną dozę swobody: miejsca zamieszkania, języka, poznanych ludzi – gdzie indziej mógłbym pracować z psem?

Odpowiada Paweł Kowalik, Architect .NET w Onwelo:

Od dziecka lubiłem rozkręcać sprzęty elektroniczne, od telewizorów po odtwarzacze wideo i samochodziki. Niestety po ponownym złożeniu nie działały tak dobrze jak wcześniej. Z komputerem mi się udało, nie tylko po ponownym złożeniu działał, ale zostało jeszcze kilka śrubek. Udało mi się zoptymalizować jego konstrukcję. Potem w liceum kolega pokazał mi, że nie tylko mogę korzystać z komputera, ale także mu rozkazywać. Taki tajny język, nieznany innym ludziom. I tak to się zaczęło.

Odpowiada Artur Kosta, Team Leader Senior Software Developer w Objectivity:

Dla mnie powód był bardzo przyziemny, zaczęło się od gry ‘Prince of Persia’ na komputerze wujka, który był informatykiem. Dość późno jak na dzisiejsze standardy dostałem swój komputer, więc zanim to się stało kupowałem czasopismo ‘Komputer Świat’ (bardzo modne wtedy) i poznawałem sekrety Windowsa i rankingi drukarek oraz palmtop-ów (tak, to jest prawdziwe urządzenie). Aż pewnego dnia odwiedziłem siostrę, która studiowała informatykę i zabrałem jej książkę “Podstawy języka C++”. Już wiedziałem, że to jest to co chcę robić w życiu.

3. Jakie znasz niestandardowe sposoby na podniesienie umiejętności?

Odpowiada Paweł Komarnicki, właściciel w Cubitoo:

Będzie to brzmiało śmiesznie, ale: “spróbuj wszystkiego”, tj. oprócz programowania spróbuj projektowania graficznego, albo gotowania, szydełkowania, obróbki metali. Napisz książkę. Wiele z “przypadkowych” umiejętności nie tylko zmieniły moje podejście do programowania, ale także pozwoliły mi na zmianę mojego postrzegania problemów, bycia bardziej kreatywnym, a także wyrobiły wrażliwość na detale. Nie są to typowe “umiejętności programisty”, ale każda w jakiś sposób mnie wzmocniła i rozwinęła.

Odpowiada Paweł Kowalik, Architect .NET w Onwelo:

Po pierwsze: działanie. Ale to standardowy sposób. Nauka programowania przez programowanie. Po drugie: nauczanie. I to już jest mniej standardowy sposób. Ale dużo więcej nauczysz się ucząc innych. Poukładasz sobie w głowie zdobytą wiedzę. Co więcej: rzeczy, które Tobie wydają się oczywiste dla kogoś innego już nie są. Dlatego spodziewaj się wielu pytań. Także jeżeli jesteś juniorem, znajdź kolegę juniora. Ty nauczysz się A, on nauczy się B. Ty nauczysz go A. On nauczy Cię B. I zadawaj mu podchwytliwe pytania.

Odpowiada Artur Kosta, Team Leader Senior Software Developer w Objectivity:

Nie znam niestandardowych sposób, ale moim zdaniem najlepszy sposób to pisać, pisać i jeszcze raz pisać…kod. Można czytać książki, blogi i tutoriale, ale dla mnie to właśnie praktyka: po pierwsze utrwala wiedzę, po drugie pozwala wejść głębiej. Każdy umie napisać “Hello world!”, ale dopiero kiedy zderzymy się z prawdziwym problemem, wyjątkiem którego miało nie być, memory leakiem, którego nie planowaliśmy – to właśnie wtedy zaczynamy szukać, interesować się, poznajemy różne narzędzia, metody pracy, wzorce pomagające uniknąć błędów itp. I jest też udowodnione, że najlepiej uczymy się, gdy jesteśmy ciekawi, czyli nie wchłaniamy setek linijek wiedzy, tylko dociekamy, badamy, szukamy.

4. Co uważasz za największy do dziś boost w Twojej ścieżce kariery?

Odpowiada Paweł Komarnicki, właściciel w Cubitoo:

Dla mnie był to wyjazd za granicę i pierwsza praca w startupie “od zera”. Co innego programowanie “po godzinach”, dla siebie, czy praca w już istniejącej strukturze, kodzie, przyzwyczajeniach. Konieczność podejmowania bardzo odważnych decyzji, mając świadomość, że “nikt tego po mnie nie poprawi” pchnęły mnie w kierunku, dzięki którym dzisiaj jestem nie tylko jestem starszym programistą i CTO, ale także rozważam start kariery jako mentor.

Odpowiada Paweł Kowalik, Architect .NET w Onwelo:

Zaczynałem karierę od pracy na etacie. W firmie, która miała wewnętrzne IT spędziłem połowę mojej zawodowej kariery. Miałem to szczęście, że projekty były bardzo ciekawe i zróżnicowane. Od frontu, przez backend, bazy danych, embeded, mobile aż do rozmów z biznesem i utrzymania. Dużo security, które mnie interesuje. Jednak był to bardzo zamknięty świat. Przez ten czas miałem kontakt z niewielką liczbą koleżanek i kolegów programistów. W pewnym momencie całkiem przypadkowo znalazłem warszawską grupę .NET. Wybrałem się na meetup i zszokowała mnie liczba osób. Jeśli nie wiecie, to na meetupy przychodzą setki osób z branży.

W tamtym momencie zmieniłem też pracę na softhouse i założyłem jednoosobową działalność gospodarczą. Przede wszystkim otworzyło mi to oczy na kwestię podatków, zusów i tego, że urlopy nie zawsze są płatne. Największym boostem było poznanie dużej liczby nowych, naprawdę fajnych osób. Zobaczyłem jak ogromną społeczność tworzymy. A wspólna integracja, wyjścia na piwo i dyskusje, nie tylko o programowaniu, rozwinęły mnie chyba najbardziej.

Technicznie zawsze byłem dobry. Interpersonalnie już mniej. Dzięki różnym meetupom i przejściu na B2B do softhouse moja kariera weszła na inny poziom. Otworzyły się ścieżki, na które sam nawet bym nie wpadł. To jest właśnie potęga społeczności i ludzi w naszej branży. Zero wyścigu szczurów, ciekawe pomysły i dużo chęci pomocy innym. Ta wymiana doświadczeń i korzystanie z rad innych osób. Polecam.

Odpowiada Artur Kosta, Team Leader Senior Software Developer w Objectivity:

A czym jest kariera dla programisty? Life-changerem dla mnie był keynote wygłoszony przez Sandro Mancuso na otwarcie DroidCon-a w 2015 roku. Niby jest to oczywiste, a jednak często nie jest. Kariera programisty kończy się gdy [programista] podejmuje się innych stanowisk (leader, manager). Kiedy nowe obowiązki zabierają czas, który mógłby poświęcić na programowanie (specjalnie nie napisałem „robienie tego co kocha” bo może ktoś odnajdzie nowy cel w tych obowiązkach). Kariera programisty jest pozioma i nie jest to wada. Po prostu rozwijamy się zmieniając projekty lub technologie. Każda zmiana pracy lub projektu to jest boost. Wyjście ze strefy komfortu i wejście na wyższe obroty żeby pokazać w nowej firmie/projekcie, że dobrze wybrali. Poznanie nowych narzędzi, nowych rozwiązań, problemów z którymi jeden projekty się zmagają a inne nie.

5. Jak przygotować się do bycia dobrym programistą za 5 lat?

Odpowiada Paweł Komarnicki, właściciel w Cubitoo:

Dobrzy programiści nie biorą się z powietrza, jesteśmy wynikiem wielu lat pracy, szkolenia, błędów i samodzielnego rozwoju. Po pierwsze, gdybym miał zaczął od zera dziś, zacząłbym od podstaw: algorytmy, struktury danych, architektura oprogramia. Te rzeczy nigdy się nie wyjdą z mody, co najwyżej wyewoluują. Po drugie, w mojej karierze programowałem już w wielu językach: Visual Basic, Pascal, C++, C#, Java, Prolog, Python, Ruby, JavaScript – nie warto się przywiązywać do jednej technologii, ale warto mieć ulubione narzędzia (dla mnie są to Ruby on Rails i JavaScript/CoffeeScript). Wreszcie, po trzecie, warto patrzeć dokąd krążek zmierza, a nie gdzie aktualnie jest: dla mnie przyszłościowy okazał się Ruby on Rails, a teraz zaczynam coraz bardziej przyjaźnie patrzeć w stronę Fluttera. Będę w stanie tworzyć kompletne platformy internetowe, z dedykowanymi aplikacjami na Androida i iOS.

Odpowiada Paweł Kowalik, Architect .NET w Onwelo:

To podchwytliwe pytanie. Musielibyśmy ustalić co to znaczy „być dobrym programistą”. Pewnie można by na ten temat napisać książkę, a każdy z nas ma swoją definicję. Według mnie bycie dobrym programistą to dawanie wartości klientowi. Tak jak napisałem wcześniej, musimy rozwijać się wszechstronnie. Umiejętności techniczne: tutaj bardziej skupmy się na algorytmach, wzorcach i czytelności kodu, niż na konkretnym frameworku czy języku. Umiejętności interpersonalne: bardziej słuchajmy niż mówmy, podsuwajmy pomysły wskazując nie tylko problemy ale przede wszystkim rozwiązania.

Odpowiada Artur Kosta, Team Leader Senior Software Developer w Objectivity:

Zależy do kogo kierujemy tę radę. Dla doświadczonego programisty, przygotowaniem będzie utrzymanie się na “powierzchni technologicznej”. Świat technologii zmienia się bardzo szybko, ten programistyczny też. Pojawiają się nowe języki, nowe rozwiązania, nowe narzędzia. Trzeba śledzić to, próbować nowych rzeczy i nie zamykać się w swoim bezpiecznym świecie. Dla początkującego programisty przygotowaniem będzie sporo teorii, algorytmy, optymalizacje, i sporo rzeczy których możemy się nauczyć w trakcie studiów na dobrej uczelni. To daje fundament pod dobrego programistę. Następnym krokiem jest podjęcie praktyki, płatnej, bezpłatnej, nie ma znaczenia, byle był to prawdziwy projekt w którym będą wymagania. Pisanie dla siebie jest ok, ale rzadko zdarza się, że wymagamy od siebie testów, poprawnej architektury itp. często ‘machamy na to ręką’. Warto wejść w ten świat i zdobywać doświadczenie, równocześnie obserwując rozwój technologii i próbując innych rzeczy.

6. Co dzisiaj w pracy programisty jest akceptowalne, a takie nie było jeszcze pięć lat temu?

Odpowiada Paweł Komarnicki, właściciel w Cubitoo:

Być może jest to kwestia technologii, w której pracuję, ale szokuje mnie ilość programistów, którzy robią ”tylko front-end” albo “tylko back-end”. Nie wyobrażam sobie, że można tworzyć interfejs aplikacji, bez znajomości tego, co dzieje się za kulisami. Kiedy zaczynałem karierę, standardem było tworzenie oprogramowania full-stack.

Także w kwestii warunków pracy, aktualnie coraz częściej widzę akceptację dla pracy zdalnej, albo możliwość pracy z domu. Jest to bardzo dobry kierunek rozwoju branży programistycznej, zarówno stwarzający bardziej przyjazną atmosferę dla pracowników, jak i pozwalający firmom na zatrudnianie doskonałych specjalistów z innych miast, czy krajów.

Odpowiada Paweł Kowalik, Architect .NET w Onwelo:

Z mojego punktu widzenia chyba zawsze wszystko było akceptowalne. Mamy to szczęście, że programowanie to zdecydowanie rynek pracownika. Mam wrażenie jednak, że staliśmy się trochę bardziej roszczeniowi. Konsola, piłkarzyki a jednocześnie praca zdalna i owoce we wtorki. Z drugiej strony robimy to, bo możemy. Pytanie tylko jak długo jeszcze.

Odpowiada Artur Kosta, Team Leader Senior Software Developer w Objectivity:

Nie widzę różnicy między dzisiaj, a pięć lat temu. Może gdyby to była kwestia 10 lat coś by się dało zauważyć:

• nie wszędzie można było zwracać się na ‘ty’ do osób wyżej,
• studia były niepodważalnym wymogiem na stanowisko programisty.

7. Jaki problem świata chciałbyś rozwiązać za pomocą programowania, gdybyś miał czas, ludzi i pieniądze?

Odpowiada Paweł Komarnicki, właściciel w Cubitoo:

Chciałbym rozwiązać dwa problemy, tworząc produkty dla ludzi chcących poznać samych siebie i mieć wgląd we własne zdrowie, psychikę, cykl organizmu. Chciałbym takżę tworzyć produkty dla efektywnych zespołów: wspierać ich wysiłki organizacyjne, zarządzanie zadaniami, komunikację, bez bagażu “tego jak to robi konkurencja”.

Odpowiada Paweł Kowalik, Architect .NET w Onwelo:

Chyba skupiłbym się na wykorzystaniu sztucznej inteligencji w diagnozowaniu chorób. Mamy do dyspozycji moc obliczeniową i ogromną liczbę danych. Nieporównywalnie więcej niż kiedykolwiek w historii. Zbierzmy lekarzy, diagnostów laboratoryjnych, pielęgniarki i programistów w jednym pokoju i dajmy im dużą przestrzeń do event stormingu.

Odpowiada Artur Kosta, Team Leader Senior Software Developer w Objectivity:

Optymalizacja produkcji jedzenia na skalę globalną. Ogromne ilości nadwyżek jedzenia są wyrzucane do śmieci, dosłownie. Posiadamy skanery kodów kreskowych, kodów, które są unikatowe dla produktów. Możemy tworzyć mapy obciążenia sklepów, tak jak Google tworzy mapy korków ulicznych. Ale my dzięki tym danym będziemy mogli ograniczyć ilość produktów wysyłanych do danego sklepu to optymalnej wartości, przez co ograniczona zostanie z czasem produkcja nadmierna bo będzie produkowana potrzebna ilość. I tak jak Google Maps można to skalować w zależności od świąt i innych zmiennych.

Zdjęcie główne artykułu pochodzi z unsplash.com.

Oferty pracy z