Cześć! 

To jest 241. odcinek podcastu Porozmawiajmy o IT, w którym w cyklu rozmów z Łukaszem Drynkowskim z portalu z ogłoszeniami pracy IT SolidJobs, który mam przyjemność współtworzyć, dyskutujemy o Software Craftsmanship, czyli o rzemiośle programisty. 

Zapraszamy do słuchania i komentowania. A teraz życzymy Ci już miłego słuchania!

Odpalamy!

 

Cześć, Łukasz! 

 

Cześć, Krzysztof! 

 

To nasze kolejne spotkanie w ramach serii podcastów o Software Craftsmanship. Wszystkich odsyłamy oczywiście do wcześniejszych odcinków, bo myślę, że to będzie dobre wprowadzenie i dobre uzupełnienie też tego tematu, który chcemy dzisiaj poruszyć. Mieliśmy nieco problem, mam wrażenie, w dobrym określeniu tego, o czym będziemy dzisiaj chcieli mówić, ale chyba takim najlepszym przybliżeniem i w końcu tym tematem, który wybraliśmy, jest temat inżyniera rozwiązań. 

Pamiętam zupełne początki swojej kariery programistycznej, gdzie wszyscy tak naprawdę byli fullstackami. Często się o tym mówi, często się to przywołuje. Wtedy dość naturalne było to, że w momencie, kiedy był jakiś soft do zrobienia, jakaś strona, jakaś aplikacja, to taki programista zajmował się tym od A do Z, nierzadko nawet dotykając zebrania wymagań, deploymentu, utrzymania itd. 

Oczywiście później musieliśmy jakoś wykształcić różnego typu specjalizacje, ponieważ zwyczajnie jedna osoba nie była w stanie podołać wszystkim tym obowiązkom, natomiast teraz mam wrażenie, że coraz częściej też wraca się do takich podstaw czy do tych korzeni, żeby właśnie próbować w jakiś sposób holistyczny patrzeć na proces wytwarzania oprogramowania i także żeby próbować dotykać tych różnych aspektów wytwarzania oprogramowania, co na koniec dnia przekłada się na to, że po prostu jakość tego kodu wytwarzanego jest lepsza. 

W związku z tym dzisiejszy programista to nie tylko koder, tutaj już pewnie nieraz o tym wspominaliśmy, ale to również przynajmniej powinna być osoba, która jest w stanie być partnerem, swego rodzaju doradcą dla biznesu, która nie tylko dba o te aspekty techniczne, ale również takie całościowe, związane z dowiezieniem projektu. W związku z tym postanowiliśmy ten temat właśnie dzisiaj poruszyć, stąd pomysł na inżyniera rozwiązań. 

Czy chciałbyś Łukasz krótko może powiedzieć, jak ty rozumiesz właśnie kim taki inżynier rozwiązań może być? 

 

Dla mnie inżynier rozwiązań to jest takie rozwinięcie po prostu pracy programisty. To jest ktoś, kto nie tylko skupia się na kodzie i aspektach technicznych, ale także ma rozeznanie na rynku rozwiązań, zna np. swoją konkurencję. Na słabe i dobre strony tych rozwiązań konkurencyjnych potrafi tutaj zaproponować w swoim projekcie jakieś usprawnienia, które po prostu nie są gdzieś tam na roadmapie, ale widzi tę potrzebę, bo np. sam korzysta z danego rozwiązania albo zbiera jakiś feedback, czyli też nie boi się eksperymentować, nie boi się komunikować swoich racji, swoich przekonań. 

 

Tak, wiesz, to o czym powiedziałeś, że to jest osoba, która umie w komunikację, myślę, że jest znaczące, bo podkreśla się coraz bardziej tą wagę umiejętności miękkich w IT. Myślę, że to jest jeden właśnie z takich przykładów, jedna z takich sytuacji, gdzie ta komunikacja bardzo się przydaje, bo dawno już wyszliśmy z tego etapu pracy w piwnicy samodzielnie, musimy się komunikować nie tylko w zespole, ale również z przełożonymi, z tzw. biznesem, i taki inżynier rozwiązań, skoro chce dowieźć się to rozwiązanie, można powiedzieć, od A do Z albo przynajmniej w dużym zakresie, w aspekcie różnych kwestii, które składają się na projekt, to niejako nie da się tego zrobić bez komunikacji z różnymi osobami o różnych rolach. 

Więc chciałbym tutaj też podkreślić, że komunikacja to musi być jedna z tych umiejętności, która dla inżyniera rozwiązanie jest po prostu bliska. 

 

Tak, i dodajmy, że komunikacja w zespole to jest jedna sprawa, a komunikacja poza zespół, czyli np. z biznesem, czy też nawet z użytkownikami, to jakby jest osobna gałąź i po prostu się swoimi prawami tutaj rządzi jeden sposób komunikacji i drugi, trzeba dostosować ten komunikat zawsze do odbiorcy. 

 

Przypomina mi się teraz nasza rozmowa w ramach podcastu, którą jakiś czas temu, całkiem niedawno mieliśmy z Agnieszką Myśliwczyk, gdzie Agnieszka podkreślała, że te warunki na rynku pracy IT, które teraz mamy, ta sytuacja, zmusza niejako programistów, innych specjalistów w IT, żeby byli wartościowi dla projektu, żeby byli wartościowi dla firmy, żeby po prostu dowozili wartość. 

I tak myślę sobie, że ten inżynier rozwiązań to też po części jest niejako efekt tego, z czym teraz mierzymy się na rynku pracy w IT, że nie tylko jest potrzebny ktoś, kto bardzo wąsko realizuje określony typ zadań, jest tym przysłowiowym koderem, ale osoba, która też sprawdzi się i która będzie wartościowa w projekcie na różnych jego aspektach. 

Myślę sobie, patrząc przyszłościowo albo wychodząc z jakąś radą dla słuchaczy, że próba rozwijania tych swoich kompetencji poza wąską specjalizację właśnie w kierunku tego przysłowiowego inżyniera rozwiązań może być dobrym zakładem, może być czymś, w co warto po prostu iść, ponieważ nasza przydatność dla firmy, dla pracodawcy będzie zwyczajnie większa, co ma szansę też zwiększyć naszą wartość na rynku pracy. 

 

Czyli po prostu to jest ciekawa droga rozwoju swojej kariery. 

Często dostaję takie pytanie, a jak zostać z tego juniora mid-developerem, albo jestem midem, A jak zostać seniorem? To ja może tutaj z takiego spojrzenia właśnie pokażę tego, o czym my rozmawiamy, i jak ja rozumiem te różne poziomy kariery. To oczywiście jest jedno spojrzenie, to mogą być tutaj różne aspekty, których teraz nie powiem po prostu, bo chciałbym tu się poruszać w ramach naszego tematu. 

Taki junior to jest ktoś, kto po prostu dostaje zadanie do wykonania i dostarcza funkcję, coś, co swoją rolę spełnia, pomaga użytkownikowi wykonać jakieś codzienne zadania. Potem mamy tego mida, który wie, że nie tylko trzeba dostarczyć funkcję sztukę, ale też wie, że są takie rzeczy, jak np. wymagania poza funkcjonalne. Musi to jeszcze mieć fajny UX, żeby to się łatwo intuicyjnie z tego korzystało, ale też np. zwraca uwagę na sprawy związane z wydajnością tego rozwiązania, zwraca uwagę na aspekty związane z architekturą tego rozwiązania. Możemy dalej budować, na tym co ten mid zrobił. 

I potem wchodzi ten senior developer, który moim zdaniem wyróżnia się tym, że to jest ktoś, kto powie: A może zrobimy to jednak inaczej? Albo: Może tutaj nie potrzeba w ogóle tego robić, może zrobimy coś dużo prostszego, zajmie to nam tydzień, a nie pół roku, a spełni wymagania 90% tutaj naszych użytkowników? Może nie wszystko trzeba robić po prostu w ramach systemu. Część zadań można wykonywać poza systemem. Może być jeszcze jakiś Excel, który coś tutaj pomoże. Albo w drugą stronę, może ten senior developer musi powiedzieć: Tutaj zamiast robić to tydzień, to jeszcze dajcie nam dwa dni i zamiast działać w jednym specyficznym przypadku, to obejmiemy wszystkie możliwe case’y, i nie będzie trzeba siadać tutaj drugi raz nad tym rozwiązaniem i drugi raz coś wymyślać, co wiadomo, jak później się do tego wejdzie, to będzie dodatkowy narzut na wejście w temat.

I tutaj mamy tego inżyniera rozwiązań, czyli ten, no nie wiem, czy to level up, czy ktoś tutaj raczej obok pewnie, który właśnie już się mniej skupia na tych rozwiązaniach, bym powiedział, technicznych, a większy nacisk właśnie też kładzie na te aspekty biznesowe. 

Taki junior to jest ktoś, kto po prostu dostaje zadanie do wykonania i dostarcza funkcję, coś, co swoją rolę spełnia, pomaga użytkownikowi wykonać jakieś codzienne zadania. Potem mamy tego mida, który wie, że nie tylko trzeba dostarczyć funkcję sztukę, ale też wie, że są takie rzeczy, jak np. wymagania poza funkcjonalne. Musi to jeszcze mieć fajny UX, żeby to się łatwo intuicyjnie z tego korzystało, ale też np. zwraca uwagę na sprawy związane z wydajnością tego rozwiązania, zwraca uwagę na aspekty związane z architekturą tego rozwiązania. Możemy dalej budować, na tym co ten mid zrobił. 

I potem wchodzi ten senior developer, który moim zdaniem wyróżnia się tym, że to jest ktoś, kto powie: A może zrobimy to jednak inaczej?

 

Tak, przedstawiłeś tutaj ścieżkę rozwoju kariery. Pewnie istotnym elementem, niezależnie od tego, na jakim etapie jesteśmy, jest to, żeby się ciągle dokształcać. Ta ciekawość, o której tutaj powiedziałeś, mówiąc, czym się charakteryzuje inżynier rozwiązań, myślę, że powinna być cechą osoby na każdym levelu tej drabiny rozwojowej. I właśnie, jeśli chodzi o rozwój, o to, jak poszerzać swoje kompetencje, wiedzę, to pewnie mamy tutaj coś ciekawego do zasugerowania. 

 

Myślę, że w takim rozwoju nas tutaj developerów ważne jest bycie na czasie i kontrolowanie bieżących trendów, tego, co się dzieje na naszym poletku. To jest trudne, żeby samemu te wszystkie różne źródła agregować. 

Na szczęście są tutaj dobrzy ludzie. I chcielibyśmy polecić w tym odcinku Unknown News, czyli taki newsletter robiony przez Jakuba Mrugalskiego, który zbiera co tydzień najfajniejsze rzeczy z naszego poletka programistycznego i z branży i fajnie to agreguje, wysyła raz w tygodniu zbiór po prostu ciekawych linków do różnych stron. 

I to, co jest fajne, takie ekstra tutaj, to że przy każdym linku jest też krótki opis, tak że wiesz, z czym to się je, zanim klikniesz, możesz po prostu zdecydować, które tematy Cię interesują, które nie, a też właśnie te opisy sprawiają, że często w coś klikam, bo po prostu, mimo że to nie jest coś, co leży w obszarze moich zainteresowań, to dzięki opisowi czegoś się może tutaj dowiem, co nawet bym się nie spodziewał, że chciałbym posiąść tę wiedzę. Tak że myślę, że damy tutaj pod odcinkiem linka i zachęcamy do tego, żeby się zapisać na taki newsletter. 

 

Tak, ja bym tutaj chciał się jeszcze odnieść do tego, co powiedziałeś, że ten inżynier rozwiązań to może być taki level up, może być kolejny poziom rozwoju. Myślę sobie, że te niektóre cechy inżyniera rozwiązań powinny być cechami nie tylko na tym najwyższym poziomie, ale wręcz od początku naszego wspinania się po szczeblach kariery. Bo trzeba sobie jasno powiedzieć albo wręcz przypomnieć, że jako programiści jesteśmy tutaj po to, żeby rozwiązywać problemy. Kod jest tylko jedną z możliwości, czyli też jednym z narzędzi, jakie możemy użyć, żeby problem rozwiązać. Na koniec dnia powinniśmy dostarczać wartość. 

Myślę, że z tej perspektywy na to spojrzeć, to cechy inżyniera rozwiązań powinny nam towarzyszyć każdego dnia, po to, żeby właśnie ta wartość była odpowiednia, żeby faktycznie wynosiła coś do projektu, do życia użytkowników, po to, żeby służyła klientowi. 

Kontynuując ten temat, że kod jest tylko jednym z narzędzi, jednym ze sposobów do dostarczenia wartości, trzeba również pamiętać, że zbieranie wymagań, dostarczanie tych wymagań, pomysłów, jakichś idei, jak problem rozwiązać, też oczywiście jest elementem składowym dostarczania wartości. 

Bo nie możemy tylko polegać na tym, co nam produkt czy biznes dostarczy nam programistom. Trzeba pamiętać, że to jest tylko jeden z aspektów, jeden z wymiarów całego projektu. Biznes będzie patrzył na to, żeby maksymalizować wartość finansową, komercyjną. W związku z tym… z tej perspektywy będzie patrzył na projekt. My natomiast jako inżynierowie, i tutaj chciałbym podkreślić to słowo – inżynierowie – musimy dbać też o jakość tych rozwiązań, jak również o to, żeby one były utrzymywalne, żeby były bezpieczne, skalowalne, żeby po prostu dało się je dalej rozwijać. Nie możemy polegać na tym, albo nie możemy liczyć na to, że to biznes nam będzie mówił, jak mamy o te rzeczy niefunkcjonalne zadbać. To jest elementem po prostu naszego fachu, żeby to robić. 

 

Tak, tak że bardzo ważne jest to, żebyśmy nie podchodzili bezkrytycznie do tych zadań, które otrzymaliśmy. To, że coś jest napisane w tym przysłowiowym tickecie w Jirze, to nie znaczy, że ktoś tam np. się nie pomylił. 

Już chyba taką anegdotę kiedyś przytaczałem, ale miałem kiedyś taką sytuację, gdzie po prostu programista zrobił jeden do jeden to, co było napisane w tickecie, ale to ja na to patrzę, dlaczego to zrobiłeś tak? Bo tak było napisane w tickecie. Ale przecież to nie ma prawa tak działać, to jest sprzeczne z logiką. No ale tak było napisane w tickecie. 

Musimy tutaj rozmawiać, musimy się zastanawiać, czy to, co ktoś nam dał do zrobienia, czy nie można wymyślić czegoś lepszego, szybszego albo właśnie nie szybszego, ale bardziej kompleksowego rozwiązania, i proponować to, rozmawiać. Nie jesteśmy po prostu tu po to, żeby tylko i wyłącznie pisać kod, tak myślę – jesteśmy po to, żeby tutaj rozwiązywać problemy. 

Musimy tutaj rozmawiać, musimy się zastanawiać, czy to, co ktoś nam dał do zrobienia, czy nie można wymyślić czegoś lepszego, szybszego albo właśnie nie szybszego, ale bardziej kompleksowego rozwiązania, i proponować to, rozmawiać. Nie jesteśmy po prostu tu po to, żeby tylko i wyłącznie pisać kod, tak myślę – jesteśmy po to, żeby tutaj rozwiązywać problemy. 

 

Tutaj pewnie można odesłać do pierwszego odcinka z tej serii, o etosie programisty, gdzie mówiliśmy o tym, że nie możemy być cały czas takimi właśnie junior developerami, slash coderami, którzy tylko wklepują czy też wypluwają kod realizujący to, co nam gdzieś tam w naszym tasku wpadło, tylko powinniśmy się zastanawiać, jak to szerzej wkomponuje się w cały produkt. I też, żeby ta jakość, która za tym stoi, była na odpowiednim poziomie. 

 

Tak, i pamiętajmy cały czas, że ten software, to oprogramowanie, które piszemy, nie jest celem samym sobie, to nie chodzi o to, żeby to gdzieś tam sobie leżało, tylko chodzi o to, żeby rozwiązywało jakiś problem. To jest narzędzie, a nie cel. Tak że skupmy się na tych realnych problemach, na tych aspektach po prostu – znowu tego brzydkiego słowa użyję – biznesowych.

 

Tak, myślę, że z tym się wiąże też po prostu branie odpowiedzialności za tę część projektu albo za cały projekt, który jako zespół dowozimy, bo dosyć łatwo jest się gdzieś tam wymigać z myślenia o pewnych aspektach, jeśli przykładowo jesteśmy backend developerem, to możemy powiedzieć, co nas ten frontend albo co nas ta infrastruktura obchodzi. Ja tutaj jestem po to, żeby pisać kod backendowy.

I to jest unikanie tej odpowiedzialności. To nie jest dbanie o inżynierię całego rozwiązania. Jestem fanem tego, żebyśmy jako poszczególni członkowie zespołów brali odpowiedzialność za to, co realizujemy, jaką wartość na koniec dnia jako całość dowozimy. Wtedy tylko możemy się nazwać inżynierem rozwiązań, kiedy nie tylko to swoje wąskie poletko będziemy dbać, ale też będziemy myśleć, jaką wartość jako cały zespół, jako cały produkt wnosimy w życia użytkowników.

Tak, myślę, że z tym się wiąże też po prostu branie odpowiedzialności za tę część projektu albo za cały projekt, który jako zespół dowozimy, bo dosyć łatwo jest się gdzieś tam wymigać z myślenia o pewnych aspektach, jeśli przykładowo jesteśmy backend developerem, to możemy powiedzieć, co nas ten frontend albo co nas ta infrastruktura obchodzi. Ja tutaj jestem po to, żeby pisać kod backendowy.

I to jest unikanie tej odpowiedzialności. To nie jest dbanie o inżynierię całego rozwiązania. Jestem fanem tego, żebyśmy jako poszczególni członkowie zespołów brali odpowiedzialność za to, co realizujemy, jaką wartość na koniec dnia jako całość dowozimy

Co oczywiście nie znaczy, że nie mamy się specjalizować, żeby tutaj nam to przesłanie nie przysłoniło. Fajnie, jeśli w zespole mamy kogoś, kto się pasjonuje np. bazami danych i zawsze tę dodatkową wiedzę ekspercką nam da w tym danym temacie, ale oczywiście to nie może być tak, że ta jedna osoba tutaj odpowiada zawsze za ten jeden aspekt, a cała reszta zespołu, każdy swoje. To tak być nie może. Nie jest to w duchu Agile.

 

Tak, zdecydowanie. I właśnie, nie chodzi nam też tutaj o to, żeby kod był możliwie najlepszej jakości, jaka tylko jest do wymarzenia, bo dobrze wiemy, że to na koniec dnia niekoniecznie musi podwyższać UX, niekoniecznie musi wpływać na to, że projekt będzie dowożony w czasie, że będzie w budżecie dowożony itd. 

I inżynier rozwiązań tutaj w tym aspekcie, o którym rozmawiamy, to nie jest tylko wybitny fachowiec, który idealnie zna się na tej swojej działce, ale to jest osoba, która czasem potrafi, czy też wręcz jest skłonna powiedzieć, że nie musimy tego robić, możemy to pominąć, możemy o tych case’ach np. na ten moment zapomnieć albo w ogóle nie piszmy tego kodu, taki kod, który nie powstał, wiadomo, że jest najłatwiejszy w utrzymaniu.

Więc musimy się starać dobierać te rozwiązania do problemu i nie zawsze większa ilość kodu, która powstanie albo kod lepszej jakości, który powstanie, musi być tym celem, do którego dążymy.

 

Nazywamy siebie tutaj software developerami, ale co to w ogóle znaczy słowo developer? Co to znaczy develop? To jakby nie znaczy napisz sztukę funkcji zgodnie z ticketem, tylko mamy teraz to, co zostało gdzieś tam opisane, musimy na to spojrzeć ze wszystkich stron, zastanowić się, czy to spełnia te wymagania takie high level, czy to rozwiązuje dany problem, a po drugie, czy ten użytkownik będzie wiedział, jak z tego skorzystać, czy ten UX jest rzeczywiście taki, jak ma być, czy to graficznie dobrze wygląda.

To też fajnie w grach komputerowych widać, jak tam jakieś są czasami z wersji beta, a potem z kolejnych wersji, jak się zmienia, jak drobne takie zmiany, np. w interfejsie, przesunięcie z prawej do lewej jakiegoś elementu, czy też jakaś drobna zmiana, która po prostu ma duży wpływ na ostateczne odczucia tego użytkownika z tego, jak się z danej funkcji korzysta.

W aplikacjach internetowych np. duże znaczenie ma to, gdzie te elementy są ułożone, czy są zgodnie z jakimiś konwencjami, czy ktoś tutaj wymyśla koło na nowo. To są takie rzeczy, które zazwyczaj w pierwszej iteracji o nich się po prostu nie myśli i jest potrzebne tutaj kolejne spojrzenie, też spojrzenie osób z boku – tu też rola właśnie tego inżyniera rozwiązań myślę, że byłaby, żeby proponować, sugerować i po prostu ten rozwój tego oprogramowania stymulować.

 

Tak, czyli nie tylko napisanie kodu od A do Z zgodnie z wymaganiami z zadania, ale również ciągły rozwój po to, żeby maksymalizować właśnie tę dostarczaną wartość.

Łukasz, tutaj wiele rad, myślę, padło nie tylko na temat tego, jak być kimś, kto pisze kod, ale również zmierzać w kierunku bycia inżynierem rozwiązań. Myślę, że to jest dobry moment, żeby podsumować, o czym dzisiaj powiedzieliśmy.

 

Tak, to może zacznę od tego, że nie musicie mieć tutaj na plakietce, na stoliku napisane inżynier rozwiązań, żeby stosować się do tych naszych dzisiejszych rad. Zawsze warto starać się robić coś więcej. To jest moim zdaniem droga ogólnie awansu czy ścieżki kariery, że nie tak, że ktoś Cię mianuje, tylko po prostu robisz to i stajesz się tym inżynierem rozwiązań. Tak że nawet w takim spojrzeniu warto po prostu pokazywać, że mam te pomysły i kontrybuować jednak do tego, co robimy.

Pamiętajmy, że są te dwa spojrzenia, spojrzenie takie techniczne i spojrzenie biznesowe użytkownika. Starajmy się tutaj i w jednym, i w drugim aspekcie znajdować ulepszenia, czy też propozycje zmian. Też pamiętajmy, że czasami warto jest czegoś nie zrobić, albo zrobić coś więcej, niż mamy napisane w tym przysłowiowym tickecie na Jirze. Starajmy się po prostu end to end podchodzić do tych zadań i bierzmy odpowiedzialność za to, co robimy.

 

Tak, dokładnie. Nie zawsze o wszystkie te aspekty da się zadbać, ale powinniśmy się w tym doskonalić i próbować za każdym razem, żeby faktycznie udało się przynajmniej część tych rzeczy wdrożyć, użyć i gdzieś tam zastosować w projekcie.

Świetnie, Łukasz, bardzo Ci dziękuję za dzisiejsze spotkanie. Słuchaczy zapraszamy do wcześniejszych odcinków z tej serii, które są doskonałym uzupełnieniem do tego, co dzisiaj powiedzieliśmy. Zapraszamy oczywiście do odwiedzenia SolidJobs, gdzie możecie znaleźć ogłoszenia o pracę zawsze z widełkami wynagrodzeń. Zapraszamy do dodawania tam ogłoszeń, jeśli w Waszej firmie, w Waszym projekcie jest potrzeba znalezienia nowych pracowników. I zapraszamy do kolejnych odcinków, które już niebawem w ramach tej serii się pojawią.

 

Tak, i zapraszamy do subskrybowania Unknown News Jakuba Mrugalskiego. Myślę, że naprawdę warto raz w tygodniu taką dawkę aktualności dostać i się z nią zapoznać.

Zgadzam się. Link oczywiście w notatce.

 

Dzięki, Łukasz, cześć!

 

Dzięki, cześć!