3 kroki do stania się lepszym programistą

Programowanie to sztuka i wymaga znacznie więcej aniżeli wiedzy technicznej. Jak każda inna, w dużej mierze polega na doświadczeniu. Jednak doświadczenie doświadczeniu nierówne, bo każde kształtuje nasze nawyki na swój sposób. Tym razem chciałbym Wam zaproponować kilka rzeczy, których kiedyś nie robiłem, a uważam że znacząco podniosły moje umiejętności.

Napisz to od nowa

Programowanie jest skomplikowane, projektując rozwiązanie trudno jest od razu przewidzieć wszystkie wymagania i uwarunkowania wpływające na ostateczny kształt programu. Piszemy program i nie działa. Szukamy rozwiązania i znajdujemy sposób, który działa. Często takie rozwiązanie jest uwikłane w początkowe założenia, które nie pozwalają zrobić tego we właściwy sposób i zmusza nas do stosowania obejść. Często okazuje się, że takie założenia przyjęte na samym początku zatruwają życie dopóki się ich nie usunie. Z drugiej strony, często nie ma łatwiejszego sposobu niż zacząć o początku i w ogólnym rozrachunku, im szybciej to zrobimy tym lepiej.

Co ciekawe, gdy piszę kolejne rozwiązanie dla tego samego problemu moje rozumowanie jest inne i naturalnie przyjmuję bardziej elastyczne rozwiązanie, lepiej pasujące do problemu. W ten sposób rozwinąłem w sobie lepsze zrozumienie w jaki sposób mogę podejść do problemu i jaka jest praktyczna różnica. Co więcej, po przepisaniu kodu na nowo rozumiem i problem, i swoje rozwiązanie, znacznie lepiej.

Jednak kiedyś byłem bardzo przywiązany do kodu, który napisałem, zwłaszcza jeśli nie do końca wiedziałem dlaczego działa. Im częściej przepisywałem kod tym bardziej rozwijałem w sobie oczekiwanie od siebie zrozumienia jego zasad działania, dzięki czemu tworzyłem kod lepszej jakości. Po jakimś czasie stało się naturalne, że bardzo dobrze zdaję sobie sprawę z tego jak działa mój program i jak mógłbym napisać go inaczej. Dzięki temu zacząłem odczuwać koszt przepisania go w sposób znacznie bardziej obiektywny — nie było tam strachu i niepewności związanego z niezrozumieniem problemu. W związku z tym, nie waham się odrzucać rozwiązania, jeśli widzę, że bardziej opłaca się napisać je od początku. Ogólnie rzecz ujmując, czuję się znacznie pewniej odnośnie programów, które piszę i projektów, których potencjalnie mógłbym się podjąć.

Oczywiście na samym początku, koszt takiego przedsięwzięcia jest stosunkowo duży, bo mając mało doświadczenia, zwykle działamy mniej lub bardziej po omacku. Stąd, prawdopodobnie lepiej praktykować to przy własnych projektach nieobarczonych presją czasową. Z drugiej strony, koszt ten spada wraz z objętością kodu, a zatem, jeśli skupimy się na małej części rozwiązania to i tak nie zajmie to bardzo dużo czasu. I tu kolejny pożyteczny nawyk się wyrabia — tworzenie małych, niezależnych rozwiązań, których możemy łatwo użyć w innym projekcie.

Dodatkowo, ten koszt czasowy przedsięwzięcia też ma swoją funkcję. Uczy cierpliwości, która pomaga w pracy. Racjonalne tworzenie programów wymaga czasu i robienie rzeczy na hura, choć przynosi szybsze efekty, na dłuższą metę, nie jest wcale bardziej efektywne (nie mówiąc o jakości rozwiązań).

Najpierw zrób to „na piechotę”

Już nie pamiętam, gdzie przeczytałem o tym, ale okazało się to wybawieniem od niepewności jaką wzbudza nadmierna złożoność problemu, ilość czynników do wzięcia pod uwagę. Mianowicie, zanim podejdzie się do automatyzacji rozwiązania problemu, należy chociaż raz zrobić to najłatwiejszym możliwym sposobem, w małej skali.

Znacznie łatwiej jest przełożyć na kod działania, które przed chwilą zrobiło się samemu, przy pomocy istniejących już narzędzi. Ponadto, jest to całkiem dobry sposób określania złożoności problemu — jeśli trudno wyobrazić nam sobie wykonanie jakiegoś zadania bez pomocy programu, prawdopodobnie składa się on z mniejszych problemów, które tak czy tak należałoby rozwiązać osobno i złożyć potem w jedną całość.

Tak więc jednocześnie uczymy się właściwego dzielenia problemów na mniejsze, co jest oddzielną umiejętnością, tak bardzo ważnego dla efektywnej pracy. Często nawet nie zdajemy sobie sprawę, że wielokrotnie rozwiązujemy ten sam problem wielokrotnie, zmyleni choćby tym, że działamy na innym typie danych.

W taki sposób z łatwością możemy zaobserwować czy na pewno podejmujemy się minimalnego problemu i unikamy programistycznego bujania w obłokach, kodowania bez jasnego celu. Przechodzimy w tryb programowanie poprzez ewolucję, zaczynając od bardzo prostych, cząstkowych przypadków, stopniowo rozszerzając zakres działania.

Rozwiązuj swoje problemy

Kiedyś nie programowałem, żeby ułatwiać swoje życie. Poza pracą pisałem programy, które w taki czy inny sposób zaspokajały moją ciekawość. Często było to, jakże powszechne, rozwiązywanie byle jakich problemów, byleby wypróbować nową technologię.

Działo się tak, między innymi dlatego, że zwyczajnie nie umiałem identyfikować czynności, które wykonuję, a mogłyby być mniejszym czy większym wysiłkiem zautomatyzowane. Z perspektywy czasu, miało to swoje poważne konsekwencje.

Po pierwsze, podczas gdy mogłem ułatwiać sobie życie, traciłem czas na gruszki na wierzbie. Ktoś powie, że trzeba najpierw się nauczyć programować, a potem robić to w praktycznym celu, być może sam kiedyś w to podświadomie wierzyłem. Prawdopodobnie przyzwyczaiły mnie do tego szkoła i studia. Teraz jednak widzę, że to bzdura. Od jakiegoś czasu uczę się nowych rzeczy na praktycznych przykładach i działa to wyśmienicie (nawet w środowisku komercyjnym).

Oczywiście jest to możliwe dzięki ogólnemu pojęciu co jest możliwe jakim wysiłkiem, a to przychodzi z doświadczeniem. Z drugiej strony, pomoc dobrego mentora może znacznie ułatwić pracę. Inna sprawa, że nikogo takiego wówczas nie znałem.

To jednak mały jeszcze koszt, bo przecież robiłem to co lubię. Z drugiej strony to wyrabiało we mnie nawyk rozwiązywania czyichś problemów, a to ma już wielorakie konsekwencje.

Po pierwsze, to że piszemy program dla kogoś nie znaczy, że nie możemy swojej pracy usprawnić. Oczywiście mamy różne narzędzia, IDE, git, docker, itd. One pomagają, jednak żadne z nich nie zastąpi wysiłku dopasowania narzędzi do konkretnego przypadku. Dla mnie ma to pewnie jeszcze większe znaczenie, bo popularne narzędzia często nie pasują do mojej percepcji, wzbudzają we mnie tylko niepotrzebną frustrację.

Po drugie, rozwiązując własne problemy, możemy lepiej zrozumieć swoją pracę w szerszej perspektywie. Nie stawiamy czoła zadaniu, które stawia ktoś przed nami. Mamy problem i pełne pole możliwości jego rozwiązania. Dzięki temu, że są to nasze problemy, dobrze orientujemy się w dziedzinie. Co za tym idzie, możemy znacznie łatwiej wejść w ten aspekt programowania. To sprawia, że stajemy się bardziej samodzielni i możemy lepiej zrozumieć sytuację klienta.

W końcu, po trzecie, jeśli mamy pasję i wspomagamy rozwijanie jej przy pomocy programowania, mamy świetną motywację do pracy i dobre zrozumienie problemu. Również łatwiej wdrożyć zasadę „zrób to na piechotę”. W perspektywie czasu, może to prowadzić do stworzenia własnego innowacyjnego rozwiązania, które da nam więcej niezależności.

Podsumowując

Programowanie to znacznie więcej niż technologie. Poprzestając na uczeniu się technologii czy poszczególnych rozwiązań, trudno jest nabyć prawdziwą biegłość. Aby ją osiągnąć, potrzebujemy znacznie więcej własnej inwencji. To tylko niektóre ze sposobów poszerzania swoich horyzontów, te jednak są stosunkowo proste do przekazania i wprowadzenia w życie. Na przykład warto polecić zainteresować się teorią wyższego szczebla niż wzorce projektowe — prawdziwej nauce. No, ale do tego trzeba po prostu dorosnąć.