001: Zajawki chwast.it

Obecne zajawki


01:08 - @peel opowiada o swoich eksperymentach z funkcyjnym podejściem do infrastruktury (nix, dhall) aby wyeliminować globalny stan
02:13 - @kubek2k po raz kolejny podchodzi do nauki Haskella aby móc czytać poważniejsze publikacje dotyczące programowania funkcyjnego. Oprócz tego uczy się elektroniki i niepochlebnie wypowiada się o AppleScript.
03:42 - @kwasniew stara się uczyć czegoś na front-endzie (CSS na głębszym poziomie), czegoś na back-endzie (Designing Data Intensive Applications) i czegoś wokół aspektów miękkich IT (research do studiów podyplomowych na AGH).


Poszukiwanie kolejnych zajawek


05:32 - @kubek2k poleca śledzić odpowiednie osoby na twitterze oraz chodzić na wykłady oderwane od naszej codziennej rzeczywistości
06:21 - @kwasniew korzysta z obecności ekspertów z którymi pracuje i uczy się tego do czego ma akurat dostęp w danej chwili. Oprócz tego stara się zrozumieć cały stos technologiczny aby unikać mikrooptymalizacji.
08:22 - @peel jako “failed scientist” poznaje technologie dokładniej niż tego potrzebuje czytając whitepapery. Również sama praca jest dla niego źródłem zajawek.


Lifehacki studiowania


10:21 - @kwasniew zaczyna naukę od najtrudniejszych rzeczy, zaplanowanych dzień wcześniej. Oprócz tego aplikuje limit tematów do nauki w toku. Tematy, które rozpoczyna stara się doprowadzać do poziomu nieświadomej kompetencji.
11:57 - @kwasniew mówi o szukaniu luk w technologiach, których się uczymy. Opowiada o swoich doświadczeniach z Elm gdzie problemem są czasy kompilacji dużych projektów i brakujące elementy języka.
13:04 - @peel opowiada o swoim artykule opisującym organizację środowiska pracy i wiedzy, aby unikać tinkeringu. Wypracowany przez niego workflow częściowo automatyzuje co, kiedy i jak się uczyć.
14:14 - @peel zdradza szczegóły swojego workflow: etap weryfikacji jakości i backgroundu materiału, skanowania treści i w końcu dokładnego zrozumienia.
15:40 - @kubek2k nie może się powstrzymać przed poznawaniem nowych rzeczy, które często później trzeba odrzucić
16:36 - @kubek2k bardziej ceni proces notowania niż same notatki
17:02 - @kubek2k kursy z deadlinami pomagają w systematycznej nauce
17:29 - @kubek2k aby w pełni się czegoś nauczyć trzeba to zastosować w praktyce np. w projektach open source
18:02 - dyskusja na temat kosztów utopionych. Tak jak korporacje trzymają się technologii, które zakupiły, tak my programiści kurczowo trzymamy się tego co już znamy. Jednym z narzędzi do radzenia sobie z tym błędem poznawczym jest przybranie perspektywy doradcy.


Co świadomie odrzucać


20:20 - @kwasniew opowiada o swojej diecie informacyjnej i technologiach do których nie chce wracać (JEE, Spring/Hibernate, full-stack frameworks)
20:53 - @kwasniew warto mieć system wartości do podejmowania decyzji technologicznych. W jego systemie są m.in: szanowanie tego jak działa sieć Web, szybki feedback od testów/kompilatora/serwera, proste mechanizmy języka (np. funkcje zamiast klas), nauczalność, brak magii
21:51 - @kwasniew heurystyki odrzucania na bazie systemu wartości. Czerwona lampka: adnotacje, this w JS, technologie klasy “enterprise”, wolny start serwera mierzony w sekundach
22:57 - @kubek2k w zupełnie nowej dziedzinie nie mamy punktu odniesienia i jesteśmy skazani na wiele nieudanych eksperymentów
23:46 - @kubek2k heurystyka - dobre CLI przy technologiach opsowych aby było łatwo automatyzować
24:18 - @kubek2k heurystyka - czy technologia używa uznanego nazewnictwa, czy rozwiązanie nie łamie teorii np. CAP theorem
25:03 - @peel sceptycznie obserwuje hype technologiczny, który często jest starymi rozwiązaniami opakowanymi w nowe nazwy. Podejrzliwie spogląda na technologie za którymi stoi za dużo pieniędzy
26:03 - @peel “least powerful abstraction” - dobieraj rozwiązania do swojej skali probl