chwast.it https://chwast.it Najgorszy podcast programistyczny w Polsce. Niezobowiązująco, nieznośnie i prawdopodobnie lekceważąco o szeroko pojętej inżynierii oprogramowania opowiadają: @kwasniew - wielki fan sieci Web i prostych (niekoniecznie popularnych) rozwiązań. Zwolennik odnajdywania oryginalnych problemów zamiast naprawiania symptomów. Programista, speaker, trener. @kubek2k - pomysłodawca całego zamieszania. Developer praktykujący programistyczny szamanizm. Szczerze niewierzacy agilista. Ostatnio nie mamy z nim kontaktu, więc pewnie popełnia kolejny refactoring. @peel - señor code arsonist. Praktyk, teoretyk i teolog programowania funkcyjnego. Speaker, maker, miłośnik poprawiania tych drobnych rzeczy, które irytują. Wróg złych rozwiązań. Prawdopodobnie nie raz mu się naraziliście. Czarownik evil-mode. Mon, 05 Nov 2018 18:43:33 +0000 en-US hourly 1 http://jekyllrb.com Najgorszy podcast programistyczny w Polsce. Niezobowiązująco, nieznośnie i prawdopodobnie lekceważąco o szeroko pojętej inżynierii oprogramowania opowiadają: @kwasniew - wielki fan sieci Web i prostych (niekoniecznie popularnych) rozwiązań. Zwolennik odnajdywania oryginalnych problemów zamiast naprawiania symptomów. Programista, speaker, trener. @kubek2k - pomysłodawca całego zamieszania. Developer praktykujący programistyczny szamanizm. Szczerze niewierzacy agilista. Ostatnio nie mamy z nim kontaktu, więc pewnie popełnia kolejny refactoring. @peel - señor code arsonist. Praktyk, teoretyk i teolog programowania funkcyjnego. Speaker, maker, miłośnik poprawiania tych drobnych rzeczy, które irytują. Wróg złych rozwiązań. Prawdopodobnie nie raz mu się naraziliście. Czarownik evil-mode. chwast.it no peel+podcast@coderasonist.com (chwast.it) Najgorszy podcast programistyczny w Polsce. Niezobowiązująco, nieznośnie i prawdopodobnie lekceważąco o szeroko pojętej inżynierii oprogramowania opowiadają: @kwasniew - wielki fan sieci Web i prostych (niekoniecznie popularnych) rozwiązań. Zwolennik odna chwast.it https://chwast.it/img/albumart.jpg https://chwast.it podcast@coderasonist.com 004: Agile https://chwast.it/004-agile https://chwast.it/004-agile#comments Sun, 22 Jul 2018 00:00:00 +0000 https://chwast.it/2269cc9e-f8a0-4463-88a2-a2cca10e12f7 18 lat Agile
  • 00:39 - @kwasniew co nas boli w Agile?
  • 01:23 - @kubek2k płacze czytając manifest
  • 02:52 - @peel o kole zatoczonym przez metodyki i ‘68 NATO Software Engineering Conference
  • 05:07 - @peel Tom DeMarco i rewizja kontroli projektów
  • 05:52 - @kwasniew mówi o pierwszym dniu w projekcie i nowych nazwach spotkań
  • 07:35 - @kwasniew o Agile Coachach
  • 08:37 - @peel pyta o przebranżowienie niemodnych Project Managerów
  • 09:14 - @kwasniew o certyfikacji

Co czerpać a co olać

  • 11:20 - @kubek2k o nerkach predatora i robieniu co trzeba
  • 13:11 - @kubek2k scrum to metodyka radzenia sobie z problemami a nie rozwijania softu
  • 14:12 - @peel o metrykach, dowożeniu jakiegoś produktu a nie rozwiązywanie problemów
  • 18:02 - @kwasniew o tym co mierzyć i śledzić
  • 21:26 - @kwasniew płynie o psychologii
  • 22:48 - @peel o liczbach i przepalonych milionach euro
  • 24:39 - @kwasniew o usuwaniu warstw pośrednich
  • 25:53 - @kubek2k scrum promuje underachieversow

Huby (bracket funguses)

  • 26:05 - @kwasniew od liderach
  • 27:06 - @peel o hubach
  • 28:02 - @kubek2k co zrobić kiedy utknąłeś
  • 28:21 - @peel o dzieleniu się wiedzą
  • 29:43 - @kwasniew zawijać się do mniej ‘tradycyjnie’ zarządzanego projektu
  • 30:19 - @kubek2k tradycyjne projekty umierają

Call to Action

  • 30:47 - @peel: impact, pomiary, komunikacja
  • 31:31 - @kubek2k o ratowaniu kotków

Linki

]]> 18 lat Agile
  • 00:39 - @kwasniew co nas boli w Agile?
  • 01:23 - @kubek2k płacze czytając manifest
  • 02:52 - @peel o kole zatoczonym przez metodyki i ‘68 NATO Software Engineering Conference
  • 05:07 - @peel Tom DeMarco i rewizja kontroli projektów
  • 05:52 - @kwasniew mówi o pierwszym dniu w projekcie i nowych nazwach spotkań
  • 07:35 - @kwasniew o Agile Coachach
  • 08:37 - @peel pyta o przebranżowienie niemodnych Project Managerów
  • 09:14 - @kwasniew o certyfikacji

Co czerpać a co olać

  • 11:20 - @kubek2k o nerkach predatora i robieniu co trzeba
  • 13:11 - @kubek2k scrum to metodyka radzenia sobie z problemami a nie rozwijania softu
  • 14:12 - @peel o metrykach, dowożeniu jakiegoś produktu a nie rozwiązywanie problemów
  • 18:02 - @kwasniew o tym co mierzyć i śledzić
  • 21:26 - @kwasniew płynie o psychologii
  • 22:48 - @peel o liczbach i przepalonych milionach euro
  • 24:39 - @kwasniew o usuwaniu warstw pośrednich
  • 25:53 - @kubek2k scrum promuje underachieversow

Huby (bracket funguses)

  • 26:05 - @kwasniew od liderach
  • 27:06 - @peel o hubach
  • 28:02 - @kubek2k co zrobić kiedy utknąłeś
  • 28:21 - @peel o dzieleniu się wiedzą
  • 29:43 - @kwasniew zawijać się do mniej ‘tradycyjnie’ zarządzanego projektu
  • 30:19 - @kubek2k tradycyjne projekty umierają

Call to Action

  • 30:47 - @peel: impact, pomiary, komunikacja
  • 31:31 - @kubek2k o ratowaniu kotków

Linki

]]> chwast.it false 33:05 panel, panel, agile 003: Obiektowosc https://chwast.it/003-obiektowosc https://chwast.it/003-obiektowosc#comments Sat, 23 Jun 2018 00:00:00 +0000 https://chwast.it/e9d3bcd5-2aa3-4472-bca6-24a2a400140f OOP OCB?
  • 00:55 - @kubek2k pyta o to jak rozumiemy OO
  • 01:18 - @kwasniew wyjaśnia co to w ogóle jest paradygmat
  • 02:05 - dla @kwasniew OO to “stan i zachowanie które wspólnie podrożują sobie w czasie”
  • 03:02 - @peel narzeka na Alana Kaya który do tej pory nie może dojść do ostatecznej definicji OO
  • 03:45 - @peel nawiązuje do definicji zespolu Barbary Liskov: “abstrakcje są sumą obserwacji i reprezentacji”
  • 05:03 - @kubek2k nawizuje do procesu myślowego Alana Kaya i historii definicji OO opisanej na c2 wiki
  • 06:32 - @kubek2k opisuje swoja wymarzoną definicję OO
  • 07:30 - @kubek2k opisuje idee DCI jako (teoretycznie) to o czym rzeczywiście myslał Alan Kay wg Jamesa Copliena

Plusy i Minusy

  • 09:05 - @kubek2k pyta o plusy i minusy OO
  • 09:26 - @kwasniew zwraca uwage na popularność OO w kontekście “zbiorowego mitu”
  • 10:26 - @kwasniew o tym, że OO prowadzi to skomplikowanych konstruktów językowych
  • 11:12 - @peel nawiązuje do COM - “wysoka reużywalność kodu” i “łatwość uczenia się”
  • 12:28 - @peel mówi o mieszaniu modelu abstract data types z algebraic data types
  • 14:15 - @peel mówi o trudnościach w zrozumieniu cudzego kodu z powodu braku weryfikowalności w OO
  • 15:00 - @peel “interfejsy nie wymuszaja wystarczająco odpowiedniego zachowania”
  • 15:53 - @peel o wąskim spektrum idealnych zastosowań OO
  • 16:14 - @kubek2k zwraca uwage na to, iż OO w czasach powstawania było “krokiem naprzód” w Przemyślu IT
  • 16:48 - @kubek2k o braku sensownego mechanizmu wyrażania interakcji między obiektami
  • 18:10 - @peel wcina się “bez trybu” ze schedami kulturowymi w Przemyślu IT

Praktyczne OOP vs Reszta Swiata

  • 20:12 - @kubek2k o OOP w Przemyślu
  • 21:00 - @kwasniew o możliwosci życia bez “thisa”
  • 21:50 - @kwasniew o prostych, ale wystarczających feature’ach językowych
  • 22:40 - chorwaccy kibice świetują remis Brazylii
  • 23:15 - @peel po raz trzeci o ADT
  • 24:12 - @kubek2k o konieczności zaglądania poza własną bańkę technologiczną

Linki

]]> OOP OCB?
  • 00:55 - @kubek2k pyta o to jak rozumiemy OO
  • 01:18 - @kwasniew wyjaśnia co to w ogóle jest paradygmat
  • 02:05 - dla @kwasniew OO to “stan i zachowanie które wspólnie podrożują sobie w czasie”
  • 03:02 - @peel narzeka na Alana Kaya który do tej pory nie może dojść do ostatecznej definicji OO
  • 03:45 - @peel nawiązuje do definicji zespolu Barbary Liskov: “abstrakcje są sumą obserwacji i reprezentacji”
  • 05:03 - @kubek2k nawizuje do procesu myślowego Alana Kaya i historii definicji OO opisanej na c2 wiki
  • 06:32 - @kubek2k opisuje swoja wymarzoną definicję OO
  • 07:30 - @kubek2k opisuje idee DCI jako (teoretycznie) to o czym rzeczywiście myslał Alan Kay wg Jamesa Copliena

Plusy i Minusy

  • 09:05 - @kubek2k pyta o plusy i minusy OO
  • 09:26 - @kwasniew zwraca uwage na popularność OO w kontekście “zbiorowego mitu”
  • 10:26 - @kwasniew o tym, że OO prowadzi to skomplikowanych konstruktów językowych
  • 11:12 - @peel nawiązuje do COM - “wysoka reużywalność kodu” i “łatwość uczenia się”
  • 12:28 - @peel mówi o mieszaniu modelu abstract data types z algebraic data types
  • 14:15 - @peel mówi o trudnościach w zrozumieniu cudzego kodu z powodu braku weryfikowalności w OO
  • 15:00 - @peel “interfejsy nie wymuszaja wystarczająco odpowiedniego zachowania”
  • 15:53 - @peel o wąskim spektrum idealnych zastosowań OO
  • 16:14 - @kubek2k zwraca uwage na to, iż OO w czasach powstawania było “krokiem naprzód” w Przemyślu IT
  • 16:48 - @kubek2k o braku sensownego mechanizmu wyrażania interakcji między obiektami
  • 18:10 - @peel wcina się “bez trybu” ze schedami kulturowymi w Przemyślu IT

Praktyczne OOP vs Reszta Swiata

  • 20:12 - @kubek2k o OOP w Przemyślu
  • 21:00 - @kwasniew o możliwosci życia bez “thisa”
  • 21:50 - @kwasniew o prostych, ale wystarczających feature’ach językowych
  • 22:40 - chorwaccy kibice świetują remis Brazylii
  • 23:15 - @peel po raz trzeci o ADT
  • 24:12 - @kubek2k o konieczności zaglądania poza własną bańkę technologiczną

Linki

]]> chwast.it false 26:06 panel, panel, obiektowosc 002: Poczatki https://chwast.it/002-poczatki https://chwast.it/002-poczatki#comments Mon, 04 Dec 2017 00:00:00 +0000 https://chwast.it/a22346e4-dc92-41da-b59f-6b65473e9117 Wywiad z Marcinem Milasem - absolwentem bootcampu
  • 01:25 - Marcin opowiada skąd wziął się pomysł na bootcamp z programowania na frontendzie
  • 03:40 - obawy i motywacja związane z porzuceniem poprzedniej pracy w innej branży
  • 05:11 - jak się czuje programista rok po bootcampie
  • 06:36 - proces rekrutacji i prework - czyli początkowy etap bootcampu
  • 09:13 - jak wygląda dzień uczestnika bootcampu w wersji stacjonarnej
  • 11:13 - poszukiwanie pracy i rozmowy rekrutacyjne
  • 13:46 - obawy odnośnie pierwszej pracy
  • 15:38 - jak wygląda dalszy rozwój zawodowy Marcina
  • 27:22 - czy warto było pójść tą drogą?
  • 28:32 - nie warto się spieszyć
  • 29:13 - podejście do wykładowców na bootcampie
  • 29:43 - szkoły internetowe
  • 30:19 - jak szkoły programowania wspierają studentów po kursie

Wywiad z Bartoszem Cytrowskim - trenerem

  • 36:54 - @cytrowski kto przychodzi na bootcampy
  • 37:24 - @cytrowski potrzebny jest trener prowadzący
  • 38:06 - @cytrowski brakuje dobrych trenerów
  • 38:31 - @cytrowski przygotowanie kursantów do bootcampu
  • 39:01 - @cytrowski rola pracy zespołowej podczas bootcampu
  • 39:43 - @cytrowski systematyczność jest ważna
  • 40:19 - @cytrowski opory przed zadawaniem pytań i popełnianiem błędów

Dyskusja na temat przyjmowania nowych pracowników

  • 18:09 - @kubek2k rola seniora w relacji z juniorem
  • 19:17 - @kwasniew model Dreyfus Squared/Matrix. Jak świadomie dobierać pracowników w efektywne pary.
  • 21:09 - @kwasniew model nauki z perspektywy nowicjusza
  • 21:46 - @peel problem tzw. expert beginners
  • 22:20 - @kwasniew przyjmowanie ludzi do pracy to nie może być przykry obowiązek
  • 23:08 - @kwasniew hierarchia potrzeb Maslowa w kontekście programowania i rola budowania poczucia bezpieczeństwa
  • 24:20 - @kubek2k instytucja Buddyego
  • 24:47 - @kwasniew podział instytucji Buddyego w ramach ekspertyzy poszczególnych członków zespołu
  • 25:41 - @kwasniew kultura bezpieczeństwa w Etsy - przyzwolenie na popełnianie błędow
  • 31:50 - @kubek2k odpowiedzialność nowej osoby
  • 32:10 - @kwasniew nastawienie na rozwój vs nastawienie na trwałość
  • 33:51 - @peel badania dla indeed.com: bootcampy vs studia
  • 34:50 - @peel brak roli programisty domenowego
  • 35:43 - @kubek2k data scientist to poniekąd programista domenowy
  • 41:27 - @kubek2k jak wykorzystać wiedzę osób z innej branży
  • 43:04 - @kwasniew “mere exposure effect” w kontekście programowania
  • 45:22 - @kwasniew mit pasji
  • 48:02 - @kwasniew mainstream jest dobry na początek
  • 48:30 - @kubek2k różnica w barierach wejścia w technologie

Muzyka

W odcinku, za pozwoleniem artystów wykorzystano:

Linki

]]> Wywiad z Marcinem Milasem - absolwentem bootcampu
  • 01:25 - Marcin opowiada skąd wziął się pomysł na bootcamp z programowania na frontendzie
  • 03:40 - obawy i motywacja związane z porzuceniem poprzedniej pracy w innej branży
  • 05:11 - jak się czuje programista rok po bootcampie
  • 06:36 - proces rekrutacji i prework - czyli początkowy etap bootcampu
  • 09:13 - jak wygląda dzień uczestnika bootcampu w wersji stacjonarnej
  • 11:13 - poszukiwanie pracy i rozmowy rekrutacyjne
  • 13:46 - obawy odnośnie pierwszej pracy
  • 15:38 - jak wygląda dalszy rozwój zawodowy Marcina
  • 27:22 - czy warto było pójść tą drogą?
  • 28:32 - nie warto się spieszyć
  • 29:13 - podejście do wykładowców na bootcampie
  • 29:43 - szkoły internetowe
  • 30:19 - jak szkoły programowania wspierają studentów po kursie

Wywiad z Bartoszem Cytrowskim - trenerem

  • 36:54 - @cytrowski kto przychodzi na bootcampy
  • 37:24 - @cytrowski potrzebny jest trener prowadzący
  • 38:06 - @cytrowski brakuje dobrych trenerów
  • 38:31 - @cytrowski przygotowanie kursantów do bootcampu
  • 39:01 - @cytrowski rola pracy zespołowej podczas bootcampu
  • 39:43 - @cytrowski systematyczność jest ważna
  • 40:19 - @cytrowski opory przed zadawaniem pytań i popełnianiem błędów

Dyskusja na temat przyjmowania nowych pracowników

  • 18:09 - @kubek2k rola seniora w relacji z juniorem
  • 19:17 - @kwasniew model Dreyfus Squared/Matrix. Jak świadomie dobierać pracowników w efektywne pary.
  • 21:09 - @kwasniew model nauki z perspektywy nowicjusza
  • 21:46 - @peel problem tzw. expert beginners
  • 22:20 - @kwasniew przyjmowanie ludzi do pracy to nie może być przykry obowiązek
  • 23:08 - @kwasniew hierarchia potrzeb Maslowa w kontekście programowania i rola budowania poczucia bezpieczeństwa
  • 24:20 - @kubek2k instytucja Buddyego
  • 24:47 - @kwasniew podział instytucji Buddyego w ramach ekspertyzy poszczególnych członków zespołu
  • 25:41 - @kwasniew kultura bezpieczeństwa w Etsy - przyzwolenie na popełnianie błędow
  • 31:50 - @kubek2k odpowiedzialność nowej osoby
  • 32:10 - @kwasniew nastawienie na rozwój vs nastawienie na trwałość
  • 33:51 - @peel badania dla indeed.com: bootcampy vs studia
  • 34:50 - @peel brak roli programisty domenowego
  • 35:43 - @kubek2k data scientist to poniekąd programista domenowy
  • 41:27 - @kubek2k jak wykorzystać wiedzę osób z innej branży
  • 43:04 - @kwasniew “mere exposure effect” w kontekście programowania
  • 45:22 - @kwasniew mit pasji
  • 48:02 - @kwasniew mainstream jest dobry na początek
  • 48:30 - @kubek2k różnica w barierach wejścia w technologie

Muzyka

W odcinku, za pozwoleniem artystów wykorzystano:

Linki

]]> chwast.it false 50:00 reportaz, panel, reportaz, poczatki 001: Zajawki https://chwast.it/001-zajawki https://chwast.it/001-zajawki#comments Sun, 29 Oct 2017 00:00:00 +0000 https://chwast.it/b89b958a-d206-4ace-b61c-5b2e7856ec56 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 problemu i adaptuj gdy trzeba

Dyskusja końcowa

  • 26:49 - dyskusja na temat krytykowania. W naszej kulturze lubimy narzekać. Z drugiej strony warto wzbogacić krytykę przekazem pozytywnym. Robienie małych kroków (kaizen) czasami nie wystarczy.
  • 28:14 - dyskusja dotycząca zmiany podejścia do nauki przez pryzmat doświadczenia. Zaczynamy od szybkich zwycięstw, a z czasem zależy nam dogłębnym zrozumieniu.
  • 30:40 - @kubek2k preferuje aby szkoły wyższe uczyły niepraktycznych rzeczy i poszerzały horyzonty dotyczące fundamentów programowania. Później łatwiej zrozumieć całą nadbudowę.

Linki

Aktualne zajawki

Źródła zajawek

Heurystyki

]]> 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 problemu i adaptuj gdy trzeba

Dyskusja końcowa

  • 26:49 - dyskusja na temat krytykowania. W naszej kulturze lubimy narzekać. Z drugiej strony warto wzbogacić krytykę przekazem pozytywnym. Robienie małych kroków (kaizen) czasami nie wystarczy.
  • 28:14 - dyskusja dotycząca zmiany podejścia do nauki przez pryzmat doświadczenia. Zaczynamy od szybkich zwycięstw, a z czasem zależy nam dogłębnym zrozumieniu.
  • 30:40 - @kubek2k preferuje aby szkoły wyższe uczyły niepraktycznych rzeczy i poszerzały horyzonty dotyczące fundamentów programowania. Później łatwiej zrozumieć całą nadbudowę.

Linki

Aktualne zajawki

Źródła zajawek

Heurystyki

]]> chwast.it false 32:24 panel, panel, zajawki