Ja podobnie jak @katelx, ale jednak inaczej.
Jeśli chodzi o sideprojecty (na których się w sumie najwięcej uczę):
a) tworzę prototyp (czasem ten cykl trwa kilka godzin, czasem kilka tygodni), często w ogóle używając nowej dla mnie technologii
b) rozwijam go trochę byle jak, aż do momentu kiedy cały kod staje się dość chaotyczny i ciężko mi się samemu w nim połapać
c) wtedy przepisuję od nowa, na czysto, ze wszystkimi dobrymi praktykami, korzystając również z TDD itp.
d) kod okazuje się "przeinżynierowany" i w końcu dochodzę do tego, że utykam w martwym punkcie, że porobiłem ileś modułów i abstrakcji, które nic nie robią tak naprawdę.
e) więc przepisuję jeszcze raz od nowa, już jednak podchodząc bardziej pragmatycznie, odrzucając TDD czy zaawansowane konstrukcje i stawiając na to, żeby program działał przede wszystkim. Stosuję dobrze poznane wzorce, ewentualne eksperymenty robiąc sobie na boku jako spajki. Przede wszystkim funkcjonalność, YAGNI, MVP(mam na myśli minimum viable project oczywiście, coś co działa, a co nie jest idealne) etc.
f) po jakimś czasie albo rozwijam dalej sideproject, albo z jakichś powodów go porzucam, albo przepisuję jeszcze raz od nowa :)
g) tym niemniej na każdym etapie się czegoś nowego uczę. Przede wszystkim poznaję plusy i minusy pewnych rozwiązań i coraz bardziej rozumiem problem, który chcę rozwiązać. No i dużo jest myslenia, choćby w kiblu. Nie tylko siedząc przed kompem.
Powyższe punkty jednak dotyczą sideprojectów, gdzie mam 100% swobody do tego co robię, jak robię i ile czasu to robię. W pracy zwykle bywałem rzucany na głęboką wodę i były już istniejące projekty do rozwijania, więc ta nauka inaczej przebiegała (myślę zresztą, że z powodu presji czasu w pracy z musu się mniej uczę, bo kto by mi pozwolił eksplorować rozwiązanie przez kilka tygodni? W pracy ważniejsze od nauki bywa "dostarczanie"). Więc w pracy zwykle:
a) zaznajamiam się z codebasem, czytam też dokumentację bibliotek/frameworków, których mam używać
b) hakuję jakieś funkcjonalności, lepiej lub gorzej (czasem również robię kilka podejść, ale szczerze mówiąc trochę mi wstyd, jak dużo prototypuję i rozkminiam, bo czuję presję czasu).
c) daję do code review, dostaję jakiś feedback
d) poprawiam
e) hakuję kolejne funkcjonalności, ew. dalej doczytując dokumentację czy zaznajamiąc się z codebasem itp.
Czyli w zasadzie uczę się robiąc taski i eksplorując kod, ale jednak czuję zbyt dużą presję czasu, i mam wrażenie że jest to nauka dość powierzchowna. Bo trzeba robić swoją robotę.