Przykład rzetelości w IT

"Jak zaprojektowałbyś eksperyment aby sprawdzić swoją tezę?" - gdyby każda prezentacja w naszej branży zaczynał się od takiego stwierdzenia, to świat byłby lepszy:)

Merytorycznie świetna prezentacja, nawet jeżeli nie interesujesz się wydajnością, to warto obejrzeć pierwsze 4 minuty jak wzorcowy przykład krytycznego myślenia (myślenia nad tym co się myśli?)
http://www.infoq.com/presentations/top-10-performance-myths

O empatii

Dziś pierwszy próbny post z kategorii "na miękko". Próbny, bo jeżeli znajdzie zainteresowanie, to będę wrzucał więcej tego typu tematyki.

Zewsząd słyszymy, że w naszej branży brakuje empatii - zarówno w relacjach między członkami zespołu jak i w relacjach naszych z tak zwanym "biznesem". (Być może jest to główny powód dla którego obiecujące metodyki prowadzenia projektów nie dają obiecanych rezultatów...)

Jeżeli się czegoś nie ma, to zwykle ciężko sobie uświadomić, że się tego nie ma:P
Więc co to jest?
Podczas "porannej" niedzielnej sesji riserczowej trafiłem na ciekawy artykuł: O empatii i jeszcze ciekawszy (bo napisany w "naszym" stylu) komentarz do niego:

"(...)mamy dwa rodzaje empatii. Kognitywna i emocjonalna. Czyli Jasiu wie, ze jak walnie Marysie po glowie lopatka to Marysi bedzie przykro, albo - Marysi jest przykro to Jasiowi tez sie robi przykro. Zazwyczaj mamy je obie. Dlatego nie walimy Marysi lopatka po glowie, bo wiemy ze wtedy Marysia placze i nam sie tez robi przykro. Oczywiscie jak juz dojrzejemy do posiadania empatii, co zajmuje jakies 3 lata

Psychopatom brakuje tej emocjonalnej - moga spokojnie patrzec na czyjas krzywde i ich to nie rusza. Kognitywna maja swietnie rozwinieta, dzieki temu wiedza co inni czuja i moga nimi manipulowac. To samo dotyczy osob narcystycznych, moze pojawiac sie w stanach dysocjacyjnych (np ostra reakcja na stres - czlowiek w momencie wypadku zamiast ratowac rannego pasazera zbiera swoje notatki z pobocza) W pewnym sensie rowniez schizofrenia i urazy glowy - platy czolowe.

Autystykom brakuje tej kognitywnej. Nie potrafia rozpoznac emocji u
innych, rowniez i u siebie. Niestety emocjonalnie "czuja" innych, nawet
jak nie potrafia tego nazwac, co czesto jest dla nich powodem stresu.(...)"

//=========================================

btw: drugi akapit jest szczególnie ważny w świetle głośnych badań sprzed 2 lat: 1 in 25 Business Leaders May Be Psychopaths - w skrótowym tekście link do badań.

Artykuł: Building Blocks dla Twojej lewej półkuli

Redaktor naukowy Iain Mcgilchrist w swej książce The Master and His Emissary (będącej podsumowaniem ostatnich 10 lat badań nad mózgiem) posłużył się wymowną metaforą lewej półkuli mózgu jako "salonu luster" - jeżeli wpadnie do niego promień światła, to będzie odbijał się w salonie po ustalonej przez ustawienie luster drodze, zawsze takiej samej.

Lewa półkula myśli indukcyjnie (nota bene: znana ze szkoły indukcja matematyczna jest rodzajem dedukcji:), posługując się "foremkami" na myśli. Tworzy ona narrację rzeczywistości używając tylko takich foremek jakie "zna".

Dlaczego piszę o tym w kontekście programowania?

Bo jeżeli jedyne foremki jakie zna nasza lewa półkula to serwis i anemiczna encja, to jest ona w stanie zamodelować cały świat serwisem i encją (rekordem i procedurą jeżeli wciąż programujesz w Turbo Pascalu lub strukturą i funkcją jeżeli w C).

Da się - wiem, bo tak robiłem:)

Jeżeli jedyna foremka jaką zna nasza półkula to Hashmapa, to wszystko będzie Hashmapą-hashmap:P

Lewa półkula jest również specjalistą w stworzeniu paranoi, że jest to najlepszy z możliwych modeli - bo mój (hmm ciekawe co neuro-naukowcy powiedzieliby na umiejscowienie ego w mózgu...).

Do tej pory wiele pisałem o Building Blocks z wachlarza technik DDD. Tym razem zapraszam do lektury artykułu, który jest poświęcony bardziej ogólnym BB, które można wyróżniać w każdym projekcie, nie stosując nawet DDD: "Building Blocks dla Twojej lewej półkuli: połączenia podejścia obiektowego, proceduralnego, funkcyjnego w codziennej pracy z kodem". Artykuł ukazał się w najnowszym wydaniu Programistamag.

Generalnie chodzi o to aby poszerzyć wachlarz "foremek" jakie stosuje nasza lew półkula do modelowania problemów. Dzięki temu modele staną się bardziej realistycznie (bez sztucznych ograniczeń) i giętkie.

Śmiech przez łzy #1

Pewien człowiek przeprowadził się na wieś aby rozkręcić tam interes. Dużo słyszał na salonach o tym, że "teraz wartość wejść w kury". Pozyskał zatem dofinansowanie i postawił wspaniałe kurniki przemysłowe oparte o najnowsze rozwiązania architektoniczne i wytyczne dostawców podsystemów, zastosował wszystkie modne metodyki (niektóre nawet dwa razy) i wdrożył frameworki hodowli oraz szyny dystrybucji paszy, zaczął nawet mówić do drobiu w najnowszych językach co chwilę wtrącając nawias wąsaty "{".

Pewnego dnia odwiedził go autochtoniczny sąsiad i zapytał: "Dlaczego zamiast jajek zbiera Pan gówna?"

Cytaty #2

"We have tried to demonstrate by these examples that it is almost always incorrect to begin decomposition of a system into modules on the basis of flowchart.

We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others."

David L Parns
"On the Criteria to Be Used in Decomposing Systems into Modules"
za: http://www.infoq.com/presentations/Architecture-Uncertainty - prezentacja jednego z moich ulubionych "filozofów oprogramowania", który dodaje później:
"Projektujemy wokół tego czego nie wiemy, ukrywamy niewiedzę, aby niewiedza nie była problemem"

Video z Confitury

Właśnie się zorientowałem, że od jakiegoś czasu dostępna jest moja prezentacja z tegorocznej Confitury: Model jest wszystkim czego potrzebujesz (w aplikacjach biznesowych) - czyli czego nauczyłem się podczas 6 lat praktykowania i nauczania DDD).

Cytaty #1

"People with strong technical backgrounds can covert any task into a technical task, thus avoiding work they don't want to do"

"By pretending the work is somehow abstracted from the people we can transform our interpersonal failure into a mechanical failure. It's much easier to say for example, 'We couldn't get the program working on time, than 'I wasn't skilled enough to help Jack become a better programmer'"

Te miażdżące cytaty pochodzą z książki: Becoming a Technical Leader: An Organic Problem-Solving Approach.