Szerintem ennek az egyik oka az, hogy elvárjuk, minden fusson mindenen. Nem csak minden java program minden jvm-en, minden architektúrán, de minden weboldal fusson az elmúlt 5 év minden böngészőverzióján, és a microsoft word az elmúlt 5 év összes PC konfigurációján.
Minnél több platformra optimalizálsz egyszerre, annál komplexebb a feladat. Emiatt történnek olyanok, hogy az egyszerű C fordító újabban először LVM-re fordít, majd onnan gépi kódra. És mivel az új hardware arhcitektúrák sokkal bonyolultabbak, mint amire a C-t írták, rengeteget optimalizál közben. Így lesz a gcc forráskódja többszázezer sor, és ezért fut sokáig.
A Mythical man-monthban volt szó arról, hogy egy programot megírni X effort, azt megbízhatóvá, mindenhol deoployolhatóvá tenni 100X effort. Ezt a könyvet lasan 50 évvel ezelőtt írták, a hardware fejlőség miatt ez a 100-as szorzó még több lett. És ezt sikerült automatizálni a mindenféle toolokkal, csak ennek az automatizálásnak ára van.
A cég működéséből meg az adatokból arra következtetek, hogy ennyi embert kerestek meg, nem azt, hogy ennyi jelentkezett. Illetve volt egy ilyen is, hogy "felháborodott, hogy nem ajánlattal hívtam, csak érdeklődéssel" (vagy valami hasonló). Sokminden torzít, az biztos, meg persze ez egyetlen rekrúter cég, így a mintavétel is nagyon kicsi.
Ez amúgy így kicsit elhamarkodott, csak számból következtetni. Pl tesztelők mennyisége simán lehet azért ilyen magas, mert abból mindig vannak jelentkezők, elérhető emberek. (Ha kirakok egy manuális tesztelő pozíciót lehet 10x ember jelentkezik rá egy fejlesztőihez képest, főleg ha junior szintre)
Én nagyon vágyom már arra, hogy egy projektben ki tudjam próbálni a #noestimates-t (Vasco Duarte prezije a témában, odatekertem a fontos részhez: https://youtu.be/7ud-4bKJr8k?t=2141) - ez ugyanis azt mondja, hogy ha csupán a feladatok mennyiségéből akarunk előrejelezni, akkor még az is meglehet, hogy pontosabb lesz, de amit mindenképpen nyerünk az az, hogy nem szórunk el egy csomó időt a becslésre.
Hallottam már olyan projektről, amelyikben a végeláthatatlan backlogot minden tervezésnél újra meg újra előveszik és becslik - egészen barbár módja az idő- és türelem pazarlásának.
Egyébként ha jól tudom, a legújabb scrum revízióban már nincs is benne a becslés.
Egy hasonlót pont láttam a napokban, ott ő 3D nyomtatta a PC házat és a monitort is hozzá, de szintén Raspberry PI ketyeg benne: https://youtu.be/V-pACEENHBw
El ne felejtsem, a bloat másik oka a nettó inkompetencia.
Szerintem ennek az egyik oka az, hogy elvárjuk, minden fusson mindenen. Nem csak minden java program minden jvm-en, minden architektúrán, de minden weboldal fusson az elmúlt 5 év minden böngészőverzióján, és a microsoft word az elmúlt 5 év összes PC konfigurációján.
Minnél több platformra optimalizálsz egyszerre, annál komplexebb a feladat. Emiatt történnek olyanok, hogy az egyszerű C fordító újabban először LVM-re fordít, majd onnan gépi kódra. És mivel az új hardware arhcitektúrák sokkal bonyolultabbak, mint amire a C-t írták, rengeteget optimalizál közben. Így lesz a gcc forráskódja többszázezer sor, és ezért fut sokáig.
A Mythical man-monthban volt szó arról, hogy egy programot megírni X effort, azt megbízhatóvá, mindenhol deoployolhatóvá tenni 100X effort. Ezt a könyvet lasan 50 évvel ezelőtt írták, a hardware fejlőség miatt ez a 100-as szorzó még több lett. És ezt sikerült automatizálni a mindenféle toolokkal, csak ennek az automatizálásnak ára van.
Tűpontos és 2018 óta a helyzet csak rosszabb lett :(
Lásd még: https://blog.kolboid.eu/tervezesi-tevedes-optimizmus-torzitas-hofstadter-torvenye/
Egy másik, de hasonló topic alatt már meg lett említve, gondoltam érdemes lehet itt is: https://lorinczorsolya.hu/blog/informatikus-fizetesek-salary-guide-ok-es-berkalkulatorok-gyujtemenye
A cég működéséből meg az adatokból arra következtetek, hogy ennyi embert kerestek meg, nem azt, hogy ennyi jelentkezett. Illetve volt egy ilyen is, hogy "felháborodott, hogy nem ajánlattal hívtam, csak érdeklődéssel" (vagy valami hasonló). Sokminden torzít, az biztos, meg persze ez egyetlen rekrúter cég, így a mintavétel is nagyon kicsi.
Ez amúgy így kicsit elhamarkodott, csak számból következtetni. Pl tesztelők mennyisége simán lehet azért ilyen magas, mert abból mindig vannak jelentkezők, elérhető emberek. (Ha kirakok egy manuális tesztelő pozíciót lehet 10x ember jelentkezik rá egy fejlesztőihez képest, főleg ha junior szintre)
Orsi összegyűjtött még néhányat: https://lorinczorsolya.hu/blog/informatikus-fizetesek-salary-guide-ok-es-berkalkulatorok-gyujtemenye
Legkeresettebb területek
Nekem régóta fura - és ez a táblázat is ezt erősíti bennem -, hogy a matrix miért nincs jobban elterjedve...
Jó ez a táblázat, de pár népszerűbb szolgáltatás még szerintem hasznos lenne bele. (Igen, láttam az "Edit chart" gombot, de nem tudok eleget hozzá :))
Ezt tök érdekes összevetni Orosz Gergely írásával: https://blog.pragmaticengineer.com/software-engineering-salaries-in-the-netherlands-and-europe/ Miszerint a legmagasabb fizetések meg se jelennek a nyilvánosan elérhető adatok között. Vagyis, ha jól gpndolom, akkor itt a magyar piacon, a nem startupoknál elérhető fizetési sávokat jelenítik meg.
Én nagyon vágyom már arra, hogy egy projektben ki tudjam próbálni a #noestimates-t (Vasco Duarte prezije a témában, odatekertem a fontos részhez: https://youtu.be/7ud-4bKJr8k?t=2141) - ez ugyanis azt mondja, hogy ha csupán a feladatok mennyiségéből akarunk előrejelezni, akkor még az is meglehet, hogy pontosabb lesz, de amit mindenképpen nyerünk az az, hogy nem szórunk el egy csomó időt a becslésre.
Hallottam már olyan projektről, amelyikben a végeláthatatlan backlogot minden tervezésnél újra meg újra előveszik és becslik - egészen barbár módja az idő- és türelem pazarlásának.
Egyébként ha jól tudom, a legújabb scrum revízióban már nincs is benne a becslés.
Ez mennyire jó projekt!
Egy hasonlót pont láttam a napokban, ott ő 3D nyomtatta a PC házat és a monitort is hozzá, de szintén Raspberry PI ketyeg benne: https://youtu.be/V-pACEENHBw