Odnośnie nauki poprzez pisanie byłbym daleki od stwierdzenia, że samo pisanie kodu to najlepsza metoda na naukę. Tak to łatwo można zweryfikować czy wiedza jaka masz i umiejętności dobrze rzutują na projekt, i albo coś nam wychodzi albo projekt stawia opór. Oczywiście można się zatrzymać, pomyśleć, zbadać alternatywy, poznać więcej informacji, przećwiczyć inne ścieżki itp, ale podczas pisania projektu, zwłaszcza komercyjnego to takiego komfortu zbytnio nie ma, w trakcie pisania kodu skłaniamy się ku nieciekawym kompromisom, to nie są rzeczy jakie chce się powtarzać w kolejnych projektach.
Także tak to nawet nie zawsze sie dowiemy czego nie wiemy, w zasadzie bardziej byłbym skłonny do stwierdzenia, że dowiemy się tylko jakie problemy były dla nas kłopotliwe / niewygodne.
Tutaj rokujący programista to taki, który tutaj odrobi pracę domową i ten problem wyłapie i zacznie studiować metody radzenia sobie z takimi rzeczami. W lepszej sytuacji jest ten kto zna więcej paradygmatów, więcej zróżnicowanych technik, bo takie rzeczy pozwalają patrzeć z różnych perspektyw, pozwalają sprawniej dokonać selekcji i zawęzić obszar przeszukiwania.
Ale samo programowanie to nie wszystko, bo ważniejsze są narzędzia. To drugi ważny obszar od którego zależy jak bardzo pewny grunt mam pod sobą. Tutaj warto poznać ograniczenia z jakich składają się narzędzia, wiedzieć dlaczego tak te narzędzia działają, jakie są problemy, jak mozna przy nich postąpić - ta rzecz wymaga przebrnięcia przez książki, dokumentacje, rozmowy z programistami, czytanie kodu, coraz większego zagłębiania się w temat i problemy związane z narzędziem itp. Bez tej świadomości nic nam po samym pisaniu, bo to co przedstawiamy w kodzie wtedy wygląda raczej jak zgadywanie.
No i trzecia rzecz, jak ktoś się nauczył wielu technik oraz rzeczywiście zna narzędzia to kolejna trudna rzecz jaka go czeka to mooooocne wdepnięce hamulcja, ponieważ potrzebny będzie umiar, słuchanie innych, rozkładanie sił na cały projekt, pisanie możliwie prostego kodu i to nie jest taka łatwa zrobić to (to tak jak przejście z haskella / rusta do pracy okopach w javascript es 3). Ciężko jest powiedzieć stop sobie, a co gorsza innym, gdy przecież cały świat przecież gna do przodu jak gazela.
Jeśli mamy taką osobę w zespole to niemal wszyscy programisci przy takim gościu również wyglądają jak gwiazdy. Dużo łatwiej jest wtedy redukować poziom złożoności w projekcie, ryzyka jakie wiąże się z projektem, nie wspominając już o samym utrzymaniu.
Także ja tak bym w skrócie ujął to co ma znaczenie z perspektywy uczenia się programowania.