Jesteśmy już starzy?

Trochę statystyk z jednej z polskich firm IT( mowa a całkowitym doświadczeniu IT a nie tylko firmowym ):

  1. cały zespół ma 477 lat doświadczenia IT
  2. średnie (arytmetyczne) doświadczenie IT na pracownika – 10,8 roku
  3. największe doświadczenie (jednostkowe) – 36 lat
  4. najmniejsze doświadczenie (jednostkowe) – 0 lat
  5. ilość osób – 0 – 9 lat doświadczenia – 24
  6. ilość osób – 10 – 19 lat doświadczenia – 14
  7. ilość osób – 20 – 36 lat doświadczenia – 6

 

Pozdrawiam

-Janusz

12 komentarzy do “Jesteśmy już starzy?”

  1. I wszystkich zastapi sztuczna inteligencja co napisze oprogramowanie a potem znajdzie i naprawi pluskwy 😉 …Tak sama z siebie. Czekam na moment kiedy sztuczna inteligencja zastapi zarzad firmy 🙂

    -Maciek

  2. Na razie tlumacze programy w Cobolu na angielski bo sztuczna „inteligiencja” nie radzi sobie z Cobolem.
    Potem pewnie z tego AI napisze programy w Javie.

    Jurek

  3. Ta „inteligencja” już tłumaczy COBOL na Javę. Ale bez zrozumienia „o so kurva choźi”.

    MNSHO (my not so humble opinions):

    1) w samym programie w COBOLu, lub innym języku, w źródłowym kodzie nie ma wystarczająco “business and reality context” by przetłumaczyć na ludzki język. Trzeba patrzyć szerzej i mieć wiedzę w danej dziedzinie i szczegółowo w danej organizacji. AI może da radę, kiedyś, ale póki co bez Jurków i innych nam podobnych nie ma szans.

    2) COBOLu się nie da przetłumaczyć na Jawę (me thinks), dla mnie to trochę tak jakby używać, powiedzmy AMG GT do pracy która dzisiaj robi Kamaz albo John Deere. Pewnie kawałki się da pociągnąć (np. Front end z CICSa) ale jak ładunek jest za ciężki to… jest za ciężki. (Kropka).

    3) … na razie tyle… pozdrawiam wszystkich, szczególnie tych “starszych” 🙂

    LjF.

  4. Pozwolę się wtrącić,
    Ile czasu sie u Was programuje ze słuchawkami na uszach ? więcej niż 10-20% ?
    Kompletnie nie rozumiem strachu przed AI.
    Niech sobie AI programuje, w korpo przecież się nie pisze kodu tylko uprawia politykę.
    Przecież większośc to są niekończące się dyskusje co napisać, jak, jaka ma by architektura, jaki model, która koncepcja wygra.
    Później walka na MR – czemu tak a nie inaczej i niekończące się dyskusje i komentarze.
    Później merge conflicts, rebase, merge to dev testowanie od nowa…
    Po merge’u jest walka z dependency które tworzą runtime exceptions, z deploymentem, z hostami, ze środowiskiem UAT które nigdy nie działa , a to nie ma market data na tym hoscie, a to nie ma ref data na tamtym hoście a to credit checker leży na innym hoscie, a to UI nie działa bo backend do UI leży (jeden z 5 microservices do UI) trzeba chase’ować 4 inne team’y żeby naprawiły swój microservice itp.
    Później testowanie, przygotowanie release, checkout, ponowne pytania jak to w ogóle działa, a sprawdz logi bo moze cos jest nie tak, później rollback bo ktoś z downstreamu narzeka że czegoś nie ma i się raport nie generuje itd.
    Przecież, żadne AI się nie zajmuje takim czymś…

    1. Bartosz,

      Testowanie jest na poczatku. Do tego sluzy TDD i BDD. Jak sie tego nie robi to projekty wychodza tak sobie i potem jest polityka co poszlo zle i cos moze jest zle z architektura (ostatnio bylem Chief Architect w pewnym banku pracujac z CTO, CIO i CISO i cos z tych rzeczy poznalem blizej)

      Przedtem bylem w Wells Fargo w CIO office i trenowalem cale zespoly (2000 developerow w platnosciach) jako Senior Lead Agile Coach. Widzialem dyrektorow z certyfikatami, ktorych musialem prostowac co to jest Agile i jak to dziala (jestem ekspertem w Scrum bo uczylem sie tego ok 2005 roku od samych tworcow i tych co podpisali Agile Manifesto – mielismy ich w Goldman Sachs a potem w firmie inwestycyjnej ososbiscie zbudowalem caly proces Agile bedac zarowno Tech Lead i Program Manager pod opieka i jako dordca technologiczny dwoch CTO).

      Tak ze rozumiem, ze jest polityka, ale to wynika z kultury i z uprzednich bledow. Swiat sie zmienia – metody sie zmieniaja i warto za nimi podazac. My tymi metodami zbudowalismy kilka systemow platnosci i inwestycji.
      Mnie takze polityka wkurza i to jest powod dlaczego moj ostatni dzien w banku byl trzy tygodnie temu mimo ze moj szef CTO chcial mnie zatrzymac, ale „politykom” stalem na przeszkodzie czyli architektom z nowego Flagstar wytknalem braki w wiedzy, doswiadczeniu oraz czytaniu ze zrozumieniem dokumentow C-level (nie podazali za wymaganiami security sformulowanymi przez CISO a odsylali wszystkich do tego dokumentu). Pewien Managing Dyrektor z konkuerncyknej firmy (Deloitte) robil zapiski z moich uwag i przyznal ze nie mial pojecia w niektorych sferach w ktorych mialem doswiadczenie. Potem zainteresowal sie mna wiec byc moze pojede pracowac do Deloitte jako doradca procesow wytwarzania oprogramowania i architektury technologicznej. Kto wie?

      Jednak to nie jest powod by proprawny proces zastepowac AI szczegolnie ze w fianasach jest audyt (na taki odpowiadlem jak bylem VP w dawno temu w Goldman Sachs i Fortress). Uwazasz ze AI, ktore napisaloby oprogramowanie umialoby odpowiedziec na taki audyt? Ciekaw jestem jak audytor rozmawialby z AI pytajac co sie zmienilo w kodzie od punktu A do punktu B i dlaczego.

      Kod sie pisze dla innych a nie dla siebie. Dlatego mamy jezyki, ktore maja ludzka notacje zeby zrozumiec algorytm (poza tym testy zautomatyzowane to dokumentacja oczekiwan) . Inaczej maszyny moglyby same pisac binarnie lub heksadecymalnie wprost w asemblerze (to robilem na przelomnie lat 80 i 90 dla kontrolerow, ale takze bibliotek na Intelu).

      AI ma zastosowanie glowne w zmudnych zadaniach operacyjnych jak utrzymanie techniczne czyli dochodzenie co moglo byc zrodlowym problemem, ale takze sprawdzenie, czy czegos sie nie przepuscilo oraz procesy takie jak wypuszczenie na produkcje – to sa zadania gdzie AI moze sie sprawdzic i zastapi ludzi a nie w kontekstach ludzkich gdzie jest regulacja prawna i odpowiedzialnosc w biznesie.

      -Maciek

      1. Nie boję się AI (stary jestem ale to nie ma nic do rzeczy) 🙂

        Używam AI w pracy bardzo dużo. Nie mam wątpliwości że jest to wspaniała technologia i … pomaga ludziom.

        Póki co ma bardzo ograniczony „context”, ale niesamowicie przyspiesza pracę developera jeśli masz konkretny problem do zaimplementowania, szczególnie jeśli to w języku który jest dla starego nowy 🙂

        Kilka razy już AI pomogło mi rozwiązać bardzo skomplikowane problemy, skomplikowane, wąskie ale głębokie 🙂 bardzo konkretne (np. W Javie w concurrent processing spawned processes using subsystems, in VSCode extension environment hung, and never finished, running POJO was no problem).

        Ten AI “context” będzie się rozszerzał i forsował postępy w algorytmach i technologii (widzieliście ostanie nowości z Nvidii?).

        LjF.

        1. A przejdziesz z tych problemow interview czy przyprowadzisz na rozmowe AI? Bo tak sie sklada ze z takich problemow w Java sam kandydatow odpytuje czasem?
          No spojrz dlaczego zawieszaja sie rownolegle struminie w Javie. Jest na ten temat arytkul. Ciekawe co powie AI. Ja to znam nie tylko z teorii, ale takze z praktyki jak pisalem oprogrmowanie we wlasnym startupie. Jakos nie siegalem po AI.

          Kontekst AI moze sie rozszerzac, ale nigdy nie osiagnie ludzkich zdolnosci, bo co najwyzej go sie uczy i nasladuje w przyspieszonym tempie a konteks ludzki jest nieskonczony.

          Poza tym jak pisalem z roboty mozna latwo wyleciec jak nie da sie odpowiedziec na audyt. Tak sie sklada ze audyt moze zamknac firme i tyle z biznesu. jak kiedys ubezpieczysz wlasna firme i bedziesz mial audyt (nikt nie chce z toba robic interesow finasowych jesli nie masz tego) to zrozumiez ze AI nie pomoze.

          -Maciek

  5. nie ma obawy, to kolejna ściema w ostatnich latach

    https://www.youtube.com/watch?v=xbf4BGIBENk

    Big Tech Is Faking AI
    A new report has shown that Amazon’s „Just Walk Out” AI checkout process is actually processed by 1,000 staff in India. Tech companies are under pressure to deliver AI, so we have fake AI announcements, fake AI demonstrations, and AI being the excuse for brazenly breaking the law and screwing over creators and customers. Google, Amazon, and …
    http://www.youtube.com

  6. AI jest teraz w modzie. Bez podowania konkretnych przykładów (żeby nie narazić się na konsekwencje) – widzę że się zdarza że do czegoś co jest zrobione normalnymi IF… Else…itp. dokleja się naklejkę AI i się to wtedy lepiej sprzedaje…

    Pozdrawiam grupę!

    Bartosz S.

    1. Bartosz,

      Dokladnie. Kiedys w Thomson Reuters mialem taki kod (pisany przez czlowieka). Piec tysiecy linii jedna klasa co miala wywalac wyniki obliczen gieldowych VAP (volume-at-price) na platformie Thomson Reuters (dzis sie inaczej nazywa). To byla „moja” aplikacja (pod moja opieka przejeta od kogos a dokladniej od goscia z doktoratem z fizyki co nie mial pojecia jak czytelnie i sensownie programowac i dlaczego tak trzeba) wlacznie z kilkoma innymi aplikacjami.

      Cala klasa to bylo else-if i sprawdzania dziesiatkow warunkow czesto nie majacych nic wspolnego ze soba. To podlega tzw. refactoring w metodach OOP/OOA (o tym wlasnie mowimy ale jak widac ludzie do tego uzywaja dzis AI) . Jak to zaproponowalem przerobic to szefowa i autor sie oburzyli. Po czym poszedlem i bez pytania wszytko to przerobilem na kupe prostrzych klas ze zdyscyplionwala odpowiedzialnoscia (zasady SOLID).

      Efekt tego byl taki ze nie muszac przlyepiac zadnej latki zaawansowanej technologii, gdy przyszlo do zmian to w tym kodzie zabieralo mi to ok. 2 godzin a nie dwa tygodnie (roumiejac konsekwencje zmian i upraszczajac testy).

      Smiali sie ze mnie jak chiacialem im zmeinic proces na zblizony do Goldman Sachs walczjac w to refactoring. Gdy dalem wymowienie (bo wracalem do GS tylko ze na wyzszy poziom VP) to dwa tygodnie przed odejsciem prosili mnie zebym ich nauczyl tego z czego sie wczesniej smiali. Dzis pewnie by szukali jak rozwiazac probelm uzywajac AI… czyli dodac kilkaset nowych else-if i szukac w ich gaszczu jak to wlasciwie dziala 😉

      -Maciek

      1. Tak AI chyba jest dobre do nauki nowego języka ogólnego frameworku, ostatnio się z Dashem męczyłem powinienem AI użyć.

        @Maciek Samsel ale to wszedzie tak jest, miałem na jednym wielkim projekcie popisany kod gdzie wszystko było static, każda metoda static, jakies pseudo classy gdzie wszystko jest jest publiczne, zaifowane że ekran ucieka setki spacji w prawo. Przerobiłem to na mnóstwo małych klas interface’ów pipeline’ów, każda methoda zwięzła robi jedną rzecz, ZERO IFs, wszystko visitor patter zamiast „if instanceof”, albo stream().filter()…zamiast ifów ale nie przeszło merge, zaskomplikowane…nie wiadomo czy działa, powiedziano że to trzeba rozbic na 20 MR.
        Jak ktoś tego nie zna tylko pisze skrypty (jedna wielka metoda) to tak jest…
        Wajchy każdy zrozumie po prostu 🙂
        if(wajchaA){
        if(wajchaB && !wajchaC){
        if(wajchaD) {
        continue;
        }
        if(wajchaE) break;

        1. Bartosz,

          Rob mniejsze zmiany i podziel wedlug kryteriow. Za kazdym razem rob merge. Robienie refactroringu na duza skale bez wielokrotnego merge, commit, push nie jest dobra praktyka. Ja zalecam developerom jak najczestsze zmiany w SCM czyi raz dziennie a nie dluzej niz raz na dwa dni i zawsze przed weekendem lub urlopem… a nawet przed jakims osobistym wydarzeniem. W ostatnim wypadku to nie zart. Zawsze kiedy jezdze na zawody strzeleckie (a robie to juz od 10 lat) robie commit-push z opisami a wspolpracownikom mowie co i jak. To samo polecam wszystkim co uprawiaja sporty ekstremalne. Ryzyko osobiste nie upowaznia do tego by wstrzymac kontynuacje biznesu.

          -Maciek

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Time limit is exhausted. Please reload CAPTCHA.