Metody grindowania umiejętności potrzebnych do pracy jako programista

Jak wiadomo, są te cztery strony z zadaniami, na których grindujemy umiejętności algorytmiczne przydatne przy rekrutacji i na nich rozwiązujemy te zadania algorytmiczne aby - jeśli będzie to wymagane przy rekrutacji - tam je szybko rozwiązać.

Problemem jest tu fakt, iż - mimo przydatności ich we wielu procesach rekrutacji - nie za bardzo przydają się te umiejętności przy problemach projektowych pracy programisty, gdy już ją zdobędziemy.

Chciałbym więc zapytać - jakie macie strategie rozwoju w aspektach projektowych? By jak najszybciej nowe problemy programistyczne w pracy, z jakimi się spotkacie rozwiązywać? Co najbardziej wam pomogło? Co było w waszym przypadku game changerem?

Studia i czytanie książek są game changerem.

idziebezrobocie napisał(a):

By jak najszybciej nowe problemy programistyczne w pracy, z jakimi się spotkacie rozwiązywać? Co najbardziej wam pomogło?

Przegadanie z zespołem. Samemu można kombinować, ale łatwiej jest z kimś przegadać problem.

jakie macie strategie rozwoju w aspektach projektowych?

Generalnie i głupiec zbuduje most jeśli będzie miał nieograniczoną ilość czasu i pieniędzy, stąd w projektowaniu nie chodzi o uzyskanie rozwiązania the best of the best of the best, lecz z naciskiem na optymalne wykorzystanie zasobów. Projektowanie to gra ograniczeń. Tu z miejsca włącza mi się cytat Bruce Lee "brak ograniczeń jest ograniczeniem" i przekładając na ten wątek chodzi o to, że warto widzieć ograniczenia, bo dzięki nim łatwiej jest rozpoznać w którym kierunku należy pokierować pracą.

Jak znasz ograniczenia projektowe, wtedy łatwiej jest podejmować powiązane z projektem decyzje np. kwestii narzędzi, usług, ludzi. Tu można temat drożyć głębiej, ponieważ każde narzędzie to również wynik jakiegoś kompromisu jaki otwiera projekt na pewne możliwości, jak i zawsze po drodze coś zamyka. Znając ograniczenia projektowe raczej powinieneś unikać tych narzędzi, które wywołują większy koszt i zbyt dużo odbierają .

Niestety w IT bawimy się technologiami. Dla programistów większe zainteresowanie wzbudza fakt, gdy ktoś pracuje z cassandrą niż z mysql, większa uwaga idzie za tą osobą króra używa np. Haskella niż PHP itd. Tak się dzieje, że jako programiści przez 99% czasu nie myślimy o kosztach jakie wywoła narzędzie, lecz o tym, aby w pracy wytrzymać te cholerne 8h. Dla programisty stokroć lżejszy jest dzień, gdy obok nas jest wyjątkowy stos technologiczny, który zachęca do najlepszych praktyk i który również poza wywoływaniem ciekawych problemów, wyzwala pragnienie wykorzystania narzędzi w pełnym potencjalne. Uwielbiamy być tym rozpraszani i przy takim podejściu po prostu za rzadko przechodzi przez głowę myśl o kosztach tej zabawy.

Drugą stroną na którą warto patrzeć poza ograniczeniami są wymagania, ale i też ryzyka jakie idące w parze z projektem, bo wtedy idzie rozpoznać to czego właściwie potrzebuje klient. Klienci często tego nie wiedzą dokładnie czego chcą więc rozpoznanie potrzeb klienta daje nam istotny wpływ na ukształtowanie projektu. Warto podkreślić, projekt nie jest czymś zero jedynkowym, lecz znowu grą znowu grą kompromisów, dlatego warto znać choćby podstawy branży klienta, aby wiedzieć co mu doradzić.

Reasumując to wszystko, jeśli zaczynasz pracę to raczej nie masz styku z klientem, a większość najważniejszych decyzji technicznych podjął za Ciebie ktoś inny, ale na tym etapie możesz bez brania na siebie większej odpowiedzialności ustalić dlaczego tak się stało. Rzucaj pytania nawet samemu sobie, rób notatki, wracaj, te ciekawsze pytania rzucają też do zespołu, lidera, nawet i nawet klienta jeśli ten będzie miał czas na takie rzeczy. To właśnie te rzeczy moim zdaniem rokują jak dobry mógłbyś być w aspektach projektowych.

Mnie uczyło cierpienie i rozmowy z kolegami.

Żadne leet cody, książki czy studia nie dały mi tyle co projekty - czy to jakieś PoCki na boku, czy to OSS, czy to faktycznie klepanie czegoś przez dłuzszy czas.

Jak chcesz sprawnie realizować projekty, to bądź w wielu różnych i dostrzeż co się sprawdza, a co nie.

Chcesz sprawnie wdrażać się w nowe code basy, to naucz się odnajdywać w 10 warstwowych legacy oraz zaznajom się z trendami architektonicznymi. Wtedy żaden codebase nie będzie ci straszny

By jak najszybciej nowe problemy programistyczne w pracy, z jakimi się spotkacie rozwiązywać?

Tutaj doświadczenie jest potrzebne, które jakoś musisz nabrać.

Werbalizacja problemu, podejście do tematu z wielu różnych perspektyw, kwestionowanie założeń.

znowutosamo napisał(a):

jakie macie strategie rozwoju w aspektach projektowych?

Generalnie i głupiec zbuduje most jeśli będzie miał nieograniczoną ilość czasu i pieniędzy,

Nie. Głupiec albo ignorant na pewne rzeczy nie wpadnie. Może poszukać gotowca, ale i tak nie będzie umiał go użyć. Często dlatego, że będzie chciał już natychmiast coś wdrożyć, zamiast na spokojnie przerobić fundamenty.

Przy czym każdy jest czasem głupcem albo ignorantem. Gorzej jeśli dla kogoś to permanentny stan.

WeiXiao napisał(a):

Żadne leet cody, książki czy studia nie dały mi tyle co projekty - czy to jakieś PoCki na boku, czy to OSS, czy to faktycznie klepanie czegoś przez dłuzszy czas.

Na studiach mieliśmy po 8 przedmiotów na semestr + aktywności poza studiami + często praca. W korpo/sh masz 1 projekt na 2 lata. Kto się szybciej rozwija? Chyba już sam zapomniałeś jak dużo robiłeś na studiach i jaką masz przewagę nad innymi.

Ludzie chcą dzisiaj robić ML/AI, a nie wiedzą co to jest całka. U nas musiałeś rozwiązać 100 całek i zdać egzamin, żeby iść dalej. Ale bootcampy z całkami chyba nie są popularne, prawda?

@twoj_stary_pijany

Na studiach mieliśmy po 8 przedmiotów na semestr + aktywności poza studiami + często praca.

Z tych 8 przedmiotów 2 były czystą stratą czasu

Na 2 kolejne byłem przygotowany bo pewnie w momencie podejścia do nich już od lat pracowałem

1 nie był bezpośrednio związany z CS - jakieś elektroniki, języki angielskie itd.

@TheWypierdzisty

@twoj_stary_pijany: ale takie osobiste pytanie, czy po walczeniu na studiach z całkami bez problemowo poradzisz sobie teraz z problemami fizycznymi, które też się zmieniają w czasie i trzeba całkować, myślę że pewnie sobie poradzisz, ale czy czujesz że sam rozwiążesz wszystko co ci się przytrafi? — TheWypierdzisty dziś, 11:32

Nie pracuję z takimi rzeczami na co dzień. Ale część mojej pracy polega na tym, że rekomenduję swoim klientom pewne rozwiązania. I potrafię przeczytać chat gpt whitepapera i mniej więcej zrozumieć wzory, które tam są, a następnie dać rekomendację mojemu klientowi na ten temat.

Przypomina mi się ten mem o tym jak to minął kolejny dzień bez zastosowania wzorów skróconego mnożenia i facetka w szkole nie miała racji z tym, że to się przydaje bo na kasie w Biedronce mi się w ogóle to nie przydaje. Tylko, że może właśnie dlatego pracujesz na kasie w biedronce. A inni tworzą raport dla swojej firmy gdzie szacują dlaczego warto wejść w jakąś technologię albo dlaczego warto z tym poczekać i ten raport służy w dyskusji na temat grubych kontraktów.

idziebezrobocie napisał(a):

Chciałbym więc zapytać - jakie macie strategie rozwoju w aspektach projektowych? By jak najszybciej nowe problemy programistyczne w pracy, z jakimi się spotkacie rozwiązywać? Co najbardziej wam pomogło? Co było w waszym przypadku game changerem?

Czasami trzeba pojechać klasyką.

idziebezrobocie napisał(a):

Problemem jest tu fakt, iż - mimo przydatności ich we wielu procesach rekrutacji - nie za bardzo przydają się te umiejętności przy problemach projektowych pracy programisty, gdy już ją zdobędziemy.

Dyskusyjne. Praca programisty polega na rozkładaniu złożonych problemów na mniej złożone problemy tak długo aż staną się dostatecznie proste do ogarnięcia.

Chciałbym więc zapytać - jakie macie strategie rozwoju w aspektach projektowych? By jak najszybciej nowe problemy programistyczne w pracy, z jakimi się spotkacie rozwiązywać? Co najbardziej wam pomogło? Co było w waszym przypadku game changerem?

Wyrobienie sobie nawyku przemyślenia co się chce napisać, jak to ma być napisane i dlaczego zanim dotknę klawiatury. Z moich obserwacji najczęstszym błędem w naszej pracy jest pisanie rzeczy które wydają się fajne, zamiast pisania rzeczy potrzebnych. To co u mnie się sprawdza, to poświęcenie czasu na zrozumienie problemu, zastanowieniu się czy to jest problem, zapisaniu 1-2 zdań, upewnienie się, że rozumiem to tak samo jak "właściciel problemu" pozwala zaoszczędzić sporo czasu.
Kiedy już mam taką definicję, to można zacząć dalszą pracę i dość łatwo odrzucać zadania, które nie są częścią rozwiązania aktualnego problemu.
Druga rzecz, której warto się nauczyć, to prowadzenie efektywnej dyskusji opartej o argumenty. Obejmuje to zarówno umiejętność argumentowania swoich racji, jak i wymaganie od innych, żeby takie argumenty przedstawiali.
I ostatni kawałek, przyduszenie swojego strachu i ego na tyle, żeby konfrontować własne pomysły z innymi ludźmi i nie koncentrować się na "wygranej", tylko na znalezieniu najlepszego rozwiązania.