U mnie wyróżniłbym następująco:
I. Przez pierwsze 10-13 lat prawie w każdym tygodniu po szkole, pracy zaglądałem do kiosków/księgarni/bibliotek szukając rzeczy powiązanych z programowaniem. Przez lata byłem na bieżąco z tym co wydawał helion. Ogólnie bycie w technicznej księgarni miało ten dodatkowy plus, że jak się nudzisz to zajrzysz też nawet do książki z excelem, delphi, actionscript3 czy edytorem vim więc nigdy nie wiesz z czym właściwie wyjdziesz. Więc jeśli pytasz o jakiś materiał do wskazania to ja zastanawiam się czemu w ogóle chcesz się ograniczać?
II. Postawienie sobie poprzeczki, aby kod, dało się przetestować. Właściwie możliwość przetestowanie czegoś otwiera tak wiele zagadnień i pytań, że ten temat przez lata wracał do mnie jak bumerang. Ta rzecz zaprocentowała u mnie w szczególności na etacie.
III. W przypadku programowania najbardziej znaczące jest to jak patrzysz na problemy, bo umiejętność zmiany perspektywy to klucz, który z reguły daje coś w rodzaju +80 do IQ i właśnie z tego względu uwaga: warto uczyć, ale tak z naciskiem na efekty. Bo tak gadać o niczym to ok, ale osoba dalej z Tobą nie ruszy. Natomiast, gdy chcesz widzieć u kogoś postęp to takie podejście zmusza Cię byś nauczył kogoś w pierwszej kolejności myśleć o problemach, rozkładaniu ich i dostrzeganiu i wykorzystywaniu ograniczeń, aby na nich oprzeć rozwiązanie. Ucząc, lepiej jest iść w minimalizm, odsłanianie tylko tego co niezbędne, bo im więcej gramatyki odsłonisz tym więcej absurdów zobaczysz na sam koniec. Ucząc ciągle obserwujesz, widzisz co działa, co nie, widzisz jak ktoś utrudnia sobie pracę. Mi co jakiś czas generowało się pytanie do przemyślenia, spostrzeżenie podważające sposób pracy z problemami. Warto w tym czasie też prowadzić notatki, regularnie wracać do nich, rozwijać odpowiedzi na pytania. To pozwoliło mi pojąć, że nie myślę wystarczająco jasno i że wiele rzeczy wymaga po mojej stronie doprecyzowania.
