Jest duża szansa, że spotkałeś się ze stwierdzeniem, że praca programisty nie jest stresująca, a sami programiści nie mają praktycznie żadnej odpowiedzialności. Być może patrząc na to jako użytkownik finalnego produktu można dojść do takich wniosków. Jednak od zaplecza wygląda to zgoła inaczej. Dzisiaj porozmawiamy o odpowiedzialnym programiście i wyjaśnimy kim jest developer.

Odpowiedzialność

Odpowiedzialność w pracy nie występuje jedynie w odniesieniu do ewentualnych problemów z prawem albo rozmowy z dyrektorem w razie zrobienia czegoś źle. Jest też coś takiego jak odpowiedzialność moralna.

Za słownikiem języka polskiego:

odpowiedzialność

«obowiązek moralny lub prawny odpowiadania za swoje lub czyjeś czyny»

«przyjęcie na siebie obowiązku zadbania o kogoś lub o coś»

O ile w pracy programisty odpowiedzialność prawna w praktyce występuje raczej rzadko o tyle odpowiedzialność moralna to coś o czym każdy programista powinien myśleć. Wbrew pozorom spotykamy się z nią bardzo często. Wystarczy sobie przypomnieć narzekania na beznadziejne decyzje podjęte przez poprzednich pracowników w projekcie.

Jeśli spojrzysz na definicję zamieszoną powyżej to zobaczysz, że odpowiedzialność to przyjęcie na siebie obowiązku zadbania o coś. Tym czymś w przypadku programisty będzie kod jak i projekt ogólnie. Jednak powstaje pytanie na czym w takim razie polega ta odpowiedzialność za projekt?

Pierwszą odpowiedzią jaka powinna Ci przyjść do głowy jest dbanie o jakość kodu jaki produkujesz. Sprawdza się tutaj harcerska reguła żeby zostawiać miejsce, które się opuszcza w lepszym stanie niż było przed przybyciem.

Jednak poza taką prostą odpowiedzialnością jaką jest dbanie o stan kodu jest też odpowiedzialność za jakość pracy na wyższym poziomie. Jeżeli widzisz proces, który można ulepszyć albo zautomatyzować to może warto poczynić kroki w tym kierunku? Tracenie czasu na czynności, które mogą się dziać same nie jest domeną ludzi odpowiedzialnych.

Na sam koniec warto też wspomnieć o dbaniu nie tylko o mięcho projektowe ale też o użytkowników. Nie myśl tylko o sobie, ale też o osobach, które będą korzystać z efektów Twojej pracy. Jeżeli widzisz coś co twoim zdaniem jest nieintuicyjne albo zwyczajnie brzydkie to zgłoś to, albo jeśli masz na tyle mocy decyzyjnej po prostu popraw.

Klient nie zawsze ma rację

Mimo, że biznes próbuje nam wmówić, że klient ma zawsze rację to w praktyce nie zawsze jest to prawdą. A im dłużej pracuje się z klientem tym mniej prawdy w tym stwierdzeniu się widzi.

Klient przychodzący do firmy programistycznej nie musi znać się na kwestiach technicznych. I zazwyczaj faktycznie się nie zna. On zna się na swojej dziedzinie. Jednak zamawiając produkt w postaci oprogramowania ma pewną wizję czy to wynikającą z podpatrzenia podobnych rozwiązań czy z własnych przemyśleń i przeczucia popartego doświadczeniem we własnej branży.

Brak wiedzy na temat wytwarzania oprogramowania może skutkować wymyślaniem mechanizmów, które są bardzo kosztowne w realizacji, a jednocześnie mogą być zastąpione przez coś prostszego. Jest też szansa, że klient usłyszał o modnej technologii, która „jest rozwiązaniem wszystkich problemów” i pod wpływem tego teraz sugeruje, że chce żeby zespół tego użył. On nie musi wiedzieć jakie są programistyczne i projektowe konsekwencje z tym związane.

Projektowanie oprogramowania to niekiedy długi proces. Kombajny informatyczne, zwłaszcza takie rozwijane przez wiele lat, zawierają mnóstwo mechanizmów, które ciężko zapamiętać. Ile to razy klient będzie chciał dodać coś co się wyklucza z funkcjonalnością, która już istnieje, albo co w kontekście tej aplikacji nie ma sensu? Czy on to robi specjalnie bo chce dopiec programistom? Absolutnie! W końcu to jego pieniądze i złośliwe utrudnianie życia osobom, za które płaci zdecydowanie nie jest mu na rękę.

Rolą klienta jest dostarczenie wiedzy na temat dziedziny, dla której powstaje produkt. Ale to rolą wykonawcy jest uświadomienie tego klienta jakie rozwiązania przybliżą go do produktu, którego tak naprawdę potrzebuje. Bo to co klient chce i to co klient potrzebuje to często dwie osobne rzeczy. I o tym trzeba pamiętać. Tak samo jak trzeba pamiętać, że dziwne, nielogiczne albo sprzeczne decyzje klienta nie wynikają z jego złośliwości ale co najwyżej z niewiedzy bądź błędnego wyobrażenia na temat oprogramowania.

Developer

I w tym momencie wkraczasz Ty – developer!

Słowo developer pojawia się coraz częściej w ofertach pracy dla programistów. Warto więc powiedzieć coś więcej o tej postaci. Bazując chociażby na TYM artykule można powiedzieć, że developer jest osobą, która nie tylko pisze kod, ale jest też komunikatywna i potrafi znajdować rozwiązania, które są nastawione na spełnienie wymagań.

Osoba, która mówi o sobie „developer” zdecydowanie powinna mieć doświadczenie i praktyczną wiedzę. Developerem w IT nie zostajesz dostając dyplom uczelni. Zostajesz nim dopiero w procesie ciągłej nauki i zbierania doświadczenia. To jak szybko to doświadczenie zbierzesz zależy od Ciebie jednak jedno jest pewne – wymaga to obcowania z wieloma problemami i tematami. W końcu skąd będziesz wiedział, które rozwiązanie jest optymalne w konkretnym przypadku jeżeli wcześniej nie sprawdziłeś kilku z nich?

Drugą kwestią jest komunikatywność. Cechą dobrego developera jest szerzenie wiedzy w zespole i poza nim. Ale też komunikatywność bardzo ułatwia, a czasami wręcz umożliwia zbieranie wiedzy w kolejnych tematach. Rozmowy na konferencjach, wymiana wiedzy w przerwie na kawę, dyskusja w internecie. To wszystko wymaga komunikatywności i skutkuje uczeniem się na cudzych błędach bądź poznawaniem przypadków i rozwiązań, o których się nie słyszało.

W tekście o jednej zasadzie szukania materiałów do nauki mówiłem o zwracaniu uwagi na materiały oparte o praktykę. Takie materiały powstają głównie dzięki właśnie developerom. To oni mają dużą praktyczną wiedzę, znają problemy i ich rozwiązania.

Gdzie tu odpowiedzialność?

Jednak jak to wszystko ma się do odpowiedzialności? Ano ma się tak, że jako developer, który dobrze zna wiele podejść i problemów powinieneś sygnalizować klientowi, że coś co wymyślił nie sprawdzi się. Ten klient opisany wyżej mimo, że tego nie mówi to zakłada, że trafi na osoby kompetentne, które będą go wspierać. I jako developer taką osobą kompetentną powinieneś być. To wymaga jednak wspomnianej już komunikatywności. Jako osoba odpowiedzialna powinieneś dbać o to, żeby produkt działał poprawnie i rozwiązywał problemy Twojego klienta. Jeżeli będzie on zadowolony z działania to i przymknie oko na potrzebę wygospodarowania czasu na niewidoczne poprawki techniczne bądź usprawniania jakości kodu. A to pozwoli Tobie i reszcie zespołu zadbać o jakość Waszego produktu również w kontekście bebechów. Bo nie ma nic gorszego niż zgadzanie się na każdą, nawet najbardziej absurdalną prośbę klienta, a potem klejenie całości taśmą „byle działało do mojego zwolnienia”.