O co chodzi z rynkiem pracy IT?

LukeJL napisał(a):

meehow.cpp napisał(a):

Tak btw. mój przyjaciel robił praktycznie w pojedynkę projekt, o którym było w lokalnych mediach. Dosyć grubo AI, synteza dźwięku i analiza obrazu. Jego kod był miliardkroć czytelniejszy w proof-of-concept niż produkcyjny, komunikujących się tam developerów pracujących w zespołach. ;)

Ale to chyba jest sytuacją oczekiwaną? Więcej programistów = więcej entropii. Tak zawsze chyba było, skoro utarło się przysłowie "gdzie kucharek sześć, tam nie ma gdzie jeść".

Ideą projektów zespołowych nie jest to, żeby kod był super czytelny, tylko żeby zrobić coś dużego, większego niż to, co byłby w stanie zrobić pojedynczy programista. To normalne, że taki projekt pisany w ileś osób będzie tworzony chaotycznie, a architektura jego przypominać będzie pisane na kolanie big ball of mud.

Jeśli w projekcie znajduje się senior czy mid z dobrymi chęciami, to może spróbować zrobić z tym porządek, nadać projektowi styl, zakazić programistów dobrymi praktykami, ale to będzie taka trochę walka z wiatrakami. Może też się tak zdarzyć nadgorliwość, że ktoś za bardzo jest do przodu, a wtedy będziemy mieli do czynienia ze zwykłym przeinżynierowaniem i zaciemnianiem kodu. A wszystko w imię źle pojętych "dobrych praktyk".

Czyli trzeba wyważyć. I myślę, że rekrutacje powinny badać też skille miękkie, umiejętność pracy w zespole, bo to się przydaje. Programiści żyją w przekonaniu, że technikalia są najważniejsze, jednak prawda jest taka, że pracodawcom wystarczy zwykle ktoś, kto będzie pisać działający spaghetti kod, jednak będzie to robić w sposób zgrany z innymi.

Ok, ale ideą też nie jest aby pakować sqlowe query w widoki lub zamiast zapoznać się z dokumentacją systemu i napisać plugin, dodawać katalog i klepać w nim masakrę od podstaw, do tego z takimi lukami. To tak jako przykład. Wcześniej wspomniany kolega musiał przepisywać od zera appkę która zarządzała playerem w pewnej hali widowiskowej. Stwierdził, że trudno tam mówić o błędach bo cały kod jest jednym wielkim błędem - a on jest bardzo łagodny w wypowiedziach i bardzo niekonfrontacyjny - przepisał w pojedynkę coś co pisał zespół i przy okazji załatał błędy.

@meehow.cpp: Nie wiem jaka jest teza twoich wypowiedzi. Że każdy system może napisać jedna osoba i w związku z tym umiejętność pracy w zespole jest pozbawiona jakiegokolwiek znaczenia? Czy, że jak masz w zespole kiepskich fachowców, to mogą siedzieć lata w projekcie i w najlepszym wypadku wyprodukować coś, co czasami będzie trochę działać, ale nie ma szans, żeby doprowadzić to coś do stanu kiedy działa?
Przecież oczywiste jest, że są kawałki kodu, którym pojedynczy programista nie da rady, bo jest za dużo do zrobienia w określonym czasie. Jak trzeba więcej rąk do pracy, to te ręce muszą się dogadać, jak podzielić robotę, jak nie wchodzić sobie w drogę, czy napisać to w C++, czy w PHP, czy użyć do przechowywania SQL, czy NoSQL. Oczywiste też jest, że jak jest zespół, który albo ogólnie nie ma skilla, albo nie potrafi się dogadać, to nie jest w stanie wyprodukować nawet najprostszego kawałka działającego kodu.

Ta historia znaczy tylko tyle, że do projektu wzięto patałachów albo że kolega był genialny, a nie że ta historia to bzdura, a nie że masz rację

ToTomki napisał(a):

Ta historia znaczy tylko tyle, że do projektu wzięto patałachów albo że kolega był genialny, a nie że ta historia to bzdura, a nie że masz rację

Widziałem taka sytuację. A w zasadzie to żona widziała. Tylko nie wiem czego to dowodzi że czterech juniorów próbowało stworzyć system przez pół roku a potem drugie pół roku jeden senior przepisywał to jeszcze raz, ale tym razem żeby działało bez crashy na produkcji

Takie historie kończą się zwykle tym, że autor kodu odchodzi z projektu, a po kilku miesiącach okazuje się, że tego projektu nie da się utrzymywać/nie do końca odpowiada potrzebom, w rezultacie zespół robi projekt znowu od nowa, tym razem zespołowo. Ew. ten "genialny" kod okazuje się wkrótce przykrym legacy, którego ciężko się pozbyć.

Nie wiem z czego to wynika, bo przecież w świecie open source pełno jest projektów rozwijanych głównie przez jedną osobę i są to super fajne projekty. Nawet komercyjnie mamy świetne produkty tworzone przez jedną osobę (Sublime Text[1]).

Jednak w świecie programowania typowo pracowego, gdzie soft się tworzy w zespołach na zlecenie kogoś z góry, to samowolka właśnie mi się kojarzy z mocną partyzantką, gdzie ktoś sobie coś wymyślił, mocno odleciał, a potem trzeba albo z tego korzystać (mimo że niewygodne), albo przepisywać.

[1] nie uważam, że Sublime Text jest dobrym edytorem do programowania w 2022 roku, jednak doceniam ogólne wykonanie jako super szybkiego fikuśnego notatnika z unikalnym designem (na którym się wzorują inne edytory).

albo autor odchodzi zespołu albo jest do tego zmuszony a młodzi zdolni z wielkich ośrodków stwierdzają że wersję 2.0 napiszą w czymś o czym włąśnie przeczytali w reklamie.
Klienci cały czas używają wersji 1.0 bo 2,0 się nie da

@LukeJL: Wynika to z tego, że projekty OSS robią za darmo ludzie, którzy chcą to robić. Chcą też ten kod nie tylko produkt komuś pokazać. W dodatku, w takich typowych projektach OSS jest duża rotacja i to wymaga kodu, który musi być przyzwoitej jakości, bo inaczej projekt umiera, jako nie dający się rozwijać. Według mnie, tym czynnikiem X, który sprawia, że w przeciwieństwie do znakomitej większośći "pracowych" projektów OSS wygląda inaczej są zwyczajnie ludzie, który chcą i potrafią. No i nikt im nie narzuca tony kontrproduktywnych standardów wciskanych przez zgraję konsultantów jako prawdy objawione.
Powiedzmy, że jakiś produkt trafia do zespołu ogarniętych, szanujących swoją pracę ludzi, nawet jeżeli zaczynają pracować na w jakimś bagnie, to dogadają się, krok po kroku, czasami szybciej, czasami wolniej będą w stanie ten projekt wyprowadzić na prostą.
Co się stanie, jeżeli trafi to do jakiegoś zespołu z łapanki? Powiedzą, że się nie da, pomarudzą jak ktoś próbuje wskazać jakąś drogę to go zaszczekają hasłami typu "ale to nie my pisaliśmy". Nawet jak trafi się ktoś, komu zależy, to po jakimś czasie ucieknie, bo po co ma się kopać z koniem.

Jakiś czas temu zetknąłem się z projektem, powiedzmy ebook readera. W skrócie, projekt polegał na tym, że użytkownik miał się zalogować, pobrać bibliotekę dokumentów, jak pojawiło się coś nowego, albo jakaś aktualizacja, to miał sobie to pobrać do biblioteki lokalnej. Spotkania, na których próbowano mi wytłumaczyć dlaczego to jest bardziej skomplikowane niż mi się wydaje i na których powtarzano to co napisałem w poprzednim zdaniu trwały wiele godzin, ale serio nie dostrzegłem żadnej funkcji tego systemu, która sprawiłaby, ze to jest bardziej skomplikowane.
I może trywializuję problem, ale wydaje mi się, że napisanie modułu, który pobierze sobie z jakiegoś endpointa listę plików, porówna ją z lokalną listą plików i na podstawie różnicy w iluś tam równoległych wątkach pobierze to co trzeba nie jest specjalnym wyzwaniem, nawet jeśli trzeba obsłużyć jakieś zerwane połączenia, jest zadaniem na kilka, niż kilkanaście godzin pracy. Wiem, bo kiedyś pisałem, coś z grubsza podobnego i mam silne przekonanie, że implementacja zajęłaby mi mniej czasu niż słuchanie o tym jak bardzo złożony to jest problem.
Natomiast powód, dla którego się o tym dowiedziałem jest prawdziwą perełką. Ktoś to już napisał, przetestował, wysłał do klienta (dużego) i dostał zwrotkę, że "sorki, nie działa" i to z testów wewnętrznych klienta, takich iteracji było kilka. Ostatecznie "biznes" zaczął szukać pomocy u innych zespołów w firmie. Ostatecznie padło na jeden z moich, bo akurat podobny techstack, jak w tym produkcie. Zajrzeli w kod (jak już dostali dostęp) i okazało się, że w kodzie testy nic nie testują, pamięć cieknie, synchronizacja między wątkami nie istnieje, nie wiadomo co zostało pobrane, kiedy i z jakim skutkiem.

Dla tego, trochę się nie zgadzam, kiedy słyszę, że mam wygórowane oczekiwania na rekrutacji, bo to bagno stworzyli ludzie, których ktoś niedbale zatrudnił. Możliwe, ze tego kogoś też ktoś zatrudnił nierozważnie.

A ja się przyznam, że utrzymując serwis przez ponad pół roku myślałem, że już poznałem w pełni projekt (w kontakcie z głównymi userami byłem regularnie, obsługiwałem tickety itd.), a potem przyszły testy UX nowego UI i aż mnie zamurowało jak zacząłem słuchać zwykłego usera testującego aplikację i wyjaśniającego jego tok rozumowania.

Bez tego typu spotkań mam wrażenie, że nie da się zrobić nic dobrego. A przynajmniej wiele osób nie potrafi. No i ja nie umiem, no przynajmniej nie idealnego

Przepraszam za spam ale może mi ktoś to potwierdzić/utwierdzić mnie w przekonaniu, że tak jest:

Osoba osoba = new Osoba("Kowalski");
list.add(osoba);
osoba.setName("Nowak");
osoba.getName()== list.get(0).getName();//jaki będzie wynik?

jaki będzie wynik i dlaczego? :D z tego co widzę nie musimy po tym manewrze osoba.setName("Nowak"); wrzucać zaaktualizowanej osoby jeszcze raz do Listy osób ponieważ list przechowuje referencje i tym samym dlatego mamy true po tym porównaniu?

Jak osoba, ktora z 4 YoE zawalila rozmowe na mida:

• Bagno w zeszlej pracy.
• Problemy zdrowotne.
• Depresja
• Stress od rozmowy.

W wyniku nie odpowiedziałem nawet na podstawowe pytania z Reactu, mimo pracy z nim przez 3 lata .

Rozne rzeczy sie dzieja w zyciu.

raczej upatrywalbym winy w tym ze jestes slaby i mimo tych 3 lat nic sie w sumie nie nauczyles

Rzucę wam jeszcze jedną wywrotową koncepcję - jak uważacie czy:
interview techniczne powinno być przed czy po interview miękkim?
Kolejność ma znaczenie?

A co to jest interview miękkie? Jeśli sprawdzenie umiejętności wysławiania się przez tzw. panią z HR, to powinno być przed technicznym.

Ja przez rozwiązywanie niektorych zadan rekrutacyjnych zacząłem wymagac pieniądzy za czas poświęcony na ich rozwiązywanie. Ostatnio dostałem zadanie do napisania obliczającej prowizje bankowe i mogłem je wykonać w dowolnej technologii. Wybrałem dowolna technologie i dostałem negatywny feedback, później przeanalizowałem to zadanie nie dało się tam niczego spieprzyć. Mogę się domyślić, że chodziło o napisanie o aplikacji mobilnej, ale było przecież napisane w dowolnej technologii. Przez ludzi, którzy nawet nie potrafią opisać poprawnie zadania. Pracowałem w kilku branżach inżynieryjnych, w żadnej z nich nie spotkałem się z zadaniami rekrutacyjnymi. Poza tym programista to nie jest jakaś elita zawodów. W Niemczech regularnie widzę różne oferty pracy prostych zawodów typu: malarz, tynkarz za dużo większe pieniądze i to do tego z zakwaterowaniem. Także jak ktoś mi mówi, że chce zadanie to ja się pytam ile za nie zapłaci.