Co chciałbym wiedzieć, kiedy zaczynałem kodzić?

Gdybym cofnął się ileś lat wstecz i miał dać sobie jakieś porady, pewnie byłoby to: zajmij się hodowlą owiec na jakimś zadupiu. Nie zmarnujesz, życia przed komputerem. Ale prawdopodobnie nie takie porady chciał(a)byś czytać.

Jednym z powtarzających się tematów, jakie widuję na blogach i forach, jest pytanie czego autor żałuje, że nie widział na początku. Połowa z punktów na liście równa się przeczytaniu kilkunastu książek, druga połowa praktykom wyniesionym z pracy w korpo (o jakiś standardach), a całość w zasadzie sprowadza się do żalu, że autor na starcie nie miał 10 lat doświadczenia. Od miesiąca kodzisz i chcesz jakieś porady? Spoko, streszczę ci tylko 50 praktyk wynikających z ostatnich 7 lat mojego życia zawodowego. Moje streszczenie na bank sprawi, że w 2 tygodnie wprowadzisz je wszystkie w życie.

Na podobne bzdury przyjdzie pora nieco później, najlepiej w innym poście. Teraz skupię się na rzeczach, których jakoś w książkach nie wspominali. Na wdrożeniach w korpo też jakoś im umknęły.

Jak wygląda dzień pracy programisty wg stereotypów wyniesionych z filmów (oraz postów internetowych frustratów)? Przychodzisz do roboty na 13. Nikt się nie dowala, bo jesteś niezastąpionym geniuszem. Następnie uruchamiasz komputer, przed oczami ukazuje ci czarny ekran. Wpisujesz na klawiaturze zhakuj Pentagon, ale w taki sposób, że nikt inny na to nie wpadnie i w magiczny sposób załatwiasz w pojedynkę robotę całego departamentu. Co prawda ludzie powinni padać przed tobą na kolana, ale jakoś tego nie robią, bo siedzisz w piwnicy z innymi nieumytymi, zarośniętymi typami. Od czasu do czasu, od czapy całkujecie w pamięci i rzucacie cytatami z Gwiezdnych Wojen. Normalnych ludzi oglądacie tylko na zdjęciach…

Tak naprawdę, to przychodzisz do roboty na jakąś wczesną godzinę. Elastyczne godziny pracy oznaczają, że 8 godzin, musisz tak czy inaczej przekiblować, ale możesz sobie z grubsza określić zakres. Pod warunkiem, że obejmie on wszystkie wymagane meetingi. Istnieje podejrzenie graniczące z pewnością, że będziesz robił w modelu Agile. Teoretycznie stały za nim pewne wzniosłe ideały, ale praktyce sprowadza się to do:

• meldowania się codziennie na 15 minutowe streszczenie w kółeczku na środku sali (stand-up, bynajmniej nie comedy),
• w zasadzie zerowej dokumentacji w kodzie,
• oraz pewnego standardowego zestawu meetingów (demo, retro, planning).

Znaczy, Agile formalnie NIE jest tym samym co Scrum, ale większość korpoludków nie zauważa różnicy. (Znałem ludzi, którzy nie odróżniali Scruma od TDD - jak ktoś myli praktyką programistów z metodologią zarządzania, to wiedz, że coś się dzieje).

Jak może się domyślasz, oznacza to, że nie siedzicie w piwnicy. Wręcz przeciwnie, jest spora szansa na pochmurną pogodę z open-spacem. W nazwie stanowiska będziesz miał(a) nie programista, a deweloper, co jest lekką sugestią, że programowanie to tylko część twoich obowiązków. Mniejsza część. W praktyce, zawsze będziesz brał(a) udział w ustalaniu specyfikacji, dyskusjach co, jak, na kiedy. Będziesz spędzał(a) czas na pisaniu maili, komentarzy w narzędziach śledzących postęp prac nad projektem. Będziesz osobiście zagadywać do ekspertów, żeby wyjaśnili ci, czego dokładnie chcą, albo jak działa ta dziwna rzecz, jaką masz zaklepać. Jeśli jesteś nieśmiałym kujonem, który miał nadzieję na spokój, to - niestety - oszukali cię.

Aha. Nie jest również ważne, że programujesz. Programowanie to tylko skutek uboczny dostarczania. Gdybyś był(a) zatrudnion[y/a] jako programista C++, ale wyklikał(a) appkę dla klienta w jakimś generatorze albo game makerze, nikt by nic nie powiedział. Liczba linii kodu - nieistotna. Jeśli ikonki zmieniają kolorki, a zadania na tablicy przesuwają się z todo na done, nikogo z biznesu nie obchodzi jak do tego doszło. (Ciebie i twój zespół może to BARDZO obchodzić, ale biznes nie dba o to co robisz, tak długo, jak pod koniec dnia dostaną coś, za co można kasować frajera klienta).

Na koniec jest jeszcze matma. Jeśli boisz się, że nie skończył[e/a]ś studiów wyższych z całkowania, to mam dla ciebie dobrą wiadomość: programując używasz matematyki znacznie mniej, niż ludzi myślą. W praktyce, programowanie często sprowadza się do przepychania danych z jego miejsca na drugie oraz zwalaniu całej roboty na biblioteki programistyczne i frameworki, w których ktoś już rozwiązał problem za ciebie. Logiczne myślenie i algebra na poziomie gimnazjum pozwala zajechać całkiem daleko. Są miejsca, gdzie więcej matmy ci się przyda… ale do tego czasu będziesz w stanie nadrobić to sam(a).

Podsumowując: w tej branży jak chcesz dalej zajechać to umiejętności społeczne będą równie istotne jak te techniczne. Mając podstawy programowania oraz spore umiejętności w dogadywaniu się z ludźmi, zajedziesz znacznie dalej niż piwniczanin hakujący serwery. Koniec końców będziesz musiał(a) pracować z ludźmi dostarczając produkt dla ludzi.