A sorozat 1. része (Az IT nem gyártósor) most arra keresem a választ, miért nem alkalmazott matematika az informatika, és milyen informatikus lesz a matematikusból.

A sorozat 1. része (Az IT nem gyártósor) most arra keresem a választ, miért nem alkalmazott matematika az informatika, és milyen informatikus lesz a matematikusból.

Had kezdjem azzal, hogy mi a közös a matematikában és az informatikában – mert sok közös pont van: algebra, logika, számítás elmélet, statisztika, stb. Számos informatikai problémához matematika tudás szükség, mint például: mesterséges intelligencia, hálózat elmélet, tömörítés, képfeldolgozás, biztonságtechnika/kódolás, adatátvitel, hibajavítás.

Emlékszem, volt olyan időszak az IT történetben, amikor havonta jelent meg újabb és újabb tömörítési algoritmus, elavulttá téve a régieket. Az az időszak elmúlt – ma már minden komolyabb problémára tudjuk a standard megoldást. Mindenki ismeri a leggyorsabb sorbarendezési algoritmust, tudjuk a normál formákat, szabványos kép és videóformátumot használunk. Miközben az elméleti kihívások száma csökkent, a jó munkásemberek iránti igény megnőtt: ma már nem jó elméletekre, hanem jó minőségre és elégedett ügyfelekre hajtunk. A prioritások megváltoztak, az IT nem matematika többé.

Habár több IT-ban dolgozó matematikust is ismertem, de IT vezetőt egyet sem. Talán azért, mert egy tudósember számára az IT menedzseri pozíció a legkevésbé vonzó. A tudósembert az elméletek, a problémák érdeklik, amire max fejlesztőként van esélye. Meg egyébként is, a matematikus fokmérője a publikáció, menő matematikus pedig tudományos munkásságra hajt (PhD, doktori, professzori katedra az egyetemen, előadások). Ehhez képest jól fizetett IT gurunak lenni egy multinál = kudarc.

Az alábbi listában azokat a főbb indokokat szedtem össze, amik miatt az IT nem matematika.

Informatikai tapasztalat

Mint korábban írtam, az informatikust a tapasztalat teszi. Nem az, hogy mennyire okos vagy hogy milyen elméletet rakott össze. Egy jó fejű matematikusnak képes kb fél nap megtanulni egy C#-ot, és rögtön tud írni programot, de hogy egy stabilan működő, felhasználóbarát programot írjon, ahhoz kevés az elmélet. Sok esetben a műszaki, szakmai döntéseket nem számok, hanem megérzések és korábbi tapasztalatok alapján hozzuk (pl. adj becslést egy rosszul specifikált igényre).

Elmélet vs gyakorlat

Sok esetben a legjobb megoldás az, ha az elmélettel ellentétes megoldást alkalmazunk, gyakorlati okok miatt. Például egy adatbázist leoptimizálhatunk a normál formák alapján, de bizonyos esetekben az a praktikusabb, ha bizonyos adatokat duplikálunk a jobb teljesítmény érdekében.
Vagy ha az elméletben legjobb algoritmus megvalósítása több időt/munkát igényelne, mint a kevésbé jó.

A felhasználók

Az IT-ban van egy nagyon fontos kockázati tényező, ami egyetlen elméleti tudományban sincs: a felhasználók. Akik emberek, gyarlóak, igényeik vannak, sokat hibáznak, de nem szabad velük szembehelyezkedni. Akkor sem, ha Nobel díjasnak gondoljuk magunkat.

Csapatmunka

A jó eszű programozó nagy segítség a csapatnak. De ez itt csapatmunka, és a zsenialitásnál fontosabb, hogy össze tudjon dolgozni a többiekkel. Akkor is, ha azok nála butábbak.

A kihívások hiánya

A 21. századi informatikában a problémák nagy része rutin jellegű, azaz valamilyen középszerű ember a rendelkezésre álló információk alapján mechanikusan meg tud oldani. Nincs szükség elméletekre vagy tudományos háttérre, nincs szükség elméletek ütköztetésére. Vannak ugyan kihívásokat jelentő szakterületek, ahova kell 1-2 zseni, de nem ez az általános.
A felhasználóknak egyszerű adatbázisos szoftverek, csili-vili web oldalak és dobozos termékek kellenek.

Fizetés

Vannak igen jól fizeti matematikus állások (pl. elemző egy banknál), tehát aki akar, az sok pénzt is tud keresni. Ehhez képest nem túl jó érzés elmenni átlagos fejlesztőnek és pont ugyanannyit keresni, mint egy sokkal butább informatikus.
A cég pedig nem fog többet fizetni egy programozónak azért, mert tud integrálni…

A Legjobb Gyakorlat csodálatos világa

A 21. század IT világában szinte mindenre van best practice, valahol valaki kidolgozott legalább egy standardot, esetleg még minősített szakvizsgát is lehet tenni. Nem kell kitalálni semmit, csak elolvasni és alkalmazni. Uncsi.
Arról nem is beszélve, hogy egy buta, de a tipikus megoldásokat jól ismerő fejlesztő hamarabb old meg informatikai problémákat, mint aki okos, de nem rendelkezik IT háttérrel.

Karrier lehetőség hiánya

Tegyük fel, hogy az informatikussá avanzsált matematikus beválik, és nagyon jól végzi a munkáját. Mi lesz vele 5-10 év után?
Ha az adott területen voltak is kihívások, ennyi idő után már minden rutinmunka lesz.
5-10 év után már illene csapatot vezetnie és jól kommunikálnia az ügyféllel – amihez a legkevésbé van affinitása.
Menedzser nem lesz, mert az nem érdekes.
Talán guru lesz és konferenciákra jár előadni, de ilyen emberből csak kevés kell.
De az IT egy rendes matematikus számára mindig is „mellékes” marad, nem lesz életcél.

Az IT nyelve

Annak idején a számítástechnika nyelve megegyezett a matematika nyelvével. Az évtizedek során a kettő szétvált. Manapság az informatikai cikkeket és könyveket informatikusok írják informatikus aggyal. Azaz ha valaki nagyon bele akarja magát ásni a szakmába, akkor fel kell vennie ezt a hozzáállást és nyelvezetet. Kívülállóként nem lesz egyszerű.

Vezető tudományág vs szolgáltatás

A matematika – bármennyire is utálják egyesek – az a tudomány, ahol nagyszerű új elméletek születnek, amiket majd valahol máshol alkalmaznak. A matematika az, ami képes áttörést hozni, ahol lehet forradalmat csinálni, új területeket felfedezni és Nobel díjra szert tenni.
Ezzel szemben az informatika egyre inkább szolgáltatás vagy közmű. Vannak kitörési pontok és forradalmi lehetőségek, de ezek új szoftvert, új üzleti modellt vagy új céget jelentenek. Vagyis új szolgáltatást.