Új hozzászólás Aktív témák

• #43 opr nagyúr opr #42

  Új Válasz 2016-12-16 12:37:20 #43

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  opr

  nagyúr

  válasz opr #42 üzenetére

  ui.: (Csak lejart a szerk...)

  Persze a fentiekhez hozza kell tennem, hogy mindezek mellett is igaz is, hogy rengeteg kokler van a szakmaban. Dolgoztam mar olyan emberekkel, akiknek hatosagilag tiltanam azt is, hogy a kovetkezo 5 evben lathasson szamitogepet, nemhogy engednem programozni. Raadasul az ilyen kollegat meg elkuldeni is nehez a cegtol, ha valami csoda folytan atjut az interjun (csoda legtobb esetben = rokon, ismeros, mely torok...), mert rohadt nehez programozot talalni, a vezetes pedig nem minosegben, hanem darabszamban gondolkozik, es fajna neki leirni, hogy nem novekedett a fejlesztesi kapacitas, ugyhogy inkabb azt mondjak, hogy jajj, hat figyeljetek ra, segitsetek neki, majd belejon!
  Amikor meg kozlod, hogy kurv@jo, mostmar akkor tolthetek napi 2 orat a szarjanak az ujrairasaval meg a gyerek nyektetesevel, akinek a hozzaallasa kb az, hogy hagyjalmar, tudom (nem, b+, ha tudnad, nem kene itt allnom es mondogatnom), a vezetoseg rant egyet a vallan, a kovetkezo meetingen meg mergesen kerdezi, hogy miert nem gyorsult fel a fejlesztes, amikor kaptatok egy plusz embert... Na, altalaban en akkor kezdek munkat keresni, hogy hatha a kovetkezo cegnel nem igy lesz, de sajnos, a tapasztalat az, hogy de, igy lesz.

• #42 opr nagyúr #65675776 #41

  Új Válasz 2016-12-16 12:24:57 #42

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  opr

  nagyúr

  válasz #65675776 #41 üzenetére

  "Dehát ez a dolga, ezért fizetik."
  Sajnos nem.
  Azert fizetik, hogy megcsinalja azt, amit a tulaj/manager/product owner megalmodott. Es hidd el, tapasztalatbol beszelek, hiaba kampanyol akarhogy a fejleszto, ha akar csak egy hettel is kitolja a fejlesztesi/tesztelesi idot egy optimalizacio, az esetek 90%ban nem fogjak neki engedni. Plane elso kiadas elott.

  "Persze inkább úgy vannak vele, hogy ha van erősebb hardver, akkor vegye meg azt a felhasználó, nehogy már szegény programozónak dolgoznia kelljen."
  Ebben van igazsag, csak forditva ulsz a lovon. A programozo, legalabbis az, akit en annak tekintek imadja reszelgetni a kodot, mindig szebbre, olvashatobbra, erthetobbre, egyszerubbre, es ezekkel egyutt altalaban optimalisra irni. A problema akkor kezdodik, amikor ezt
  a) nem hagyjak, illetve
  b) mar megtette, de igy se jo, es akkor jon a keserves reszelgetes, ami igazabol mar sokat nem hoz, max par %ot, de cserebe honapokkal tolja ki a fejlesztesi idot, es 90%, hogy technical debt-et vezet be, ami pedig azzal jar, hogy kesobb nehezebb patchelni/boviteni/tesztelni az alkalmazast. (A kolleganak fentebb tippem szerint pont ez a gondja.)

  "Az nem zavarja, hogy az erőforrások 30-40%-a van csak kihasználva."
  Oooo dehogynem, keves irritalobb dolog van, mint amikor latod a profilerben, hogy mennyi kraft marad a rendszerben, de valami gatol abban, hogy azokat ki is tudd hasznalni. Ezekre jo es ertheto peldakat talalhatsz pl Abu cikkeiben, amikor a Vulcan/dx12 API-krol, illetve azoknak a terveirol es szuksegessegerol irt.

  "Persze elhiszem, hogy egyszerűbb előre gyártott komponensekből összegórálni a programot, de az olyan is."
  Teljesen masrol beszelgetunk.

  "Utóbbi a programozók managerek szemében már a végletekig optimalizált."
  Nekem volt olyan munkahelyem, ahol napi szinten veszekedtem a kedves vezetessel, hogy ugyan, hadd dolgozzak mar egy modulon meg 1-2 napot(!), mert rengeteget lehetne meg fogni rajta. Talan ketszer hagytak.

  Es akkor meg a fentiekhez hozzatennem, hogy sokszor konkretan nem lehetseges az optimalizacio, vagy a tobbszalusitas. Sot, szvsz minden kollega, aki akar csak egy kozepesen eros junior szintjen van, tud olyan peldat mondani, amikor egy feladat tobb szalon konkretan lassabb, mint egy szalon.
  Illetve van az a helyzet is, amikor mar optimalizalt, szepen skalazodo, jofajta kodod van, de eroforras hijan sajnos tovabb kell tobbszalusitani. Ilyenkor +1 szal altalaban maximum 5-15%ot hoz, es minden ujabb mar csak ennel kevesebbet, cserebe hatvanyozottan novekszik a komplexitas.

  Hidd el, ez nem egy egyszeru jatek, raadasul magas absztrakciokkal dobalozunk, sokszor csak fejlesztes kozben (rossz esetben utan) derul ki, hogy dragabb lett a leves, mint a hus.

  szerk.: helyesiras, tordeles, ilyenek

• #40 opr nagyúr #65675776 #38

  Új Válasz 2016-12-16 11:33:36 #40

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  opr

  nagyúr

  válasz #65675776 #38 üzenetére

  Amikor ilyen hozzaszolasokat olvasok, komolyan elgondolkozok rajta, hogy irni kene vegre egy mindenki szamara ertheto cikksorozatot az optimalizacio, tobbszalu programozas, developement pipeline, koltseg-elony vonalon...

  Komolyan, neha ugy erzem, az emberek azt hiszik, hogy az optimalizacio egy olyan dolog, hogy a kocka felkel, haromszor raver a monitorra fallosszal, es bumm, egy mosogepen is 120fps-el fut realtime a reszecskeszimulacio szepen animalva, ezek a barmok meg inkabb szuperszamitogepekkel szopn@k...

Új hozzászólás Aktív témák