Tyle się mówi o rozwoju programistów. Ba, sam o tym często gadam. Że to dobre, że trzeba, żeby nie stać w miejscu a iść do przodu…
Ale powiedzcie mi: jak ma się rozwijać programista w typowym programistycznym polskim (i pewnie nie tylko) dev-kołhozie? Przychodzi do roboty, siada do projektu, po 8h wstaje i wychodzi. Niby normalka, ale… niekoniecznie. Moim zdaniem kluczowe jest pytanie: do jakiego projektu ten programista siada? Jeżeli od lat gapi się w monitor i dłubie w tym samym kodzie, utrzymuje i poprawia bugi w rozwiązaniu które zna na wylot, bo od baaardzo dawna nie widział niczego innego, to jego możliwości rozwoju są, lekko mówiąc, dość ograniczone.
Owszem, firma wyśle go na “autoryzowane szkolenia” żeby się rozwinął. Ale o tym już pisałem: “Szkolenia programistyczne, czyli maszyna ssąco-uciszająca” (BTW: wkrótce prawdopodobnie coś więcej w tym temacie).
Owszem, może sam oglądać jakieś dev-kursy i czytać dev-książki, ale gdzie zastosuje i sprawdzi nową wiedzę?
No tak, może wrócić do domu i robić “coś własnego”. Ale po pierwsze: ile razy można robić to “coś własnego” co ma zerowe zastosowanie i zaraz wędruje do kosza? A po drugie: tak, takie “coś własnego” daje frajdę, ale otwarcie się na nowe możliwości i prawdziwe poznanie “jakiejś rzeczy która jego nie jest” przychodzi dopiero wraz z przejściem całego cyklu tworzenia oprogramowania: od planowania po wdrożenie i support. Ile takich domowych projektów wchodzi w fazę wdrożenia i supportu? Nada.
Nie wspominając już o tym, że wiele osób po pracy po prostu nie ma na takie rzeczy czasu i sił (co w pełni zrozumiałem po powiększeniu rodziny).
Refleksje takie (i sporo innych) wywołało u mnie całe to zamieszanie wokół TDD: czy to żyje czy nie żyje? Ile osób tyle opinii, ale jak odróżnić kto wie o czym mówi a kto ściemnia? Z dysputy między @DHH, Fowlerem a Beckiem (część 1, część 2, umiarkowanie polecam) jasno wynika, że nawet taki koleś jak twórca Railsów nie jest do końca wiarygodny w temacie, w którym wygenerował taką burzę. Ja osobiście byłem zdziwiony jego poglądami i doświadczeniami. Ale zaczynam dryfować od tematu na rafy i skały, lasy i knieje…
Jak zatem umożliwić programiście rozwój? Gdzie ma szansę napisać soft, poświęcając na to niemało czasu, mając szansę na zweryfikowanie jakichś praktyk czy bibliotek od początku do końca? Ano w pracy oczywiście. Ale jak? Przecież jest jeden projekt, nie zmienimy nagle sposobu jego tworzenia tylko po to żeby ktoś się czegoś nauczył, nie?
Ano nie, nie trzeba tego robić. Wiecie co jest moim zdaniem rozwiązaniem tego problemu? Wiele projektów! :) I nie chodzi mi o to, żeby firma nieprogramistyczna posiadająca zespół dev pracujący nad jednym własnym systemem do użytku wewnętrznego nagle brała zewnętrzne zlecenia tylko po to żeby na nich eksperymentować. To samo można robić w ramach tego jednego systemu właśnie!
Zobaczcie… Przychodzi nowe wymaganie: trzeba zrobić “coś”. To “coś” nie jest stuprocentowo powiązane z “core” systemu. Może to być wysyłanie maila czy SMSa, może być wygenerowanie komunikatu z jakiegoś szablonu, może to być komunikacja z jakimś zewnętrznym systemem… Wystarczy zmienić mindset i zamiast ślepo klikać na solucję i wybierać “new project”, otworzyć nową instancję VS i kliknąć “new solution”. Założyć nowe repozytorium kodu zamiast pchać wszystko w jedno miejsce. Widzicie różnicę? Ta jedna prosta zmiana uwalnia nas od wszystkich ograniczeń: wykorzystywanych bibliotek, ich wersji, a nawet praktyk i stylu kodowania!
Oczywiście pojawiają się nowe wyzwania, jak chociażby zarządzanie administracyjne wieloma aplikacjami zamiast jednej. Tutaj przychodzą z pomocą świetne narzędzia (jak Octopus Deploy), które nie tylko ten problem w znacznym stopniu mitygują, ale też uświadamiają, że podejście “wieloaplikacyjne” jest po prostu lepsze niż podejście “monolityczne” nawet z administracyjnego punktu widzenia (można chociażby aktualizować tylko małą część systemu zamiast całości za każdym razem). A jakie ciekawe wyzwania się rodzą! Jak te aplikacje mają się między sobą komunikować? Przez wspólną bazę? A może na gołym MSMQ? A może RabbitMQ? A może nad to jeszcze MassTransit albo NServiceBus? A może zwykłe API RESTowe wystawione na Nancy czy ServiceStack? To jest FUN!
Dochodzi też problem taki, że jak programista pracujący nad takim pobocznym projektem wpadnie pod pociąg (ale w Polsce, jak się okazuje, jednak nie pod Pendolino;) ) to ktoś inny musi jego kod przejąć. A tam będzie “straszne nowe”. Z jednej strony – rozumiem takie obawy. Ale trzeba na to spojrzeć z rozsądnego punktu widzenia… Trzeba tak dobierać zakres projektów “eksperymentalnych”, aby ich ogarnięcie nie było niemożliwe w skończonym czasie. Trzeba też zdawać sobie sprawę z tego, że programista MUSI się uczyć, nikt (chyba że jakiś pechowy leń) nie dojedzie do emeryturki (hehe) na wiedzy zdobytej na studiach (he-he i jeszcze raz he). Bardzo pomaga też praktyka dokumentowania swoich doświadczeń tak, aby nie szły w tak zwane zapomnienie. Albo w piach, jak krew. Firmowy OneNote to rozwiązanie doskonałe i bardzo pomocne w spisywaniu dev-bojów przez każdego programistę.
W Ultrico jest nas trzech, z czego dwóch (w tym ja) od niewiele ponad roku. Pracowałem nad około 10 projektami. Sam zacząłem chyba dwa. W jednym mogłem użyć Simple.Data, w innym NHibernate. W jednym projekcie jest Angular, w innym Knockout, w jeszcze innym być może sprawdzimy React. Tu mamy Moq, tam NSubstitute. Tu nlog, tam Serilog. Tu Shouldy, a tam Fluent-Validation. Tu rake, tam psake, a gdzieniegdzie dodatkowo wspomniany Octopus. Tu “czyste” TDD, tam raczej testy integracyjne… Długo by wymieniać. Wcześniej w Predice też projektów było dużo (ale i inna specyfika firmy) i też można było się pobawić, poeksperymentować. Ale znam również ból siedzenia w korpo, gdzie codziennie widzę to samo i na jakąkolwiek wzmiankę o wypróbowaniu czegoś innego, poszerzeniu horyzontów, dostaje się po łbie.
Opisywane przeze mnie środowisko pewnie ma swoje nazwy – może jakieś kojarzycie? Jedni nazwą to “microservices”. Inni: SOA. Jeszcze inni jeszcze inaczej albo wcale.
Ja tego nie nazywam w ogóle, bo dla mnie najważniejsze jest jedno: możliwość programowania przez eksplorację (podlinkowany post sprzed 4 lat!, aktualny do dziś). My, devy siedzące na samym dole w tych dev-kopalniach, powinniśmy walczyć o swoje prawa. Nie mamy Solidarności która będzie palić opony w naszym imieniu, ale zasugerować zmiany może każdy. A jak się nie da, to każdy z kolei może znaleźć bardziej elastyczne miejsce, w którym spędzi 1/3 swojego życia. Cel: zabić nudę. Nie dać się marazmowi. Nieustannie czerpać przyjemność z pracy. I rozwijać się nawet na “zwykłym” etacie.
Jak to u Was wygląda? Jak “ostrzycie piłę”? Możecie eksperymentować, czy jesteście uwiązani do jednego danego monolitu jak Jaś do Małgosi?
Architektura przyjazna rozwojowi programisty | Maciej Aniserowicz o programowaniu…
Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl…
Częściowo masz rację, peoblem pojawia się tylko te 10 projektów za kilka lat będzie utrzymywanych przez zupełnie inny zespół ludzi. Oni nie będą czuli takiego zapału to tarego kodu, a to że każdy projekt będzie inny nie ułatwi im zadania. Jestem w dokładnie tej sytuacji – 3 przejęte projekty, a każdy inny :) Twórcy pewnie dobrze się bawili i uczyli, dla mnie to wrzód na d… Doprowadziło to do absurdalnej decyzji szefowstwa, że teraz użycie każdej nowej biblioteki ma być konsultowane z głównym architektem systemu. Ze skrajności w skrajność :<
Ja staram się zmieniać technologie tak często jak się da. Jeżeli aplikacja jest już wystarczająco rozwinięta (czyt. nie jestem w stanie nauczyć się/wypróbować na niej nic nowego zostawiam ją młodszym deweloperom, którzy mogą się z niej uczyć. Drugim rozwiązaniem jest podejście dokładnie odwrotne to znaczy, kontynuacja pracy nad projektem zaczętym przez kogoś zdolniejszego/mądrzejszego. Poza tym należy unikać dużych projektów.
Wadą takiego podejścia jest to, że człowiek nie ma możliwości stania się ekspertem w żadnej dziedzinie. Z drugiej strony nie nudzi się ;-)
@Pingback – nie wydaje mi się, ze konsultowanie nowych bibliotek z głównym architektem jest złe. Na ogół ktoś powinien pilnować, żeby aplikacja się nie rozlazła. Problem jest wtedy gdy główny architekt jest osobą ekstremalnie zachowawczą i nie dopuszcza do siebie myśli jakiejkolwiek zmiany. Wtedy są tylko dwa wyjścia – uciec od projektu lub samemu stać się głównym architektem ;-)
Rummy,
Wszystko z rozwagą i umiarem :). Nie wrzucę 5 nowych bibliotek/technologii w kluczowy projekt, od którego zależy być-albo-nie-być firmy. Ale podejście “wieloaplikacyjne” siłą rzeczy generuje malutkie usługi (kilka klas na krzyż), które są banalnie proste. I tam można poszaleć, bo nawet dla juniora ogarnięcie tego nie będzie problemem.
Boży,
Ekspertem możemy się stać w bibliotekach wykorzystywanych w wielkich wieloletnich projektach. Ale czy zależy nam na stawaniu się ekspertami od konkretnej wersji konkretnego frameworka/biblioteki? Mi nie – jeśli “liznę” ich wystarczająco wiele to przeskoczenie i nauczenie się każdej kolejnej jest prostsze.
hej, fajny wpis, a mi się przy okazji nasunęło pytanie zainspirowane jednym z paragrafów tego posta. mówisz, że w Twojej firmie jest 3 developerów – co sądzisz o tak małej liczbie programistów w zespole? Czy są jakieś wartości liczbowe w których coś się zmienia (inaczej pracuje się we dwójkę (czy w ogóle można tak pracować), trójkę, dziesiątkę itp.)? Chętnie posłucham doświadczeń bardziej doświadczonych praktyką w zespołach.
ifrom997,
“Mała” liczba programistów to dla mnie 1, i często tyle wystarcza. Sporo rzeczy zrobilem w pojedynkę.
Mamy w Ultrico wiele projektów, sporo z nich jest ciągle rozwijanych więc często pracujemy nad różnymi rzeczami nawet na swoje obszary w ogóle nie wchodząc mimo, że jest nas tylko 3. Szukamy ludzi do “rozrośnięcia” zespołu, ale specyfika pracy raczej nie powinna się zmienić nawet gdyby doszły kolejne osoby.
W większych firmach programiści awansują na “team leaderów” po to, żeby się skalować. Ja swoją wydajność, bez fałszywej skromności, oceniam na 3-4 “korporacyjnych” programistów (nikomu nie ujmując, tak to po prostu wygląda po latach doświadczeń w różnych miejscach). Próby skalowania mnie jeszcze bardziej poprzez przydzielenie mi zespołu programistycznego (od 2 do chyba 6 osób) nie były kompletnie nieudane, ale też nie dały jakichś oszałamiających rezultatów.
Wszystko zależy od specyfiki firmy, od projektów i od… ludzi. Ja jestem programistą i nie chcę być żadnym “kierownikiem” ani “liderem” ani “managerem”. I najlepiej pracuje mi się w pojedynkę.
dzięki za odpowiedź.
To jeszcze lekko pociągnę ten temat, 3 developerów, analityk, tester i front-endowiec czy 3 one-man-army robiących od kodu przez bazę na stylowaniu w CSS skończywszy?
Wydawało mi się, że w firmie software’owej raczej występuje podział, a in-house’owe działy IT w innych branżach próbują merge’ować wszystkie role w jedną.
Jest nas po prostu trzech i każdy robi właściwie wszystko – od bazy przez server i client po CSSy.
Mój rozwój: siedzę teraz w pracy i po kryjomu czytam tego bloga, bo kolejny już dzień uprawiam (na zlecenie góry) programowanie przez kopiowanie i mam ochotę wyskoczyć przez okno. :(
Jest jeszcze jedna kwestia która często wyklucza możliwość takiego podejścia. KASA. Eksperymentowanie to dodatkowy nakład i dodatkowe ryzyko. Klienci raczej niechętnie płacą za zachcianki developerów a eksperymentowanie bez akceptacji ryzyka przez biznes to stąpanie po cienkim lodzie.
Bardzo ważne to co mówisz. Najczęstsze powody zmiany pracy jakie słyszę od nowo rekrutowanych osób to “brak możliwości rozwoju”, “ten sam projekt od x lat” itp.
Z drugiej strony częściowo zgadzam się z kontrargumentacją, że mnożenie technologi w jednym projekcie tylko po to, żeby się rozwijać, może się źle skończyć.
U nas (Future Processing) wypracowaliśmy coś pośredniego, co IMO działa bardzo dobrze. Każdy ma możliwość kliknięcia buttona “change project” w systemie wewnętrznym i od razu kadry w porozumieniu z jego przełożonym szukają mu nowego zajęcia, spełniającego jego oczekiwania. Czasem takie roszady trwają 2 tygodnie, czasem kilka miesięcy, ale w rotacja jest fajna.
Jest tylko jedno ale: Taki mechanizm wymaga sporej liczby, zróżnicowanych projektów.
mała,
To skacz i nie wracaj, mało innych miejsc do pracy? :)
PtaQ,
Nie piszę o bezmyślnym ładowaniu się we wszystko “co nowe” i robieniu projektów w kompletnie nieznanych technologiach. Tylko po kolei, rozsądnie, “one step at a time”, wybierając takie projekty w których zastosowanie czegoś nowego to max kilka dni a nie miesięcy. Wiadomo że nie można przesadzić.
A swoją drogą klient narzucający technologię czy bibliotekę to średnie rozwiązanie :).
Krzysiek Szabelski,
Tak, dlatego znowu: z rozwagą i rozsądkiem.
A co do sporej liczby zróżnicowanych projektów to niekoniecznie. Wystarczy kolejne ficzery/wymagania traktować nie jako nową klasę w naszym systemie, a jako kolejny “podsystem”.
Twórcy railsów nie nalezy brac zbytnio na powaznie. Facet po uszy tkwi w “bańce” doliny krzemowej i lubi powypluwać z siebie trochę głupot :)
https://twitter.com/shitdhhsays
W moim przypadku było tak (z czego jestem bardzo zadowolony), że rozwój zawodowy powodowany jest m.in. zmianą pracy. Pracowałem w jednej firmie ponad 5 lat, pod koniec było już bardzo nudno. Później przeniosłem się do innej firmy, gdzie przepracowałem 2 lata. Był to czas intensywnego rozwoju, poznawania technologii obcych mi do tej pory (głównie SharePoint). Nie było łatwo. Teraz już w nowej pracy nadal poznaję SharePoint-a, robię rzeczy coraz bardziej zaawansowane. Ale zajmuję się już tylko SharePointem, a nie SharePointem i wieloma innymi oddalonymi od siebie technologiami. Z jednej strony było to fajne doświadczenie, ale z drugiej było to życie w ciągłym “niedouczeniu”, ciągłym zmaganiem się z robieniem prostych, ale też i bardzo trudnych rzeczy w nowych technologiach. Było to jednak psychicznie wykańczające głównie z powodu terminów i stresu w pracy (już nie wpominając, że jechało się do Klienta jako ekspert od czegoś tam – praktycznie tego nie znając).