Programozók ez mennyre igaz?

A válaszoló lényegében azt írta, hogy a szar programozókat kirúgják - őszintén, ez meglep téged?

Jó referenciával olyan helyre vesznek fel, ahova érdemes is menni. Egyébként programozni nem csak itthon lehet, ebben az esetben még költözni sem feltétlenül kell.

Mennyire igaz?

Semennyire.

Rengeteg "informatikus" van, ez tény. De aki ért is hozzá, abból hiány van.

Boldog-boldogtalan elvégez egy webdesigner, vagy programozó okj-t, és ő már attól ugye "informatikus". Papíron. Aztán ők azok, akik az első komolyabb interjú-feladatnál elvéreznek, majd ezután hangoztatják, hogy túltelített a piac, meg hogy lehetetlen elhelyezkedni.

Az meg, hogy aki nem alkalmas a munkára, megválnak tőle, minden területen természetes dolog.

Ez teljesen igaz.

Egy OKJ-tol nem lesz valaki programozo, sot meg egy egyetemi kepzes sem feltelenul eleg.

Persze, hogy be tudod magolni azt a 10 oldal utasításkészletet akármilyen nyelvből, amire adják a programozó OKJ-t, és papíron ugyan informatikus vagy, de a gyakorlatban nincs mögötted az a szakmai tudás, ami képessé tenne téged arra, hogy el tudd végezni a legalapvetőbb dolgokat egy cégnél.

Egy Programozó nem csupán billentyűpüföléssel tölti a munkaidejét, hanem:

-Kapcsolattartás az ügyfelekkel, méghozzá nem falusi paraszt, hanem öltönyös hivatalnok stílusban

-Specifikáció egyeztetés az Analyst munkatárssal

-Kód-verifikáció az Architekt(ekk)el

-Modelleket kell alkotnod, és meg kell győznöd a többieket is, hogy ez a helyes út

-Dokumentálnod kell MINDENT (ez az időd 20%-a, még akkor is, ha 2 fős cégben vagy)

-A főnök vagy valamelyik spiclije óránkként megkérdezi, hogy kész-e vagy már

-NE adj isten olyan kódot kell írnod, amit már a tervezési fázisban kell optimalizálni az alábbi szempontok szerint:

+futásidő

+kódméret

+felhasznált ram

+periféria hozzáférés !!! >HARD-REALTIME< !!! ütemezése

+párhuzamosíthatóság

-a párhuzamos folyamatok külön esete az, amikor ne adj isten debuggolni kell valami hozzáférést (igen, erre lenne való a mutex, csak sok primitív programozócska imád blocking módszerrel kódolni, mert úgy a legegyszerűbb)

-Ha mindez megvan, akkor csinálj agilis módszerekkel teszt-case-eket (kb 100-as nagyságrendben gondolj ki +HIL), és ugyanezeket is programozd le, majd vezess jegyzőkönyvet

Hogy nehezítsünk a dolgon, mindezt olykor angolul is elvárják, méghozzá tegnapi határidőre.

Most már érted, hogy nem csak a kiadott kódjaid miatt tudsz elbocsátódni egy munkahelyről?

A tervezésidejű optimalizálásról annyit, hogy egy nettó baromság. Az optimalizálás !egyetlen! feedback-je a mérés. Mérés nélkül optimalizálni olyan, mint a nyelv ismerete nélkül programozni.

Egyszerűen ma a hardware-k és a fordítók komplexitása sokkal nagyobb mint régen. Nem lehetséges programot előre optimalizálni (mert nem tudod mi mennyit számít vagy javít-e egyáltalán) és az optimalizálásnál kilépési kritériumra van szükség (mikor hagyd abba, mert pénzbe kerül és mással is lehet foglalkozni). Tehát nem lehet csak előre optimalizálni és úgy sem, hogy legyen gyorsabb (vagy remélem megfizetik :) ).

Persze, megpróbáltam én is ezt beadni a vezetőségnek, csak nem hiszik el, hogy tervezéskor nem lehet optimalizálni :D

Nyilván nekem se lenne jó, ha a béta tesztelő folyton rám mutogatna, és engem rúgnának ki, mert nem gondoltam előre a határciklusok eliminálására.

Igen, ezt hagytam ki, egy programozótól alapvető elvárás, hogy tisztában legyen a nyelv gyengeségeivel, és erre már jó előre megírja a kódjában a védelmet (pl nonblocking kezelések, API visszatérési hibakódok, folyamat biztonságos leállítás)

" nem fogsz tudni kézzel gyorsabb assembly kódot írni."

Ezzel vitatkoznék, egy kezdő kolléga "kódjának" verifikálása után 800ms futásidőt leredukáltam 30 ms-re.

A kódolás stílusán is sok minden múlhat.