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.?
2
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...
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.
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.
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.
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.
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.
3
Pisanie dobrych testów dla swojego kodu IMO rozwija najbardziej.
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. :)
2
https://vimeo.com/71278954
Zdziwił mnie hejt na jave już w 97'
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ć :)