Są programiści i programiści. Tak jak lekarze i lekarze. Hydraulicy i hydraulicy. Istnieją ludzie, którzy dostarczają niskiej jakości produkt, zrobiony w najprostszy sposób, popełniając szereg błędów w trakcie tworzenia danego produktu. Ale go dostarczają. Może on działać na słowo honoru albo działać całkiem całkiem.

Część tych osób (jak nie większość z nich) uważa, że jest świetnymi programistami i to, co dostarczyli jest super jakości. W końcu tak to powinno wyglądać według tutoriali Microsoft… Jedyny słuszny sposób tworzenia to cshtml przez model, który zawiera po 20 atrybutów na własności opisujących jak ma ona być wyświetlona i co ma być w niej walidowane i jak. A następnie w kontrolerze jest robione sieczka 200-300 linijkowa która łączy się do bazy, mapuje, etc.Spotkaliście takie osoby?

Ja miałem nie raz z takimi styczność. Z częścią z nich nigdy nie udało mi się dogadać. Chociażby dlatego, że osoby te przeważnie mają bardzo duże ego i jakakolwiek próba dyskusji kończy się: nie bo tak jest dobrze, tak robi MS, tak powinno się to robić według tutoriali i Microsoft patterns & practices. I nie ma dyskusji. A próba rozmowy może się skończyć tym, ze próbujemy podważyć umiejętności programistyczne danej osoby i ośmieszyć ją wśród pozostałych członków zespołu. Zaś prawie na pewno nasze podejście jest złe, bo wymaga więcej pisania kodu. Cały czas powtarzamy jakieś kod, w ogóle nie wykorzystujemy mocy LINQ pomijając JOINy, zero re-używalności itp.

Różnica pomiędzy tymi dobrymi a tymi złymi programistami polega na tym, że ten dobry będzie wiedział, że da się lepiej, będzie potrafił porozmawiać na ten temat jak i wyciągnąć wnioski czy też przekonać do swoich racji (nie bo MS tak mówi). Nie będzie on zamknięty na jakąś jedną szkołę i jedyny słuszny sposób rozwiązania problemu. Ten zły zaś, zatrzymał się i sądzi, że pozjadał wszystkie rozumy.

Z pierwszymi chcę pracować i ich szczerze podziwiam, drugich staram się unikać jak ogień wody. Sam też mam nadzieję, że zaliczam się do tych pierwszych, choć nie raz pewnie byłem tym z dużym ego :/ A ty?

PODOBNE ARTYKUŁYWIĘCEJ OD AUTORA

8 KOMENTARZE

  1. To jest prawdziwe patrząc jednowymiarowo – akurat w takiej działce jak opisałeś (otwarcie na nowe pomysły itp.) mam podobne odczucia. Ale jednocześnie nie wydaje mi się, żeby to była najważniejsza cecha odróżniająca dobrego programistę od złego.

    • jezeli nie masz tej, to nigdy nie sie nie rozwiniesz. zamkiniesz sie na jedna slusza technologie bo tak bo ktos tak powiedzial bo inni tak robia. i nie przyjmiesz do wiadomosci ze moze byc inaczej. Ani tez nie dasz rosadnych argumentow dlaczego korzsytasz z tego rozwiazania a nie z innego.

  2. Cześć kiedyś na starcie mojego życia programistycznego… ojj tak(ego), aby wyjść z tego błędnego koła pomogła mi właśnie współpraca z innymi (bogatszymi w wiedzę) którzy pokazali mi błędy.

    Brałem i nadal biorę garściami tych cennych rad, myślę że ego to jedno ale charakter i chęć poznania czegoś świeżego lepszego to drugie, trzeba w pewnym momencie obudzić się, na szczęście mam to dawno za sobą ?

  3. Mam wrazenie, ze skrociles historie w momencie gdy stawala sie na prawde interesujaca ;) Mysle, ze zgodzisz sie ze mna, ze to zespol dostarcza, nie dobry czy zly czlonek tegoz zespolu. Tak wiec podejscie unikania jak “ogien wody” to opcja z rzeczywistosci (nazwijmy “kolorowej”). Grymaszenie, ze nie gadam z Kuba bo ma ego – szaro to widze :D

    • to zalezy w jakich organizacjach pracujesz. w duzych korpo to pewnie masz zespoly – i o tym mozna i osobny wpis. ale czesciej sie spotyka ze jedna apka byla pisana przez jakiegos jednego dev. tych apek sa setki. w jednej z firmy w ktorej pracowalem, robilem support dla 3 000 (znalezionych i wykrytych) takich apek napisanych przez jednego dev (nie per apka, ale jeden dev kilka apek). Do tego pracuje teraz w fimie w ktorej tez duzo aplikacji powstaje solo bez teamu.

      wiec teraz jezeli mowimy o zespole. to w jaki sposob ta osoba sie znalazla w zespole ludzi ktorzy chca sie rozwijac? dla mnie blad HR. i tak nie raz mialem w zespole taka osobe i mozna probowac sobie nia radzic (pytanie czy to Twoja rola jako dev czy raczej lead i manager powinien to robic) ale w koncu koncow jak ona sie nie zmienia, to i tak z teamu wychodzila.

      Wiec tak unikam jak moge takich osob ale to nie oaznacza, ze na nie trafiam i nie wspolracuje na tyle na ile sie da.

      wiec kazda wypowiedz mozna pociagnac, jak i ze przeciez sa jeszcze sredni programisci. Sa tez tacy ktorzy w ogole progamowac nie potrafia. troche falsywej dychotomii sie wkradlo ale celowo.

      Wiec wracajac do glownego pytania: jezeli zespol to zespol dostarcza. jezeli w zespole jest ten programista z ktorym sie nie da dogadac to pytanie kto budowal ten zespol i dlaczego on tam trafil. jak juz tam jest, to co mozemy zrobic by wspolpraca sie udala. co my jestesmy wstanie zrobic by zachecie ta osoba do sprobowania czegos nowego. Ale w ktoryms momencie i tak trzeba powiedziec sobie dosc. Jezeli my robimy co w naszej mocy by wpsolpracowac z dana osoba, akceptowac ja i jej pomysly. brac je pod uwage i rozwazac, a ona nie chce sie zmienic i caly czas robi swoje mimo ze caly zespol robi inaczej to sory. gdzie jest miejsce dla takiej osoby w zespole?

      • > …ale czesciej sie spotyka ze jedna apka byla pisana przez jakiegos jednego dev. tych apek sa setki…
        Rzeczywiscie mamy rozne doswiadczenia. Dobra kwestia do dyskusji przy szklance/butelce ;)

  4. Podejście “ja to zrobiłem dobrze, a wszystkie inne rozwiązania są złe” zawsze będzie odpychające… Nieistotne, czy to w programowaniu czy w innych dziedzinach. Trzeba pamiętać, że żaden człowiek nie jest nieomylny. Uczymy się całe życie. Natomiast jeżeli chodzi o tworzenie samych projektów, to dopóki robimy to sami, nic nie stoi na przeszkodzie, żeby “być złym programistą” i pisać coś “w jedyny słuszny sposób”. Sytuacja wygląda inaczej, kiedy tworzy się coś w grupie… No przecież trzeba iść na kompromisy… jeżeli ktoś nie jest w stanie, to się nie nadaje do pracy zespołowej – proste :)

Comments are closed.