Lenistwo motorem postępu, a więc dziś zamiast pisać od siebie, przetłumaczę ten oto artykuł wybitnego programisty z wieloletnim doświadczeniem:
Tłumaczenie jest amatorskie, niedokładne i na pewno da się je "zrobić" lepiej. Wszelkie uwagi mile widziane.
***
Pisanie kodu jest jak czarowanie. Wystarczy wypowiedzieć właściwe zaklęcie - i zaczynają się dziać rzeczy niezwykłe. Lub straszne. Zostanie wielkim programistą nie jest proste. Wymaga czasu. Przedstawiam Wam listę dziesięciu podpowiedzi dla młodych programistów, żeby ułatwić im podążanie tą ścieżką.
1. Nie spiesz się.
Zostanie dobrym programistą wymaga lat praktyki, więc bądź cierpliwy. Niezależnie od tego, jaki jesteś zdolny, twoje pierwsze projekty będą słabe. Jeżeli jednak będziesz programował codziennie, po pięciu latach będzie już całkiem nieźle. A po dwudziestu możesz nawet zostać programistą wybitnym.
2. Programuj, programuj.
Naturalnie urodzeni programiści istnieją tylko w legendach. Owszem, talent pomaga, ale nade wszystko potrzebujesz praktyki. Poświęcaj na programowanie każdą wolną minutę. Będziesz potrzebował lat praktyki, samodzielnie i z pomocą innych. Nie zostaniesz od tego bogaty, ale staniesz się lepszym człowiekiem. Programowanie jest jak granie na instrumencie. Zagraj tę samą melodię sto razy, a za każdym razem odkryjesz coś nowego.
3. Rozwijaj swoje silne strony.
Każdy jest inny. Musisz odkryć, w czym jesteś naprawdę dobry. Może w rozwiązywaniu problemów? Może w uczeniu innych? A może w długim, intensywnym skupianiu się na skomplikowanych zagadnieniach? Najlepszą oznaką, że jesteś w czymś dobry jest to, że będziesz czerpał z tego satysfakcję. Z upływem czasu będziesz coraz lepszy w różnych aspektach programowania.
4. Naucz się współpracować.
Solo zawsze będziesz po prostu średni. Prawdziwie zabłysnąć możesz tylko współpracując z innymi. Naucz się przyznawać do własnej niewiedzy i do korzystania z wiedzy innych. Szukaj projektów, w których jesteś potrzebny i które postawią przed tobą prawdziwe wyzwania. Dołączaj do projektów Open Source. Zapoznaj się z kulturą społeczności Open Source. Ucz się od innych, zwłaszcza na ich błędach.
5. Korzystaj z nauki, nie z magii.
Większość ludzi z branży tworzenia oprogramowania jest w błędzie. Naucz się rozpoznawać i odrzucać argumenty magiczne. Nauka mówi jak rozwiązywać prawdziwe problemy za pomocą często niestandardowych metod, z rygorystyczną kontrolą błędów. Nie podążaj za modą. Łap się za najpilniejszy problem i rozwiąż go używając minimum środków. Przetestuj swoje rozwiązanie i zachowaj je tylko wówczas, jeżeli sądzisz, że działa.
6. Ufaj swoim instynktom.
Na ogół rodzimy się z solidnym instynktem do współpracy. Niestety, szkoła i praca odbierają nam tę cenną umiejętność. Zamiast tego uczymy się akceptować ból i niewygodę. Naucz się więc ufać swoim instynktom. Jeżeli coś, co robisz, wydaje się nieprawidłowe, napraw to. Nawet jeżeli ma ci to zająć dekadę: zapisz sobie, zrozum i napraw.
7. Pracuj z dostępnymi narzędziami.
Rozwiązuj problemy używając narzędzi, które masz pod ręką, z ludźmi, którzy są akurat dostępni. Skup się na uzyskaniu minimalnych, skromnych ale prawidłowych wyników. Nie próbuj wynajdować przyszłości. Naucz się tworzyć prawdziwe rozwiązania prawdziwych problemów. Przyszłość wynajdzie się sama.
8. Przyjmuj krytykę.
Odrzuć swoje ego. Jeżeli ktoś krytykuje twoją pracę, to może zaboleć. Ale o wiele gorsze jest bycie ignorowanym. Proś ludzi o krytyczne opinie. Publikuj swoją pracę wraz z kodem źródłowym, o ile to możliwe. Od czasu do czasu natrafisz na trolla, który będzie próbował naprawdę cię zranić. Nie ma w tym nic osobistego. Naucz się otrząsać z takich sytuacji.
9. Bądź tani.
To ważne, aby być tanim. Naucz się używać Linuksa i tanich, używanych komputerów. Opanuj wiersz poleceń. Używaj "małych" języków, jak C, zamiast uczyć się "wielkich", jak C++. Opanowanie "większego" języka nie sprawi, że staniesz się lepszym programistą.
10. Publikuj swoje prace.
Pokaż swój kod światu, pod swoim nazwiskiem. Wspieraj projekty Open Source. Jeżeli cię nie chcą w jakimś projekcie, znajdź sobie inny. Buduj swój publiczny profil, na przykład na GitHub. To może być twoje przyszłe CV.
***
Na zakończenie kilka moich uwag.
W 120% procentach zgadzam się ze wszystkimi powyższymi punktami, z wyjątkiem punktów 5 i 9.
Nie do końca rozumiem punkt 5, więc przetłumaczyłem go tak, jak go rozumiem (oryginał jest dla mnie niejasny i wewnętrznie sprzeczny - może któryś z Czytelników z IQ powyżej numeru buta podpowie mi, o co mogło chodzić Autorowi?)
Punkt 9 - no cóż. Nie zawsze opłaca się być tanim, ale jak sobie przypomnę, ile zarabiałem w swojej pierwszej pracy dwadzieścia kilka lat temu, to może coś w tym faktycznie jest 😉 Natomiast co do uczenia się "małych" języków, tu się z Autorem nie zgadzam. Uważam, że należy uczyć się technologii dobrze ugruntowanych oraz mających szerokie perspektywy. Oczywiście bez szklanej kuli ciężko powiedzieć, czy taka lub owaka technologia będzie używana za 15-20 lat, więc trzeba trochę polegać na intuicji i instynkcie. Na przykład klamoty takie jak Python, Java, JS, C# czy SQL wydają się królować i ich nauka jest mało "ryzykowna". Ale trzeba być ostrożnym - taka na przykład CORBA, która miała być rdzeniem wymiany danych jeszcze 20 lat temu, okazała się kulą w płot. COM/COM+ też odchodzi w zapomnienie. Najlepiej być czujnym i wiedzieć, kiedy opuścić tonący statek.
Jeżeli zaś chodzi o samego Autora powyższej listy - to osobna, dość smutna historia. Facet przeszedł sześć lat temu operację usunięcia dróg żółciowych oraz chemioterapię. Niestety, okazało się niedawno, że ma przerzut na płuca i wkrótce umrze. Ostatni wpis na swoim blogu umieścił tydzień temu. Opisuje w nim, jak należy oraz jak nie należy zachowywać się w obecności osoby śmiertelnie chorej. Tu można poczytać: http://hintjens.com/blog:115
w inżynierii nie mam magii. Spotykałem klientów, którzy nie umieli wytłumaczyć dlaczego robią coś tak a nie inaczej ale wynikało to z ich niedouczenia nie zaś wiedzy tajemnej. Zwykle im wychodziło ale czasami walili takie babole, że szkoda gadać. Doświadczeni inżynierowie nie czarują, im wychodzi bo wiedzą w czym rzecz.