Jak stać się junior developerem - Tutorial cz. 2

Cześć, pod poprzednim artykułem pokazało się kilka komentarzy, które uświadomiły mi, że to co napisałem nie jest do końca kompletne i usystematyzowane. Dziś postaram się nieco uzupełnić poprzedni wpis dodając elementy, które były treścią komentarzy. Zacznijmy standardowo od aspektów związanych bezpośrednio z pracą programisty, tak bez wchodzenia w konkretną technologię.

Na pewno brakowało czegoś na temat rozwiązywania problemów. Jest to umiejętność niezbędna do pracy każdego programisty. Tylko jak te problemy rozwiązywać to zależy tak naprawdę od paradygmatu języka programowania. Poza walką .NET/Java czy Ruby/Python/PHP, mamy coś takiego co nazywa się paradygmatem programowania, gdzie wyróżniamy np. języki obiektowe, funkcyjne, itp. Itd.. Ten kto chce znajdzie wszystkie paradygmaty w Internecie. Dodatkowo każdy język może umożliwiać programowanie wieloparadygamtowe np. C# jest obiektowy, imperatywny, strukturalny i częściowo funkcyjny. Co dla nas jako dla programisty oznacza paradygmat. Właściwie jest on wszystkim w momencie rozbijania naszego zadania na mniejsze składowe . W programowaniu obiektowym jest duża szansa, że rozwiązując jakiś problem stworzymy kilka klas, które korzystając ze swoich funkcjonalności będą rozwiązywały nasz problem. W przypadku języka funkcyjnego to właśnie funkcje będą rozwiązaniem naszego problemu i może jeszcze jakieś struktury danych i tak dalej w przypadku innych paradygmatów. Tu z mojej strony taka dobra rada, żeby jak już nauczysz się jednego paradygmatu to zerknąć czasem gdzieś poza swoją strefę komfortu. Ja tak z mojej strony uczę się języka Rust, który nie jest obiektowy, a dodatkowo nie ma maszyny wirtualnej do zarządzania pamięcią. Moje pierwsze starcia pokazały mi, że nie jest tak prosto wyzbyć się nawyków z języka obiektowego, ale można i to daje również mi nowe możliwości w C#.

Drugą rzeczą są narzędzia i chodzi mi tu o ich znajomość praktyczną, a nie tylko wpis na LinkedIn. Oznacza to, że nie klikamy po naszym IDE tylko chociaż umiem używać podstawowych skrótów klawiszowych. Dodatkowo dobrze jak umielibyśmy posługiwać się wspomnianym w komentarzach debuggerem przynajmniej w formie podstawowej. Co do testów to raczej na początku nie zawracałbym sobie tym głowy, ale jak coś się będzie wiedziało to spoko. Jeszcze jedna rzecz, o której wspomniałem, ale powtórzę jeszcze raz to znajomość przynajmniej jednego systemu kontroli wersji. Tu polecam Git'a, ponieważ jest on chyba najbardziej popularnym narzędziem tego typu.

Teraz przejdźmy do rzeczy nie związanych z ściśle z samym pisaniem kodu czy narzędziami. Zacznijmy od wyszukiwania rozwiązań. Często jest tak, że problem który mamy rozwiązać jest już rozwiązany i wystarczy skorzystać z pracy kogoś dostosowując tylko kod do naszego problemu. Tu przyda się umiejętność jak dla mnie trywialna, czyli korzystanie z wyszukiwarki Google. Tak może tu zadziwię niektóre osoby, ale programiści nawet Ci którzy w branży są już długo korzystają z Google do wyszukiwania rozwiązań, a nie piszą wszystkiego od zera. Tu dodatkowo warto szukać w języku angielskim, ponieważ w IT jest to taki język domyślny. Jak nie umiemy formułować swoich wypowiedzi w języku Shakespeare'a to polecam Google translator. Sam tak na początku robiłem. Jeżeli chodzi o Internet nie można tu pominąć StackOverflow, czyli największego globalnego forum programistycznego. Można tam znaleźć rozwiązania właściwie na każdy nasz problem, więc pewnie długo nie będziecie musieli pisać tam żadnych postów, poza tym większość zapytań do Google będzie właśnie tam was kierować.

Co do języka angielskiego to polecam właśnie w tym języku czytać wszelkie materiały dotyczące programowania. Wiem sam tworzę treści w języku polskim i sam takie treści konsumuję, ale mimo to większość mojej obecnej wiedzy pochodzi ze źródeł anglojęzycznych, bo np. o takim OpenGL to nie ma za dużo na polskiej blogosferze programistycznej.

Dodatkowo powtórzę, że warto budować swoje portfolio, piszcie aplikacje nawet małe byle działające. Im więcej ich napiszecie tym lepiej poukładane one będą i będziecie mieli większą siłę przebicia na rynku.

Jest jedna rzecz którą polecę jeszcze na koniec. To coś co pozwoliło mi mocno pokonać krzywą nauki, a są to wystąpienia na Youtube. Można tam znaleźć masę konferencji i różnych innych wystąpień w języku angielski jak i polskim. Warto więc poszperać, ponieważ własne nagrania mają nawet grupy programistyczne. Ja z takich nagrań dowiedziałem się o Akka.NET, której później używałem w projekcie. Warto więc zamiast oglądać śmieszne koty poświęcić tą godzinę co jakiś czas na ciekawą prelekcję, która pozwoli nam zyskać ciekawą wiedzę.

W komentarzach przewinął się jeszcze temat przygotowania do rozmowy kwalifikacyjnej. Tu będzie dość kontrowersyjnie, ponieważ ja uważam, że to bez sensu. Naszym przygotowaniem są projekty, które nauczyły nas programować. Jeżeli w nich czujemy się pewnie i znamy w miarę technologię, w której zamierzamy pracować to trzeba zmierzyć się z rozmową. Jeżeli się nie dostaniemy to zawsze można próbować znowu, a mamy czarno na białym czego nie umiemy i nad czym trzeba popracować, żeby zdobyć nową wiedzę. Nikt was nie będzie specjalnie przepytywał z nie wiadomo jakich wiadomości szczególnie jak to będzie wasza pierwsza praca. Ja sam tak robiłem i nadal tak robię tzn. na rozmowię idę z marszu, ponieważ nie ma sensu studiować miliona pytań kwalifikacyjnych, bo i tak jak nas zatrudnią to pracodawca dostanie walidacje naszych odpowiedzi w postaci naszej pracy. Jak na rozmowie odpowiedzieliśmy, bo wykuliśmy coś na pamięć, a nie umiemy tego zastosować to wyjdzie bardzo szybko, więc nie ma sensu tego robić.

To chyba na tyle. Jak mi się jeszcze coś nasunie to pewnie powstanie kolejna część. Jak zawsze zapraszam do sekcji komentarzy, gdzie chętnie podyskutuje o tym co tu napisałem, jak i o waszych pomysłach.