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


  Agile Manifesto - http://agilemanifesto.org/
  Software Engineering NATO ‘68 - http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF
  Software Engineering Techniques NATO ‘69 - http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1969.PDF
  Tom DeMarco - Controlling Software Projects - https://www.amazon.com/Controlling-Software-Projects-Tom-DeMarco/dp/0917072324
  Tom DeMarco - Software Engineering: An Idea Whose Time Has Come and Gone? https://www.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf
  Fred George - Programmer Anarchy https://vimeo.com/43690647
  Mårten Gustafson - Bastardised Kanban https://speakerdeck.com/chids/bastardised-kanban
  Impact Mapping - https://www.impactmapping.org/
  Lean Startup - http://theleanstartup.com/principles
  Nicole Forsgren, Jez Humble - Accelerate https://itrevolution.com/book/accelerate/
  State of DevOps https://puppet.com/resources/whitepaper/state-of-devops-report
  Standish CHAOS Reports https://www.standishgroup.com/store/services/10-project-environmental-benchmarks.html
  XP http://www.extremeprogramming.org/


004: Agile

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.

Technology

Tech News

Podcasting

Gadgets

Software How-To

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


  Anjana Vakil - Programming Across Paradigms https://www.youtube.com/watch?v=Pg3UeB-5FdA
  Kyle Simpson - OO without classes. Why I don’t like JS classes https://github.com/getify/You-Dont-Know-JS/blob/master/this%20%26%20object%20prototypes/ch6.md
  Brian Lonsdorf - Oh Composable World! https://www.youtube.com/watch?v=SfWR3dKnFIo
  Alan Kay on OOP http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
  David Parnas - On the criteria to be used in decomposing systems into modules http://repository.cmu.edu/cgi/viewcontent.cgi?article=2979&context;=compsci
  William R. Cook - Object-Oriented Programming Versus Abstract Data Types http://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOPvsADT90.pdf
  William R. Cook - On understanding data abstraction, revisited. http://www.cs.utexas.edu/%7Ewcook/Drafts/2009/essay.pdf
  Jeremy Gibbons - Unfolding Abstract Data Types http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/adt.pdf
  Joe Armstrong - Why OO Sucks? http://harmful.cat-v.org/software/OO_programming/why_oo_sucks
  Yval Noah Harari - Sapiens: A brief history of humankind https://en.wikipedia.org/wiki/Sapiens:_A_Brief_History_of_Humankind
  “Pit of despair” - https://en.wikipedia.org/wiki/Pit_of_despair
  Data, Context, Interaction - https://en.wikipedia.org/wiki/Data,_context_and_interaction


003: Obiektowosc

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:

  Night Runner - Red Dawn
  Night Runner - Pale Rider
  Night Runner - Thunderbird


Linki


  Rise of the Expert Beginner: https://www.daedtech.com/how-software-groups-rot-legacy-of-the-expert-beginner
  How Software Groups Rot: https://www.daedtech.com/how-software-groups-rot-legacy-of-the-expert-beginner
  Etsy blameless culture: https://qz.com/504661/why-etsy-engineers-send-company-wide-emails-confessing-mistakes-they-made/
  Carol Dweck - Mindset: https://www.amazon.com/Mindset-Psychology-Carol-S-Dweck/dp/0345472322
  indeed.com - http://blog.indeed.com/2017/05/02/what-employers-think-about-coding-bootcamp/
  Mere-exposure effect: https://en.wikipedia.org/wiki/Mere-exposure_effect
  Can Newport - So Good They Can’t Ignore You: https://www.amazon.com/Good-They-Cant-Ignore-You/dp/1455509124


002: Poczatki

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


  Nix
    
      nix package manager: https://nixos.org/nix/
      nixos: https://nixos.org/
      disnix: https://nixos.org/disnix/
      nixops: https://nixos.org/nixops/
    
  
  Dhall: https://github.com/dhall-lang/dhall-lang
  Haskell:
    
      Future learn Haskell: https://www.futurelearn.com/courses/functional-programming-haskell/
      Learn You a Haskell for Great Good: http://learnyouahaskell.com/
    
  
  Kurs Elektroniki MT: http://mlodytechnik.pl/eksperymenty-i-zadania-szkolne/kursy/23909-praktyczny-kurs-elektroniki
  AppleScript (nie klikać, grozi uszkodzeniem mózgu): https://developer.apple.com/library/content/documentation/AppleScript/Conceptual/AppleScriptLangGuide/introduction/ASLR_intro.html
  CSS in Depth: https://www.manning.com/books/css-in-depth
  Designing Data Intensive Applications - Martin Klepmann: http://shop.oreilly.com/product/0636920032175.do
  Uncertified Scrum Master (http://business-management.pl/program/)
    
      Daniel Kahneman: https://www.amazon.com/Thinking-Fast-Slow-Daniel-Kahneman/dp/0374533555
      Anders Ericsson: https://www.amazon.com/Peak-Secrets-New-Science-Expertise/dp/0544456238
      Nicole Forsgren, Jez Humble: https://puppet.com/resources/whitepaper/state-of-devops-report
    
  


Źródła zajawek


  Stefan Tilkov: https://twitter.com/stilkov
  Brian Lonsdorf: https://twitter.com/drboolean
  Michael Fogus: https://twitter.com/fogus
  Konferencje z ciekawymi tematami:
    
      LambdaDays: http://www.lambdadays.org/
      Polyconf: https://polyconf.com/
      Strangeloop: https://www.thestrangeloop.com/
    
  
  Daniel Worthington-Bodart
    
      https://github.com/bodar
      talk o szybkich buildach https://www.infoq.com/presentations/Crazy-Fast-Build-Times-or-When-10-Seconds-Starts-to-Make-You-Nervous
    
  
  Artykuł Piotrka o czytaniu whitepaperów https://codearsonist.com/reading-for-programmers
  Coursera: https://www.coursera.org
  Future Learn: https://www.futurelearn.com
  Koszty utopione: https://en.wikipedia.org/wiki/Sunk_cost


Heurystyki


  List Edsgera W. Dijkstry do Rady Budżetowej University of Texas (a nie MIT jak to było powiedziane w podcaście) w sprawie zmiany Haskella na Javę http://chrisdone.com/posts/dijkstra-haskell-java


004: Agile

Download our free app to listen on your phone