W firmie, w zespole, jesteśmy na etapie intensywnego zatrudniania. Niedawno dołączyło do nas kilka osób. Po nowym roku chcemy przygarnąć nawet kilkanaście lub więcej. Byłem na niektórych rozmowach. Byłem też na rozmowach do innych zespołów. Rozmawiam też z kolegami, którzy rozmowy prowadzą. I widzę jedną zależność, widzę jedną różnicę pomiędzy osobami, które zatrudniamy i tymi, które odrzucamy. Można podzielić je na dwie grupy.

Teoria praktyki

Druga grupa to ta, w której osoba zapytana o jakieś typowe zagadnienie typu „czym się różni X od Y” odpowiada bez zająknięcia. Potrafi zacytować dokumentację. Nawet odnieść się do jakichś dyskusji w sieci. Jednak jeżeli tylko zadamy jej pytanie bardziej otwarte, albo dotyczące praktycznego wykorzystania wiedzy, to zaczynają się duże schody.

Pierwsza grupa za to często ma jakieś braki w znajomości pojęć. Czasami o jakimś schemacie mówi naokoło. Ale za to potrafi powiedzieć coś o tematach, których nie ma w dokumentacji czy kursie, który omawia tylko strukturę języka czy frameworka. Potrafi się odnieść do jakiegoś zagadnienia w kontekście praktyczności. Np. kiedy poprosi się ją o omówienie zasady SOLID to wykroczy poza definicję z książki i odniesie się do jej zastosowania w realnym kodzie.

Poza szablonem

Jednym z pytań jakie zadajemy jest to czym jest klasa niemutowalna, czy obiekt niemutowalny bardziej. Niektórzy o tym słyszeli, a inni nie (polecam mój tekst na ten temat). Nie każdy, zwłaszcza jeśli ma mało doświadczenia zawodowego, musiał się z tym pojęciem spotkać (niestety). Jednak w razie braku odpowiedzi dodajemy, że chodzi o obiekt, którego stanu nie da się zmienić po utworzeniu go. I tutaj mamy dwie wspomniane wcześniej grupy.

Ci uczący się tylko dokumentacji i tutoriali szukają jakiegoś słowa kluczowego, jakiegoś elementu języka, który niemutowalność by włączał. Widać, że zastanawiają się czy przypadkiem nie pominęli czegoś przy analizowaniu frameworka. Mimo, że znają doskonale każdy z potrzebnych tutaj elementów taki jak prywatny setter, prywatny konstruktor, metoda statyczna, która zwróci obiekt itd. to nie potrafią z tych klocków, które mają, złożyć czegoś co wykracza poza szablon jaki poznawali.

Drudzy, zakładając, że nie wykuli tego pojęcia na pamięć (ale takie rzeczy wychodzą kiedy zadaje się kolejne pytania albo prosi o wyjaśnienie), zaczynają kombinować. Albo po prostu doskonale wiedzą o co chodzi bo z tym pracują (ale wtedy mówimy o osobach bardziej doświadczonych ogólnie). Skoro nie można później zmienić stanu to pewnie setter nie może być dostępny. Jak nie jest publiczny to jak coś ustawić? Ano przez konstruktor można w sumie itd. I w ten sposób dochodzą do rozwiązania przy okazji nierzadko dyskutując na jego temat z rekruterem.

Myślenie jest uniwersalne

Wiem, że dużo osób chce wejść w świat programowania. Ilu z Was jest w takiej sytuacji, że planuje takie posunięcie? Jeżeli już zaczęliście to spójrzcie na ten proces z perspektywy tego czym się zajmujecie. Czy po zapoznaniu się ze strukturą języka dalej brniecie w masę definicji i próbujecie każdy fragment poznać dogłębnie? Zapoznajecie się z każdą funkcjonalnością frameworka jakiego zaczynacie używać zanim napiszecie chociaż jedną linijkę?

A może przeciwnie – po poznaniu podstaw zaczyna się kombinowanie? Próbujecie samodzielnie składać nowe elementy z tego czego się już nauczyliście? Zaczynacie zapoznawać się z konstrukcjami, które wykorzystują język, a nie skupiacie się tylko na języku programowania?

Jeżeli jesteście w tej drugiej grupie to jesteście na dobrej drodze żeby uniezależnić się od narzędzia jakim jest język, a zostać po prostu programistą. Bo większość koncepcji programowania i pewne schematy myślenia są niezależne od języka, w którym piszecie kod. Definicję rzadko używanej funkcji albo sposób włączenia jakiegoś feature’a można w razie konieczności szybko znaleźć. Umiejętność wykorzystania go w nowej sytuacji nie znajdzie się tak szybko. Dopiero ćwicząc rozwiązywanie nieoczywistych problemów ćwiczymy wykorzystywanie tego co umiemy w nowych sytuacjach.