A jaka to różnica jest między kodem we własnych projektach a komercyjnych?
Między kodem? W sensie pętlami, ifami i klasami? Właściwie żadna. Różnica jest w pracy. W firmie tworzysz dla klienta, który ma jakieś wymagania, na dodatek ciągle je zmienia. A Ty i tak musisz dotrzymać terminów i zrobić coś naprawdę działającego, a nie jedynie wyglądającego jak aplikacja.
(Na dodatek klient często jest idiotą, ale Ty nie możesz nigdy dać mu tego do zrozumienia. ;))
Ponadto, tworząc komercyjnie siłą rzeczy nabierasz też doświadczenia w dziedzinie dla której tworzysz aplikacje. Programista systemu księgowego, któremu nie trzeba już tłumaczyć czym się różni storno czerwone od czarnego jest bardziej wartościowym pracownikiem.
Różnica jest na pewno w wielkości tworzonych aplikacji, to oczywiste ale poza tym?
Uważasz, że to mało? W małych projekcikach nie trzeba się martwić o wydajność, stabilność, awaryjność, czy duże ilości danych. Nie trzeba się też martwić o interfejsy do zewnętrznych systemów, bo ich zazwyczaj nie ma. Nie trzeba się martwić o czas reakcji na błędy ani o sposób wdrażania nowych wersji na środowisko produkcyjne, bo jego też nie ma.
Przecież taki student we własnym projekcie tez pisze dokumentacje, testy, używa tych samych technik i najczęściej również tych samych narzędzi co w projektach komercyjnych.
Pokaż mi studencki projekt, w którym jest kilka aplikacji .NET, kilka Javowych, jedna w Oracle Formsach, jedna na Sharepoincie, kilka interfejsów do zewnętrznych sklepów i banków, a wszystko gada z Mainframe z lat osiemdziesiątych.
Pokaż mi studencki projekt, który składa się z wielu modułów, pracujących na wielu serwerach, które komunikują się ze sobą w niezawodny sposób, i są niepodatne na awarie.
Pokaż mi studencki projekt, w którym stosowane jest CI i CD, zaczyna się analizą biznesową, a kolejne funkcje systemu są testowane przez testerów.
Kolejna rzecz - w swoim studenckim projekcie (szczególnie jak jest się dobrym studentem), napisze się świetny kod, użyje super technik i najnowszych technologii. Tymczasem w rzeczywistości trzeba umieć naprawiać błędy w słabym kodzie, a stosowane technologie zdarzają się bardzo stare.
Praca programisty to nie jest pisanie kodu tylko tworzenie narzędzi, które mają efektywnie realizować potrzeby klienta. Pisanie kodu to bardzo mała część tej pracy.