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ł?

3 thoughts on “Miara rozwoju zawodowego”

  1. To jest miara dla początkujących programistów. Przez pierwszych parę lat uczymy się separowania kodu, dzielenia na warstwy, dobrych praktyk, więc nic dziwnego w tym, że kod pisany 3 lata temu jest dla nas okropny.
    Ale jeśli ktoś z 15 letnim stażem znajduje takie rzeczy w swoim trzyletnim kodzie, to raczej znaczy, że się nie rozwija.

    1. Jeśli kogoś z kilkuletnim doświadczeniem nazywamy początkującym to tak, jest to raczej miara dla początkujących :) Osoby, które mają kilkanaście lat doświadczenia albo doskonale wiedzą co robią, albo ich to nie obchodzi i zajmują się rzeczami, które nie wymagają stałej aktualizacji wiedzy. Ale również ci bardziej doświadczeni mimo wszystko mogą się w ten sposób sprawdzić, tylko już np. nie na poziomie jakości konkretnych metod czy klas, ale np. na poziomie architektury czy doboru frameworków bo nawet jeśli programują dłużej niż ich koledzy z pracy żyją to jednak nadal mogą poznawać nowe podejścia do tematu czy będące aktualnie „na czasie” architektury aplikacji. W końcu programista uczy się całe życie.

  2. Moim zdaniem każdy, kto ma problem z SOLID, wzorcami projektowymi i podziałem na warstwy jest początkujący.

    I nie możesz stwierdzić, że Twój kod napisany 5 lat temu jest zły, dlatego że teraz użyłbyś frameworka, którego wtedy nie było. To świadczy o rozwoju technologii, nie o Twoim osobistym. :)

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *