Ezzel a 12 programozási nyelvvel lehet a legtöbb pénzt keresni

Ezzel a 12 programozási nyelvvel lehet a legtöbb pénzt keresni
2014-12-04T09:45:37+01:00
2014-12-10T18:11:26+01:00
2022-10-21T23:20:35+02:00
  • Attól függ mennyit tudsz spórolni a nyelvvel. Általában igazából nem sokat.

    Vagy de. Nem mintha a kis spórolás nem lenne spórolás, és a sok kicsi nem menne sokra.

    A programozásban ugyanis nem a begépelés a leginkább időigényes.

    Rajtad kívül senki nem beszélt (csak) a gépelésről, illetve annak időigényéről. Nem mintha ha tényleg csak a gépelésen lehetne spórolni, akkor azt ne lenne érdemes megtenni.

    Ha valaki ezen akar spórolni, akkor az nem fog megállni a nyelvnél.

    A te érvelési hibád: Csúszós lejtő
    Mutasd a teljes hozzászólást!
  • Nem mindegy, hogy típusos a nyelv vagy nem az. Kell e az elején deklarálni minden változót vagy nem. Mikor mi a jobb, mivel lehet gyorsabban fejleszteni. Lehet, hogy a jó nyelv megválasztásával 10-20% fejlesztési időt is nyerhetsz. Ha több jó nyelv van és egyik sem tud valami előnyt adni, amitől az kell, akkor bizony az idő lehet fő szempont is.
    Az, hogy kihagyják pl az automatizált tesztelés megírását és használatát, az bizonyos eseteknél nem időnyerés, hanem időhúzás. Ugyanis jön a reklamáció és azt javítani kell. Vagy továbbfejlesztéskor csúszik majd, mire rájönnek, hogy mit szúrtak el vagy egy, eljesen rossz kódot írnak rá, mert a rejtőzködő hibás működésre építkeztek.
    A programozási módszerekben van inkább lehetőség fejlesztési idő gyorsítására, ami jó és elfogadható, de ez inkább megérne egy külön cikket, külön beszélgetést.
    Mutasd a teljes hozzászólást!
  • Nem fő szempont, ugyanakkor nem mindegy, hogy mennyi ideig vacakolsz valaminek a leprogramozásával, mert azért itt is van tűréshatár.
    Mutasd a teljes hozzászólást!
  • Attól függ mennyit tudsz spórolni a nyelvvel. Általában igazából nem sokat. A programozásban ugyanis nem a begépelés a leginkább időigényes. Ha valaki ezen akar spórolni, akkor az nem fog megállni a nyelvnél.
    Mutasd a teljes hozzászólást!
  • Igazából az amit a programnyelvvel időt tudsz spórolni, az minimális a többi spórolási lehetőséghez képest.

    De az amit a programnyelvvel tudsz spórolni az egyetlen dolog amivel úgy tudsz spórolni, hogy ezzel a végeredmény minősége nem romlik. Sőt, a korábban írtak értelmében ez még lehetővé is teheti azt, hogy végső soron jobban kidolgozott és jobb minőségű végeredményt szállíts le úgy, hogy közben időben és árban is versenyképes marad.

    Éppen ezért nagyon fontos az, hogy a programozási nyelvvel mennyi időt tudsz spórolni. Mert ez az egyetlen dolog, amivel hosszú távon is előnyös tud maradni a spórolás, és nem megy a termék minőségének és a cég stratégiai érdekeinek kárára.

    Ezért régen rossz, ha már a programnyelv választásakor a fejlesztési sebesség a fő szempont

    A fentiek értelmében pont ez kell, hogy az elsődleges szempont legyen. Ti. hogy az adott eszközzel milyen gyorsan lehet az adott feladatot megoldani. Mert ebből következik az is, hogy az elkészülő munkát adott kidolgozottság mellett mikorra, milyen áron és milyen minőségben tudod leszállítani. Vagy megfordítva: azt, hogy adott idő- és költséghatárok között milyen kidolgozottsági (rétegezettségi, tesztelési, stb.) szinten tudod elkészíteni.

    ez ugyanis azt jelenti, hogy a többi, ennél jóval időigényesebb dolgot is kihagyják a fejlesztésből.

    Az említett "időigényesebb dolgok" elhagyása hanyagságból, bénaságból vagy egyszerűen puszta nyereségvágyból mindig lehetséges - bármilyen nyelvet is használsz a megoldáshoz. De csakis akkor szükséges, ha olyan nyelvet választottál a megoldáshoz, amivel az ideálisnál csak lassabban tudsz haladni.

    Ebben az esetben ugyanis kénytelen vagy a rétegezettséget, validációt, stb. elhagyni, elhanyagolni, pusztán azért, hogy versenyképes határidőre, versenyképes áron tudj megoldást szállítani az adott feladatra szuboptimális nyelvvel is.
    Mutasd a teljes hozzászólást!
  • Igazából az amit a programnyelvvel időt tudsz spórolni, az minimális a többi spórolási lehetőséghez képest. Ezért régen rossz, ha már a programnyelv választásakor a fejlesztési sebesség a fő szempont - ez ugyanis azt jelenti, hogy a többi, ennél jóval időigényesebb dolgot is kihagyják a fejlesztésből.
    Mutasd a teljes hozzászólást!
  • De ahol hajtás van, ott hajtás van. Ahol meg van idő mindenre, ott van idő. Én eddig azt láttam, hogy ahol hajtás van, ott első körben az automatikus tesztelés esik áldozatul. Aztán a rétegzés, majd a validációk.

    Ezeknek egyrészt megint semmi köze nincs a használt nyelvhez, se a sebességhez. Piszok lassan és/vagy neked kedves nyelvben dolgozva is el lehet hagyni az automatikus tesztelést vagy a validációt. Sőt, minél lassabban lehet haladni eleve egy adott eszközzel, annál inkább el is kell majd hagyni az ilyen dolgokat ugyanazon határidő tartása érdekében.

    A másik, hogy a nyomás, hogy minél kevesebb idő alatt legyen kifejlesztve valami, minden piacra termelő cég esetében ott van. Pont azért, mert az idő=pénz, és mert így a gyorsaság alapvetően befolyásolja a költségeket, illetve végső soron a termék, a munka árát is. Ebben az értelemben mindenhol éppen ugyanakkora hajtás van - és ha mégsem, az pusztán a cég stratégiai döntésének eredménye.

    A hajtás és a kidolgozás elhagyása vagy elnagyolása ezzel összefüggésben nem annak következménye, hogy a használt nyelv, eszköz gyors fejlesztést tesz lehetővé, hanem legfeljebb pont azé, hogy bizony csak lassabb fejlesztést tesz csak lehetővé az adott eszköz, mint amivel a konkurencia dolgozik. És hogy ezért ahhoz, hogy árban tudjon versenyezni vele az adott cég, a kidolgozás részletességén, átfogóságán kell spórolnia.

    Ezekhez képest a használt programnyelv milyensége nem nagyon számít.

    Nem ezekhez képest nem számít, hanem teljesen független tőlük. A kérdés, hogy akkor miért akarod mégis a nyelvekkel és azzal, hogy azok alapvetően mennyire gyors fejlesztést tesznek lehetővé, összefüggésbe hozni a fenti mulasztásokat vagy egyszerűsítéseket?

    Főleg, hogy - ahogy az előbb elmondtam - ez is pont egy gyors fejlesztést lehetővé tevő nyelv használata mellett szól. Ti. mert minél több időt spórolsz meg az alapfejlesztésen, annál kevésbé kell visszanyírni az olyan dolgokból, mint a rétegezettség vagy a validáció annak érdekében, hogy lehessen a határidőt tartani.
    Mutasd a teljes hozzászólást!
  • De ahol hajtás van, ott hajtás van. Ahol meg van idő mindenre, ott van idő. Én eddig azt láttam, hogy ahol hajtás van, ott első körben az automatikus tesztelés esik áldozatul. Aztán a rétegzés, majd a validációk. Ezekhez képest a használt programnyelv milyensége nem nagyon számít.
    Mutasd a teljes hozzászólást!
  • De mindannak amit most írtál semmi köze nincs a használt programozási nyelvhez. Egyik sem kényszerít téged ezen hibák elkövetésére, és semelyik másik nem is tud megóvni tőlük (ill. végső soron magadtól).
    Mutasd a teljes hozzászólást!
  • Én azt mondtam, hogy a fő szempont. Pl. lehet úgy is fejleszteni, hogy nincs az app rétegezve, a BL be van gyógyítva az UI-ba, nincs unit teszt de még csak gondolva sincs arra, hogy tesztelhetőre tervezzünk bármit is, nem foglalkozunk a típusokkal, a validációval sem töltünk el sok időt, nem dokumentálunk, nem foglalkozunk olyan hülyeségekkel hogy kódolási  konvenciók, stb. Így sokkal gyorsabban lehet haladni, de nem igazán szeretem az ilyen projekteket.
    Mutasd a teljes hozzászólást!
  • Az alap minden piaci fejlesztésnél, hogy a sebesség a fő szempont. Azért, mert a "first to market" önmagában is komoly - akár behozhatatlan - előny tud lenni. De azért is, mert amivel gyorsan lehet haladni, azt - pont emiatt - olcsón is lehet megcsinálni.

    Sőt, amivel gyorsabban lehet haladni, ott ugyanannyi pénzből és/vagy időből több jut így a tesztelésre, vagy a minőség más jellegű csiszolására is. Tehát amelyik eszközzel, nyelvvel gyorsabban lehet fejleszteni, azzal olcsóbban és/vagy jobb minőségben lehet ugyanazt szoftvert lehet előállítani.

    A lassúság ezzel szemben sehol és semmilyen szempontból nem pozitívum vagy követelmény. A lassúságból önmagában nem következik semmilyen előny. Ezt csak az szeretné gondolni, aki nem tudja tartani a lépést a gyors fejlesztőkkel és gyors eszközökkel.
    Mutasd a teljes hozzászólást!
  • Ahol a fejlesztés sebessége a fő szempont, ott már régen rossz. Ez leginkább pincebétét jelent, ahol kicsi rabszolgák gyártják az ócsított appokat a szomszéd pincebétéknek egy tál levesért.
    Mutasd a teljes hozzászólást!
  • Biztos, hogy hiányos a lista, mert az ABAP nem szerepel rajta, és szerintem azzal keresnek a legtöbbet.
    Mutasd a teljes hozzászólást!
  • Ő arra gondolt, hogy egyszerre több cégnek dolgozva is össze lehet talán kaparintani ekkora összeget. Persze kellenek a jó ajánlatok, anélkül nem megy.
    Mutasd a teljes hozzászólást!
  • Tudsz jobbat náluk, amivel gyorsabban lehet fejleszteni?
    Mutasd a teljes hozzászólást!
  • Nemtom, speciel nekem most egy Matlab(*) + CUDA területen van hasonló fizu, ezt például a listán nem látom sehol. Más nyelvekkel is ki lehet fogni, bár lehet most a Ruby a menő. (Ha másképp nem, akkor nem bejelentve biztosan megadják egy jó fejlesztőnek PHP-ra is, sajnos Magyarország az ilyen)

    (*)Itt is az az indok, hogy hű de gyors a fejlesztés, mert úgy kezeli a cucc a mátrixokat, hogy fantasztikus, meg nem kell típusozni (jajj, de nehéz is az :D) stb. de nekem 10 év C++, meg C# után még mindig egy krix-krax halmaz abszolút nem a gyors fejlesztésről szól, de most ez van, ezért adják a zsetont.
    Mutasd a teljes hozzászólást!
  • Magyarorszagon php programozokent kapott mar valaki netto 500at? 

    Ruby fejlesztokent tobb ceget is tudok magyarorszagon ahol a netto 500at kifizetik.
    Mutasd a teljes hozzászólást!
  • 500e ft nettó a legtöbb php-snak az álom kategória.

    Nem a nyelven múlik, meg attól is függ hány cégnek dolgozik egyszerre.
    Mutasd a teljes hozzászólást!
  • Átlagfizetést nézni arra, hogy mennyire lehet jól keresni egy nyelvvel teljesen hülyeség.

    Vegyünk két nyelvet, A-t és B-t. Feltételezve, hogy összesen 200 penge programozó létezik mindkét nyelvből.

    A-val van 100 állás hirdetve évi $125k-s fizuval, a B-vel szintén 100 évi 100k-val.
    A-val ezekután meghirdetnek még 100 állást évi 60k-ért.
    Ebben a pillanatban B hirtelen egy "sokkal jobban fizető nyelv" lett mint A, miközben valójában az A-ban programozók átlagosan is jóval több pénzt fognak keresni.


    Valódi fizetési becslésést egyes fizetési kategóriákban lehetne megnézni az álláshirdetések számát (ez is csak dura becslés, ugyanis nem tudod hányból hányan tudnak ott elhelyezkedni adott nyelvvel).
    Ezentúl max az össz-fizetés összehasonlításának van értelme (átlagolás nélkül).
    Mutasd a teljes hozzászólást!
  • Kifejtem :) A karbantartás alatt nem csak a verziókhoz való igazítást értem, az a kisebbik baj. A nagyobbik, hogy minden program változik az idők során. Egyrészt a megtalált bugokat javítani kell, másrészt jönnek új feladatok, hízik a kód, régieket át kell alakítani, újabb bugokat teszel a rendszerbe, szóval egy szoftver sosincs kész, csak a fejlesztés üteme csökken. Na ezért fontos a karbantarthatóság. Mondjuk 2 év múlva jóskapistának mennyi idejébe kerül pl egy módosítást megcsinálni? Ez az alapvető kérdés. Mindig TCO-t fognak számolni a szoftver teljes életciklusára, ami egy üzleti szoftvernél átlagosan 15 év!
    Mutasd a teljes hozzászólást!
  • Előre nem is lehet nagyon megmondani, hogy hogyan változik a programnyelv.

    Ha becsukod a szemed, biztosan nem latod hogy mi van elotted.
    Mutasd a teljes hozzászólást!
  • Az sem segitett, hogy a ft 20-25%-ot romlott a dollarhoz kepest...
    Meg ugye nalunk a berbol a kb. 50% elvonas is magasabb, mint az usa berterhek. (80k$-bol kb. 60k$ zsebben marad feleseggel, ket gyerekkel.)

    Nalunk ugye 22M, az kb. 1.4Mbrutto/ho (valos koltsege a cegnek 1.8M), ket gyerekkel abbol 940k/ho marad meg.
    Mutasd a teljes hozzászólást!
  • Fene sem bánná ha a lista végén szereplő C#-hoz bejegyzett összeget keresné az ember. Kutyát nem érdekli, hogy le van maradva a Java-hoz, Objective-C-hez képest. Átszámolva ~22 millió forint éves szinten. Hol kapunk ma ilyet? nem sok helyen
    Mutasd a teljes hozzászólást!
  • A tök ismeretlent egy cég sem veszi fel. Jobb helyeken a felvétel úgy működik, hogy megnézik, hogy van e előélete és milyen. Jó esetben a jó híre már előtte eljutott hozzá. Második lépcsőben teszt alá veszik, a kapott feladatokkal hogyan boldogul. Harmadik lépcsőben ha szükséges és lehetséges, olyan feladatokat kap a sikeres felvétel után, aminek kevésbé kockázatos, aminek az elrontása nem okoz nagy problémát, könnyű ellenőrizni és javítani. Ahogy egyre jobb kódokat ír vagy erről megbizonyosodik a cég, annál komolyabb feladatokat kaphat.
    Ez egy lehetőség. Egy cég képes lehet nagyon jól szűrni, delegálni feladatokat, fejleszteni az adott illetőt. Igen, ha mindjárt profi kell, akkor sokkal komolyabb tesztre és odafigyelésre van szükség eleinte a cégnek.
    Nyilván mindenki érdeke az, vagy érdeke kéne lennie, hogy a céghez jó ember kerüljön be és jó munkát végezzen.
    Azt is megértem, hogy egy cégnek az a jó, ha évek óta jól bevált profi emberek dolgoznak, akikben könnyű megbízni és mindenbegyeztetés, munka gördülékenyen, nagy hatékonysággal haladjon, meg jó a légkör, jó a már összeszokott jó csapat. Azt is megértem, hogy nehéz megválni tőlük és lehet, hogy nincs is erre szükség. De vajon minden cégnél így van ez? Nem is lehet egyértelmű, minden cégnek jó megoldást javasolni így általánoságban, bár azt hiszem ez nekünk nem is lehet feladatunk.
    Mutasd a teljes hozzászólást!
  • A karbantartást kifejtenéd? Lehet, hogy nem egy dologra gondolunk.
    Van több nyelv is, aminél a kód visszafelé kompatibilis. Szóval frissítheted például a php motort, a régi php kódok úgyanúgy működnek. Vagy ez java esetén van így? Pontosan nem tudom.
    Előre nem is lehet nagyon megmondani, hogy hogyan változik a programnyelv. Az is lehet, hogy 10 évig is jól működik a kód, de ez idő alatt olyan megoldások születek a nyelvben, ami bizonyos szempontból jobb(pl gyorsabb, áttekinthetőbb, biztonságosabb stb), ezért érdemes bizonyos részeket átírni. Nyilván az se mindegy, hogy mennyit kell átírni. Elég e pl a függvények nevét átírni, esetleg a programozási nyelv fejlesztője csinálja pl azt, hogy aki az echo "szöveg" utasítást ír, annak pl az újabb mecho "szoveg" utasítás fusson le, ami jobb. Vagy ezt a programozó hídalja át valahogy.
    Azért ha belegondolunk, lehet, hogy nem tart sokáig más programnyelv kódjait sokáig karbantartani, mégis talán olcsóbban is kijöhet vele. Ráadásul sokkal több jó embert találhat a piacon.
    Mutasd a teljes hozzászólást!
  • A szoftverek az életciklusuk alatt elég sok pénzt felemésztenek, ezért aki hosszú távon képes gondolkozni az kiszámolja, hogy a karbantartás mibe kerül és ezért tudnak nyerni viszonylag haszontalannak látszó környezetek.

    Ezt így konkrétan nem írtam le, de tudom. Erre van is egy jó példám: valamikor a 2000 évek elején írtam egy sqlite-t használó webcrawlert (eredetileg csv szerű flat file volt). Az eltelt idő alatt rengeteg módosításon ment keresztül.  A legelső (amiért akkor fizetett) és a mostani változatban 2 sor biztosan azonos:

    #!usr/bin/env python # -*- coding: utf-8 -*-
    Apróság, eredetileg 8 most 11 webáruház adott kategóriák adatait, valami 50 gyártó kínálatát menti le és statisztikákat készít küönböző szempontok alapján.  De már kb. 3 millió fölött van az idők során a belefektetett összeg. Na meg egypár akó bort is megittam....

    És sokkal egyszerűbb pythonban megírni / módosítgatni / javítgatni, mint pl C-ben. Mert:  a megrendelő windowst használ én QNX-et (vagy Tiny Core Linux-ot) közös nevező: Python. És a célnak nagyon megfelel.
    Mutasd a teljes hozzászólást!
  • Látod LC, igazunk volt anno, amikor írtuk hogy a PHP-sok nem keresnek olyan jól Persze lehet hogy csak kimaradt a statisztikából, ezt nem tudni. És akkor még sting hozta az ellenkezőjét, miszerint alig volt különbség a javas és a PHP-s fizetések között. Persze lehet hogy azóta fordult a világ...
    Mutasd a teljes hozzászólást!
  • Nyilván valakinek nagyon fontos lehet, hogy ezzel a nyelvvel legyen megírva valami, ha ennyit hajlandó fizetni érte

    Nem gondolom, hogy egy helloworld-nél nagyobb szoftvefejelesztésnél ez a különbség akkora tétel lenne, de majd jönnek az okosak, és megmondják.

    De ennyi erővel lehetne csodálkozni, hogy annyi mindent visual studióban fejlesztenek, "hiszen valakinek nagyon fontos lehet, (...) ha ennyit hajlandó fizetni érte"
    Mutasd a teljes hozzászólást!
  • Azért ami általános feladat az mindegyik nyelven megírható, nem ez a különbség. A szoftverek az életciklusuk alatt elég sok pénzt felemésztenek, ezért aki hosszú távon képes gondolkozni az kiszámolja, hogy a karbantartás mibe kerül és ezért tudnak nyerni viszonylag haszontalannak látszó környezetek. A Ruby lassú, mint az atom, a Python se egy express, főleg nem azok egy Java/C#-hoz képest vagy akár C/C++-hoz képest, csak olcsóbban karbantartható kódot eredményeznek. Legalábbis ezt mondják az okosok.
    Mutasd a teljes hozzászólást!
  • Ez a Ruby meg Python mit tud? Leugrik a közértbe kenyérért?

     Miért? A visual basic, delphi vagy a php leugruik sörért?

    atomjani86:

    Szerintem csak azért nincs a listában, mert 10szer többet keresnek, mint a Ruby-sok és hogy ez ne szúrja senki szemét.

    Ez azért így nem igaz. Az átlag php fejlesztők kevesebbet keresnek, s pont azért mert több (sok) a php fejlesztő. Kevesled a fizut? Van helyetted 100 másik.  500e ft nettó a legtöbb php-snak az álom kategória.  S amit meg leg lehet írni PHP-ban, azt pythonban is. Vica-versa már nem működik. Nagyon sok olyan dolog van, ami pythonban könnyen megírható, de php-ban már nem, vagy nagyon körülményesen.
    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