Dość długo siedzę w IT. Zawsze od strony kodu i konkretu. Długo byłem programistą i wydaje mi się, że chociaż częściowo już rozumiem, co jest ważne. Co jest ważne, żeby stać się dobrym programistą. Jeśli chcesz poczytać to powiem w krótkich żołnierskich słowach co sprawiło, że nauczyłem się efektywnie tworzyć oprogramowanie. Oto sekret 😉

17022012105012-programista

Programowanie jest teoretyczno-praktyczne

Programowanie to z jednej strony rzemiosło z drugiej strony nauka ścisła. Nie można być dobrym programistą jeśli nie zna się teorii. Studia uczą jej częściowo – wiedza przekazywana na studiach informatycznych jest bardzo ważna. Programista który nie rozumie pojęć, architektury, wzorców projektowych, działania algorytmów (np. jak rozumieć dobrze bazy danych gdy nie rozumie się drzew?) nigdy nie będzie bardzo dobry. Nie przeskoczy levelu z „Szybkiego pisania kodu” na tworzenie innowacyjnych rozwiązań inżynierskich.

Bardzo dobrzy programiści są wielokrotnie wydajniejsi niż średni programiści. Wielu to podkreśla – coś w tym jest. Wydaje mi się, że kluczem do tej zagadki jest nauczenie się korzystania z wiedzy teoretycznej przez .. lata praktyki. Zauważanie prawidłowości i wzorców. Zauważanie skrótów. Programowanie jest teoretyczno-praktyczne i tego związku nie można rozdzielić.

Technologie się zmieniają, sposób myślenia nie tak często

Są różne paradygmaty programowania. Programowanie obiektowe vs. proceduralne. Programowanie funkcyjne, programowanie rozproszone. W ramach danego podejścia są różne technologie, techniki i techniczki – które zmieniają się częściej lub wolniej. Sposób myślenia jednak nie zmienia się tak często. Ktoś kto wie jak działają wzorce projektowe (np. Factory Method, Dependency Injection) i umie je stosować w .NET – szybko złapie jak działa podobny algorytm napisany w Javie albo .. w JavaScripcie (gdy już zrozumie wzorzec Prototype i dziedziczenie w JS). Uczenie się z książek o danej technologii to bardzo często strata czasu. Zwłaszcza na początku. Trzeba wejść w rytm. Zrozumieć zasady programowania obiektowego – DRY, Zasada podstawień Liskov (LSP) jest ich trochę. Trzeba zrozumieć idee. Języków programowania i bibliotek zawsze można się nauczyć i to szybko. Bardzo wiele bibliotek jest dostępnych w różnych językach – to też przyspiesza adaptacje.

Dobry cieśla – piłą ręczną czy mechaniczną wytnie podobny kształt, stworzy podobny mebel. Idea tego co chce stworzyć jest niezależna od narzędzi którymi się będzie posługiwał.

Co powinieneś przeczytać? Dobre książki o inżynierii oprogramowania. Bądź dumny z tego co wiesz i z tego, że jesteś ekspertem. Nie bądź „samoukiem”.

To co robisz, robisz po coś

Pisanie kodu – mimo, że łatwo popaść w takie myślenie – nie jest sztuką samą dla siebie. Kod musi być ładny i przemyślany, trzeba być z niego dumnym. Ale on jest po coś. Jest pisany dla ludzi. Ludzie – ze wszystkimi swoimi wadami będą korzystać z efektów tego kodu.

Oprogramowanie powinno być użyteczne i powinno być dopracowane. Powinno być „ludzkie” – posługiwać się sensownymi komunikatami, interakcjami które są zrozumiałe. „Developers for developers” – tak, była taka seria książek Oreilly. Na tym poprzestańmy. Oprogramowanie jest dla użytkowników.

Nawet w narzędziach programistycznych – github, Ruby On Rails – widać bardzo duże przejway „humanizmu”. Te narzędzia działaja out of box i nie trzeba (prawie) się ich uczyć. Użyteczność jest kluczowa aby naszą pracę szanowała reszta zespołu i użytkownicy.

Zamykaj, uruchamiaj, wdrażaj

Programowanie nie jest po to aby programować. Tylko po to, aby zaprogramować :-) Małe kroki budują motywację. Buduj małymi krokami. Dla mnie najgorszy zawsze był start projektu: nic nie było widać a pracy wydawało się nie do przerobienia. Złam to myślenie. Zamknij coś, uruchom, pokaż komuś żeby się zmotywować. Dziel zadania na takie które dają szybki efekt. Tylko tak można skończyć duży projekt w realnym czasie i nie popaść w depresję. PMowie to lubią

Nie przestawaj się uczyć

Każdy jest w stanie poświęcić dziennie 60 minut na swój rozwój. Jestem tatą 2.5 miesięcznego Olka, pracuję po 9-12h dziennie. Nie narzekam na zbyt dużą ilość czasu wolnego :-) Ale codziennie poświęcam 60 minut (około) na naukę. Słucham nagrań TED, audiobooków i czytam książki. Bez tego czuję się strasznie parszywie. Korzystając z tych 60 minut jestem w stanie w miesiącu przeczytać 3 grube książki i kilka gazet.

Warto uświadomić sobie ile wiedzy można przyswoić w ten sposób w rok czasu… Można stać się ekspertem w danej dziedzinie. A to tylko jedna godzina dziennie.

Nie bądź bucem

Programowanie jest trudne, toteż łatwo popaść w myślenie „on, ona, oni są głupi, jak oni mogę tego nie rozumieć?”. Programiści mają tak często. Ale uwaga – to są słabi programiści.

Pokora pozwala się uczyć i rozwiązywać ludziom problemy. To, że ktoś nam płaci za programowanie nie wynika z tego, że tak strasznie cieszy się, że może z nami pracować. Rozwiązujemy czyjeś problemy. Nie można rozwiązać kogoś problemu nie słuchając, zakładając, że wie się najlepiej.

Zwracaj uwagę na detale

Po czym poznać czy programista zwraca uwagę na detale? Po marginesach. To moja teoria ale się sprawdza. Chodzi o wdrożone formularze lub strony WWW. Programiści którzy zwracają uwagę na detale starają się zadbać o odpowiednie marginesy.

Detale są ważne wszędzie. W kodzie- żeby przewidzieć ewentualne błędy. W interfejsie – żeby aplikacja nie straszyła, aby było mało poprawek.

Zrób coś za darmo

Najwięcej nauczyłem się rozwijając serię programów AMIGO Software. To były darmowe aplikacje które pisałem przez kilka lat po szkole. Nigdy na nich nic nie zarobiłem. Nauczyłem się mnóstwo, na każdej rozmowie o pracę te programy robiły wrażenie. Przede wszystkim miałem wrażenie, że komuś pomogłem udostępniając takie programy jak Zajączek za darmo. To było świetne. Nigdzie nie nauczyłem się tyle o tworzeniu oprogramowania (o samym procesie, testach, feedbacku itd).

Nie obrażaj się

Poprawki nie są wymierzone w programistę. Zawsze cieszyłem się z poprawek. Każda z nich to czas który ktoś poświęcił żeby mój program był lepszy. Tak serio, to powinienem mu być za to wdzięczny. Zawsze lubiłem testy. Wtedy już wszystko było wiadomo, jak ma działać, jak ma wyglądać. Wystarczyło wprowadzić poprawki.

Masz pytania? Potrzebujesz wsparcia? Napisz do mnie: pkarwatka@divante.pl