Wiecie jak wygląda krzywa uczenia? Uczycie się n godzin robiąc małe postępy, nagle jeden przykład, jedno przeczytane zdanie dotyczące tego, jedno wytłumaczenie i myk wszystko staje się banalne. Znacie takie tematy, których poznanie zmieniło wasze spojrzenie na programowanie, przeszliście na kolejny poziom abstrakcji itd.?
- Rejestracja:prawie 5 lat
- Ostatnio:3 dni
- Lokalizacja:Wrocław
- Postów:495
2
- Rejestracja:około 8 lat
- Ostatnio:około 5 godzin
- Postów:4882
3
https://mitpress.mit.edu/sites/default/files/sicp/index.html
https://www.amazon.com/Algorithms-Java-Parts-1-4-Pts-1-4/dp/0201361205
https://www.amazon.com/gp/product/0262220695
https://mitpress.mit.edu/sites/default/files/sicp/index.html - koszmary wróciły XD
:-D
Za Van Roya i Haridiego zawsze plus
- Rejestracja:prawie 5 lat
- Ostatnio:4 miesiące
- Postów:2420
5
Znacie takie tematy, których poznanie zmieniło wasze spojrzenie na programowanie, przeszliście na kolejny poziom abstrakcji itd.?
Nie znam, ale mogę Ci powiedzieć o jednym "Game changerze":
- Perfekcyjny, płynny angielski
Jeżeli będziesz mówił tak jak amerykanie lub jak bryton to respekt dla Ciebie +100.
PS. Jest jeszcze jeden, dobre kontakty na początku kariery, np. ojciec lub wujek którzy są dobrymi programistami na wysokich stanowiskach...
edytowany 3x, ostatnio: 99xmarcin
- Rejestracja:około 11 lat
- Ostatnio:25 minut
- Postów:8397
14
dla mnie to było:
-
pojęcie Proof of Concept / prototypowania. To, że nie trzeba robić od razu kodu produkcyjnego, a można sobie zrobić kod, żeby sprawdzić pewne podejście, a później wywalić ten kod i przepisać od nowa. Odkrycie, że programowanie jest procesem iteracyjnym, gdzie ciągle się zbiera wiedzę i weryfikuje założenia.
-
kontrola wersji (czyli de facto Git). Chociaż dalej zbyt mało wykorzystuję gałęzie i ogólnie mam wrażenie, że wykorzystuję kawałek mocy Gita. Jednak jest to cudowne, że można sobie wszystko cofnąć i mieć historię tego, co się działo.
-
Pisanie testów. Że zamiast ręcznie wszystko sprawdzać, czy działa, to się pisze testy i samo się testuje (chociaż nie wszędzie się tak da / jest sens automatycznie testować).
-
Odkrycie, że najlepszy kod to prosty kod (czasem nawet naiwny albo nie do końca elegancki), a nie taki, który zawiera od groma wzorców projektowych i różnych udziwnień i wygląda profesjonalnie, jednak ciężko go zrozumieć i utrzymywać .
-
Że większość programistów nie wie, co robi i ogólnie ma dość słabe umiejętności programowania, więc nie ma co mieć kompleksów na punkcie swoich umiejętności.
edytowany 1x, ostatnio: LukeJL
- Rejestracja:ponad 3 lata
- Ostatnio:około 3 lata
- Postów:29
3
Tak, rozwiązaniem jest zabawa.
Jeśli się bawisz tym co robisz to wtedy mniej się męczysz, jesteś wnikliwy, otwarty na alternatywy, próbujesz nie tylko rozwiązać problem, ale też łatwiej przychodzi Ci zrozumienie "przestrzeni" jaka w obrębie wybranego problemu występuje. Wtedy z czasem widzisz więcej, łatwiej idzie zmienić perspektywę, a w efekcie końcowym dochodzisz do lepszych pytań i wniosków.
edytowany 1x, ostatnio: fgh
- Rejestracja:około 7 lat
- Ostatnio:około godziny
- Postów:857
8
- Testowanie powinno symulować użycie kodu w produkcyjnym środowisku. Podział na unity/integracje jest słaby, bo nic nie wnosi, trzeba testować na czuja tak, żeby było jak najlepiej w zależności od wielu czynników takich jak czas/perspektywy rozwoju aplikacji/ograniczenia techniczne itd. . Testy powinny być proste z dobrze napisanymi helperami beż żadnych z
SetUp/TearDown: jak patrzę na funkcję testową i nie wiem co i jak testuje to popełniłem błąd - Kod piszemy dla ludzi: pisanie abstrakcyjnego kodu nie zawsze ma sens: najważniejsze to wczuć się w przyszłego programistę, który będzie musiał zrozumieć o co tu chodzi.
- Kod powinien być pisany tak, żeby osoba nieznająca technologi mogła nad nim pracować. Wszystko powinno być uproszczone do minimum a rozwiązania powinny być proste i idiotoodporne.
rozwiązania powinny być proste i idiotoodporne jeśli coś jest idiotoodporne wówczas już nie jest takie proste. To jest cena współpracy z idiotami.
- Rejestracja:prawie 10 lat
- Ostatnio:ponad 3 lata
- Lokalizacja:Warszawa
- Postów:59
5
- Scala i otwarcie oczy na programowanie funkcyjne
- Kod piszemy tak aby był jak najniższy próg wejścia dla nowych osób
- Zdarzają się seniorzy idioci. Przejdą każdą rozmowę kwalifikacyjną, ale powinno się ich wpuszczać do projektu.
Zobacz pozostałe 15 komentarzy
Podobnie Scala jest faktycznie dość ekspresywna, ale pod względem składni jest prostsza od javy
Co masz na myśli?
a w scali to raczej nieustannie podnosi się poprzeczkę, aby Ci nowi mieli trudniej - nie w przypadku ZIO :) - to jest bardzo przyjazne. Polecam.
Hmmm a czy grafik musi wiedziec jak dziala komputer zeby robic dobre grafiki, video? Interfejs jest prosty. A na pewno prostszy niz jakies transformatory monad i inne cuda wyciagniete z Haskella.
@0xmarcin: jest jak pisze @stivens - nie musisz wiedzieć jak działa, żeby móc korzystać. To nie spring. Ale jeśli CIe interesuje to w sumie proste wideo - jak zrobić swoje ZIO : https://www.youtube.com/watch?v=MSygEhqdsqs
- Rejestracja:ponad 8 lat
- Ostatnio:około 11 godzin
- Lokalizacja:U krasnoludów - pod górą
- Postów:4706
9
Na studiach wykładowca wytłumaczył mi, że programowanie nie polega na operacjach na bajtach i bitach. To był taki największy game changer.
Nigdy się nad tym nie zastanawiałem. Na czym polega?
@szafran98: na pisaniu programu, jeśli twoją dziedziną nie są bity i bajty (a przeważnie nie są - chyba, że programujesz system operacyjny) to powinieneś abstrahować od takich detali. W szczególności warto używać języka programowania, który cię od tego izoluje (tzw. pierdoły implementacyjne). Programy komputerowe mają sens i można je analizować nawet jeśli są napisane w języku programowania, który nie ma jeszcze kompilatora, lub nie istnieje jeszcze maszyna, która potrafi je wykonać.
o bitach i bajtach też trzeba myśleć, np. jak się wybiera typ bufora w grafice 3D xD
- Rejestracja:ponad 18 lat
- Ostatnio:3 dni
3
- Przejście na Linuksa, a co za tym idzie używanie powłoki i Vima.
- Umiejętne używanie gita (głównie chodzi o małe commity i
git reset --hard HEADkiedy się zamotam, ale też merge, rebase, bisect, a zwłaszcza przełącznik--patch) - Dobre pisanie testów (takich, które dokumentują, sprawią, ze myślę jak się będzie używać tego kodu i dzięki którym nie martwię się, że coś zepsuję)
- Programowaniu funkcyjne
- Zrozumienie, że wszystko sprowadza się do przepływu informacji z punktu A do punktu B, przez punkty pośrednie, a w każdym punkcie pośrednim mozna dodać jeszcze jeden.
- Lisp
przypuszczam, że w kolejce czeka Haskell, być może Idris. :)
edytowany 5x, ostatnio: elwis
Bardzo ładne punkty kolejne. Haskell to niestety gigantyczna kobyła. Zastanawiam się czy da się ten język hobbystyczne przerobić na tyle żeby moc z czystym sumieniem przejść do Idrisa. Czy jednak należy wdrożyć naukę równoległa
"(…) a w każdym punkcie pośrednim mozna dodać jeszcze jeden" – chyba "między punktami", a nie "w punkcie"?
Tak, ściśle ujmując tak.
- Rejestracja:ponad 8 lat
- Ostatnio:prawie 2 lata
- Postów:337
- Rejestracja:około 9 lat
- Ostatnio:około 2 godziny
- Postów:5105
2
przejście się na OI nie wiedząc nawet że ludzie jakieś książki czytają, przygotowują się do tego :D
5 lat czytania głupot na 4p na pewno na +, no cóż, niestety nie jest to jeden prosty "trik", a jeżeli chcesz, to może consistency?
legendarny talk Seligii na pewno na +
hn na pewno na +, bo przecież nie każda dyskusja musi mięć poziom jak na wykopie czy w komentarzach pod jakimś super expressem lub onetem, większe diversity of background/experience
przeglądanie prawdziwego kodu typu OSS, bo archytekty na forum jedno, a branża i prawdziwe projekty nierzadko drugie
fajny side project może dać naprawdę dużo, a jeżeli ktoś nie ma czasu, to nawet w dobrze zaplanowaną godzinkę da się dużo naklepać :)
edytowany 10x, ostatnio: WeiXiao
Zobacz pozostałe 3 komentarze
pandemia chyba sprawiła że 4p to bardziej forum polityczne :D
A, w rzeczy samej, jak się czyta wszystkie treści na forum, to tak. ;) Dla mnie mikroblogi są łatwiejsze w odbiorze niż Flame; ale może to niedobrze, że omijam niektóre treści, może idę po naj… po linii najmniejszego oporu…
nazwałbym to po prostu
intellectual hygiene
Ładne określenie. :)
"fajny side project może dać naprawdę dużo, a jeżeli ktoś nie ma czasu, to nawet w dobrze zaplanowaną godzinkę da się dużo naklepać" – dla mnie na przykład liczy się, by nie rozgrzebywać swoich projektów, a kończyć. Nie zawsze się da, więc po prostu patrzę, czy współczynnik "rozgrzebane"/"wszystkie" nie podchodzi zbyt blisko jedynki.
PerlMonkPerlMonk