Tutaj odpowiedź moim zdaniem należy podzielić na dwie części:
samodzielne projekty wrzucane w swoje portfolio,
projekty OpenSource tworzone zespołowo.
Samodzielne projekty dla swojego portfolio
Projekty indywidualne warto zacząć pisać i publikować, na takich platformach jak GitHub, od razu po poznaniu składni – argumentów za tym jest wiele. Najważniejszymi z nich moim zdaniem są:
zdobywanie praktyki:
Szczegóły
sama znajomość składni i teorii jest niczym, gdy nie mamy praktyki zdobytej w okopach – tam gdzie krew, pot i łzy. Można przeczytać ogromne ilości książek, jednak nasz kod zyskiwać będzie na jakości dopiero wtedy, gdy nauczymy się stosować to wszystko w praktyce.
doskonalenie się w obsłudze repozytoriów:
Szczegóły
wielu początkujących programistów (i nie tylko) traktuje git’a jako narzędzie do pakowania paczek, a platformy typu GitHub jako miejsce, gdzie można wrzucić gotowy projekt i pochwalić się nim. Warto jednak nauczyć się korzystać z tego narzędzia i platform z nim związanych jako z czegoś, co pozwoli nam pokazać historię powstawania projektu. W późniejszej pracy zespołowej jest to bardzo pomocne, np. pewien programista stworzył funkcję, w której, jak się z czasem okazało się, coś nie działa. Przeglądając historię commitów szybciej zrozumie się, co, gdzie i kiedy powstało niż patrząc na całość projektu jako monolit.
projekty te nigdzie nam nie znikną i będziemy mogli do nich wrócić za jakiś czas:
Szczegóły
sam dość późno zacząłem wrzucać na repozytoria swoje projekty, na których zdobywałem wiedzę i trochę tego żałuję – część projektów zrobionych i zapisanych na dysku uciekła w niebyt. Tworząc różne specyficzne rzeczy w ramach rozwoju, miałem okazję zaimplementować kilka ciekawych rozwiązań, a chcąc do nich wrócić, nie miałem już do czego. Dlatego od niedawna na moim githubie pojawiają się różne rzeczy, które same w sobie nie mają sensu. Czasem nawet nie są dokończone, ale to zawsze będzie dla mnie jakiś punkt odniesienia. Nic mnie to nie kosztuje, aby trzymać tam wszystko, co nie jest tworzone czysto komercyjnie.
można potwierdzić swoje umiejętności:
Szczegóły
część projektów, która mi zaginęła, pomogłaby mi pokazać potencjalnym pracodawcom czy zleceniodawcom, z czym miałem do czynienia poza komercyjnymi obowiązkami. Pisząc z rekruterami czy osobami technicznymi przeglądającymi CV pod względem technicznym, usłyszałem, że dość często zwracają uwagę na to, czy poza pracą ktoś się rozwija albo czy ma potwierdzenie doświadczenia w danym języku czy technologiach. Nawet nieskończony projekt, w którym wykorzystaliśmy jakąś bibliotekę czy technologię to coś więcej niż nic, także zaczynając coś robić, warto stworzyć plik README.md i opisać go jako projekt edukacyjny oraz wskazać, co chcieliśmy za jego pomocą osiągnąć, czy czego się nauczyliśmy. To ostatnie pokaże, że wyciągamy wnioski, a nie tylko przepisujemy kod z neta. 😉
pomoc innym:
Szczegóły
kiedyś ktoś mi powiedział, że dobry programista nie pisze wszystkiego sam, ale potrafi też wykorzystać cudzy kod. Możliwe, że na pewnym poziomie rozwoju inni programiści będą mogli czerpać z naszego kodu inspirację lub wykorzystać nasze rozwiązanie. Osobiście uważam, że nie ma w tym nic złego, choć powinno się w repo oznaczyć źródło takiej inspiracji lub biblioteki. Dzięki istniejącym bibliotekom możemy zaoszczędzić dużo czasu. Także nie tylko bierzmy od innych, ale i dajmy coś od siebie.
To główne argumenty, dla których, moim zdaniem, warto publikować swoje projekty w publicznych repozytoriach. Jeśli dla was istnieją równie ważne argumenty lub z czymś się nie zgadzacie, możecie podzielić się tym w komentarzu.
Projekty zespołowe
Z zaangażowaniem się w projekty zespołowe wiąże się więcej korzyści, ale i jeszcze większa odpowiedzialność. Dlatego postaram się najpierw przedstawić warunki, które powinniście spełnić zanim do takiego projektu dołączycie.
Wymagania:
wykazanie się samodzielnością:
Szczegóły
w takich projektach prawie zawsze znajdzie się ktoś, kto Ci pomoże, ale każdy z nas ma ograniczoną ilość czasu. Dlatego ważne jest, abyś potrafił lub potrafiła samodzielnie znaleźć odpowiedzi na proste pytania, korzystając z Google lub StackOverflow. Niańczenie kogoś cały czas jest bardzo uciążliwe, a w projektach tego typu nikt nie ma z tego pieniędzy czy innych materialnych korzyści. Także przed przystąpieniem do pracy zespołowej naucz się samodzielnie zdobywać wiedzę na w miarę dobrym poziomie.
poświęcenie czasu:
Szczegóły
praca w takich zespołach odbywa się asynchronicznie i prędzej lub później ktoś będzie potrzebował użyć Twojego fragmentu kodu lub zaprezentować jego działanie. Dlatego jeśli nie jesteś w stanie w tygodniu poświęcić około 5 godzin to lepiej sobie to odpuścić. 😛
cierpliwość:
Szczegóły
jeśli już napotkasz problem i zadasz pytanie, a masz denerwować się, że ludzie nie odpowiadają natychmiast, to też lepiej się w to nie angażować. Ludzie mają swoje życie i inne obowiązki, jeśli chcesz otrzymywać natychmiastowe porady i odpowiedzi, to w innych miejscach istnieją również bootcampy czy programy mentorskie.
umiejętność dyskusji i argumentacji:
Szczegóły
nie zawsze nasze zdanie jest najlepsze i tutaj dla dobra projektu należy umieć argumentować swoje racje oraz potrafić zrozumieć argumenty drugiej strony, ale to tylko tyle. Choć czasem aż tyle. 😛
Jeśli zatem potrafisz w takich projektach dać ze swojej strony tyle i aż tyle, ile dostaniesz w zamian…
Korzyści:
doskonalenie i podnoszenie jakości swojego kodu:
Szczegóły
uwagi innych co do czytelności kodu lub sposobów lepszego rozwiązania problemu są najcenniejsze w całym procesie nauki, a przy pracy zespołowej o nie najłatwiej. W projektach tego typu często są życzliwe osoby mogące udzielić nam także wskazówek, które ułatwią nam naukę.
nauka pracy zespołowej:
Szczegóły
programowanie w obecnych czasach to zdecydowanie sport zespołowy, nie znam żadnego dużego oprogramowania czy projektu stworzonego w pojedynkę. Czasy, kiedy można było siedzieć w piwnicy i nie odzywać się do nikogo się skończyły. Teraz, nawet jeśli ktoś siedzi w piwnicy, to ma ją połączoną z dużą ilością innych piwnic i pozostaje w stałym kontakcie z innymi piwniczakami, wymieniając się pomysłami lub dzieląc się nowymi bibliotekami czy technologiami.
przedsmak pracy zawodowej:
Szczegóły
jeśli jeszcze nie zacząłeś/zaczęłaś pracy komercyjnej, w takim projekcie będziesz mógł/mogła często zasmakować jej namiastki. Uwierzcie mi, że pisanie samemu nijak ma się do tego, jak wygląda praca zespołowa. Dzięki takim projektom będziecie lepiej przygotowani do nowych wyzwań w pierwszej pracy. 😉
możliwość poznania wielu narzędzi:
Szczegóły
w projektach często wykorzystuje się różne narzędzia, a ludzie mają różne patenty na ich optymalizację. Dlatego, dołączając do projektu, warto podpytać o konfigurację i używane programy. Ludzie często mają różne patenty, choćby na optymalizację IDE, albo różne alternatywne terminale. Warto poznać dużo możliwości, aby wybrać dla siebie najlepszą.
