Co zadziałało

1. Dałem radę. Wypuszczałem dwa wpisy w tygodniu. To w sumie najważniejsza z tych rzeczy, które się udały, najważniejszy wskaźnik. Minął pierwszy z trzech miesięcy konkursowych, a ten wpis jest dziesiąty (!) w marcu. Jednocześnie uniknąłem wypuszczania naprawdę krótkich wpisów, albo dzielenia wpisów na kilka części, żeby wyrobić się w KPIach. Nie wykluczone, że taka konieczność się jeszcze pojawi, ale na razie jeszcze nie miałem problemu ze znalezieniem tematu i wygospodarowaniem wystarczającej ilości czasu.

2. Więcej zastanawiam się nad środowiskiem. Praca programisty często polega na tym, że bierze się jakiś szkielet, albo wchodzi się już do jakiegoś toczącego się projektu i pracuje na tym, co jest zrobione, narzędzi ucząc się przy okazji. Tutaj mam okazję tworzyć projekt od początku, nie goni mnie konieczność ciągłego dodawania business value, tylko moge spokojnie zastanowić się nad tym, dlaczego coś robię tak, a nie inaczej. Także sam fakt, że później to opisuję, powoduje, że więcej się nad tym zastanawiam.

3. Wszedłem w Reacta, co było jednym z założeń rozwijania takiego, a nie innego projektu. Tak naprawdę tylko przez praktykę można się czegoś dobrze nauczyć, więc tworzenie projektu z Reactem na pokładzie to był strzał w dziesiątkę. Wiem już lepiej, jak React.js wygląda, jak się w nim programuje, jaką filozofię przedstawia. Wiem też, że mnóstwo rzeczy jeszcze nie wiem, ale i tak jestem dużo, dużo dalej niż miesiąc temu.

4. Nauczyłem się mówić sobie dość, choć to może trochę zaskakujący wniosek. Dawniej, kiedy tworzyłem jakieś swoje projekty, kończąc pracę nad kawałkiem funkcjonalności, miałem do siebie wyrzuty, że mógłbym coś jeszcze poprawić, coś zrobić lepiej, doimplementować tę małą rzecz. Wyłączałem komputer z poczuciem winy, że zostawiam coś nie zostało przeze mnie dokończone. Teraz, nad tym projektem, dużo łatwiej pracować mi regularnie, ale małymi kroczkami, bez zbędnej szarpaniny. I musze powiedzieć, że to ożywcze uczucie i dużo większy komfort.

Co nie zadziałało

1. Mój system pisania postów, o którym pisałem tutaj nie do końca zadziałał, a właściwie zadziałał tylko częściowo. Trzymam pomysły na Trello, ale szkice już nie znajdują się w Google Docs, tylko w IntelliJ. Jakoś znacznie łatwiej jest mi utworzyć nowy plik *.md i tam zacząć pisać, a później trzymać ten plik na dysku, nawet bez żadnej synchronizacji, niż wchodzić za każdym razem na Google Docs, czekać aż strona się załaduje i tam wprowadzać zmiany. Po prostu mam pliki w miejscu, z którego będą publikowane i edytuję je w podobny sposób, jak na co dzień edytuję kod (vimowy tryb edycji też trochę zmienia).

Inna sprawa, że na Trello zrobił mi się już bałagan i na pewno nie opublikuję wszystkich postów, które tam są zarysowane. Za dużo tego, będę musiał kiedyś przesiać.

2. Szybki rozwój projektu nie działa w tym podejściu – projekt co prawda rozwija się systematycznie, ale nie szybko. Mam poczucie, że uczestnicząc w tym konkursie, to jednak bezpośrednio rozliczany jestem z pisania postów, a nie z kodowania. Kodowanie powstaje z boku i OK, fajnie się koduje, dużo się uczę, mam poczucie systematyczności, ale mam też poczucie ograniczoności własnego czasu, dlatego też więcej czasu zajmuje pisanie bloga, niż pisanie kodu. W projekcie dla klienta takiego podejścia bym nie zalecał.

Co można zrobić, żeby było lepiej

Oczywiście zmienię trochę sposób pisania postów. Albo w zasadzie nie zmienię, tylko przestanę oszukiwać, że robię inaczej. Posty wrzucam do IntelliJ i koniec, brakuje mi tylko jakiejś dodatkowej synchronizacji, bo publiczne repozytorium na GutHubie nie wystarcza (nie chcę np. wrzucać niedokończonych postów na inne publiczne branche).

Mam swoją instancję GitLaba i nie wykluczam, że tam będę trzymał kod źródłowy bloga. Wtedy mógłbym sobie zrobić jakieś continuous deployment, które kod z mastera na GitLabie wrzucałoby na repozytorium GitHuba.

Jeśli chodzi o punkt drugi z tego, co nie zadziałało, trudno mi powiedzieć, jak mógłbym zmienić swoje podejście. Czasu poświęcanego na starter niestety nie mogę wydłużyć. Mogę za to spróbować pisać krócej i więcej kodować. Być może coś takiego zadziała, być może warto tak zrobić.

Statystyki

Podczas tego miesiąca napisałem 10 postów, w sumie ponad 70 tys. znaków (prawie dwa arkusze wydawnicze). Starter aplikacji to w tej chwili 18 commitów i 509 linijek kodu (plus trochę kodu, który jeszcze nie został opublikowany). Wszystko to zajęło mi niecałe 44 godziny.