Cześć!

Rozmowy kwalifikacyjne to stresującego okoliczności. Zwykle dla obydwu stron. Jakiś czas temu miałem do zrekrutowania “seniorów”. Wpadłem na pomysł, że będę zadawał zestaw bardzo prostych pytań, na które każdy odpowie. Takie co jak wpiszesz w google pytanie o daną technologię, to pierwszy link już da Ci odpowiedź. Celem tego było, żeby odpytywany dobrze się poczuł, rozluźnił i potem przy trudniejszych pytaniach już pokazał lepiej swoją wiedzę. Zapewne domyślasz się do czego zmierzam - większość odpytywanych poległa już na tych najprostszych pytaniach…

Nie czytam za dużo książek poradników czy też popularnych ostatnio biografii. Mam wrażenie, że za dużo w nich promocji autorów, a za mało przesłania. Wolę dobrą beletrystykę typu “Zabić Drozda”, “1984”, “Kocia Kołyska”. Uważam, że więcej można się z nich o życiu dowiedzieć niż z tego typu poradników. Ostatnio stwierdziłem, że może pora trochę nadrobić i sprawdzić czy te książki są faktycznie takie jakie mi się wydawało. Zdążyłem trafić na kilka niezłych jak Atomic Habits czy Company of One. Co do niektórych to mam wrażenie, że gdyby skondensować je do dłuższego wpisu na blogu to miałyby dużo większą wartość niż sztucznie zapełnione do formatu książki.

Jedną z tego typu książek, jest “Mindset: The New Psychology of Success” Carol Dweck. Przez ponad 200 stron autorka na wiele sposobów magluje swoją teorię, że ludzie dzielą się na dwie grupy:

• nastawionych na trwałość,
• nastawionych na rozwój.

Z grubsza można powiedzieć, że ludzie nastawieni na trwałość wierzą, że każdy człowiek ma wrodzony zestaw zdolności. Uważają, że jeśli coś Ci wychodzi to masz talent, jeśli nie - to go nie masz. Uznają, że raczej już tego nie zmienisz. Ludzie nastawieni na rozwój uważają, że wszystko da się poprawić i rozwinąć. Zgodnie z zasadą “Co trzeba zrobić, żeby zagrać w Carnegie Hall?” - “Dużo ćwiczyć”. Oczywiście nie są to marzyciele, którzy wierzą, że wszystko im się uda. Po prostu uważają, że jeśli się nad czymś pracuje regularnie to się będzie w tym lepszym (co pokrywa się z przesłaniem wspomnianej książki Atomic Habits). Takie właśnie mambo-jumbo jest w tej książce.

Dlaczego o tym piszę? Jest w tej książce ciekawe spostrzeżenie co do ludzi “nastawionych na trwałość”. Ludzie Ci jeśli odniosą jakiś sukces będą chcieli go utrzymać. Co w tym dziwnego? To, że będą chcieli go utrzymać w specyficzny sposób. Martwią się, że gdy popełnią błąd i inni ludzie to zauważą to uznają, że jednak nie są tacy super. Skupiają się na tym, żeby nie zostać zdemaskowanym jako oszust. Zatem będą unikać ryzyka, okazji do wyjścia poza strefę, w której czują się pewnie, bo a nóż ktoś uzna, że się nie znają. Wtedy może się okazać, że jednak nie mają talentu i “wszystko stracone”.

Takie podejście popularne jest w korporacjach. Takich gdzie za dobre się nie wynagradza, a za zło karze. Nikt Cię nie nagrodzi jak zrobisz coś dobrze, ale jak coś zrobisz coś źle to ukarze. Jedyną pewną strategią jest nie robić nic.

Przeczytałem też ostatnio artykuł “Why Senior Engineers Hate Coding Interviews”. Gdzie autor pisze dlaczego “seniorzy” nie lubią robić zadań technicznych. Ja bym to nawet rozciągnął również o pytania o detale techniczne. “Pfff, co za pytanie, przecież ja jestem seniorem, nie będę rozmawiał o takich pierdołach”. Coś jak pytanie znajomego o wyliczenia finansowe “Ja się na tym nie znam, jestem humanistą”. A ile znasz języków? “Polski i cośtam po angielsku - nie mam talentu do języków”.

Niedawno we wpisie na blogu, który szumnie nazwałem “Architect manifesto” stwierdziłem, że architekt powinien być aktywnym programistą. Powinien pracować na architkutrze, którą wymyślił. Powinien brudzić sobie ręce kodem razem z zespołem.

Uwarunkowania w projektach są różne. Często “kultura organizacyjna” (a w zasadzie jej brak) wymaga częstych spotkań, wycen, maili, excela. Meeting Driven Development i Mail Oriented Programming. Wiadomo, w pewnych firmach tak po prostu jest. Ale czy na pewno tylko to jest powodem, dla którego starsi programiści i architekci nie chcą programować? Czy naprawdę mają takie ważne zadania zawsze, że nie są w stanie usiąść i napisać paru linijek kodu? Dlaczego taką wielką ujmą jest “naklepanie formatki”? Dlaczego taki problem jest “doklepać CRUDowy endpoint czy tabelkę”? Czemu “szkoda ich czasu na takie rzeczy”?

Czy to nie jest tak, że będąc takimi osobami, nawet chcemy pomóc. Mówimy, “kurcze, trzeba pomóc to domknąć - usiądę i doklepię tę brakującą formatkę”. Czy nie bywa tak, że siadamy nad tym i orientujemy się, że za cholerę nie wiemy jak to zrobić? Że boimy się zapytać i przyznać, że czegoś nie wiemy? Jak reagujemy w tej sytuacji? Jesteśmy nastawieni na trwałość i bronimy swojej bazy poprzez zajęcie się “innym pilnym zadaniem”? Czy jesteśmy nastawieni na rozwój i prosimy juniora o pomoc w CSS?

Co o tym sądzisz?

Na koniec zestaw linków:

• napisałem kolejny wpis na blogu na bazie starego maila - tym razem “Optimistic concurrency for pessimistic times” - do poczytania: https://event-driven.io/en/optimistic_concurrency_for_pessimistic_times/
• wypuściłem kolejne “Architecture Weekly” z zestawem linków, które mnie zainteresowały w ostatnim tygodniu - https://github.com/oskardudycz/ArchitectureWeekly#21st-december-2020 - miłej lektury
• rok temu napisałem z okazji świąt również mniej mięśnie “Nie bądź jak Ebenezer Scrooge, czyli słów kilka o pracoholizmie” - zachęcam do lektury https://oskar-dudycz.netlify.app/pl/kilka_slow_o_pracoholizmie/. Ciągle aktualne.

Pozdrawiam serdecznie i życzę Ci spokojnych, zdrowych i rodzinnych Świąt! Odpoczynku! Oskar