Krótko o mnie
Nazywam się Włodek Krakowski. Jestem trenerem technicznym oraz prelegentem na konferencjach specjalizującym się w zagadnieniach pracy z kodem zastanym i długiem technicznym poprzez techniki refaktoryzacji kodu. Mieszkam w Krakowie, ale często podróżuję po Polsce, Europie i Świecie aby wspierać moich klientów w ich działaniach.
Tematem jakości kodu interesuję się od początków mojej pracy w branży IT. Od roku 2001 przeszedłem przez wiele perspektyw postrzegania tego zagadnienia począwszy od czasu kiedy zaczynałem jako programista, poprzez rolę lidera zespołu aż do obecnej roli trenera prowadzącego szkolenia. Obecnie pomagam moim klientom zadawać właściwe pytania aby znajdować właściwe odpowiedzi umożliwiające utrzymanie lub poprawę jakości kodu z jakim pracujemy.
Tematem jakości kodu interesuję się od początków mojej pracy w branży IT. Od roku 2001 przeszedłem przez wiele perspektyw postrzegania tego zagadnienia począwszy od czasu kiedy zaczynałem jako programista, poprzez rolę lidera zespołu aż do obecnej roli trenera prowadzącego szkolenia. Obecnie pomagam moim klientom zadawać właściwe pytania aby znajdować właściwe odpowiedzi umożliwiające utrzymanie lub poprawę jakości kodu z jakim pracujemy.
Dojrzałe pytania o jakość kodu
Kiedy już wiemy że przede wszystkim wszystkie nasze produkty powinny działać prawidłowo i dostarczać wartość dla klientów możemy zadać trochę inne pytanie. Czy jest możliwe dostarczenie wartości biznesowej na podstawie kodu o niskiej jakości tzn. mało czytelnego, mało przetestowanego i źle zaprojektowanego? W szczególności czy to jest możliwe długoterminowo, kiedy będziemy dostarczać dla klienta kolejne wersje naszego produktu? Jak bardzo prawdopodobne jest że nasz produkt będzie ulepszany i rozwijany w przyszłości? Jakich umiejętności potrzebujemy aby sprostać tym wyzwaniom?
Znalezienie powyższych pytań przy których w odpowiedziach pomaga refaktoryzacja zajęło mi dużo czasu. Ale dzięki temu wiem, że znajdowanie odpowiedzi zaczyna się zadawania odpowiednich pytań. Są to pytania uczącego się, zdecydowanie nie pytania wyrokującego i tego Ci czytelniku życzę.
Moja historia - od programisty do prelegenta
Pracę zawodową rozpocząłem w 2001 roku. W tamtym czasie, znając najważniejsze zagadnienia jak np. wzorce projektowe – jakość kodu była dla mnie najważniejszą rzeczą. Zdziwiony więc byłem, kiedy opowieści o usprawnieniach technicznych które wprowadziłem i z których byłem dumny nie wywoływały wielkiego entuzjazmu u osób z branży biznesowej. Zapewne dlatego, że z ich puntku widzenia kod działał nadal “tak samo” a klienci już czekali na kolejne rzeczy…
Koncentracja wyłącznie na wartości biznesowej (funkcjonalności) zdecydowanie się sprawdzała – ale tylko do pewnego rozmiaru projektu. Potem nasi klienci (i testerzy manualni) byli w stanie znaleźć błędy dużo szybciej niż my sami – czyli programiści. Co więcej naprawiając istniejące błędy wprowadzaliśmy na ich miejsce inne.
Czas biegł do przodu, a ja w poszukiwaniu pracy w projekcie z lepszą jakością kodu zmieniałem pracę lub projekt w firmie. I w pewnym momencie dołączyłem do zespołu którego częścią pracy oprócz pisania oprogramowania była administracja narzędzi oraz prowadzenie szkoleń! NIe tylko prowadziliśmy już istniejące szkolenia techniczne ale także mogliśmy wprowadzać nowe i własne. I w ten sposób mogłem doskonalić swój warsztat szkoleniowy na podstawie informacji zwrotnych od uczestników.
W tym punkcie rozpoczęła się moja podróż i przygoda z prowadzeniem szkoleń. Zrozumiałem i poczułem że to jest będzie zawsze moją pasja!
Później jeszcze raz zmieniłem pracę i zostałem liderem zespołu. Byłem odpowiedzialny za zbudowanie zespołu od początku, a co więcej byłem osobą która napisała pierwsze linie kodu nowego projektu myśląc wtedy że problem jakości nie będzie go nigdy dotyczyć.
Powyższe doświadczenie umożliwiło mi spojrzeć na zagadnienie jakości kodu z dodatkowej perspektywy – organizacyjnej. Bo na jakość trzeba znaleźć czas – ale nie dodatkowy tylko będący nieodłączną częścią procesu tworzenia oprogramowania.
Koncentracja wyłącznie na wartości biznesowej (funkcjonalności) zdecydowanie się sprawdzała – ale tylko do pewnego rozmiaru projektu. Potem nasi klienci (i testerzy manualni) byli w stanie znaleźć błędy dużo szybciej niż my sami – czyli programiści. Co więcej naprawiając istniejące błędy wprowadzaliśmy na ich miejsce inne.
Czas biegł do przodu, a ja w poszukiwaniu pracy w projekcie z lepszą jakością kodu zmieniałem pracę lub projekt w firmie. I w pewnym momencie dołączyłem do zespołu którego częścią pracy oprócz pisania oprogramowania była administracja narzędzi oraz prowadzenie szkoleń! NIe tylko prowadziliśmy już istniejące szkolenia techniczne ale także mogliśmy wprowadzać nowe i własne. I w ten sposób mogłem doskonalić swój warsztat szkoleniowy na podstawie informacji zwrotnych od uczestników.
Później jeszcze raz zmieniłem pracę i zostałem liderem zespołu. Byłem odpowiedzialny za zbudowanie zespołu od początku, a co więcej byłem osobą która napisała pierwsze linie kodu nowego projektu myśląc wtedy że problem jakości nie będzie go nigdy dotyczyć.
Powyższe doświadczenie umożliwiło mi spojrzeć na zagadnienie jakości kodu z dodatkowej perspektywy – organizacyjnej. Bo na jakość trzeba znaleźć czas – ale nie dodatkowy tylko będący nieodłączną częścią procesu tworzenia oprogramowania.