Hej,
zastanawiam się nad używaniem githuba przy nauce programowania, w sensie żeby pokazać przyszłemu pracodawcy, że codziennie coś tam robiłem.
tylko co w tego githuba wrzucać? co sądzicie żeby wrzucać np tablice, instrukcje sterujace, wyjatki itd itd itd czyli zalozmy punkt po punkcie z ksiazki + jakies przykłady. Ma to sens?
U kilku osób widziałem takie repo z zadaniami z różnych stron, algorytmami, tablicami, itd.
Ja bym wrzucał. Zawsze na tym repo coś jest, wpisując w CV Gita to masz poparte to praktyką, a nie suchą teorią. Poza tym pokazujesz potencjalnemu pracodawcy że się uczysz, rozwijasz, rozwiązujesz zadania.
Jak już byś założył repo to postaraj się żeby ten kod też dobrze wyglądał nawet jak to małe zadania, małe klasy.
https://google.github.io/styleguide/javaguide.html
Wrzucaj tylko takie małe rzeczy jako projekt np. nauka w którym miałbyś wiele podprojektów a nie 1 repo na każde ćwiczenie. na pewno nie zaszkodzi :)
zastanawiam się nad używaniem githuba przy nauce programowania, w sensie żeby pokazać przyszłemu pracodawcy, że codziennie coś tam robiłem.
tylko co w tego githuba wrzucać? co sądzicie żeby wrzucać np tablice, instrukcje sterujace, wyjatki itd itd itd czyli zalozmy punkt po punkcie z ksiazki
- jakies przykłady. Ma to sens?
Ma to sens tylko dla utrzymania samodyscypliny, ponieważ jak ktoś cię będzie rekrutował do firmy, nie będzie go obchodziło, że się nauczyłeś tablic we wtorek, a instrukcji sterujących w środę...
Tak małych rzeczy jak przykłady z książki (tablice, instrukcje sterujące itd) nie ma sensu wrzucać, bo nikt nie będzie przeglądał dziesiątków małych programików, które nic nie robią, ani nie pokazują jaki masz styl kodowania, sposób myślenia i zakres wiedzy.
Wielki Terrorysta napisał(a):
zastanawiam się nad używaniem githuba przy nauce programowania, w sensie żeby pokazać przyszłemu pracodawcy, że codziennie coś tam robiłem.
Wśród instynktów, w jakie natura wyposażyła pracodawców, nie ma miłości do tych, którzy "codziennie coś tam robią". Raczej wręcz pracodawcy mogą czuć podświadomą niechęć do tego typu ludzi. Mistrzowie "wyglądania na zajętych" to w biznesowej rzeczywistości plaga. Nie ma się do nich o co przyczepić, a czas przecieka przez palce. Tak że dużo lepiej, by coś zostało codzienne zrobione. Może subtelne rozróżnienie ale niepozbawione znaczenia.
Widziałem kiedyś np. blog typa, który bodajże w 100 dni napisał nietrywialną grę na telefon. Z każdego dnia wrzucał relację - o co konkretnie projekt się wzbogacił, czego autor się przy okazji nauczył.
Nie znalazłem tego konkretnego przykładu w tym momencie a nie chce mi się grzebać, ale ot, np. ta laska - http://blog.jenniferdewalt.com/post/56319597560/im-learning-to-code-by-building-180-websites-in - każdego dnia skleciła inną stronkę. Stronkę prostą - niemniej każdy przykład jest jakąś funkcjonalną całością, a nie tylko przećwiczeniem kawałeczka suchej teorii. No i świadczy to o większej inicjatywie, niż jechanie "punkt po punkcie z książki".
Tu nie chodzi o to, żeby rezultat był technicznie zaawansowany, tylko żeby wykazywał, że umiesz przerzucać mosty między teorią a praktyką. Moim zdaniem to jest kluczowa umiejętność, którą warto udowodnić pierwszemu pracodawcy.
V-2 napisał(a):
Wielki Terrorysta napisał(a):
zastanawiam się nad używaniem githuba przy nauce programowania, w sensie żeby pokazać przyszłemu pracodawcy, że codziennie coś tam robiłem.
Wśród instynktów, w jakie natura wyposażyła pracodawców, nie ma miłości do tych, którzy "codziennie coś tam robią". Raczej wręcz pracodawcy mogą czuć podświadomą niechęć do tego typu ludzi. Mistrzowie "wyglądania na zajętych" to w biznesowej rzeczywistości plaga. Nie ma się do nich o co przyczepić, a czas przecieka przez palce. Tak że dużo lepiej, by coś zostało codzienne zrobione. Może subtelne rozróżnienie ale niepozbawione znaczenia.
Widziałem kiedyś np. blog typa, który bodajże w 100 dni napisał nietrywialną grę na telefon. Z każdego dnia wrzucał relację - o co konkretnie projekt się wzbogacił, czego autor się przy okazji nauczył.
Nie znalazłem tego konkretnego przykładu w tym momencie a nie chce mi się grzebać, ale ot, np. ta laska - http://blog.jenniferdewalt.com/post/56319597560/im-learning-to-code-by-building-180-websites-in - każdego dnia skleciła inną stronkę. Stronkę prostą - niemniej każdy przykład jest jakąś funkcjonalną całością, a nie tylko przećwiczeniem kawałeczka suchej teorii. No i świadczy to o większej inicjatywie, niż jechanie "punkt po punkcie z książki".
No ale to źle czy dobrze w końcu jak regularnie się coś robi, w pierwszym akapicie chyba twierdzisz, że źle, potem dajesz przykład jakichś ludzi, którzy jednak regularnie coś publikują.
IMHO w życiu bym nie zatrudnił kogoś kto robi 180 debilnych i bezużytecznych stronek po to tylko żeby je zrobić.
No może jedna użyteczna... https://jenniferdewalt.com/need_drink/options :D
Nie jestem pewien, czy potrafię wyrazić się jaśniej. Chodzi o to, że to, co robią, ma wymiar praktyczny (nawet jako zadaniówki), a nie jest tylko suchym ćwiczeniem: "tak się łapie wyjątek, a tak się robi pętlę". Poza tym prowadzi ich własna inwencja, a nie spis treści jakiegoś podręcznika.
Wśród instynktów, w jakie natura wyposażyła pracodawców, nie ma miłości do tych, którzy "codziennie coś tam robią". Raczej wręcz pracodawcy mogą czuć
podświadomą niechęć do tego typu ludzi. Mistrzowie "wyglądania na zajętych" to w biznesowej rzeczywistości plaga. Nie ma się do nich o co przyczepić, a czas
przecieka przez palce. Tak że dużo lepiej, by coś zostało codzienne zrobione. Może subtelne rozróżnienie ale niepozbawione znaczenia.
Oj, myślę, że w wielu firmach panuje wręcz kultura ciągłego "wyglądania na zajętych" bez realnych postępów. Choćby spotkania temu służą, żeby móc nic nie robić przez kilka godzin w tygodniu, a dalej wyglądać na bardzo zajętych.
Wiele projektów też cierpi na overengineering i nadmiar wzorców projektowych, które wyglądają ładnie i profesjonalnie a służą często tylko temu, żeby praca wolniej szła - przy przeinżynierowanym kodzie (bardzo często spotykanym przecież) często jest tak, że programiści siedzą, coś tam robią, tworzą jakieś klasy, modyfikują, ale nie widać żadnych efektów biznesowych, bo zmieniają się tylko singletony, abstrakcje, wzorce, DI, zależności, buildery, agregaty, encje, wrappery, wrappery wrapperów itp. itd.
Prawda @LukeJL. Problem wedlug mnie dotyka zwłaszcza dużych korporacji, w których tak naprawdę nikt nie jest pracodawcą...
Przypomniał mi się ten tekst Paula Grahama od razu: http://www.paulgraham.com/noop.html
Nie jestem krytykiem OOP jak on, ale nie unieważnia to pewnych jego spostrzeżeń.
Frag.:
Object-oriented programming is popular in big companies, because it suits the way they write software. [...]
Object-oriented programming generates a lot of what looks like work. Back in the days of fanfold, there was a type of programmer who would only put five or ten lines of code on a page, preceded by twenty lines of elaborately formatted comments. Object-oriented programming is like crack for these people [...] it is a good tool if you want to convince yourself, or someone else, that you are doing a lot of work.
Ja od siebie mogę dodać że, podczas rekrutacji zaprosiliśmy, robiliśmy duży przesiew CVłek. Jednego chłopaka zaprosiliśmy akurat dla tego że miał kilka projektów na githubie.
Nie jestem krytykiem OOP jak on,
Ja jestem zwolennikiem mieszania paradygmatów. Część projektu w OOP, część funkcyjnie, część na eventach, część proceduralnie. Projekt nie musi być pisany w jednolity sposób, bo często paradygmat, który się sprawdza do jakiejś części projektu nie zdaje egzaminu w innej części projektu (albo paradygmat, który się sprawdza jako ogólna architektura wysokiego poziomu niekoniecznie się sprawdzi do implementacji jakiegoś konkretnego ficzeru).
Taki jest chyba zresztą trend we współczesnych językach. Ale mam wrażenie że to już gruby OT :))
LukeJL napisał(a):
Oj, myślę, że w wielu firmach panuje wręcz kultura ciągłego "wyglądania na zajętych" bez realnych postępów. Choćby spotkania temu służą, żeby móc nic nie robić przez kilka godzin w tygodniu, a dalej wyglądać na bardzo zajętych.
Wiele projektów też cierpi na overengineering i nadmiar wzorców projektowych, które wyglądają ładnie i profesjonalnie a służą często tylko temu, żeby praca wolniej szła - przy przeinżynierowanym kodzie (bardzo często spotykanym przecież) często jest tak, że programiści siedzą, coś tam robią, tworzą jakieś klasy, modyfikują, ale nie widać żadnych efektów biznesowych, bo zmieniają się tylko singletony, abstrakcje, wzorce, DI, zależności, buildery, agregaty, encje, wrappery, wrappery wrapperów itp. itd.
sory że zwiększam OT, ale czy są firmy, w których jest mniejsza ilość programistów i kody pisanie w sposób bardziej naturalny, bez tego jak to ująłeś 'overengineeringu' ?
Według mnie warto wrzucać wszystkie projekty na GitHub, z czasem sam dojdziesz do wniosku, że to czego uczyłeś się na początku i co na początku nauki wrzuciłeś na GitHuba jakoś nie bardzo pasuje do zaawansowanych rzeczy jakie będziesz pisał i skasujesz stare projekty (m.in. ze względu na jakość kodu i wszelką ilość złych praktyk jakie się w nich znajdą podczas nauki) ;)
Autorze tematu, ja uważam, że to dobry pomysł. Będziesz wszystko miał w jednym miejscu i zawsze będziesz mógł do tego potem wrócić oraz nauczysz się pracować z GitHubem i potem będziesz mógł się pochwalić tym w CV. Tylko takie bardzo podstawowe rzeczy jak instrukcje warunkowe, pętle itd... możesz sobie odpuścić.
Poszukaj i pooglądaj jakieś repozytoria, bo zapewne pierwszą osobą, która na to wpadła nie jesteś :)