Betör a programozóképzések piacára a Budapesti Metropolitan Egyetem (x)

Címkék

Váltanál, de bizonytalan vagy a jövőt illetően? A 4 hónapos képzést elvégzőknek a METU junior szoftverfejlesztő állást garantál partnercégeik egyikénél. HTML5, CSS, JavaScript, Java, Spring, Node, Angular nyelvek és keretrendszerek. Gyere el nyílt napjaink egyikére! További részletek »

Hozzászólások

Kíváncsian várom mikor esünk át a ló túloldalára ezzel... Boldog-boldogtalan fog néhány hónap alatt programozókat képezni. Ráadásul, ahogy nézem nagy biznisz, mert szép kis összeg a tandíj. Mielőtt valaki megvádolni nem féltem a helyem és nem is vagyok rosszindulatú, inkább a képzés minőségében kételkedem.

teljesen szubjektiv, de itt pl az oktato, a dpg-s srac az egyik legjobb a szakmaban, tehat oktatasi oldalról nem lesz nagy gond. aztán itt a kerdes, mire jo a 4 honap? par hete csinaltunk egy 4 reszes cikksorozatot a hwsw-n a greefox peldajan keresztul, ahol egy reszben a befogado cegeket szondaztuk, es szamomra meglepo modon dobbenetesen elegedettek voltak. egy nagyon fontos parameter, hogy az osszes ilyen privat oktatasi intezmeny eloszuri a hallgatokat.

de egy tok masik pelda: 4 evvel ezelott az egyik 40 oras alapozo ios kepzesunkre elojott egy srac. nullarol kezdte (fyi matekot tanult az elten). ra 2 evre mar o tartotta a képzést (teljesen veletlenul lett igy), ott meselte el, hogy nalunk kezdte. akkor egy ismert hazai ceg senior ios programozoja volt, jelenleg az egyik legismertebb swift evangelista itthon.

szoval kozel sem biztos, hogy ezek a tomegkepzesek csak szart boritanak a piacra. nyilvan lehet vitatkozni, hogy egy bmes infos prog háttérrel mennyivel jobb egy arc, aki mondjuk mar 10 eve van a szakmaban, de nem mindenhol kellenek programozo atyauristenek.

szerintem a legertekesebb kerdes, hogy 5 ev mulva hol lesznek ezek a sracok, akik igy kerultek a szakmaba. akkor majd ossze lehet hasonlitani egy egyetemi hatterel jovo sraccal, es utana lehet ertekiteletet mondani. meggyozodesem, hogy a privat oktatasban akkora boom lesz, hogy siman utni fogja gyakorlati szempontból az egyetemi vonalat. erdemes csak megnezni, hogy pl a codecool milyen arcokat szedett osssze mentornak. istencsaszar csapat van ott.

"legjobb a szakmaban, tehat oktatasi oldalról nem lesz nagy gond" attol meg lehet, hogy rossz oktato ;)

"csak szart boritanak a piacra. nyilvan lehet vitatkozni, hogy egy bmes infos prog háttérrel mennyivel jobb egy arc" pont az IT az a terulet, ahol az iskolai vegzettseg nem sokat szamit. Rengetegen vannak, akik meg egy 40 oras kepzesre se jartak, megis komoly karriert epitettek.

"mire jo a 4 honap?" + "meglepo modon dobbenetesen elegedettek voltak" A 4 honap 0-rol kb semmire sem eleg. A 4 honap arra jo, hogy ha a delikvensnek van sajat ambicioja, akkor szerez egy gyakorlatban alkalmazhato nagyon minimalis tudast, amire aztan a cegek raepithetik a sajat kepzeseiket. Ha nincs meg a cegnek az eroforrasa a tovabbkepzesre, vagy nincs kidolgozott modszertanja, hogyan mentoralja tovabb ezeket a fejlesztokat, akkor feszett fejsze nyele az egesz. Csak akkor erdemes beleugrani, ha a kepzes folytatodik a 4 honap utan is, de mar ceges keretek kozott.

-
Go konkurencia kezelés gyorstalpaló

Én is meglepődtem a cikk eredményein, bár azért Lillát (a szerzőt) nem vádolva részrehajlással úgy gondolom, az első évfolyamba azok invesztáltak akik eleve hisznek ebben.

A cikket olyan kritika is érte szakmai oldalról, hogy ez olyan mint a Megasztár, az első három évfolyamba még könnyű volt jó énekest találni (Caramel, Tóth-testvérek...), na de emlékszünk még a Megasztár 5 döntőseire?

Ami viszont a másik oldal: egyfelől az informatikában van egy rakás ún. tömöríthetetlen probléma, a legtöbbjük a sebességgel kapcsolatos - azaz, nincs egyszerű, triviális, gép által kivitelezhető vagy API-val eltakarható mód arra, hogy valaki értse, egy program mitől gyors vagy lassú.

Hasonló egyébként a biztonság is, bár botcsinálta biztonsági szakértővel teli a padlás, de ez a melyik hash mikor és mikor nem használható egy bonyolult kérdéskör, és nem elég valamire csak rádobni a TLS-t se.

Ezekhez be kell vágni azt a 3 év matekot amin a BME-ről kiesett évfolyamtársaim 80%-a elvérzett (a maradék 20% programozáson vérzett el, sehogy nem bírta a fejébe verni a pointerek meg a rekurzió világát, van ilyen, de azokból máshol se lesz fejlesztő), el sem lehet magyarázni annak, aki nem tanulta, mi a baj, már a látványos tüneteken (lassú a program, megint feltörték a rendszert) túl.

Ez egy klasszikus esete a Dunning-Kruger tételnek, ami kimondja, hogy ahhoz hogy valaki belássa, hogy valamihez nem ért, először elég jól kell értenie hozzá ahhoz, hogy értse hogy nem érti (Murphy-változat: primitív embernek hiába magyarázod hogy primitív, nem fogja érteni, hiszen primitív)

Azt szoktam mondani, a tanfolyamok meg az 5 év egyetem közt leginkább az volt a különbség hogy a tanfolyamokkal kaptam egy zseblámpát ahol tök jól láttam néhány dolgot, az egyetemmel meg megkaptam a barlangrendszer térképét.

Az igény azonban hatalmas. Ettől még emlékszem, milyen volt indiai programozókkal dolgozni, egy-kettő nagyon okos, a matekot is komolyan vette a középsuli, de sajnos a 3 hónap elmélet + 3 hónap gyakorlat képzés nem adott nekik kellő fogalomrendszert ahhoz, hogy értelmezni tudják, mi történik körülöttük.

Persze lehet hogy erre egy jobb tanári gárda képes, de az időtartam miatt vannak félelmeim, véges mennyiségű megértést (nem begyakorlást, nem felfedezést, megértést) lehet beleszuszakolni ennyi időbe, mennyire erős és mennyire generatív az a bázismodell amire aztán a karriert építik a végzősök.

Szerintem nagyvállalati környezetben fognak csinálni html frontend RÉSZEKET meg max. unit teszteket. Másra ilyen képzés nem tud felkészíteni. Pointerezni sem a HTML5-ben, sem Javaban nem kell, a komolyabb unitokat pedig úgysem ők írják.
Innen inkább továbblépni lesz nehéz nekik, én biztosan nem vállalnék be egy ilyet.

"Ettől még emlékszem, milyen volt indiai programozókkal dolgozni, egy-kettő nagyon okos, a matekot is komolyan vette a középsuli, de sajnos a 3 hónap elmélet + 3 hónap gyakorlat képzés nem adott nekik kellő fogalomrendszert ahhoz, hogy értelmezni tudják, mi történik körülöttük."

Na pontosan ezt gondolom erről is!

"Ami viszont a másik oldal: egyfelől az informatikában van egy rakás ún. tömöríthetetlen probléma, a legtöbbjük a sebességgel kapcsolatos - azaz, nincs egyszerű, triviális, gép által kivitelezhető vagy API-val eltakarható mód arra, hogy valaki értse, egy program mitől gyors vagy lassú."

Elmúltak azok az idők, amikor a sebesség volt a legfőbb szempont, főleg enterprise környezetben. A programozói bérek illetve a hardverárak változása felülírta. De ahol előjönnek ilyen problémák, ott többnyire vannak olyan emberek, akik ezeket megoldják. Ilyen tanfolyamokról nem a pár fős cégek visznek embert.

"Hasonló egyébként a biztonság is, bár botcsinálta biztonsági szakértővel teli a padlás, de ez a melyik hash mikor és mikor nem használható egy bonyolult kérdéskör, és nem elég valamire csak rádobni a TLS-t se."

Normális helyeken ezért van külön ember, urambocsá team a security-re, meg alkalmankénti külső auditok.

"Ezekhez be kell vágni azt a 3 év matekot amin a BME-ről kiesett évfolyamtársaim 80%-a elvérzett (a maradék 20% programozáson vérzett el, sehogy nem bírta a fejébe verni a pointerek meg a rekurzió világát, van ilyen, de azokból máshol se lesz fejlesztő), el sem lehet magyarázni annak, aki nem tanulta, mi a baj, már a látványos tüneteken (lassú a program, megint feltörték a rendszert) túl."

A programnyelvek tekintélyes része nem épít pointerek használatára. Rekurzió kapcsán pedig vicces pont a BME-t említeni, volt egy srác akit interjúztattam, 15-20 percet szenvedett egy viszonylag egyszerű feladattal, majd bemondta, hogy ez rekurzióval tök egyszerű lenne, de neki BME-n azt tanították, hogy ne használja.

"Ez egy klasszikus esete a Dunning-Kruger tételnek, ami kimondja, hogy ahhoz hogy valaki belássa, hogy valamihez nem ért, először elég jól kell értenie hozzá ahhoz, hogy értse hogy nem érti (Murphy-változat: primitív embernek hiába magyarázod hogy primitív, nem fogja érteni, hiszen primitív)"

Ugyan nem tudom ennek a tételnek mi a neve, de az ember hajlamos a saját területét bonyolultabbnak értékelni, mint amilyen a valóságban. Főleg ha beletett 5+ évet egy képzésbe, és abba kapaszkodni, hogy fél évnyi egyetemi szenvedéssel megtanult valamit, amivel megoldott egy olyan problémát, ami lehet, hogy nem is volt üzleti igény.

Persze az sem mindegy, hogy valaki real time beágyazott rendszereket ír, vagy több tucat fejlesztővel enterprise rendszert épít, de jellemzően ezek a tanfolyamok utóbbiról szólnak.

Ezt a marhaságot tényleg tanítja valaki infón?
Azt, hogy csak értelmes helyzetben használd, az igaz, de ez...
(Tippre elsőéveseknek mondják, aztán soha senki nem mondja meg nekik, mikor érdemes.)

Más kérdés mondjuk, hogy kellően magas szinten, nem funkcionális nyelven kerülném.

Ha tippelnem kéne, nekem Vitéz ugrana be elsőre.
Neki voltak hasonló, megkérdőjelezhetetlen kijelentései prog1 laboron. Ami rémlik, az a „ne használj doublet, hanem floatot mindenhol” (vagy fordítva, nem emlékszem, de mindenféle magyarázat nélkül).
Meghogy a a „generikus algoritmusok egyáltalán nem úgy jók, ahogy Zoliék tanítják”

Persze ez nem ma volt, meg elsőéves voltam. Lehet rosszul emlékszem. (esetleg LZhez tudnék még ilyen megkérdőjelezhetetlen igazságokat kötni, etc...)

Meg egy idővel szerintem ragad annyi infon az emberre, hogyha értelmes, akkor megkérdőjelezi ezeket / összerakja, miért is mondták az első félévben...
--
blogom

"Elmúltak azok az idők, amikor a sebesség volt a legfőbb szempont, főleg enterprise környezetben. "

Sajnos a biológiai hard limitek (1 mp-n belül válaszolnia kell egy csomó dolognak, van aminek 100ms alatt) nem változnak amíg a homo sapiens ül a képernyő előtt, és ebben a nagyságrendben az elosztott architektúra meg a sok ram tapasztalat szeritnt ritkán segít, a tudatosság és a mély hozzáértés annál inkább, akár alacsony órajelen (beágyazott rendszerek) is.

Rekurzió vs BME:

Nem tudom itt mi volt, nyilván a jobbrekurziót és a balrekurziót meg kell tudni különböztetni, de én azért elég sűrűn láttam enterprise Scala meg Clojure rendszerekben ilyeneket. A BME nagyképzésen tudom hogy ki kellet tudni teríteni meg átváltani meg hasonlók, hogy BSc-vel félbehagyva ilyen van-e, passz.

"Nem tudom mi ennek a tételnek a neve"

Ne haragudj, te milyen iskolát végeztél?

Nem hiszem, hogy túlértélelem a BME-t, azért szálltam ki a fejlesztésből mert belefáradtam a félszemű architektnek lenni a vakok közt, most beírjuk megrendelőként hogy max futásidő 500ms, aztán addig nem fizet az ügyfél, amíg meg nem oldják. Ha nagyon állítja hogy nem lehet akkor irok egy PoC-t hogy de.

Mi jellemzően az enterprise-ban dolgozunk inkább, meg marketingben (ott 1sec betöltési idő felett a bevétel 42%-a ugrik, így nagyobb cégek ki szokták verni a fejlesztésből... a 10 mp betöltődésű webshop az ilyen magyaros jelenség)

Szóval tipikusan Pistikékkel, akiket erős speckókkal tartunk kordában (sebességek leírva, BDD tesztek a speckó része, pszeudokód megvalósítás speckó része, várható terhelés speckó része, van hogy odaírjuk a sebességfaktor mellé hogy javasolt adatbázismotor MongoDB, javasolt memóriában tartani, vagy hogy javasolt full text search engine használata SQL helyett a következő indexsúlyokkal). Ettől Pistikének még elsőre rendszerint nem sikerül, de hát pénz akkor van, ha teljesül a speckó, ilyen a élet.

Ami ebben részemről struccpolitika, hogy nem nézek bele a forrásba: a külső modulstruktúra még rendszerint ránézésre stimmel (azt legenerálta a framework vagy benne volt valami react-os medium posztban), de belül általában már nagy a katyvasz, nincs jól szétválasztva a megjelenítés és az adatbázis modell, amire elfelejtettünk szélsőérték speckót írni az általában elszáll (sőt, az egyik leggyakoribb visszadobási ok hogy adott szélsőértékekre nem működik holott beleírtuk az acceptance-ba), a unittesztek rendszerint buták, a több objektumon és rétegen átívelő folyamatok valami misztikus lénynek minősülnek, és hát a kollaboratív szerkesztést, az undo-t, meg az egyéb párhuzamos működést vagy csak nettó fegyelmet igénylő modulokat elsőként kell általában depriózni a backlogról a "majd egyszer sohanapján" rovatba, hisz ha eddi nem értette a command + memento patternkombót, nem most fogja megtanulni, anélkül undo nincs, és Operational Transformation-t se fog egy átlag react kiddie írni neked, hiába vannak konplett libek hozzá (na, a kollaboratív szerkesztés meg az invalid draft mentés amúgy tipikusan olyan, ami meghaladja a képzetlen fejlesztő képességeit, pedig nem bonyolult csak tudni kell, mit csinálsz, nem az LTL képlet levezetését kérjük csak a megvalósítást...)

Ettől még jobban szeretek olyan emberekkel dolgozni akik anélkül is tudnak architektúrában gondolkozni meg gyors szoftvereket építeni hogy a PTK kötelezze rá, csak ezeknek közös jellemzőjük, hogy külföldre költöztek rég, rendszerint tőzsdei rendszerekkel foglalkoznak.

Szerintem ezt mindenki látja. Ha jól értem azon megy a polémia, hogy kapnak-e a hallgatók egy ilyen típusú képzésben elegendő tudást arra, hogy tovább tudjanak lépni, hogy tudják magukat továbbképezni, hogy elegendő alapjuk van-e megérteni bonyolultabb problémákat a későbbiekben.

Amennyire értem, sokan már felismerték azt, hogy egyáltalán nem árt matematikai tudás a karrier későbbi szakaszában, habár ezekhez a kezdeti lépésekhez nyilván nem kell. A mai hot topic-ok közül sokban nagyon erős matek kell. Pl. Big Data, Robotika, de az üzleti intelligenciák is egyre bonyolultabbá vállnak, köszönhetően annak hogy a közgazdászok is egyre keményebb matekot használnak. Az a régi mondás, hogy a közgazdaságtanban a százalékszámítás a legbonyolultabb művelet, már rég nem igaz.
Sokszor ezek programozást tekintve egyáltalán nem bonyolultak,Pl Robotikában a következő elemeket használom: tömb, if-then-else, for ciklus, saját függvények. Ez programozástechnikai oldalról kb. középiskolás anyag, sima szekvenciális programok. A nagy trükk a matek mögötte. Ha valaki nem érti nem fogja tudni implementálni, csak akkor, ha nagyon részletes pszeudókód-ot adok mellé és imádkozom, hogy ne üssön el valamit, mivel minden ismeret nélkül egy bonyolult képlet bepötyögése sok hibaforrást jelent.

A problémát én abban látom, hogy az arc aranyos frontendet ír majd, kap érte egy viszonylag normálisnak mondható összeget. De ez azért lesz, mert most épp hiány van ilyenből. Amint nem lesz hiány ez az összeg szépen be fog menni minimálbérre. Üzemeltetőknél is hasonló játszódott le.

Láttam, itt legtöbbször van a magát nyíltan okos tervezőnek tartó hülye code monkey meg a magát titokban okos tervezőnek tartó hülye code monkey. A nemhülye általában konfliktusba keveredik a nyíltan okos tervezőnek gondoló code monkey-val, és f.ckthissh.t alapon lelép backendet kódolni a londoni tőzsdére egy sötét sarokba egyedül ahol nem kell az idiótákkal kommunikálnia (egy idő után magyon herótod lesz tőlük) vagy az Orbán-kormány elől, vagy CTO lesz valahol.

Nem lesz az hogy architektúra tervezéshez bekérik az MSc diploma OKJ számát, hanem van a Béla, aki ügyes srác, dolgozott már nagy rendszeren, a Bea meg a Béci is, aztán majd valami lesz, összedugják a fejüket, megbeszélik, meg valaki leprotózza (ami egyben az éles kód alapja), szétosztják egymás közt a modulokat oszt hadd szóljon.

Eleve agile-ban nem nagyon van tervezés, és a legtöbb cégnél nem elég erős a peer review folyamat meg a stylechecker hogy betartasson bármit az "ahogy esik úgy puffan" architektúrán túl.

"Eleve agile-ban nem nagyon van tervezés" akkor mi biztosan rosszul csinaljuk az Agilet :) mert meg szoktuk tervezni, sot POColni is fejleszteni valot. Ki szoktunk tobb lehetoseget is probalni, az pedig, hogy le is irjuk mar vegkepp nagy hulyeseg :D

-
Go konkurencia kezelés gyorstalpaló

Nem elég pontosan fogalmaztam, egy-egy kódrészlet sebessége nem mérvadó, a terméké továbbra is fontos. És pont arra akartam célozni ezzel, hogy az esetek 99%-ában nem attól lesz bottleneck, hogy valaki nem a legoptimálisabban ír meg egy algoritmust, ezért többet ér, ha könnyen átlátható és alaposan tesztelhető, ami pont ahhoz kell, hogy ritkábban omoljon össze.

Ezen mar reg tul vagyunk. Nagyon nehez jol kepzett es foleg allando tanulasra hajlando munkaerot talalni meg nagyon sok penzert is. Valamikor 8-10 eve lattam EU statisztikakat arrol, hogy mekkora a munkaerohiany a mernoki es IT piacon. Brutalis szamok voltak...
Egy ilyen piac nagyon vonzo a munkavallalok szamara, igy termeszetes, hogy megjelennek nagy tomegben kevesbe kepzett emberek.

Ez egyaltalan nem ujkeletu, mar tobb sok eve lathato. Aki nemzetkozi kornyezetben dolgozik, az sajat boren tapasztalhatta.

Egyebkent erdemes leporolni a tortenelemoran tanultakat. Ipari forradalom: egyszeru betanitott munkasok a specializalt gepek mellett vs. a cehrendszerben kitanult mesterek...

> bruttó 330

fejlesztőként, nem tűnik soknak
mínusz ugye a nettó egy milla képzési díj

valami nem oké a matekkal

Bizonytalan vagy a jövőt illetően?

Ja. Ide passzol: A jóslás elég bizonytalan dolog, különösen a jövőre vonatkozóan.

--
ulysses.co.hu