Miara rozwoju zawodowego

Na pewno spotkałeś się ze stwierdzeniem, że jako programista powinieneś się rozwijać, a nie stać w miejscu. Niby prosta sprawa, wystarczy poczytać trochę tutoriali czy dobrych książek i pisać więcej kodu, prawda? Tylko czy na pewno będziesz się rozwijał? Jak sprawdzić czy zrobiłeś jakieś postępy?

Odpowiedź na to pytanie już nie jest taka prosta. To, że poznałeś jakąś nową bibliotekę czy nawet język programowania wcale nie oznacza jeszcze, że jako programista mocno się rozwinąłeś w swoim zawodzie. Bo programowanie nie polega na wykuciu kolejnych partii informacji i sklejania ich potem bezmyślnie w większą całość „żeby działało”.

Ja przez ostatnie parę dni znalazłem całkiem dobry wskaźnik tego na ile rozwinąłem się w programowaniu – stary projekt.

Dokładnie tak. W końcu taki odkopany projekt jest to „fizyczne” przedstawienie tego w jaki sposób programowałeś jakiś czas temu (kilka miesięcy, lat?) więc idealnie nadaje się do porównania swoich umiejętności.

Ja właśnie taki projekt odkopałem. Całkiem spory jak na jedną osobę, ostatni raz ruszany kilka miesięcy temu, a powstawał przez jakiś rok, z czego początki sięgają moich początków z ASP.NET MVC. Pierwsza myśl była taka, że najprościej by było to wyrzucić i napisać od nowa, ale po pierwsze nie mam pewności, że wszystko uda mi się przenieść tak, żeby działało identycznie (tym bardziej, że brakuje dokumentacji), a po drugie mam mało czasu na poprawki (projekt na zamówienie był robiony i teraz wymaga zmian) więc lepiej pracować iteracyjnie i w razie czego mieć poprawioną tylko część systemu, ale działającą całość, poza tym nie o to chodzi żeby zburzyć i wybudować jeszcze raz.

No dobra, po pierwszym szoku czas zabrać się za zgłębianie tajemnic. I tutaj wychodzi to o czym piszę w tym poście. Bo kiedy zacząłem przeglądać kolejne metody to łapałem się za głowę i bez szczególnego zastanawiania się wiedziałem gdzie można, zmieniając nieznacznie jakiś fragment albo dodając jedną metodę, zdecydowanie poprawić jakość kodu. Pozbycie się np. ViewBaga, bez którego w trakcie powstawania pierwszej wersji nie potrafiłem sobie poradzić, stało się dla mnie tak oczywiste i proste, że tylko głupiec mógł nie wiedzieć jak to zrobić, a takim głupcem byłem ja sam rok czy dwa lata temu. To samo tyczy się używania bibliotek. Kiedyś poza głównym frameworkiem nie korzystałem chyba z żadnej, teraz włożenie kilku, które zdecydowanie upraszczają kod i dodają pomocne funkcjonalności, to takie przyzwoite minimum. Odseparowanie zapytań do bazy danych od reszty aplikacji, poprawienie struktury modeli i pozbycie się logiki z kontrolerów to aktualnie mój priorytet. I wiem już jak to zrobić, zostaje tylko znaleźć czas.

I to właśnie jest jedna z dobrych miar rozwoju zawodowego . Gdybym otworzył taki projekt i stwierdził, że jest w sunie nie najgorzej to nie powinienem mówić o sobie programista tylko klepacz kodu, bo tak jak kiedyś wyklepałem, tak klepałbym dalej wg tego samego szablonu. A ponieważ bez problemu znajduję sposoby na sprytne i łatwe uporządkowanie kodu gdzie potrafię niewielką, przemyślaną metodą zastąpić duży blok instrukcji i w dodatku tą metodę mogę wykorzystać w kilku innych miejscach to chyba znaczy, że jednak przez ostatnio dwa lata czegoś się nauczyłem.

Jeśli macie takie swoje starsze, trochę większe projekty to może warto je odkopać w wolnej chwili i zmierzyć się z nimi jeszcze raz sprawdzając czego się człowiek przez ten czas nauczył?