Będąc seniorem..

somekind napisał(a):

Problemy, których kilkuosobowe firmy nawet nie powąchają, bo mają za mało kasy, wiedzy i doświadczenia.

Owszem, małe firmy nie są po prostu wstanie zatrudnić tylu bezużytecznych ludzi, co korporacje. A, że ludzie nie lubią czuć się bezużyteczni, to próbują sobie wymyślać pracę. Bezużyteczny kierownik wymyśli 10 nowych typów raportów, 20 nowych typów wykresów i 30 typów spotkań. Bezużyteczny architekt wymyśli chorą architekturę.

Jaki to ma związek z tematem?
Co mają wspólnego ambitne problemy, o których piszę, z zatrudnianiem bezużytecznych ludzi?

GutekSan napisał(a):

Co mają wspólnego ambitne problemy, o których piszę, z zatrudnianiem bezużytecznych ludzi?

Korporacje.

somekind napisał(a):

GutekSan napisał(a):

Co mają wspólnego ambitne problemy, o których piszę, z zatrudnianiem bezużytecznych ludzi?

Korporacje.

A jakiś związek przyczynowo-skutkowy?

GutekSan napisał(a):

somekind napisał(a):

GutekSan napisał(a):

Co mają wspólnego ambitne problemy, o których piszę, z zatrudnianiem bezużytecznych ludzi?

Korporacje.

A jakiś związek przyczynowo-skutkowy?

Związek oczywiście jest. Brak doświadczenia w pracy w korporacjach -> niezrozumienie postu.

mr_jaro napisał(a):

Pendzoncy jelen napisał(a):

a masz jakis swoj duzy biznes albo maly ale obiecujacy ?

Mam firme, pracuje na kontrakcie a po godzinach robię swoje projekty, które niedługo ujrzą światło dzienne.

chyba chodziło o to, czy jesteś w stanie zwolnić i nie wiem poświęcić więcej czasu na bardziej przyziemne sprawy, jak dziewczyna i dzieci,

i też pewnie nie chodzi o to, żeby je mieć tylko o to, żeby sobie pożyć zanim zostaniesz 50-letnim zgredem;

praca 7 godzin, 2 godziny może na dokształcanie, a reszta to rodzina i wydawanie "seniorskiej" forsy

GutekSan napisał(a):

A jakiś związek przyczynowo-skutkowy?

Związek przyczynowy opisałem poprzednio - ludzie, którzy się nudzą, wymyślają sobie robotę sami.

somekind napisał(a):

GutekSan napisał(a):

A jakiś związek przyczynowo-skutkowy?

Związek przyczynowy opisałem poprzednio - ludzie, którzy się nudzą, wymyślają sobie robotę sami.

Ale ja nie piszę ani o ludziach, którzy się nudzą.

No Ty nie, dlatego ja napisałem, żeby przedstawić drugą stronę medalu.

somekind napisał(a):

No Ty nie, dlatego ja napisałem, żeby przedstawić drugą stronę medalu.

To nie jest żadna druga strona. To jest uwaga nie mająca nic wspólnego z tematem.

Twój post też nie ma z nim związku, podobnie jak post @mr_jaro na który odpowiadałeś. :P

Napisałeś o tym, że w korporacjach są szanse rozwiązywania problemów technicznych przy wytwarzaniu oprogramowania przetwarzającego ogromne ilości danych i to jest prawda. Ale z drugiej strony w korporacjach występują też problemy wynikające z ociężałości organizacji i przerostu zatrudnienia oraz procesów.

somekind napisał(a):

Twój post też nie ma z nim związku, podobnie jak post @mr_jaro na który odpowiadałeś. :P

Napisałeś o tym, że w korporacjach są szanse rozwiązywania problemów technicznych przy wytwarzaniu oprogramowania przetwarzającego ogromne ilości danych i to jest prawda. Ale z drugiej strony w korporacjach występują też problemy wynikające z ociężałości organizacji i przerostu zatrudnienia oraz procesów.

Argument w stylu: "A u was to Murzynów biją"

To nie jest argument. To jest pokazanie drugiej strony medalu.

somekind napisał(a):

To nie jest argument. To jest pokazanie drugiej strony medalu.

To nie jest argument ani druga strona medalu. To wytknięcie jakiejś wady korporacji, po tym jak padło stwierdzenie, że korporacje dają szansę na pracę przy ambitniejszych projektach niż małe firmy. Dodam, że wady bez związku z wspomnianą zaletą, mimo że próbowałeś ten związek zasugerować pisząc:
Owszem, małe firmy nie są po prostu wstanie zatrudnić tylu bezużytecznych ludzi, co korporacje
Krótko mówiąc, standardowo marudzisz na korpo, bo ktoś ośmielił się napisać o nich coś pozytywnego.

A tak w ogóle to z poziomu programisty nie jesteś w stanie ocenić kto jest dla korpo użyteczny a kto nie. A nawet jeśli zdarzają się tacy, to co Cie to obchodzi? Programistów to w zasadzie nie dotyka, wręcz przeciwnie - pewna nadmiarowość powoduje, że nie jestem wyciskany jak cytryna.

z tego co kojarze to @katelx pracuje w korpo(bank) i ma chyba dosc ciekawe problemy ktore ciezko znalezc w malych firmach, Kojarze z drugiej strony ze jakas niezbyt duza firma robi forecasty odnosnie sprzedazy dla Tesco z wykorzystaniem AI, albo inna firemak zbiera wiekszosc cen lotow i informacji z nimi zwiazanych dla jednej z lini lotniczych (dziennie miela 10TB danych i ponoc przy obecnym rozwiazaniu maja sporo zapasu mocy). Tak wiec w malych firmach tez znajduja sie ciekawe problemy - tyle ze robione sa dla wiekszych firm :)

GutekSan napisał(a):

To nie jest argument ani druga strona medalu. To wytknięcie jakiejś wady korporacji, po tym jak padło stwierdzenie, że korporacje dają szansę na pracę przy ambitniejszych projektach niż małe firmy.

No i wskazanie negatywnej cechy czegoś, gdy ktoś pokazuje zaletę tegoż, to jest właśnie ukazanie drugiej strony medalu.
Nie próbowałem obalić faktu, że w korporacjach zdarzają się ciekawe projekty, jedynie wytknąłem jedną z ich wad. Tak po prostu dla równowagi.

A tak w ogóle to z poziomu programisty nie jesteś w stanie ocenić kto jest dla korpo użyteczny a kto nie.

Jestem w stanie stwierdzić, kto mi utrudnia życie i spowalnia pracę. Jeśli widzę, że dana osoba zajmuje się tylko i wyłącznie utrudnianiem i spowalnianiem pracy innych ludzi, to raczej nie jest użyteczny dla firmy.

A nawet jeśli zdarzają się tacy, to co Cie to obchodzi? Programistów to w zasadzie nie dotyka, wręcz przeciwnie - pewna nadmiarowość powoduje, że nie jestem wyciskany jak cytryna.

Bezsensowna architektura i nakaz stosowania idiotycznych albo przestarzałych frameworków nie dotykają programistów?
Może Ty nie lubisz programować, więc na rękę Ci ze wszystkimi spowalniaczami pracy oraz korporacyjne architektury, w których nawet strona wizytówka wymaga load balancera i hurtowni danych, ale ja po prostu lubię tworzyć działający soft przy minimalnym nakładzie kodu i czasu.

Czy jeśli już się dobije ten maxymalny level i zostanie seniorem w danej technologii, czy jest to spełnienie zawodowe?

zalezy co dla kogo jest spelnieniem zawodowym ale z obserwacji wnioskuje ze dobrzy koderzy raczej nie gonia za tytulami, to bardziej efekt uboczny

Czy jesteście spełnieni życiowo?

nie jestem seniorem wiec jeszcze nie ;);)

Czy raczej dążycie do zostania drugim Bill'em Gate'sem

nie potrafie stworzyc nic szczegolnie przydatnego dzialajac na wlasna reke i tez nie mam takich ambicji

"Czy jesteście spełnieni życiowo? " - chodzi Ci o moment: "zrobiłem już wszystko co chciałem i mogłem zrobić, a teraz już mogę umierać"?

somekind napisał(a):

No i wskazanie negatywnej cechy czegoś, gdy ktoś pokazuje zaletę tegoż, to jest właśnie ukazanie drugiej strony medalu.

Nie. Określenie "druga strona medalu" oznacza, że negatywna cecha jest nierozerwalnie związana z pozytywną i istnieje między nimi związek przyczynowo-skutkowy. Ty tego nie wykazałeś, a jedynie dostrzegłeś, że obie cechy dotyczą abstrakcyjnego bytu jakim jest korporacja, co nawet nie dowodzi ich współistnienia w jednej konkretnej organizacji.

A tak w ogóle to z poziomu programisty nie jesteś w stanie ocenić kto jest dla korpo użyteczny a kto nie.

Jestem w stanie stwierdzić, kto mi utrudnia życie i spowalnia pracę. Jeśli widzę, że dana osoba zajmuje się tylko i wyłącznie utrudnianiem i spowalnianiem pracy innych ludzi, to raczej nie jest użyteczny dla firmy.

I znowu to przeświadczenie o wyższości i nieomylności: "mnie coś przeszkadza, więc jest bezużyteczne". Gładko przeszedłeś od "przeszkadza mi" do "przeszkadza innym ludziom". Tobie się chyba wydaje, że firma to Ty.

A nawet jeśli zdarzają się tacy, to co Cie to obchodzi? Programistów to w zasadzie nie dotyka, wręcz przeciwnie - pewna nadmiarowość powoduje, że nie jestem wyciskany jak cytryna.

Bezsensowna architektura i nakaz stosowania idiotycznych albo przestarzałych frameworków nie dotykają programistów?

To są problemy, które mogą dotyczyć zarówno dużych jak i małych firm i wynikają przede wszystkim z:

• wysokich kosztów operacyjnych migracji
• braku możliwości przewidzenia kierunku rozwoju produktu, gdy dokonywano wyboru
• braku właściwych ludzi na danych stanowiskach
• utrzymaniu pewnego standardu na wyższym poziomie ogranizacyjnym

a nie z powodu nadmiaru ludzi.

Sorry, ale nie widzę dalszego sensu dyskusji z osobą, która nie chce zadać sobie trudu wyjrzenia nieco poza swoje biurko programisty.

Wesoły Mleczarz napisał(a):

Czy jesteście spełnieni życiowo?

pewnie ze tak, dobijasz lvl seniora, potem wbijasz na 4p i mozesz zaczac pluc na wszystkich, tak jak 3/4 tutaj;)

GutekSan napisał(a):

Nie. Określenie "druga strona medalu" oznacza, że negatywna cecha jest nierozerwalnie związana z pozytywną i istnieje między nimi związek przyczynowo-skutkowy.

Podaj proszę źródło takiej definicji tego związku frazeologicznego, w której związek przyczynowo-skutkowy jest wymagany.

Ty tego nie wykazałeś, a jedynie dostrzegłeś, że obie cechy dotyczą abstrakcyjnego bytu jakim jest korporacja, co nawet nie dowodzi ich współistnienia w jednej konkretnej organizacji.

Ale ja nigdzie nie pisałem, że tak jest w każdej korporacji.
A Ty twierdzisz, że ciekawe projekty są w każdej?

I znowu to przeświadczenie o wyższości i nieomylności: "mnie coś przeszkadza, więc jest bezużyteczne". Gładko przeszedłeś od "przeszkadza mi" do "przeszkadza innym ludziom". Tobie się chyba wydaje, że firma to Ty.

Nie, to Tobie się wydaje, że mi się wydaje. Ja widzę ogromną różnicę między nudnymi kwestiami organizacyjnymi, które w firmie trzeba robić, a wymyślaniem spotkań, raportów i procedur na siłę.
Moje "przeświadczenie o nieomylności" wynika z moich doświadczeń. W firmach średniej wielkości, w których pracowałem, ludzie z mojego punktu widzenia bezużyteczni i zajmujący jedynie czas ludzi faktycznie wytwarzających oprogramowanie, byli często zwalniani. Najwyraźniej nie tylko ja byłem w stanie ocenić ich pracę negatywnie, widocznie góra też była w stanie zauważyć brak efektów.

To są problemy, które mogą dotyczyć zarówno dużych jak i małych firm i wynikają przede wszystkim z:

• wysokich kosztów operacyjnych migracji
• braku możliwości przewidzenia kierunku rozwoju produktu, gdy dokonywano wyboru
• braku właściwych ludzi na danych stanowiskach
• utrzymaniu pewnego standardu na wyższym poziomie ogranizacyjnym

Nie mogą, bo małe firmy nie mają po prostu tylu pracowników na zmarnowanie. Jeśli dzięki architekturze i narzędziach potrzeba 10 razy więcej osób niż normalnie, to mała firma nawet nie zacznie realizować takiego projektu.
Ponadto tylko duże firmy stać na zatrudnienie dziesiątek osób i nie dawanie im projektów przez pół roku.

I jeśli ktoś chce pracować w kupie z powodu wysokich kosztów migracji, jego największym programistycznym marzeniem jest utrzymywanie standardu na wyższym poziomie organizacyjnym oraz marzy o pracy z niewłaściwymi ludźmi na wysokich stanowiskach, to mi nic do tego. Na pewno znajdzie swój raj w jakiejś korporacji.

Sorry, ale nie widzę dalszego sensu dyskusji z osobą, która nie chce zadać sobie trudu wyjrzenia nieco poza swoje biurko programisty.

Typowa stwierdzenie kogoś, kto jest przekonany o swojej wyższości i nieomylności.

somekind napisał(a):

To są problemy, które mogą dotyczyć zarówno dużych jak i małych firm i wynikają przede wszystkim z: (...)

Nie mogą, bo małe firmy nie mają po prostu tylu pracowników na zmarnowanie.

Aha, czyli twierdzisz, że małe firmy są wolne od problemów bezsensownej architektury i przestarzałych frameworków? I znowu magiczne łączenie wszystkiego z pracownikami na zmarnowanie...

Jeśli dzięki architekturze i narzędziach potrzeba 10 razy więcej osób niż normalnie, to mała firma nawet nie zacznie realizować takiego projektu.

Tylko, że to nie architektura i narzędzia są pierwotnym źródłem tej potrzeby tylko skala problemu do zrealizowania. I o tym pisałem od samego początku.

I jeśli ktoś chce pracować w kupie z powodu wysokich kosztów migracji, jego największym programistycznym marzeniem jest utrzymywanie standardu na wyższym poziomie organizacyjnym oraz marzy o pracy z niewłaściwymi ludźmi na wysokich stanowiskach, to mi nic do tego. Na pewno znajdzie swój raj w jakiejś korporacji.

Albo w 5-osobowym Januszsofcie.

GutekSan napisał(a):

Aha, czyli twierdzisz, że małe firmy są wolne od problemów bezsensownej architektury i przestarzałych frameworków? I znowu magiczne łączenie wszystkiego z pracownikami na zmarnowanie...

Tak, firma, która ma 10 programistów nie będzie realizowała projektu, który wymaga 50.
Tę magię nazywamy matematyką.

Tylko, że to nie architektura i narzędzia są pierwotnym źródłem tej potrzeby tylko skala problemu do zrealizowania. I o tym pisałem od samego początku.

No właśnie nie. Ja cały czas piszę o przypadkach, w których źródłem problemów jest architektura i technologia, a nie skala problemu.

Albo w 5-osobowym Januszsofcie.

Bo 5osobowe Januszsofty znane są z utrzymywania standardów na wyższym poziomie organizacyjnym. :D

somekind napisał(a):

GutekSan napisał(a):

Aha, czyli twierdzisz, że małe firmy są wolne od problemów bezsensownej architektury i przestarzałych frameworków? I znowu magiczne łączenie wszystkiego z pracownikami na zmarnowanie...

Tak, firma, która ma 10 programistów nie będzie realizowała projektu, który wymaga 50.

Ja o niebie, ty o chlebie. Ja tu mówię o problemach z architekturą a nie o realizowaniu dużych projektów.

Tylko, że to nie architektura i narzędzia są pierwotnym źródłem tej potrzeby tylko skala problemu do zrealizowania. I o tym pisałem od samego początku.

No właśnie nie. Ja cały czas piszę o przypadkach, w których źródłem problemów jest architektura i technologia, a nie skala problemu.

Tylko, że wybór takiej a nie innej architektury czy technologii zależy właśnie od skali problemu.

Albo w 5-osobowym Januszsofcie.

Bo 5osobowe Januszsofty znane są z utrzymywania standardów na wyższym poziomie organizacyjnym. :D

No właśnie nie, i dlatego opisywana przez Ciebie osoba znajdzie tam swoje miejsce.

GutekSan napisał(a):

Ja o niebie, ty o chlebie. Ja tu mówię o problemach z architekturą a nie o realizowaniu dużych projektów.

Od początku pisałem o problemach z architekturą.

Tylko, że wybór takiej a nie innej architektury czy technologii zależy właśnie od skali problemu.

Tak jest w idealnym świecie. A czasami wynika z tego, że albo wszystkie projekty w danym korpo robi się wg jednej architektury, co zazwyczaj nie ma sensu (czyli trzymamy standardy na poziomie organizacji), albo z tego, że architekci znają tylko jedną architekturę, bo od 20 lat się nie rozwijają (czyli niewłaściwi ludzie na niewłaściwych miejscach).

No właśnie nie, i dlatego opisywana przez Ciebie osoba znajdzie tam swoje miejsce.

Że niby osoba pragnąca utrzymywania standardów korporacyjnych znajdzie miejsce w miejscu, w którym się tego nie robi.
Nawet nie chcę wiedzieć jak do tego doszedłeś.

somekind napisał(a):

GutekSan napisał(a):

Ja o niebie, ty o chlebie. Ja tu mówię o problemach z architekturą a nie o realizowaniu dużych projektów.

Od początku pisałem o problemach z architekturą.

FACEPALM

Albo trolujesz albo już się totalnie pogubiłeś. Streszczenie:

• Ty: Duże korpo zatrudniają bezużytecznych ludzi
• Ja: Beużyteczni ludzie Ci nie powinni przeszkadzać
• Ty: Bezsensowna architektura i nakaz stosowania idiotycznych albo przestarzałych frameworków mają nie przeszkadzać programistom?
• Ja: To są problemy, które mogą dotyczyć zarówno dużych jak i małych firm i nie wynikają z zatrudnienia bezużytecznych ludzi.
• Ty: Nie mogą [dotyczyć], bo małe firmy nie mają po prostu tylu pracowników na zmarnowanie.
• Ja: Aha, czyli twierdzisz, że małe firmy są wolne od problemów bezsensownej architektury i przestarzałych frameworków?
• Ty: Tak [są wolne], firma, która ma 10 programistów nie będzie realizowała projektu, który wymaga 50
• Ja: Mówię o problemach z architekturą a nie o realizowaniu dużych projektów
• Ty: Od początku pisałem o problemach z architekturą

Konia z rzędem za wskazanie tu Twoje jednej, sensownej odpowiedzi.

No właśnie nie, i dlatego opisywana przez Ciebie osoba znajdzie tam swoje miejsce.

Że niby osoba pragnąca utrzymywania standardów korporacyjnych znajdzie miejsce w miejscu, w którym się tego nie robi.
Nawet nie chcę wiedzieć jak do tego doszedłeś.

Wymieniłeś 3 rzeczy. Chęć utrzymywania standardów korporacyjnych to tylko jedna z nich. Dwie pozostałe (praca w kupie, praca z niewłaściwymi ludźmi) znajdzie w Januszsofcie.

Jeśli małe firmy nie potrafią optymalnie gospodarować swoimi zasobami to dlaczego to one są duże, a nie te małe, które gospodarują lepiej i z małych powinny stać się dużymi, bo są bardziej konkurencyjne...? Hm...

GutekSan napisał(a):

Konia z rzędem za wskazanie tu Twoje jednej, sensownej odpowiedzi.

Wyciąłeś część rozmowy i próbujesz coś udowodnić. Dla przypomnienia, zaczęło się od:

Mam na myśli rozwiązywanie prawdziwych problemów technicznych, które mają działać w ogromnej skali, przetwarzać terabajty danych, wykorzystywać nowoczesne algorytmy i narzędzia.

I mojej odpowiedzi:

Owszem, zdarzają się i takie. Zdarzają się też "problemy techniczne" wynikające z tego, że jakiś architekt wymyślił, że aplikacja ma mieć 9 warstw, a logikę i tak trzymać w triggerach w bazie.

A więc, od początku pisałem o problemach technicznych powodowanych przez architekturę. Problemach, których konsekwencją jest np. znacznie większe zapotrzebowanie na zasoby ludzkie - bo jeśli przez architekturę wymaga ona 10 razy więcej pracy, to do wykonania małej aplikacji potrzeba np. 50 osób zamiast 5. Logiczne jest zatem, że w małej firmie (np. takiej, która ma 10 programistów w ogóle, a nie 50 na mały projekt) do takiej sytuacji nie dojdzie. (Aczkolwiek może dojść do podobnej - projekt do zrobienia w 3 miesiące przez jedną osobę, będzie tworzony przez tę osobę latami.)
Kolejnym powodem, dla którego w małych firmach nie dochodzi do tego typu patologii jest to, że w małych firmach nie występują raczej w ogóle architekci z wieży z kości słoniowej. (Aczkolwiek występują zwyczajnie niekompetentni.)
Tak więc, przez błędy architektoniczne mały projekt (taki, który dałoby się zrealizować nawet w małej firmie) w korporacji może stać się dużym "problemem technicznym". A jak się użyje przestarzałych technologii albo nieracjonalnych architektur, to będą to nawet "problemy wydajnościowe".

Nigdy nie przeczyłem, że w dużych firmach nie ma ciekawych projektów i prawdziwych problemów technicznych (takich, o które Tobie chodziło). Nie pisałem nic o małych firmach, ani o tym że są super, ani o tym, że są wolne od problemów architektonicznych i technologicznych, ani nigdy nie twierdziłem, ze ich nie mają (bo mają, tylko nie takie wynikające z przerostu zatrudnienia i nadmiaru niekompetentnych architektów). Ty za poczułeś się urażony tym, że napisałem coś złego o korporacjach ukazując drugą stronę medalu "problemów technicznych", dopowiedziałeś sobie jakieś moje argumenty i je kontrargumentujesz w stylu "u was biją murzynów". (Janusze to, Janusze tamto, jakbym ja cokolwiek pozytywnego w tym temacie pisał.)

A teraz jeszcze twierdzisz, że niczego nie rozumiesz... tzn. ja wierzę, ale swojej winy w tym nie widzę.

Biały Knur napisał(a):

Jeśli małe firmy nie potrafią optymalnie gospodarować swoimi zasobami to dlaczego to one są duże, a nie te małe, które gospodarują lepiej i z małych powinny stać się dużymi, bo są bardziej konkurencyjne...? Hm...

Jeśli mała firma stanie się dużą firmą, to będzie miała problemy dużych firm, takie jak np. brak wystarczającej kontroli i marnowanie zasobów.

(Aczkolwiek może dojść do podobnej - projekt do zrobienia w 3 miesiące przez jedną osobę, będzie tworzony przez tę osobę latami.)

Ano. Widziałem już duże projekty robione przez jedną, dwie osoby, w których wszystko się robiło totalnie naokoło i były tak przeinżynierowane, że pełne wejście w taki projekt okazywało się po prostu niemożliwe, z tego powodu, że zanim się doszło, w jaki sposób zrobić rzecz X trzeba było poświęcić całe dnie czasem na rozmowach technicznych z autorem projektu i na próbach wczytania się w jego kod.

Jednocześnie takie projekty były pełne legacy kodu czy pojawiały się objawy big ball of mud (Co mnie nie dziwi. Przeinżynierowany projekt często nabiera entropii z czasem i naiwna przeinżynierowana architektura nie wytrzymuje, wiele rzeczy trzeba zahakować albo zmienić/zrefaktorować).

Tylko, że przy tej sztucznie nadmuchanej skali nie da się jednak zmienić czegoś w 100%, więc dochodzi do tego, że w jednym projekcie mamy jedne moduły zrobione wg wczesnych założeń, obok tego mamy inne moduły zrobione wg kolejnych nowszych założeń, a oprócz tego jeszcze inne moduły zrobione wg najnowszych założeń (nawet niekoniecznie zmiany są enkapsulowane na poziomie modułu, bo i w środku modułu można spotkać kod stary przeplatający się z nowym...). Takie trochę wykopaliska archeologiczne.

A do takiego burdelu spokojnie może doprowadzić jedna czy dwie osoby, które zostają pozostawione samopas przez kilka, kilkanaście miesięcy. Nie potrzeba do tego całej grupy ludzi.

bo jeśli przez architekturę wymaga ona 10 razy więcej pracy, to do wykonania małej aplikacji potrzeba np. 50 osób zamiast 5.

Ale fakt, że duże firmy idą w ilość i na wszystkie bolączki (np. projekt się opóźnia) mają jedną odpowiedź: zatrudnijmy więcej ludzi. Bo co może pójść źle.
https://en.wikipedia.org/wiki/Brooks%27s_law

Nawet nie myślą o optymalizacji, bo mają hajs, więc dla nich jest zatrudnić potem 20 studentów do utrzymywania spaghetti to normalka. Więc nie muszą się starać, żeby rozwiązania były sensowne. Nie mają tego ograniczenia budżetowego. To trochę jak ludzie którzy mają tyle hajsu, że palą banknoty dla zabawy, bo po prostu mogą. Stać ich.