Munkád során inkább ezermester, vagy specialista vagy?

Egyéb

Mindegy, hogy munkahelyen csapatban, vagy szólóban nyomod. Kérdés, hogy a munkád során inkább ezermester vagy inkább specialista vagy?

  • Ezermester
    • Értened kell mindenhez, minden problémát elsősorban neked kell megoldani. Csak akkor fordulhatsz segítségért, ha már minden kötél szakad. Vagy akkor se. 
  • Specialista
    • Egy konkrét, szűk területhez kell értened. Nem várják el, hogy mindenhez is érts. Ha a szakterületeden kívülre nyúlik a probléma, akkor annak a területnek a specialistája áll rendelkezésedre. Rosszabb esetben egy ezermester.

ezermester
78% (756 szavazat)
specialista
18% (174 szavazat)
Egyéb, leírom.
4% (34 szavazat)
Összes szavazat: 964

( hrgy84 | 2020. 09. 22., k – 10:31 )

Valahol a ketto kozott.

Ezermester vagyok, mindenhez is ertenem kell, es minden problemat nekem kell elsosorban megoldanom, de csapatban dolgozok es gondolkodok, igy ha segitsegre van szuksegem batran fordulhatok akar a sajat csapatomhoz, akar mas csapatokhoz. Regebben ezt sci-finek gondoltam, ma mar ugy gondolom, hogy ez a normalis, igy kellene minden uzemeltetesi feladatkorben mukodni.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( gelei v | 2020. 09. 22., k – 10:55 )

Kimaradt a legfelkapottabb, a T-shaped. :)

( Usumu | 2020. 09. 22., k – 11:57 )

Ha rosz a gép meg kell javítani. Ja, hogy németéknek három szagembere van egy gép típusra és agyaréknak csak egy? Just Eastern European things. A német ügyfél megérti, hogy ha el megy a gáz a hűtő körből , nem egy villamos mérnök fogja meg keresni a szivárgást és megszüntetni hanem a hűtőgepszerelő, és azt is, hogy ez utóbbi nem feltétlenül ért a PLC isztatáshoz, szenzorokhoz, stb... A magyar ügyfél kevésbé. Ezért kell bizonyos területeken mindenhez is érteni.

( answ | 2020. 09. 22., k – 12:27 )

Néha azért már kicsit sok.

Terv alapján gipszkarton falból kellett volna kilógni az UTP-knek, amire lehetett volna rakni az IP kamerákat. Ez 3 db csavar + gipszkarton dübel + 8P8C vég + akkus csavarbehajtó. Erre a villanyász mindenütt egy lyukon hozta ki a riasztóval, amire a riasztós szépen rátette a PIR-jeit. Szóval fúrhattam be odébb a falat és kanalazhattam a kábelt. Aztán megcsinálta ugyanezt téglánál is, aminél már mondtam, hogy akkor szépen véssenek + vakoljanak + fessenek, aztán hívjanak vissza.

Vagy mikor egy Java alapú alkalmazásunkat (Glassfish-el) nem tudták beüzemelni egy igen nagy telekommunikációs multinál. Addig szórakoztak, míg csinálnom kellett egy teljes virtuális hálózatot VMware-el, amiben futott a klaszter és nekik csak egy start gombra kellett nyomniuk. Egészen addig azt hittem, hogy az ilyen cégeknél csak a support inkompetens, de tévedtem.

Nem ertem, nem volt leirva a megbizasban, hogy hogyan es hova kered az UTP kabelt? Vagy nem volt leirva a nagy multi szerzodeseben, hogy mit es mennyiert csinalsz meg? Ha mast csinalt, nem fizetsz, mert nem csinalta meg, amire kerted. A multi meg ha installaciot is ker, akkor rogzitsuk, hogy milyen feltetelekkel fog ez tortenni.

LOL! De minden le volt írva. Számít ez bármit Magyarországon.. Anyag + tervezés benne van + eszközök fel vannak programozva, pénzedért perelhetsz, ha sokat ugrálsz. Aztán 1-2 év múlva mire a pernek vége van, már nem is él a (generál) kivitelező cége, aki megbízott.

Multival is sok esélyed van kardoskodni. Mikor 20-onx millió kifizetése függ attól, hogy az idióták átveszik-e, akkor nem őszinte a mosoly odafent. 

( banyek | 2020. 09. 22., k – 14:06 )

Voltam en mar mind a ketto. 

Igazabol nem szeretek specialista lenni, es nem is szeretem a specialistakat, szakbarbaroknak tartom oket, akiknek - bevallom - nem feltetlenul tartom sokra, amit tudnak, hiaba tudnak rettenetesen sokat egy-egy adott feladatkorbol.

Olyan munkakban erzem jol magam, ahol ralatasom van az egesz termekre, ahol tudom, hogy miert ott, es miert ugy vannak az adatbazisok, miert olyan a network, amilyen, miert ugy mukodik a konfig menedzsment, ahogy.

Amikor olyan helyeken kell dolgozzak, ahol nincs mas dolgom, csak nyujtani egyfajta supportot, szolgaltatast, akkor hiaba tudok elmelyuli abban, amivel dolgozom, nem lesz rendszer, amit epitek, csak szakmunka. 

Ha a céges hálózat négy kontinensen van jelen, és ott komoly hálózati hiba van, azt már nem fogja tudni elhárítani senki, csak a specialista. Ugyanakkor a programozó ne akarjon adatközpont infrastruktúrális kérdésekkel fogllakozni, mert abból semmi jó nem fog kisülni.
Egy ISP vagy specialistákat vesz fel, vagy nem lesz képes szolgáltani. ÉSatöbbi.

Ez nagyon jól hangzik, viszont a gyakorlatban ez úgy néz ki, hogy a "specialistának" olyan részletesen kell elmagyarázni, hogy mit szeretnék, hogy olyan erővel már meg is csinálhatnám. Ráadásul ha bármi bonyolultabbat/szokatlant kérek, akkor biztos, hogy elsőre nem lesz jó, és úgyis nekem kell kitalálnom, hogy mit rontott el.

Szóval a vége az, hogy programozóként azért kell infrastruktúrális kérdésekkel is foglalkozni (meg amúgy minden mással ami csak felmerül), mert különben soha nem fog működni amit szeretnék.

Akkor nem ugyanazt értjük specialista alatt. Valszeg te az operátorokkal dolgzol együtt, akik előre kiadott use case-ek mentén változtatnak konfigurációt. Én hálózati specilaista vagyok, ez persze nem azt jelenti, hogy nem tudok webes toolt fejleszteni, összekalapálni és készre szabni egy linux szervert vagy szkripteket írni az automatizálható feladatokhoz.  Mindösstze azt jelenti, a leginkább azokban a hálózati protokollokban merültem el, amikről a legtöbb informatikus nem is hallott. .  De értem, amit mondasz, terveztem már olyan adatközpontot, amit 3 hét alatt összeraktam volna magam, a szolgáltató change ticket rendszer "segítségével" meg eltartott kilenc hónapot, mire az ügyfél is élvezhette.

A gyakorlatban inkább az szokott előfordulni, hogy a hálózati specialista kénytelen elmagyarázni a rendszergazdának (vagy akár a fejlesztőnek), hogy egy problémát nem úgy kell definiálni, hogy az X alkalmazás nem működik, hanem úgy, hogy A szerver nem tud kapcsolódni a B szerverhez C porton. Ha netán ez mégis összejön, akkor az A és B szerver címe helyett adnak egy hostnevet (nem FQDN), és ez a jobbik eset. Rosszabbik esetben nyitnak egy ticketet, ahol egy semmitmondó java dump van, aztán oldd meg.

Szóval a rendszergazda meg a fejlesztő az beszéljen network specialistául, és mondja el neki egészen pontosan, hogy mit is szeretne az ő domainjében, de visszafele már nyugodtan lehet semmitmondózni a java dumpot, mert az már nem az ő szakterülete. Azt hiszem, pontosan erről a jelenségről beszélt yetii feletted.

A legnagyobb pöcsök mindig az asztal másik oldalán ülnek. :) A fejlesztő/hálózatos/tűzfalas/üzemeltető szerint mindenki más hülye, abban egyeznek meg csak, hogy a management természetesen semmire nem jó és nem ért semmihez, meg némileg ennek ellentmondóan abban, hogy bármilyen nehezebb kérdést (értsd, amikor valamelyik ujjba bele kell harapni) nekik kéne megválaszolni, hogy hogyan legyen. Cserébe a management szerint meg mindegyik óvodás, max van amelyik már nagycsoportos. ;)

Nos, erre találták ki az OSI meg a TCP/IP modelleket, amiket MINDENKINEK érteni kellene. Igen, ha nem adsz ip címet és portot, vagy legalább olyan adatokat, amikből ezt ki lehet hámozni, nincs az az ezermester/specialista, aki akárcsak el tudná kezdeni a hibajavítást. Ezek nélkül ugyanis lehetetlen.  A java dump nem semmitmondó, de hálózati szempontból  ( azaz IP ill. layer3 rétegben) nem releváns, ha nem tartalmaz ip címeket mg protokoll azonosítókat - amit nem fog.

 

Jaja, a networkos alapokat mindenkinek ismerni kellene. Meg a fejlesztési alapokat, meg az OS alapokat, az elterjedtebb enterprise keretrendszereket, meg az ilyeneket is. Jep, a hálózatosnak is. És természetesen van olyan java dump, amiből semmi nem derül ki, de

- egyrészt igen nagy különbség van a " hanem úgy, hogy A szerver nem tud kapcsolódni a B szerverhez C porton" meg a "vagy legalább olyan adatokat, amikből ezt ki lehet hámozni" között. (Arról nem beszélve, hogy boldog az az applikáció ma már, amihez van egy jól definiálható port, meg két host, mert annyira egyszerű)

- másrészt meg ez az "én layer 3 -ig vagyok vele hajlandó foglalkozni" ez az, ami rohadt káros. A specialistának igenis fel kell fogni, hogy a rendszer mit akar csinálni, és kell neki tudni érdemben válaszokat találni arra a kérdésre, hogy mi a két host meg a port, akkor is, ha a bugban annyi van, hogy szar az app. ( Igen, ehhez nyilván nem elég stack trace -- bár nekem már meglepően sokból sikerült kiderítenem, hogy ki nem tudott kivel beszélni -- a fejlesztőnek is kell tudni érdemben közreműködni abban, hogy mit akar a cucca).

Illetve hát nem _kell_, lehet azon morogni, hogy ipcímport még ezt se tudja a hülye, csak akkor nem kell csodálkozni, ha le szakbarbározzák az embert.

A specialista - már ha tényleg az - egy tcpdump-ból fogja ezt tudni kihámozni - na ezt minden fejlesztőnek tudnia kellene. És a hálózatos layer3-ig fog vele foglalkozni, mert ha azt látja, hogy a hálózati kapcsolat szépen kiépült, a TCP kapcsolatok Established állapotban vannak, és nincsen black hole - akkor leveszi szépen a következő ügyfél következő ticketét, előkészíti a  jövő heti firmware ugprade-jét vagy kimegy kávézni. 

Mit várnál tőlem még, ha a wireshark segítségével kimértem, a hiba nem a hálózati rétegben van?

Mit tudnék még az alkalmazásodért tenni, ha egyszer a rúterek, switchek, tűzfalak, loadbalancerek, WAAS-ok/Riverbedek és egyéb nyalánkságok pontosan úgy vannak beállítva, ahogy az alkalmazás igényli és hibamentesen teszik a dolgukat?

Nagy szavak helyett (hidd el, ismerem mind, ültem már az asztal összes oldalán, feküdtem alatta, ültem a tetején) együttműködést. Ami egyébként szerintem benned megvan, és ezért nem is érted, hogy miről beszélünk. Bár attól még, hogy látsz kiépült TCPt, attól még egyáltalán nem biztos, hogy a hálózatod rendben van, és ezt te is tudod, gondolom. Tudod, erősen gyanús, hogy ha valami hálózati szarra szaladtak a kollégák, akkor valami nem pontosan úgy van beállítva, ahogy azt az alkalmazás igényli, és még az is lehet, hogy a te térfeleden.

(Meg egyébként azt, hogy ha már nagy szavakkal akarsz dobálózni, akkor ne gyere olyanokkal, hogy layer3-ig fog vele foglalkozni, aztán írd le, hogy load balancer meg tűzfal, meg dobálózz tcpdumppal meg ws-el, amikor az enterpriseban használt eszközök jelentékeny részében ilyet nem fogsz futtatni (és nem, egy átlag fejlesztőnek rohadtul nem kell packet tracert ismernie), mert így a végén még azt találja hinni az ember, hogy nagyzolni akarsz, aztán sikerül össze vissza beszélni, amolyan szakbarbár módjára)

Keresem a nagy szavakat az előző kommentemben, amikre hivatkozol. Ha egyszer egy adatközpontot úgy terveztek meg, hogy van egy rútingot is végző tűzfal cluster, mögötte loadbalancerek, mögötte a valamilyen  switchek, amögött vmware-t futtató vas, akkor a hálózatosnak ezekhez az eszközökhez/ill. a vmware hálózati részéhez kell elsősorban értenie. t. Azt sem értem, hogy mitől nagy szó egy tcpdump, körülbelül annyira nagy szó, mint az orvosoknál a röntgen felvétel vagy a vérkép. A paciensnek nem kell tudnia kielemezni ezeket, de azt értenie kell, hogy ezek kellenek az orvos munkájához.
Ami a layereket illeti, jól elkaptál te itt egy ponygyolaságon engem: maradjunk annyiban, bizonyos cégeknél van a specializációnak olyan foka, amikor már a tűzfalat is külön csoport vizsgálja, meg van olyan, amikor nem. A leghatékonyabb akkor voltam, amikor a szervereken root jogom volt, és az összes hálózati eszközön is admin jogggal bírtam ebből az emlékből merítve válaszoltam.

Sosem állítottam, hogy egy átlag fejlesztőnek packet tracert meg GNS3-at kellene ismernie, de józan ésszel azt gondolná az ember: a fejlesztő körülbelül meg tudja mondani, az alkalmazása milyen portokon kommunikál és kikkel. Vagy ha nem tudja, akkor - biztosan dolgozok egzotikus helyen (német piac) -  akkor nekiállunk dumpolni. 

Együttműködés - na ez az, ami a multik ún. megoldócsoportjainál nagy hiánycikk.  De erről ők is tehetnek - az ostoba processzekkel, a siló gondolkodással, az apró darabokra szeletelt workflow-kkal, amikhez három hetes belső térningen képzett bölcsézeket vesznek fel.

"Együttműködés - na ez az, ami a multik ún. megoldócsoportjainál nagy hiánycikk.  De erről ők is tehetnek - az ostoba processzekkel, a siló gondolkodással, az apró darabokra szeletelt workflow-kkal, amikhez három hetes belső térningen képzett bölcsézeket vesznek fel."

Látod, mondom, hogy nem érted. :) Sejtem, hogy azt szeretted volna mondani, hogy ha te jó szándékúan mindent megnéztél mindent, akkor mit kéne még tenned. Csak amikor ezt úgy teszed, hogy példálózós jelleggel felsorolsz egy rakás hálózat domaines szakkifejezést, akkor lehet, hogy te ezt azért tetted, hogy érzékeltesd, hogy te megnéztél alaposan mindent, de nagyon könnyű úgy hallani, hogy vagizol a "nagy szavakkal", főleg akkor, ha ezt aztán sikerül még pongyolán is előadni. És főleg akkor, mikor egyébként az akinek baja van, még mindig baja van, te meg elintézed azzal, hogy "leveszi egy másik ticketet, vagy elmegy kávézni". Mert ez bizony annak, akinek baja van, azt fogja közvetíteni, hogy szarsz a bajára, és leszel besorolva arrogáns hálózatos köcsögnek. Aminek egyenes következménye, hogy legkésőbb a következő körben te meg be fogod sorolni az okoskodó hülye fejlesztőbe, mert akkor már úgy fog jönni, még ha előtte nem is tette volna. És így kerülnek az asztal mindkét oldalára hülyék.

"Ami a layereket illeti, jól elkaptál te itt egy ponygyolaságon engem: maradjunk annyiban, bizonyos cégeknél van a specializációnak olyan foka, amikor már a tűzfalat is külön csoport vizsgálja, meg van olyan, amikor nem"

Nem mondod, mik vannak :)

"Sosem állítottam, hogy egy átlag fejlesztőnek packet tracert meg GNS3-at kellene ismernie, de józan ésszel azt gondolná az ember: a fejlesztő körülbelül meg tudja mondani, az alkalmazása milyen portokon kommunikál és kikkel."

Félre ne érts, az én józan paraszti eszem is ezt mondatja velem, én sem értem, hogy a fenébe lehet ma ITban úgy dolgozni, hogy legalább nagyjából ne legyen képbe az ember a networkinggel, de
- egyrészt bias: a fejlesztő ugyanilyen alapon fogja gondolni, hogy a hálózatos meg tud érteni egy java tracet, a supportos bele tud nézni a log üzenet alapján a forrásba, az db admin, hogy egy kurva explaint csak meg tud nézni egy hülye fejlesztő is. Aztán nagyon sokszor nem
- másrészt whishful thinking: Távozott már tőlünk idejekorán interjúról magát seniornak tartó fejlesztő (akinek a releváns tapasztalati konkrétan webfejleszősök voltak), mert a kolléga megpróbált belőle kihúzni valamit arról, hogy mennyit tud a HTTPről mint protokollról, és kb odáig jutott, hogy hát vannak benne cookiek, de a header szó már nem hagyta el a száját. Mindezt úgy, hogy második kör volt, és az elsőn elárultuk neki, hogy a termék, amihez embert keresünk gyengébb napjain is könyékig a HTTP belsejében turkál, tehát még csak váratlan se lehetett nagyon.
- negyedrészt sokszor messzebb van egy fejlesztő a hálózattól, mint gondolnád. Kér a service sdk libjétől egy connectiont, és dolgozik. Jártam én úgy, hogy kaptam egy java tracet, hogy időnként lehal a queue. Megnéztem, mondtam a fejlesztőnek, hogy az van pajti, hogy timeout miatt egy hálózat eszköz közli a két féllel, hogy ez a TCP reset, amire a szabvány azt mondja, hogy azt jelenti, hogy ezzel a kapcsolattal többet nem foglalkozunk, a te programod meg eszt szépen leszarja, aztán csodálkozik, mikor legközelebb megpróbál belebeszélni. Ő meg tette szét a kezét, hogy ő kér a glassfishtől egy connection poolt, nulla ráhatása van erre a részre.
- negyedrészt ma már egyáltalán nem triviális egy egy hálózati kommunikáció egy alkalmazás szempontjából. Bonyolult, és több protokol. Nem tudom, láttál el pl corbát pl, good luck, hogy elmondják, hogy melyik endpoint melyik portjával van a baj, simán be tud neki keverni nat, meg port fw, meg mindenféle.
- ötödrészt meg nem is mindig fejlesztő az, akinek baja van, próbálj meg egy lyncet (hogy hívják ma, skype for business?) értelmesen átengedni tűzfalon, 77 különböző szarral próbálkozik, és valami kibaszott support oldalról kell összebogarászni, hogy a héten éppen mik az endpointok az MS szerint, ahova beszél. Aztán ilyenkor lehet menni az alkalmazás üzemeltetőhöz, hogy az ő vacka, mondja meg, min beszél.

Szóval all in all, ma a hálózat erősen össze van nőve a rajta futó alkalmazásokkal (meg egyébként minden mindennel), rengeteg a határprobléma, az emberek meg problémákat akarnak megoldani, nem azt hallgatni, hogy nálam minden jó. (A műtét sikerült; a beteg meghalt.) Ezért egy jó specialistának sajnos elengedhetetlen skillje, hogy értse annyira a szomszéd területeket, meg tudjon normálisan kérdezni, hogy kiderüljön az issue, még akkor is, ha csak annyi, hogy a másik fél is megnyugtóan értse, hogy ezzel most a másik specialista kéne inkább. Különben lehet nagyon jó szaki, de csak szakbarbár lesz a többiek szemében.

Hát nézd, ha egy rednszerüzemeltető nem tudja (visszakérdezés esetén se), hogy a gépének mi a címe, és az alkalmazása hova kapcsolódik, és ezek az információk a java dumpban sincsenek benne, akkor mégis mit kéne csinálni?

Ha neked egy IP cím (urambocsá egy port) azt jelenti, hogy 'network specialistául' kell beszélni, akkor veled van baj.

Ha visszaolvasol, én nem írtam fejlesztőkről. Üzemeltetőről rendszergazdáról igen. Azoktól viszont tényleg elvárom, hogy legalább azzal legyenek tisztában, hogy mi a gépük IP címe vagy legalább az FQDN DNS neve. Ha ez nálad kiverte a biztosítékot, az nem engem minősít.

Hát nézd, ha egy rednszerüzemeltető nem tudja (visszakérdezés esetén se), hogy a gépének mi a címe, és az alkalmazása hova kapcsolódik, és ezek az információk a java dumpban sincsenek benne, akkor mégis mit kéne csinálni?

Ha neked egy IP cím (urambocsá egy port) azt jelenti, hogy 'network specialistául' kell beszélni, akkor veled van baj.

Feltehetőleg az egerem romlik, időnként egy gombnyomásra hajlamos ismételni. Az már egy jó kérdés, hogy egy gyors dupla miért generál egyből két postot. Ez vagy böngészőoldali probléma (egy gombra kétszer nyomva két POST műveletet végez), vagy szerver-oldali, de az kizárt dolog, mert nem tudom.

Nem lenne itt semmi gond, ha ez az "ezermester" értené legalább annyit a hálózatokhoz, hogy a hálózati problémákhoz nem java dumpot küldünk a hálózatosnak, hanem tcp dumpot, (akár rögzítünk egyet az ügyféllel közösen).  Specialista alatt persze én azt értem, aki ezzel tud is mit kezdeni. 

Van egy gyanúm, hogy az "ezermesterek" azért képzelik magukat képzettnek a network terén, mert azt gondolják, ha le tudnak ellenőrizni maguk is egy tűzfal szabályt, meg be tudnak állítani egy SSID-t egy AP-n , akkor mindent tudnak a hálózatok világáról.

( Sanya v | 2020. 09. 22., k – 14:10 )

Szerkesztve: 2020. 09. 22., k – 14:12

Orvos vagyok, szakorvos, egy speciális részleget vezetek. A részlegen a legtöbb mindenhez értek. Nagyon kevéshez nem. Viszont ami a részlegen kívül van, ahhoz értek orvos szinten, de koránt sem szakorvos szinten.

 

Tehát a saját területemet tekintve ezermester vagyok. Ha orvoslást tekintem kategóriának, akkor abban specialista.

( eff | 2020. 09. 22., k – 14:53 )

a sysadmin/automation engineer, szoval a ketto kozott. egyreszt ertek az automatizalashoz/uzemelteteshez, a kodot kb messzirol latom, szurke doboz szinten. Mashogy nem is igazan lehet.

( uid_16313 | 2020. 09. 22., k – 14:58 )

Magyar valóság. Egy ember 5 másik munkáját elvégzi szaré-hugyé (ha az 5 fizuhoz hasonlítjuk).

( Vamp | 2020. 09. 22., k – 15:36 )

Szerkesztve: 2020. 09. 22., k – 15:37

Papiron specialista, gyakorlatban ezermester. Elv vannak laza "feladatkorok" az IT reszlegen (storage, virtualizacio, network, etc...) gyakorlatilag ha baj van/valami tegnapra kell, ez rohadtul nem erdekel senkit :)

 

Anyacegnel (Nemetek) mindenre IS van egy ember. A masik hozza sem szagol, akkor sem ha ertene hozza, mert nem az o dolga es kesz. Az monduk szep, amikor az adott spec. elmegy kint szabira es nincs helyettesito embere...

( Foltos | 2020. 09. 22., k – 18:49 )

"M" shaped. Firmwaresként:
Elsősorban C programozás.
Van itt mikrokontroller, illetve application processor is (mostanában Cortex-A/M) ami teljesen más szemléletet igényel. Ehhez rengeteg minden kapcsolódik a SW architektúra tervezéstől a hiba keresésig. Van amihez jobban, van amihez kevésbé értek.

Infrastruktúra
Ha kell felhúzok Linux szervert + gerritet + Jenkins -t, írok groovy jobokat, heggesztek python toolokat, shell szkripteket. Üzemeltettem linuxos tűzfalat, HA -ban file szervert. Ha kell board farmot tervezek/implementálok/üzemeltetek teszteléshez.

Hardware
Ha kell meg kell tudni fogni a pákát, és a szkóppal is zsonglőrködök néha.
Ha boardot fel kell dugni PC -re, akkor akad driver debugging Windows/Linux oldalon.

Management
Idén kaptam a nyakamba line management -et, illetve csapatot vezetek.

Tulajdonképpen fel tudok húzni egy FW projektet nulláról, programozástól az automatizált teszteken keresztül a publikálásig/karbantartásig.

Mindenhez annyira értek amennyire és amikor kell. Attól függ, hogy milyen a melóhely, illetve az aktuális project, illetve azon belül a feladatom. Vannak dolgok amik álmomból is mennek 100 éve, és olyanok amiket rendszeresen újra tanulok. Tudom mikor, mit és kitől kell megkérdezni, illetve, hogy kitől kell megkérdezni, hogy kitől kell kérdezni :D

~20 éve vagyok az "iparban", és szerintem bárki hasonló idő alatt hasonlóan széles tudásanyagot halmoz fel. Éppen csak a részletek különböznek szakterülettől függően.

Az első háromhoz hasonló problémamegoldó típusú ember kell, még ha más domain tudással is, a line (people) managementhez viszont egészen más skillek szükségesek. Sokszor láttam, hogy kiváló techie kollégát megtettek line managernek, hiszen az volt az érdemi előrelépési lehetőség adott cégnél. Azt azonban már csak közepes vagy annál is rosszabb szinten tudta ellátni.

( nagyjoco | 2020. 09. 23., sze – 09:04 )

Csak routing és switching. Persze nagyválalatnál.

Kellően nagy cégnél és bonyolult hálózatnál rendszeresen akadnak érdekességek, ráadásul az utóbbi öt-hat évben (legalábbis Cisco alapokon) erőteljes technológiaváltások voltak (néha ugyan kicsit cikkcakknak tűnik), szóval lehet ott is találni változatosságot.

Pontosan.

Én is isp-nél vagyok IP hálózat "specialista", van annyira sok minden, hogy ne lehessen megunni.

Pl. tűzfalakhoz IS külön részleg van. Ők se akarnak beleszólni,milyen policyk legyenek egy IP exchange pontban, én se szólok bele, milyen nat szabályok legyenek  a dobozaikban (pedig üzemeltettem régebben asákat is, de abban nem vagyok specialista - és nem is akarok).

És igen, ha jön egy hibajegy és abban a hálózatban amiért mi felelünk, minden oké, akkor továbbdobom a megfelelő csoportnak.

Egy bizonyos hálózati meret felett az ezermesterkedés már nem lehet hatékony.

( hnsz2002 v | 2020. 09. 23., sze – 10:23 )

Ezer szakma specialistája.

"Sose a gép a hülye."

( bitshepherd | 2020. 09. 23., sze – 14:20 )

Eddig mindig olyan helyeken dolgoztam, ahol ezermesternek kellett lenni, és szerintem ez így van jól, ha kevesebb dologgal kellene foglalkoznom, akkor egy idő után megunnám.

( Oregon | 2020. 09. 23., sze – 15:58 )

Nekem az a specialitásom, hogy ezermester vagyok. :P