Nem kellenek a 40 év feletti programozók a Google-nek?
2016-10-10T09:43:09+02:00
2016-10-30T20:17:05+01:00
2022-07-21T18:21:44+02:00
  • Nem dolgoztam még ilyen témában, szóval nyilván nem tudhatom pontosan (bár ha dolgoztam volna valszeg nem írhatnám ide le). Nekem anno azt mesélték, hogy az Airbus kritikus rendszerei 3 különböző hardverre 3 nyelven 3 fejlesztőcsapat által 3 egymástól viszonylag távol eső helyen készülnek, kommunikáció nélkül azért, hogy kiszűrjék a szisztematikus hibákat.

    Szóval lehet, hogy ADA is van, passz, de biztos nem csak egy nyelvet használnak.
    Mutasd a teljes hozzászólást!
  • Nekem úgy rémlik, hogy az ADA tipikus olyan helyekre ahol a megbízhatóság az elsődleges szempont. Repülés, repülésirányítás, műholdak, hadi felhasználás.
    Mutasd a teljes hozzászólást!
  • Usákia, a "szabadság földje" ahol még azt sem döntheted el kit veszel fel...
    Mutasd a teljes hozzászólást!
  • Ennyire nem vagyok benne (szerencsére) de saccolom, hogy a szolgáltató simán megkapja ezt a jogot bróságon.
    Mutasd a teljes hozzászólást!
  • Ez nem csak jelzálog esetén befolyásolja az ingatlan tehermentességét?
    Mutasd a teljes hozzászólást!
  • Jól lehet vele tüzelni. :)
    Mutasd a teljes hozzászólást!
  • Ha ezt a Voyager-t valamikor egy idegen megtalálja, lehet csak röhögni fog egyet, hogy se egy érintőképernyő, se egy Windows XP legalább nincs rajta, á, inkább várunk, hagy fejlődjenek még egy kicsit. :)
    Mutasd a teljes hozzászólást!
  • Adósság simán örökölhető. Az ingatlan örökösei számára az ingatlan nem lesz tehermentes, amíg nem rendezik a csekkeket.
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Szerintem félreértetted, mert félreérthetően fogalmaztam.

    Nyilvánvalóan... mondtam hogy nem értem

    asszony -> mármint az én asszonyom, nem a nénire gondoltam.
    Így zakkant koromra legalább lesz egy könyvespolcom, ahova én is dugdoshatom majd a számlákat :)

    I see
    Mutasd a teljes hozzászólást!
  • Szerintem félreértetted, mert félreérthetően fogalmaztam.

    asszony -> mármint az én asszonyom, nem a nénire gondoltam.
    Így zakkant koromra legalább lesz egy könyvespolcom, ahova én is dugdoshatom majd a számlákat  :)
    Mutasd a teljes hozzászólást!
  • mire mész egy rakás befizetetlen közüzemi számlával?

    Ide vágó vicc:

    Grűn forgolódik, hánykolódik, nem tud aludni.
    Már hajnalodik, így a felesége megkérdi mi a baj, miért nem tud aludni.
    - Tartozom a Swartznak tízmillióval, holnap kell megadnom és nincs meg a pénz. -- válaszolja Grűn.
    - Sebaj, majd én elintézem! -- szól a neje.
    Felhívja így kora hajnalban Swartzot és azt mondja:
    - Te Swartz, a Grün azt üzeni nem tudja megadni a pénzedet.
    - Ez mire volt jó? -- kérdi Grün.
    - Te csak aludj nyugodtan. Innen idegeskedjen a Swartz. -- válaszol a felesége.

    Van másik is.

    A nagy nőcsábász hírében álló neves szinész öregszik, így egyre több gondja van a hírnév fenntartásával.
    Egy napon nem jön össze a fiatal színésznővel.
    - És most mi lesz? -- kérdi ijedten a szinésznőcske
    - Na egy gonddal kevesebb! -- válaszolja.
    Mutasd a teljes hozzászólást!
  • Biztos faktoringgal foglalkozik

    Na de egy halotton próbálja behajtani? Kicsit morbid...
    Mutasd a teljes hozzászólást!
  • Biztos faktoringgal foglalkozik
    Vagy költségszámlákra van szüksége adóoptimalizáláshoz

    De lehet, hogy félreolvasta és a csekkek ellenértékét keresi a könyvek között...
    Vagy antikváriumos?

    Kezd izgalmas lenni...
    Mutasd a teljes hozzászólást!
  • Úgy látszik én is hülyülök már, de nem értem: mire mész egy rakás befizetetlen közüzemi számlával?
    Mutasd a teljes hozzászólást!
  • Gondolom te valami tudományegyetemre jártál :)

    Asszem a BME Info nem számít annak, szóval nem.

    Én azt vallom, hogy majd akkor optimalizáljunk amikor kell és akkor majd belemélyedek a témába, hogy miért is lassú az osztás.

    Ez általában így van, de low-latency területen (ahol gyakran nem vársz távoli erőforrásokra, mint adatbázis vagy file-ok, hanem a kritikus path-on minden a memóriában megy) ezeknek a dolgoknak ismerete, és különösen hogy ezek bizonyos adatstruktúrákat hogyan befolyásolnak gyakran számít, ezért időpocsékolás rossz osztályokat választani amikről tudnunk kellene, hogy rossz megoldásokat használnak.

    Hányszor volt már az életedben probléma az osztás sebessége?

    Pozitív számról beszélünk. Kereskedési rendszerekben és tőzsdéken pl. nem mindegy, hogy milyen map implementációt használsz, mivel ott még a hash lookup sebessége számottevő mértékben befolyásolhatja a teljes művelet sebességét, és amikor az a hash tábla benn van az L3 cache-ben, nem mindegy hogy az az index számítás (maradékképzés) a hash-kódból 1 ciklusig tart (mert egy sima bitwise AND), vagy pedig egy teljes maradékképzés ami még az újabb prociknál is 30 feletti ciklus, és régen jóval több volt.

    Ha az az osztás vagy maradékképzés sokszor előfordul (pl. szoros ciklusban, mint egy rakás key lekérdezése egy hash-táblában), vagy egyéb CPU-unfriendly megoldásokat használsz, akkor észrevehető lehet egyéb rendszerekben is.

    Hányszor volt az architektúra a bottlenek az adott programozási szinten?

    A kérdésedre azt mondanám, hogy CPU architektúra nagyon ritkán a bottleneck, a szoftver architektúra annál gyakrabban, de ez nem jelenti azt, hogy a szoftver architektúrát nem lehet helyesen leimplementálni.
    De volt alkalmam olyan rendszeren dolgozni (kereskedési rendszerek) ahol igenis számít a teljesítmény és a latency, ahol ezért ott ezek a dolgok is fontosak. Sok kicsi ugyanis sokra megy, viszont minden milliszekundum késedelem annak az esélyét növeli hogy a tőzsdén már nem tudják kielégíteni a rendelést amit küldtél, és amit te viszont már az ügyfélnek elfogadtál (ergo pénzt buksz ha nem sikerül teljesíteni).

    Az osztás kicsit lehet, hogy extrém példa a mindennapi életben.
    De mondjuk ha összehasonlítod a különböző hash-tábla megoldásokat, olyan különbségekre lelhetsz amik viszont egy olyan több file-on dolgozó nem teljesen triviális batch adatfeldolgozás, aminek először a fileokat be kell rántani memóriába majd összekombinálni azok tartalmát (amit azért valljuk be, tekinthetünk hétköznapi példának) sebességét is drasztikusan befolyásolják:
    - nem mindegy hogy egy hash-tábla gyakorlatilag primitív típusú kulcsok és értékek esetén azokat objektumként vagy primitívként tárolja
    - nem mindegy hogy a hash-tábla nyílt (külön entry vagy bucket objektumok) vagy zárt hash-elésű (a kulcsokat és értékeket közvetlenül a tábla tömbjében tárolod)

    Szemmel jól látható különbségek vannak teljesítményben, de mindegyik visszavezethető 1 dologra: mennyire CPU-barát az adott megoldás: ha a kulcsokat vagy értékeket objektumként tárolod, valamint ha bucket vagy entry objektumaid vannak, mindegyik plusz 1-1 CPU cache fetch (az egyik leglassabb művelet) hogy az értéküket használni tudd, mivel jó eséllyel azok a memória nem CPU-ban cache-elt részén tartózkodnak.
    És akkor nem is mentünk bele még olyan dolgokba, mint hogy a CPU jobb szereti ha sorban végigmész egy nem CPU-ban cache-elt tömbön (előre befetcheli a CPU cache-be amit várhatólag következőnek kérni fogsz) mintsem, ha összevissza ugrálsz benne.

    Így függhet egy file feldolgozás sebessége is számottevően attól, hogy milyen map osztályt használsz, amiatt hogy az valamint a te kódod mennyire volt a CPU működésének megfelelően tervezve. Sok file feldolgozásakor könnyen lehet akkora időkülönbségeket megfigyelni, akik a különbséget jelenthetik aközött, hogy elkészül a feldolgozás időre, vagy nem, és ekkor más rendszerek is elkezdenek késni amiatt, mert ez az egyszerű feladat nem készült el időre.

    Pont emiatt sokkal fontosabb szerintem az adott layer ismerete mint az alattunk lévőké.

    Valóban. De nálam az adott layer néha a CPU-t jelenti És mint a file-os példa mutatja, meglepő különbségek lehetnek a hétköznapi feladatoknál is.
    Mutasd a teljes hozzászólást!
  • 80 évesen (ha megérem) én pipázgatni akarok a verandán és borozgatni..... A pipa már meg van, meg egy kis szőlő is.
    Mutasd a teljes hozzászólást!
  • Azt hiszem le kell foglalnom az asszony könyvespolcát időben!
    Mutasd a teljes hozzászólást!
  • Azt kijelenteni, hogy amiatt csokkennek a problemamegoldo os koncentralokepessegeim, mert oregszem, az sajnos ma politikailag inkorrekt, szoval en ezt ki sem jelentem, holott tapasztalom magamon is. Sôt! Elhatárolódom! 

    Viszont magyarázat azért akad még bôven: 20 evvel ezelott 20 evesen azert voltam sokkal lelkesebb, mert akkor anyagi problemaim voltak es az abbol kialakulo nikotinhiany lekuzdese erdekeben csodakra kepes az ember.
    Most meg mar nincsenek anyagi gondjaim es az, hogy x penz helyett x+1 penzem legyen, az mar nem motival annyira, mintha 0 helyett x penzem lenne. (Ha motivalna, akkor nyilvan uzletember vagy politikus lettem volna).
    Tovabba a kor elorehaladtaval az ember mar nagyobb adag "lexarom" tablettát is bevesz, emiatt sem porog annyira.

    Nugydij: En ugy vagyok vele, hogy azt a jovobeni 85 ev nyugdijkorhatart még meg is kéne érni lol. Addig 2 dolog lehet: a) nem hulyulok el es tovabbra is dolgozok, b) elhulyulok, de nem dolgozok, de nem is erdekel, mert boldog leszek amugy is lol (Egy tavolabbi ismerôs néni, aki nemreg elhalalozott peldaul egy kicsit meghibbant es azt csinalta az utobbi evekben, hogy az osszes kozuzemi szamlat nem fizette ki, hanem elrejtette a konyvespolcon kulonbozo konyvekben ellentetben azokkal az idosekkel, akiknek nem csokken a szellemi kepesseguk, mert ôk pedig folyamatosan aggodnak a szamlak befizetesen.)
    Mutasd a teljes hozzászólást!
  • Gondolom te valami tudományegyetemre jártál :)
    Én azt vallom, hogy majd akkor optimalizáljunk amikor kell és akkor majd belemélyedek a témába, hogy miért is lassú az osztás. Hányszor volt már az életedben probléma az osztás sebessége? Hányszor volt az architektúra a bottlenek az adott programozási szinten? Előbbivel még nem találkoztam utóbbival viszont igen, elég sokszor. Pont emiatt sokkal fontosabb szerintem az adott layer ismerete mint az alattunk lévőké. Persze ha végtelen ideje lenne az embernek akkor igen, szívesen megtanulnék kötni is de nincs rá időm.
    Mutasd a teljes hozzászólást!
  • meg processzort is terveznie

    Nevetni fogsz, de igenis ennek lenne értelme. Ad egy kis szemléletet a low-latency programozáshoz. Nem kell full processzort, de mondjuk egy 4-bites összeadót, hogy megértse hogy működik. Meg házi feladatnak egy osztást, hogy megtanulja hogy az osztás lassú (és ezért a prím maradékos hash-táblák is lassabbak a 2-hatványos hash-tábláknál).
    Mutasd a teljes hozzászólást!
  • Ennyire már én sem vagyok régi motoros. Bár kíváncsi lennék hogy milyen nyelven, egyáltalán mit értettek a 3 réteg alatt.

    Először is valamennyire rossz a 3 réteg fordítás. A 2000-es évek körül (és most is) a 3-tier nem 3 réteg (layer, amit egymásra épülő rétegeknél használtak jóval régebben) hanem három oszlop/pillér jelentésű inkább:
    - kliens
    - alkalmazás-szerver
    - adatbázis

    A BME-n 96-97 körül (nem kötelező formában), valamint a munkahelyemen 98 körül már volt Javas fizetős projekt.
    Mutasd a teljes hozzászólást!
  • Eddig is volt ezeknek neve :)
    Jozan paraszti esz/common sense
    Mutasd a teljes hozzászólást!
  • Why NASA Needs a Programmer Fluent In 60-Year-Old Code
    Nem oldja meg a világ problémáit de azért ilyen is van.
    Mutasd a teljes hozzászólást!
  • Nem azt mondom, hogy meg kell tanulni és minden parancsot fejből kéne tudni. A képalkotás a lényeg, hogy legyen egy elképzelésünk arról milyen folyamatok játszódnak le alacsonyabb szinten. 

    Nézd, a fejlesztői munkám során szignifikáns időt töltök el az internet böngészésével válaszok után kutatva. Régen ha C programozó voltál ott kellett, hogy legyen a Kernighan-Ritchie könyv a polcon, mert az volt a stackoverflow fából. Ma már gyorsabb guglizni, és esélyes hogy rövid idő alatt jobb választ találsz mint amit adott helyzetben kiötlenél. Ettől függetlenül vannak szituációk, mikor igenis tudni kell az alapokat. Nekem volt hogy Androidon Java-t használva kellett bit műveletekkel szórakoznom, mert az aktuális mikrovezérlőt annyira körülményes volt programozni és bemutató határidő volt, hogy inkább a telefon oldotta meg a szükséges konverziókat. Kellemetlen, de akkor nem mondhatom, hogy ilyen nincs ezen a szinten. Nem volt szép, később javítva lett, de az élet hoz néha ilyet. A járműtechnikában az igazán biztonságkritikus részeket még ma is assembly-ben írják, mert lehet emberek élete múlik rajta. A repülésben vannak olyan szándékosan redundáns rendszerek ahol 3 különböző gyártmányú, 3 különböző architektúrájú, 3 nyelven írt dolog látja el ugyan azt a feladatot, majd a végén bitre pontosan ugyan azt kell produkálni. Basszus, még a fejlesztők se kommunikálhatnak. Ja, arról nem is beszélve hogy a 787-esben sem a legújabb i7 pörög, inkább a 20-25 éves technika, mert arról már kiderült hogy nem ront el 1 milliárd számolásonként egy osztást. 

    Igen, vannak olyan területek ahol elég az, ha tudsz lego-zni, a rendelkezésedre álló elemekből valami újnak nevezhetőt ki tudsz hozni. Még ma is mindenkinek weboldal kell, arra vannak CMS rendszerek, meg előre megírt HTML/CSS kódok, még a PHP-t is picit ha meg tudod piszkálni akkor már tudsz érvényesülni mint webfejlesztő (no offence, lehet azt komolyan is csinálni, ne tessék sértésnek venni). Viszont sok helyen igenis szükség van arra, hogy mélyebben ismerd a világot. Az ember nem lexikon, azért találták ki az írást, hogy ne kelljen megjegyezni mindent, elég ha visszaolvasva érted.

    Nekem az a véleményem, hogy az, aki azt gondolja, hogy egy random cégnél 3-6-12 hónap alatt nulláról piacképes programozó tud lenni, majd semmit nem kell tennie és élete végéig remekül eléldegél, igenis bajban lesz 40-50 éves korára. Viszont aki mélyebb tudást szerez (nem kell zseninek lenni!) és folyamatosan fejleszti magát arra a következő 100 évben biztosan szükség lesz. 

    BTW
    The 2016 Top Programming Languages
    A Go kivételével a többi nem mai gyerek, bárhogy is nézzük.
    Mutasd a teljes hozzászólást!
  • Például minden programozónak illene egy kis assembly-t tolnia

    Persze meg kellene operációs rendszert írnia egy kicsit, meg processzort is terveznie, meg a végén még egy kis anyagtechnológiát mellé, hogy akkor hogy rakjuk össze a tranzisztort és akkor kihagytam a rengeteg köztes layert pl. ugye ma már a gépek jelentős része virtualizálva működik meg.
    De mi értelme van? Szerintem semmi.
    A mai komplex világban mindig valaki termékét használjuk építjük be, alakítjuk át. Elég ha ismered az alattad lévő egy-két réteget és kész.
    Az amikor szükséged lesz rá akkor megtanulod. Ha mondjuk valami nagyon gyorsra akarsz megírni akkor megírod C-ben, vagy mondjuk ha tényleg über gyors kommunikációra van szükséged akkor kihagyod az egész oprendszert és direktbe nyúlkálsz a hálókártyába. Ezekre általában soha nem lesz szükséged és ha megtanulod úgyis elfelejted őket néhány hónap alatt.

    Mellesleg ez még sokszor vissza is üthet. Rengeteg programozási könyvben van olyan fejezet, hogy "learn to forget" azaz tanulj meg elfelejteni dolgokat.

    Tipikus példa ha Winforms programozóként nekiáll valaki WPF-ben fejleszteni és szépen a régi bevett szokás szerint csinálja akkor szuperül televágja event handlerekkel a kódot amivel pont a wpf lényegét öli meg.

    Itt jön be az, hogy a fiatalok bizony formázatlanul jönnek ki és sokszor jobban is fogják használni a dolgokat mert az öregeket kötik a régi jól bevált szokásaik.
    Egyszer voltam Bjarne Stroustrup előadásán ahol elmagyarázta, hogy a modern nyelvek milyen sz@rok, mert egy csomó layer van alattuk és lassúak meg bla bla. Mi meg ott néztünk, hogy ok öreg a 80-as években lassúak voltak a gépek de ma sokkal olcsóbb alápakolni egy gépet egy java vagy c# alá és nyugodtan alszol mert nem esel bele olyan hibába, hogy valami "okos" elfelejtette a stringnek a +1 karaktert lefoglalni te pedig egy hétig debuggolod hogy vajon a teljesen máshol lévő free miért döglik meg.
    Mutasd a teljes hozzászólást!
  • Upwork, freelancer kilove, tele van indiaival es olcsok a projectek, ezek annyira nem alternativak..

    Marad a vallalkozas itthon es vagy kulfoldon remote ban.
    Mutasd a teljes hozzászólást!
  • Amúgy jövőhéten megyek egy 2. körre, beszélgetésre.
    Kifejezetten tapasztalt fejlesztőket várnak, mert doksi nincs, legacy rendszerek vannak, viszont teljesíteni kell.
    Amúgy azt vettem észre, hogy főleg support melókhoz, régi rendszerekhez szívesebben várják a tapasztaltabbakat.
    Kb 6-7 éve nem voltam újonnan induló projekten. (hiányzik is, meg nem is)
    Mutasd a teljes hozzászólást!
  • A Google szerintem azért alkalmaz fiatalokat mert hosszútávú terveik vannak és az alkalmazottaktól majd 15-20 év múlva várják az igazi teljesítményt. Ennek már egy 40 évesnél nincs értelme.

    Szerintem a googlenál sem marad senki 15-20 évig beosztottként. Persze ehhez még várni kell, a cég nincs 20 éves
    Mutasd a teljes hozzászólást!
  • Nem arról van szó hogy tudják-e hogy hány éves vagy hanem egyszerűen valóban nem vagy képes többé koncentrálni, megjegyezni dolgokat.
    Itt csak arra lehet számítani hogy nem esel túl alacsony szintre. Mondukrá ha még tudod tartani magad olyan szinten mint egy 5-6 éves gyakorlattal rendelkező programozó, még lehet hogy elviselnek. Nem leszel kárára a cégnek.
    A Google szerintem azért alkalmaz fiatalokat mert hosszútávú terveik vannak és az alkalmazottaktól majd 15-20 év múlva várják az igazi teljesítményt. Ennek már egy 40 évesnél nincs értelme.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd