Informatyk – klasyfikacja gatunku 1


Kiedy cz?owiek spoza bran?y my?li informatyk, zazwyczaj oczami wyobra?ni materializuje sobie posta? ubran? w kraciast? koszul?, w narzuconym na ni? wygniecionym polarze, w kolorze zgni?ej zieleni, kt?ra pojawia si? w jego domu lub przy jego biurku w pracy aby pod??czy? drukark?, naprawi? niedzia?aj?cy Internet lub przywr?ci? usuni?t? ikon? Worda na pulpicie. Osoba ta, bez wi?kszego zastanowienia, powinna by? w stanie powiedzie?, kt?ry laptop warto kupi? lub jak? kart? graficzn? wybra?, aby najnowszy Wied?min chodzi? jak najlepiej. Osoba ta powinna te?, najlepiej przez telefon, rozwi?za? w pi?? minut ka?dy mo?liwy problem zg?oszony przez system Windows, w dowolnej wersji, lub ka?de inne dost?pne na rynku oprogramowanie (z regu?y w wersji pirackiej). Niewiele os?b spoza bran?y dostrzega w og?le jakikolwiek inny podzia? tych dziwnych ludzi. Niewielu s?ysza?o okre?lenie programista, a ci co s?yszeli (nie b?d?c przy okazji ?wiadomym, ?e istnieje jeszcze taki zaw?d jak grafik), z regu?y klasyfikuj? ten dziwny typ ludzi jako tych, co potrafi? zrobi? stron? internetow?.
Ten dziwny typ ludzi ma te? specyficzne poczucie humoru i pos?uguje si? niby polskim, ale jak bardzo innym j?zykiem. Nigdy nie zapomn?, jak moja wspania?a ma??onka przez pi?? minut nie mog?a powstrzyma? si? od ?miechu, kiedy to chc?c zagai?, pewnego wieczora, powiedzia?em ?e jej ?procedura malowania paznokci jest bardzo interesuj?ca?. Jak ju? opanowa?a gromki ?miech powiedzia?a co? w rodzaju: ?Stary! Procedura malowania paznokci? Seriously? Kto tak m?wi? A zapomnia?am, ?e wysz?am za informatyka.?

Jednak gatunek informatyk?w jest du?o bardziej zr??nicowany. Ja w swoim kr?tkim wywodzie chcia?bym si? skupi? na szczeg?lnej grupie programist?w.

Moje prawie dziewi?cioletnie do?wiadczenie w bran?y, podczas kt?rego pe?ni?em r??ne role, od szeregowego klepacza kodu do team leadera zespo?u developerskiego jak i utrzymaniowego, pozwoli?o mi zidentyfikowa? dwa podzia?y.

Pierwszy zasadniczy podzia?, to podzia? na developer?w wytwarzania i developer?w utrzymania. Z ka?d? grup?, podobnie jak w przypadku cz??ci mowy, mo?na powi?za? w?a?ciwe pytanie. Do developer?w dzia?u wytwarzania przypisa?bym pytanie ?Co??, a do dzia?u utrzymania pytanie ?Jak??. Developerzy dzia?u wytwarzania zorientowani s? na cel. Ich zadaniem jest zaimplementowanie nowej, super potrzebnej klientowi funkcjonalno?ci. Dok?adnie wiedz? co maj? osi?gn??, jakie korzy?ci z tego b?dzie mia? klient i dlaczego b?dzie zbiera? szcz?k? z pod?ogi, jak ju? dostanie t? funkcjonalno??. Ich dzia?ania s? skierowane na realizacj? wymaga? specyfikacji funkcjonalnej. S? przy okazji ?wiadomi ram czasowych, w jakich funkcjonalno?? mia?aby powsta?, g?wnie za przyczyn? Project Managera, ca?y czas gadaj?cego o znienawidzonym przez nich harmonogramie, ograniczaj?cym jedynie ich tw?rcze my?lenie. Z regu?y nie maj? pe?nej ?wiadomo?ci faktycznych pieni?dzy, jakie otrzyma firma za ich jak?e to tw?rcz? prac?.

Kiedy developer dzia?u wytwarzania przychodzi do developera dzia?u utrzymania bardzo szybko, z ust tego drugiego, pada pytanie ?Jak??. Jaka jest procedura wdro?enia Twojej wspania?ej funkcjonalno?ci. Rzadko kiedy padnie pytanie: co ona w og?le umie ta Twoja super potrzebna, nowa opcja systemu? Jaka jest procedura rollback?u w przypadku, gdy podczas wdro?enia, co? p?jdzie nie tak? Jaka jest konfiguracja? Jak d?ugiego okna serwisowego potrzeba, aby to uruchomi?, i jak d?ugo system b?dzie niedost?pny na produkcji? Developer dzia?u wytwarzania, z regu?y, traktuje to jak sztucznie tworzone problemy. Jednak developer dzia?u utrzymania patrzy na systemy informatyczne przez zupe?nie inny pryzmat. On jest jak chirurg operuj?cy na otwartym sercu. Czas niedost?pno?ci systemu, dzia?aj?cego produkcyjnie, przek?ada si? na ilo?? got?wki w portfelu klienta, i dlatego jest bardzo ograniczony. Cz?sto okienko serwisowe, kt?re mo?na wykorzysta?, na wdro?enie nowej funkcjonalno?ci, mo?e pojawi? si? dopiero w przeci?gu tygodnia i nie mo?e by? d?u?sze ni? mi?dzy 23 a 24 w nocy. W tym czasie musi on by? w stanie przywr?ci? aplikacj? do poprzedniego stanu i zapewni? jej poprawn? prac?, gdy w dowolnym momencie co? si? wy?o?y. Dlatego te? dzia? utrzymania kocha procedury. Najlepiej takie napisane krok po kroku, nie pozostawiaj?ce najmniejszej mo?liwo?ci interpretacji. Dla tych developer?w du?o bardziej istotne jest jak co? robimy, ni? co dok?adnie dostarczamy. Jak co? ma dzia?a?, ni? co klient dzi?ki temu osi?gnie? Jak co? naprawi?, aby nie przekroczy? termin?w okre?lonych w SLA. Developerzy ci s? te? du?o bardziej ?wiadomi faktycznych zysk?w firmy, na jakie przek?ada si? ka?da godzina ich pracy. Dzia?aj? w ramach abonament?w zawieraj?cych okre?lon? liczb? godzin. CRy wyceniaj? w oparciu o cen? za godzin? pracy.

Kolejnym podzia?em, jaki uda?o mi si? zaobserwowa?, jest podzia? na tych ?zorientowanych na kod? i ?zorientowanych na funkcjonalno???. Ten podzia? jest du?o mniej oczywisty. Z tym podzia?em znowu powi?za?bym te same pytania, odpowiednio ?Jak?? oraz ?Co??. My?l?, ?e ten podzia? w wi?kszej mierze mo?na zastosowa? do developer?w dzia?u wytwarzania, jako ich klasyfikacj? wewn?trzn?. W mniejszym stopniu ma on zastosowanie do developer?w dzia?u utrzymania.

Developerzy zorientowani na kod uwielbiaj? grzeba? w kodzie. Zawsze maj? ?ci?gni?te ?r?d?a ka?dej biblioteki zewn?trznej, jakiej u?ywaj?. Analizuj? te ?r?d?a mimo, ?e mogliby po prostu u?ywa? API, gdy? i tak s? w stu procentach pewni, ?e dzia?a ona poprawnie. W ko?cu nikt nie decyduje si? na u?ywanie niestabilnych rozwi?za?. Lubi? sp?dza? godziny na analizowaniu wszystkich properties??w konfiguracyjnych zastosowanych framework??w, nawet je?li nie wszystkie z nich s? na dany moment istotne. Sypi? p??niej tymi konfiguracjami jak z r?kawa. Nie toleruj?, gdy cokolwiek w ich rozwi?zaniu, dzia?a z domy?ln? konfiguracj?, a ju? dos?ownie dostaj? spazm?w, gdy framework?i robi? co? ?pod spodem?, automatycznie. Dlatego te?, kiedy rozmawia?em z niekt?rymi kolegami o Spring Boot, to s?ysza?em wiele negatywnych opinii. ?Przecie? tam si? to dzieje magicznie. Nie mo?esz tego kontrolowa?. A co je?li co? nie b?dzie dzia?a?? Przecie? nie b?dziesz w stanie od razu powiedzie? dlaczego.? Programi?ci z tej grupy maj? alergi? na stosowanie konwencji ponad konfiguracj?. U nich ka?dy komponent musi by? jawnie zdefiniowany w XML?u, properties?ach czy yaml?u. Programi?ci ci cz?sto nie czuj? tego, ?e trzeba si? zmie?ci? w harmonogramie. Przekroczona wycena jest dla nich spraw? drugorz?dn?. Nie kwapi? si? te? do polemiki z analitykami. Najch?tniej nie mieli by z nimi nic do czynienia. Analitycy s? od tego, ?eby dostarczy? nie pozostawiaj?c? cienia w?tpliwo?ci, dokumentacj?. Nie ma potrzeby traci? czasu na rozmowy na temat inny ni? kod.

Programi?ci zorientowani na funkcjonalno?? skupiaj? si? na tym, aby funkcjonalno?ci wymaga?y jak najmniejszej ilo?ci pracy do ich realizacji. Lubi? testowa? nowe framework?i, najlepiej takie, kt?re wiele rzeczy dostarczaj? out-of-the-box. Konwencja ponad konfiguracj?? Jak najbardziej. Im mniej kodu i konfiguracji tym lepiej. Liczy si? czas i wype?nienie harmonogramu. Programi?ci Ci wiedz?, ?e w obecnych czasach, systemy musz? by? dostarczane szybko i tanio. Inaczej nie ma szans na wygranie przetargu. Programi?ci ci nie musz? od razu wiedzie? wszystkiego o nowym framework?u. Poznaj? go przyrostowo, skupiaj?c si? na cz??ci, kt?rej aktualnie potrzebuj?. Ten typ developer?w nie ma problemu z prowadzeniem dyskusji z analitykami czy klientem. Najcz??ciej ci w?a?nie programi?ci koordynuj? prac? zespo??w, ale zawsze, ale to zawsze, chc? mie? w zespole programist?w z drugiej grupy. S? ?wiadomi tego, ?e tylko wsparty ich dog??bn? wiedz?, o ka?dej linijce kodu systemu, projekt ma szans? powodzenia. Nie maj?c wsparcia, w swoich kolegach z drugiej grupy, zgin?liby marnie w momencie, gdy system zaczyna dzia?a? niestabilne i trzeba, w kr?tkim czasie, odpowiedzie? na pytanie dlaczego?

Mo?na ?mia?o powiedzie?, ?e te dwa typy programist?w si? wzajemnie uzupe?ni?. Tak samo, jak uzupe?niaj? si? programi?ci dzia?u utrzymania i wytwarzania.


Komentarz do “Informatyk – klasyfikacja gatunku

  • RAF

    heh ciekawa teoria z tym programistami 😛

    IMO jest jeszcze tak, ?e ludzie si? zmieniaj?/dojrzewaj?, wi?c takie wahania „kod” a „funkcjonalno??” mog? wyst?powa? okresowo u danego programisty 😛

Komentarze są wyłączone.