środa, 7 stycznia 2015

HR - jak robi to Google

Problem

Sytuacja na rynku pracy jest taka sama zarówno w dużym, średnim jak i małym mieście, czyli:
  • nie dość, że ciężko znaleźć nowych ludzi
  • to tracimy już posiadane talenty (skill można zbudować, talentu nie)
  • na uczelniach mamy dziwną sytuację: kilka procent "geniuszy" (tacy są zawsze) oraz "mało ambitna" reszta, zniknął główny składnik, czyli "średni", którzy w odpowiednich warunkach w pracy staną się "dobrzy"
  • musimy zatem zatrudniać każdego, kto podczas rekrutacji nie nabawił się kontuzji w starciu z klawiaturą
  • do tego bardzo niewielu pracowników rozwija się we własnym zakresie "w domu"
  • brakuje osobowości Lidera Technicznego (nie managera), który pokazały innym kierunek a oni w naturalny sposób podążyliby za nim
  • wydaje się, że nie można mieć osobowości lidera i eksperta IT w jednej osobie
  • pracownicy mimo dostępu do "opcji rozwoju" nie korzystają z nich
  • karnet na "basen" jakoś nie działa
  • nie za bardzo wiadomo o co chodzi tym programistom gdy marudzą coś o "wielkiej kupie błota" - przecież zewnętrzna firma sprząta codziennie
  • ok, już wiemy, ale co zrobić, skoro specjalizujemy się w remontach i utrzymaniu...
  • ...

Google - wersja basic

W ciągu całej "przerwy świątecznej" oglądałem namiętnie prezentacje odbywające się w ramach Google Tech Talk. Konwencja jest taka, że pracownicy firmy wybierają sobie ciekawe osoby grasujące "na wolności" (naukowcy, dietetycy, trenerzy, mnisi,...) aby przeprowadzili wewnętrzną prezentację/warsztat w zakresie bardzo szeroko rozumianego rozwoju osobistego.

Oto kilka przykładów, które warto obejrzeć choćby z czystej ciekawości:

Google - wersja premium

Na osobną uwagę zasługuje to wystąpienie: https://www.youtube.com/watch?v=MGfhQTbcqmA
Autor książki, która technicznie i kompleksowo podchodzi do problemu "szczęścia" w pracy: http://www.amazon.com/Neuroscience-Personality-Brain-Insights-People/dp/0979868475

Dzięki EEG (warsztaty dla pracowników Google po prezentacji) jest w stanie "zdiagnozować" jaki rodzaj aktywności wprawia danego programistę/programistkę we flow - stan całkowitego zaangażowania w zadanie.

Mam pewną hipotezę: najlepsi programiści z jakimi rozmawiam zwykle odpowiadają tak samo na pytanie "dlaczego zająłeś się programowaniem?" - "dlatego, że w pewnym momencie (szkoła/studia) dawało mi to wejście we flow". Niestety w komercyjnym programowaniu prędzej czy później trafiamy na projekt, gdzie flow nie pojawia się przez kolejne miesiące... Mózg uczy się nowej zasady: programowanie nie daje już dopaminy - i mamy tak zwane "wypalenie". Wracaj zatem do stanu flow raz na kilka tygodni a "wypalenie" nigdy nie wystąpi. Heh, pytanie tylko jak? Dwa linki wyżej:P

Google - wersja max

Inny ciekawy przykład: zespół, który opracował Prediction API (kilka algorytmów maszynowego uczenia ukrytych pod arcy prostym REST API) https://www.youtube.com/watch?v=FJDP_0Mrb-w

Zespół może pokazać się światu, pokazać swoje dzieło osobiście (zwróćcie uwagę na błysk w oku gdy mówią o rynku handlu modelami predykcji), pokazać się obok producenta samochodów, który już zapowiada korzystanie z ich dzieła. Czy jakaś podwyżka lub "karnet na siłkę" są w stanie przebić tę chwilę?

A co jeżeli nie pracuję w Google?

Jeżeli powyższe jest tym czego szukasz dla siebie/swoich ludzi to zastanawiasz się pewnie czy w Polsce dałoby się zorganizować coś podobnego...

Zgromadziłem grupę ciekawych ludzi z różnych ścieżek rozwojowych ale w pewnym sensie podobnych do siebie i mam pomysł na na razie eksperymentalną wersję projektu. Jeżeli chcesz spróbować w swojej organizacji/zespole to zapraszam do kontaktu prv: slawomir.sobotka (w domenie) bottega.com.pl

piątek, 19 grudnia 2014

Video z prezentacji na JDD 2014: JPA i DDD

Mapowanie relacyjnono-obiektowe prawdziwych obiektów.

Slajdy: http://prezi.com/fsvd1xnvecff/mapowanie-relacyjno-obiektowe-prawdziwych-obiektow/

Główne tezy:
  • nie używaj lazy loadingu
  • uważaj na typ kolekcji
  • rozważ 3 sposoby optimistic locking
  • wzorzec Repository ma więcej sensu się wydaje
  • CQRS na ratunek

...a tu więcej do poczytania: http://bottega.com.pl/artykuly-i-prezentacje






Jak wciągnąć eksperta domenowego w wir modelowania


Główne tezy:
  • Model jest narzędziem komunikacji
  • Przydawki są ważne:)
  • Można myśleć funkcyjnie i programować obiektowo
  • Proces jest pochodną domeny
  • User story jest słabe - potrzebujesz domain story
  • Refaktoryzacja bez zrozumienia domeny jest zgubna






wtorek, 9 grudnia 2014

poniedziałek, 1 grudnia 2014

Devtalk i konkurs

W drodze do pracy możesz posłuchać Devtalków prowadzonych przez Macieja Aniserowicza.
W tym ostatniej publikacji - rozmowy na temat DDD: 04 – O DOMAIN DRIVEN DESIGN ZE SŁAWOMIREM SOBÓTKĄ

Przy okazji rozpisaliśmy mały konkurs (szczegóły w linku) - do wygrania jest książka: Implementing DDD, która czeka już u mnie w domu na zwycięzcę.

Książkę polecam każdemu - nie tylko zainteresowanym tematyką DDD. Można znaleźć w niej syntezę najnowszych trendów architektonicznych i technik programistycznych. Autora poznałem osobiście - zdradził, że książkę oddał do "wygładzenia" autorom serii Head First (którą pewnie wszyscy znają).

środa, 15 października 2014

Relacja z JDD

Do tej pory nie pisałem relacji z konferencji, na których bywam, bo myślałem, że relacji jest tak wiele, że kolejna nic nie wniesie.

Okazało się, że tak było kiedyś... Tradycja relacjonowania zanika w narodzie, zatem pomyślałem, że ją podtrzymam - szczególnie, że tym razem każda prezentacja jaką wybrałem (niestety tylko pierwszego dnia) była wartościowa merytorycznie i świetnie poprowadzona.

Zachęcam do poświęcenia kilku godzin gdy tylko video z konferencji pojawi się na YT.
A póki co mam dla Was slajdy, które zebrałem do prelegentów.


10 THINGS I’D TELL MY YOUNGER SELF ABOUT (JAVA) WEB DEVELOPMENT 

Dykcja, fason, styl...
Historia opowiedziana po mistrzowsku od strony retorycznej: CV Mateusza sprzed 10 lat, wspomnienia technicznych decyzji jakich dokonywał (jak się okazuje) nieświadomie. Piękny przekaz dla młodszych programistów - macie szansę uniknąć błędów jaki my popełniliśmy.

A merytorycznie dużo, dużo mięcha:
  • czym kierować się wybierając framaework webowy i silnik szablonów - nie odcinaj się od HTTP - gdy będziesz chciał/chciała zrobić coś poważnego poczuje ból braku dostępu do "metalu"
  • czy Twój framework webowy i silnik szablonów da się testować wprost?
  • kiedy node.js (ogólnie event looop) ma sens a kiedy nie - masz do czynienia z High IO czy High CPU?
  • kontenery DI - odróżniaj składanie obiektów od zasięgów, to osobne klasy problemów. A tak poza tym od zasięgów są nawiasy w Javie:P
  • loguj na std.out - system operacyjny najlepiej zajmie się IO
  • adnotacje są jak łupież - w sumie Cię nie zabiją, ale brzydko to wygląda (mistrz!)
  • do tego masa przykładów eleganckich, małych bibliotek, które robią jedną rzecz i robią to dobrze - możesz z nich poskładać własny stos
Generalnie masa doświadczenia wyniesionego wprost od konsultantów ThoughtWorks.
Człowiek, który programuje z Mateuszem, to musi być szczęśliwy człowiek


W slajdach znajdziecie masę wartościowych informacji: http://www.slideshare.net/kwasniew/10-things-id-tell-my-younger-self-about-java-web-development


"Jak wprowadzić DDD w naszym smutnym projekcie" - często słyszę takie pytanie na szkoleniach... Jest to często problem na poziomie strategii organizacji - w jakim kierunki chce podążać i jak chce kreować swój proces wytwórczy.

Piotrek w przejrzysty sposób pokazał przecięcie 2 aspektów:

  • wspomnianej strategii organizacji
  • technicznych rozwiązań opartych o architekturę Ports&Adapters
jako 4 podejścia architektoniczne.

Ciekawy był również wstęp do DDD - Piotrek podszedł od strony Strategic Design. Sam zawsze obawiałem się mówić od tej strony o DDD na  konferencjach, bo wydaje mi się zbyt abstrakcyjna dla programujących odbiorców, ale w wydaniu Piotrka wyszło fajnie:)

Prezentacja w Prezi (choć wygląda jak zaimportowana z power pointa;P) http://prezi.com/y_1raovqqxc4/using-domain-driven-design-in-legacy-systems/



JEE'ISH DEVELOPMENT WITHOUT HASSLE

Po prostu mistrz sarkazmu:)
Aż zacytuję: "Używamy Spring Boot i jesteśmy lightweight".

Fajny dystans do narzędzi i podejść... generalnie przesłanie: czy na pewno potrzebujesz armaty na muchę?

W prezentacji znajdziecie polecane biblioteki, które w lekki sposób zastępują ciężkie działa. Jest tam również link do kodu - kilku projektów, które implementują TODO list przy pomocy różnych zestawów narzędzi.

Prezentacja: https://speakerdeck.com/kubamarchwicki/jee-without-hassle-pl



WHAT YOU WON'T READ IN BOOKS ABOUT IMPLEMENTING REST SERVICES

Jak zrobić świetną prezentację? Proste: wziąć sexi temat, potraktować od nietrywialnej strony i poprowadzić przez Kubę Kubryńskiego:)

Jeśli wydaje Ci się, że robisz REST, to zajrzyj do slajdów: http://www.slideshare.net/KubaKubryski/what-you-40244393
Znajdziesz tam między innymi:
  • model dojrzałości Twojego api: 
    • kupa XMLa, 
    • zasoby, 
    • czasownik http, 
    • negocjacja kontentu
  • odróżnienie zasobu od jego formy (xml, json) i wersji
  • typowe błędy w wersjonowaniu API
  • trik na paginację zasobów
  • pułapki cache
  • narzędzia dokumentacji i uruchamiania serwisów

//=========================
A tutaj linki do moich prezentacji:

wtorek, 5 sierpnia 2014

Po Confiturze - dzięki!

Chciałbym podziękować wszystkim, którzy głosowali na moją prezentację na Confiturze: http://2014.confitura.pl/#/news a szczególnie tym, którzy zostawili notkę z fidbekiem.
Dostałem dziś do nich dostęp i nieco się wzruszyłem.

Dzięki wszystkim, warto dla Was pracować nad prezentacją.
Za rok przygotuję coś ekstra... powoli rodzi mi się koncepcja, będzie to coś z zupełnie innej beczki, coś czemu poświęcam sporo czasu i energii od 2 lat, znacznie więcej niż Javie i programowaniu kiedykolwiek...

Podziękowania również dla organizatorów konferencji i twórców Prezi.com:)