chwast.it chwast.it

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/

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

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

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