Bez zbędnego wstępu zajmijmy się dziś cechami, które moim zdaniem powinien posiadać każdy programista.

Cierpliwość – to dzięki niej jesteśmy w stanie poszukiwać działających rozwiązań, szukać przyczyn występowania błędów oraz nie poddawać się w tym, co robimy.

Dokładność – jest to jedna z najważniejszych, moim zdaniem, cech. Dzięki niej jesteśmy w stanie stwierdzić, czy ktoś będzie dobrym programistą, czy też nie. Jeżeli jesteśmy niedokładni w małych rzeczach, popełniamy masę nawet drobnych błędów, to nigdy nie sprawdzimy się przy projektach. I nikt nie obdarzy nas zaufaniem i nie pozwoli nam na samodzielność w pracy.

Analityczne myślenie – samo rozwiązanie problemu, czy też napisanie kodu, to nie wszystko. Ważne jest również nieszablonowe myślenie, umiejętność przygotowywania rozwiązania, które będzie najbardziej optymalne i niezawodne.

• Czy nowo dodany kod, będzie mieć jakieś niepożądane działanie w systemie?
• Czy będziemy w łatwy sposób rozszerzać fragment tej funkcjonalności, kiedy zajdzie taka potrzeba?
• Czy jesteśmy w stanie wdrożyć, takie rozwiązanie, jakiego oczekuje klient?
• Czy nasze rozwiązanie jest optymalne?

Zaradność – czasami się zdarza, że czegoś nie wiemy lub nie jesteśmy w stanie od razu tego wykonać. Ważny jest sposób w jaki poradzimy sobie w takiej sytuacji. Dla osoby zaradnej, nie ma rzeczy niemożliwych.

• Czy na podstawie dostarczonych informacji i zdobytej wiedzy, jestem w stanie zaplanować sobie pracę, przygotować rozwiązanie i zdobyć wszelkie potrzebne mi informacje?
• Czy też będę się pytał współpracowników, o każdą małą rzecz?
• Czy przed zapytaniem bardziej doświadczonych osób, sprawdziłem wszelkie możliwe źródła?
• Czy moja wiedza na temat dziedziny, w której pracuję, jest wystarczająca do poradzenia sobie z drobnymi problemami w kodzie / środowisku / serwerze / gicie / linuxie / przeglądarce?

Chęć doskonalenia swoich umiejętności – wykonywanie ciągle tych samych zadań jest bardzo monotonne i nie prowadzi do rozwoju. Warto stawiać sobie wysoko poprzeczkę i dużo od siebie wymagać. W branży IT technologia, która jest aktualna teraz, za dwa lata może nie być już użyteczna. Nie można sobie pozwolić, na zaprzestanie rozwoju, nawet we własnym zakresie.

• Czy jestem otwarty na nowe wyzwania?
• Zdobywam wiedzę z różnych źródeł?
• Zdobywam od najbliższych pracowników feedback, co mogę poprawić?
• Czy wiem dokąd zmierzam i czego muszę się nauczyć, aby zrealizować swoje cele?
• Czy moja obecna praca, daje mi okazję do wykazania się i zdobycia nowej wiedzy, czy też w kółko wykonuję te same zadania?

Wyciąganie wniosków z błędów – każdy popełnia błędy, tak samo jak każdy kłamie. Najlepsi potrafią się do nich przyznać i szukać rozwiązań / procedur, które nigdy więcej do tego nie doprowadzą.

• Czy jesteś jedną z takich osób?
• Czy wyciągasz wnioski z popełnionych błędów i już więcej ich nie powtarzasz?
• Czy jeżeli masz jakiś problem, analizujesz z czego może on wynikać i szukasz rozwiązania?
• Czy skutecznie zapobiegasz powstawaniu kolejnych błędów?
• Czy wdrażasz procedury, które mogą cię przed nimi uchronić?

Umiejętność rozwiązywania problemów – bierze się głównie z doświadczenia. Im więcej mamy kontaktu z kodem i problemami, tym bardziej jesteśmy doświadczeni i rozwiązywanie problemów idzie nam łatwiej. Warto pomagać innym na serwisach typu stackoverflow. Dzięki temu, jesteśmy na bieżąco z problemami, z jakimi spotykają się deweloperzy, a także poznajemy rozwiązania, które mogą przydać nam się w przyszłości.

• Czy wmawiam sobie, że jest to jakaś magia, czy jestem realistą i zdaję sobie sprawę, że to tylko kod?
• Czy jestem w stanie zaproponować rozwiązanie, które poprawi obecną pracę?
• Czy odpowiednio podchodzę do problemu i szukam faktycznie tam, gdzie może występować?
• Czy z każdym napotkanym problemem, idzie mi coraz lepiej, a wynika to ze zdobytego doświadczenia?

Odpowiedzialność – to ona sprawia, że przełożeni i współpracownicy darzą nas zaufaniem. Jeżeli mówimy, że coś jest przetestowane i działa, to tak być powinno. Niestety, bardzo często, te słowa mają się nijak do rzeczywistości. Bierzmy odpowiedzialność, za to co robimy, sprawmy, że inni będą mogli na nas polegać.

• Czy biorę odpowiedzialność za powstały kod i można mi ufać?
• Czy odpowiednio komunikuję, że nie jestem czegoś pewny i proszę o sprawdzenie osób bardziej doświadczonych?
• Czy gdy pojawiają się problemy, biorę to “na klatę”, czy też zganiam na innych i mówię, że to nie mój kod?
• Czy informuję o problemach zagrażających terminowi i eskaluje to wyżej?

Samodzielność w rozwiązywaniu problemów – na podstawie dostępnych informacji, powinniśmy być w stanie przygotowywać gotowe rozwiązania, spełniające wszelkie normy jakościowego kodu. Najlepsi, wiedzą o tym, że czasami zapytanie kogoś o radę, może zaoszczędzić X godzin pracy i nie ma w tym nic złego.

• Czy przed zadaniem pytania, upewniłem się we wszelkich dostępnych źródłach i przetestowałem wszelkie możliwe sposoby, które przychodziły mi do głowy?
• Czy rzeczy, o które pytam, wynikają ze specyfiki projektu i mogę ich nie wiedzieć, czy też z mojego niedouczenia w danej dziedzinie?

Umiejętność pracy w grupie – jest to bardzo ważna cecha, ponieważ przy dużych projektach, czasami przez lata można nie poznać działania całego systemu. Są jednak osoby, które mogą znać działanie danego fragmentu, a wspólnie tworzą całość. Umiejętność porozumiewania się z osobami w grupie i szukania odpowiednich informacji, jest niezastąpiona. Trzeba też pamiętać, że pracując w grupie, tworzycie drużynę, która zmierza do tej samej bramki. Jeżeli masz z czymś problem, to w interesie całego zespołu jest, żebyś jak najszybciej znalazł rozwiązanie. Nie bój się prosić o pomoc i rozmawiać z innymi.

• Czy efektywnie przekazuję informację w grupie?
• Czy jestem w stanie współpracować z innymi i wspólnie coś tworzyć / testować?
• Czy zdaję sobie sprawę, że gramy do jednej bramki i nie ma głupich pytań?
• Czy skrywam się z problemami i nie informuję o nich grupy, bojąc się, co o mnie pomyślą?

Umiejętność przekazywania informacji, w zależności od rozmówcy – nie każda osoba z którą rozmawiamy, musi znać wszelkie techniczne aspekty zadania, nad którym pracujemy. Powinniśmy być w stanie, dopasować się do naszego rozmówcy. Inaczej przekażemy informację leadowi projektu / project managerowi / klientowi, a jeszcze w zupełnie inny sposób opowiemy o tym przedszkolakowi. To, co jest dla ciebie proste i zrozumiałe, niekoniecznie musi być takie dla twojego odbiorcy, nie zapominaj o tym.

• Czy zdaję sobie sprawę, że nie wszystkich muszą interesować szczegóły i potrafię przedstawić problem / rozwiązanie w języku zrozumiałym dla osób nietechnicznych?

Każdego dnia się uczę i zdobywam cenne doświadczenie. Poniżej zamieszczam kilka pytań, na których odpowiedź, może pobudzić Was do rozwoju i działania:

• czy pracuję mądrze i optymalnie, czy też będę uparty i szukał rozwiązania samodzielnie, wiedząc że osoba X jest w stanie naprowadzić mnie na rozwiązanie i zaoszczędzić Y czasu?
• czy tworzę case study i analizuję, z czego mógł wynikać dany problem?
• czy zapisuję sobie każdą rzecz, z którą miałem problem, żeby później to przeanalizować i znaleźć rozwiązanie?
• czy planuję sobie działanie, przed przystąpieniem do pracy?
• czy zapisałem się na newslettery, w interesującej mnie dziedzinie?
• czy znam swoje mocne i słabe strony i wiem, jak mogę je naprawić?
• czy nie boję zapytać się o feedback i rzeczy do poprawy?
• czy osoby, którymi się otaczam, są mądrzejsze ode mnie?
• czy osoby, z którymi współpracuję, darzę autorytetem?
• czy miejsce, w którym jestem, daje mi możliwość rozwoju?

Czy dodałbyś jeszcze jakieś pytanie do tej listy? Jeżeli tak, to jakie?