A közelmúltban sok szó esett a twitteren a 10x mérnökről, ami nagy vitát indított el arról, hogy mitől lesz jó mérnök. Néhány igazán hülye dolgot említettek, mint például “a 10x mérnökök utálják a megbeszéléseket” és “a 10x mérnökök későn jönnek az irodába” és “a 10x mérnökök laptopjának háttere általában fekete”. Általánosságban úgy tűnik, hogy egyesek úgy gondolják, hogy ha elég okos vagy, nem baj, ha seggfej vagy.
A Wixnél megpróbáljuk a seggfejeket az ajtón kívül hagyni. Hisszük, hogy a 10x mérnökök nem csak olyan emberek, akik 10x gyorsabban tudnak termelni, mint a legtöbb ember, sőt, ezek olyan emberek, akik egy egész csapatot 10x jobbá tudnak tenni azáltal, hogy pozitív hatással vannak mindenkire, akivel együtt dolgoznak.
Sok ember a karrierje nagy részét azzal tölti, hogy azzá váljon, amit mi tisztességes mérnöknek gondolunk. Ez azt jelenti, hogy jó kódoló vagy, aki képes problémákat megoldani, és folyékonyan tudod használni a rendelkezésedre álló eszközöket, például IDE-t, hibakeresőt, szolgáltatásokat és keretrendszereket. Ez a cikk megpróbálja leírni, hogy mi a Wix Engineeringnél mitől lesz egy tisztességes mérnökből 10x mérnök.
A mérnök egyik legfontosabb képessége, hogy képes önállóan dolgozni. Dióhéjban ez azt jelenti, hogy mindig tudja, mit kell tennie, és ritkán kerül olyan helyzetbe, amikor arra vár, hogy valaki megmondja, mit kell tennie. Ez nem azt jelenti, hogy mindent képes vagy egyedül megcsinálni, csak azt, hogy tudod, hogyan oldd fel magad és hogyan oldj fel másokat a csapatodban olyan tiszta módon, amely minimális technikai adósságot okoz. Ha például valamilyen probléma miatt leblokkolsz, találsz rá megoldást, akár úgy, hogy segítséget kérsz a társaidtól, akár úgy, hogy egyedül oldod meg. A független mérnökök képesek egy projektet az ötlettől a gyártásig annak minden fázisában végigvinni. Képesek meghatározni, hogy mik azok a dolgok, amelyekre szükségük van ahhoz, hogy egy feladatot el tudjanak végezni, és tudják, mikor kell jelezniük, ha segítségre van szükségük.
Tervezés
A legnehezebb dolog, amivel a kevésbé tapasztalt mérnökök küzdenek, az az, hogy képesek legyenek egy nagy feladatot kisebb lépésekre lebontani. Ez nem csak azért fontos, hogy meg tudjuk becsülni, mennyi ideig tart valami, hanem a jó minőségű szoftverek készítésének is kritikus része. A helyes tervezés azt jelenti, hogy a fejlesztő a lehető leghamarabb kiadhatja a termék kezdeti verzióját, és hamarabb elkezdhet visszajelzéseket kapni. A helyes tervezés azt jelenti, hogy korán megvan a rendszer tervezete, és jó képet kapunk arról, hogy mit fogunk csinálni, mielőtt a vízbe ugranánk. A helyes tervezés azt jelenti, hogy a fejlesztés során nem érik nagy meglepetések, amelyek tönkreteszik a tervét. Egy jó mérnöknek képesnek kell lennie arra, hogy lebontsa a feladatot, meghatározza a tervezést és a kiadás fázisait, és tervdokumentumokkal és becslésekkel mutassa be a tervét.
Humilitás
Ez egy nehéz kérdés. Még a legerősebb mérnököknek is sokszor van hová fejlődniük, ha alázatról van szó. Azt jelenti, hogy ne legyünk szerelmesek a saját megoldásainkba. Képesnek lenni meghallgatni és elfogadni mások megoldásait. Hogy a legjobbat feltételezd a társaidról, és amikor hibának tűnő dolgot látsz, próbáld megérteni a mögötte álló okokat. Megnyitni a dolgokat a vitára. Hagyni, hogy az emberek saját megoldásokat javasoljanak. Ossza meg az ötleteit, és soha ne aggódjon amiatt, hogy elismerést kapjon értük. Sokkal fontosabb, hogy mindenki jól érezze magát egy ötlettel, és úgy érezze, hogy csapatmunka volt, mint az, hogy mindenki tudja, hogy az Ön ötlete volt. Legyen őszinte. Adjon hitelt az embereknek. Soha ne féljen kimondani, hogy tévedett, vagy elismerni, hogy másnak van igaza. Az emberek tisztelik azokat, akik képesek megváltoztatni a véleményüket.
Újrafelhasználás
Talán triviálisan hangzik, de a legtöbb ember nem érti, hogy a fejlődés legjobb módja az, ha a korábbi munkára építünk. A kevésbé tapasztalt mérnököknek mindig az a rossz szokásuk, hogy azt gondolják, hogy a legjobb módja a gyors haladásnak, ha figyelmen kívül hagynak mindent, ami már létezik, és újrakezdik. A jó mérnökök mindig alaposan utánanéznek, megismerik, megkérdezik és megértik a már létező megoldásokat. Még ha a meglévő megoldás hiányos is, megpróbálják megnézni, hogyan lehetne javítani rajta, mielőtt úgy döntenének, hogy lecserélik. Soha nem utasítanak el egy meglévő megoldást anélkül, hogy alaposan utánanéznének, és nem beszélnének a meglévő megoldás tulajdonosával.
Infrastruktúra gondolkodásmód
A fent leírtak szerint a korábbi munka újrafelhasználása nagy hatással lehet az emberekre. Ez azt jelenti, hogy a mérnököknek mindig figyelniük kell, hogy van-e lehetőségük valami újrafelhasználhatót létrehozni. A legegyszerűbb dolog, ha van egy ilyen lehetőség, hogy figyelmen kívül hagyjuk. Az újrafelhasználható dolgok elkészítése mindig többe kerül a “készítőnek”, mint a nem újrafelhasználható dolgok elkészítése, ezért sok rövidlátó ember figyelmen kívül hagyja azokat az előnyöket, amelyeket ők és más csapatok is élvezhetnek majd a későbbiekben. Egy jó fejlesztő felismeri az újrafelhasználható dolgok létrehozásának lehetőségeit, tudja, hogyan lehet azokat a legjobb módon újrafelhasználhatóvá tenni, és ebbe fektet energiát.
Master your domain
A jó megoldások kidolgozásának egyetlen módja, ha alaposan megértjük a terméket, amin dolgozunk. A jó mérnökök nemcsak az általuk fejlesztett termék mély megértésével rendelkeznek. Értik az összes felhasználási esetet is, megértik a termék motivációját, és könnyen tudnak értelmes beszélgetést folytatni a termékmenedzserrel, megkérdőjelezik a döntéseket és alternatívákat kínálnak. Tudják, hogy melyek a fontos funkciók és melyek a kevésbé fontos dolgok, és tudják, hogyan kell ennek megfelelően rangsorolni, és szükség esetén megoldásokat kínálni. Ez nemcsak a termék szempontjából fontos, amelyen dolgozik, hanem minden olyan termék számára is, amelyet integrál.
Kíváncsiság
A jó fejlesztőknek egészséges kíváncsisággal kell rendelkezniük, amely messze túlmutat a saját területük határain. Ez különösen igaz a mögöttes technológiák tényleges működésének megismerésére, de ugyanilyen fontos megérteni azokat a termékeket, amelyeken más csapatok dolgoznak, azok architektúráját és azt, hogy hogyan kapcsolódnak össze teljes rendszerként. Ennek a tágabb kontextusnak a birtokában felbecsülhetetlen értékű lehet az összetett problémák megoldása során, és az inspiráció forrása.
No boundaries
Gyakran látjuk, hogy a rossz megoldások és a rossz architektúra forrása abban gyökerezik, hogy az emberek félnek változtatni a dobozuk határain kívül eső dolgokon. A kliensfejlesztő hajlamos arra, hogy a dolgokat a kliensen oldja meg, még akkor is, ha jobb lenne a szerveren megoldani. Az alkalmazásfejlesztő hajlamos a problémát helyben megoldani, még akkor is, ha a megoldás a platformon vagy az infrastruktúrában van. Ennek oka egyszerű. Könnyebb nem vitát kezdeményezni egy másik csapattal, könnyebb az elérhetetlen világot fekete dobozként kezelni, könnyebb azzal az ördöggel foglalkozni, akit ismerünk. A jó mérnököknek azonban tudniuk kell, hogy ők egy nagy rendszer részei, és hogy a rendszer egyetlen része sincs igazán elérhetetlen számukra. Az architektúraváltás megbeszélése egy másik csapattal egészséges és hasznos, és hozzáadhat a perspektívához. Ha felajánlod, hogy hozzájárulsz az általad igényelt változtatáshoz, az nagyszerű a csapatok közötti bizalom kiépítéséhez. Egy új terület megérintése olyan tapasztalat, amelyből csak profitálhat. A legfontosabb, hogy amikor a határaid rugalmasabbá válnak, az azt jelenti, hogy a hatásod is növekszik. Amikor elkerüli, hogy a határain kívülre nyúljon, ismerje fel, hogy ezzel valójában visszatartja magát attól, hogy nagyobb hatást érjen el.
Felelősség / felelősségvállalás
Ha nem is tűnik fel azonnal, de nagyon gyakran, ha utánajár annak, hogy miért késett vagy bukott el valamelyik projekt, akkor azt találja, hogy a felelősségvállalás és a felelősségvállalás a kiváltó ok. Az emberek mindig hajlamosak lesznek a környezetüket hibáztatni: “Meg kellett várnom, hogy egy másik csapat befejezzen valamit”, “Rendszerproblémám volt, és senkinek sem volt ideje segíteni nekem”, “Túl későn kaptam meg a definíciókat”. Egy jó mérnök tudja, hogy ezek szinte mindig kifogások. Ha Ön a feladat tulajdonosa, és Önt terheli a felelősség a feladat megvalósításáért, akkor a gondolkodásmódjának úgy kell lennie, hogy minden probléma, amivel találkozik, olyasmi, amit meg kell oldania. Ha egy másik csapat blokkolja, menjen és beszéljen velük. Ajánlja fel, hogy párban dolgozzon a problémán, és ne “dobja” másra a felelősséget. Ha még nem kaptatok definíciókat, tegyetek feltevéseket arról, hogy mik lesznek a definíciók. Jobb, ha teszel némi előrelépést, és később kiigazításokat eszközölsz, mintha csak ülsz és vársz. Ha valami nagy dolog hátráltatja Önt, tudja, mikor kell felemelni a zászlót, és tudja, hogyan lehet a problémát megkerülni, hogy legalább más fronton haladhasson. Soha ne kerülj olyan helyzetbe, hogy valaki másnak kell megoldania a problémádat, ez pont fordítva van – te vagy felelős azért, hogy eljuss a célba, és neked kell kezelned az akadályokat az úton.
Kommunikáció
Ez egy igazi játékszabályozó, és gyakran a legkritikusabb dolog, amivel egy mérnöknek rendelkeznie kell ahhoz, hogy az egész csapatra nagy hatást tudjon gyakorolni. A kommunikáció képessége a legnagyobb dolog, ami lehetővé tette az emberiség számára, hogy azzá váljon, ami, nyilvánvalóan ugyanez a dolog ugyanolyan kritikus az élet bármelyik területén, beleértve a szoftverfejlesztést is. A jó mérnököknek képesnek kell lenniük arra, hogy ékesszólóan kifejtsék ötleteiket és véleményüket. Képesnek kell lenniük arra, hogy intelligensen és tisztelettudóan vitatkozzanak társaikkal. A kommunikáció nem csak a beszédről szól, még fontosabb, hogy tudjunk hallgatni. A csapatban nem mindenki tudja majd ugyanúgy kifejezni az elképzeléseit, ezért a jó mérnöknek türelmesnek kell lennie, és fel kell tennie a megfelelő kérdéseket, hogy megértse, mit gondolnak a többiek, és segítsen nekik, hogy meghallgassák őket. Mindez ugyanolyan fontos mind a szóbeli, mind az írásbeli kommunikáció esetében, és ami még fontosabb, nem csak a beszélgetés – a fejlesztők élete tele van a kommunikáció rengeteg formájával: dokumentumok, prezentációk, dokumentáció, kódkommentárok, commit-üzenetek. Még az olvasható kód írása és a változók nevének jó megválasztása is a kommunikáció egy formája.
Teammunka
Ez az egyik olyan hely, ahol még a tapasztalt mérnökök is nagyon gyakran elbuknak, és nem is tudják, hogy ez történik. Gondolj arra, hányszor mondtad azt, hogy “ez túl bonyolult, bízd csak rám”. Gondolj arra, hányszor mondtad, hogy “ez a feladat egyszemélyes munka, több ember hozzáadásával nem lesz könnyebb”. Gondolj azokra az esetekre, amikor nem volt időd segíteni valaki másnak, és soha nem követted nyomon, vagy javítottál/javítottál valakinek kódot anélkül, hogy megkérdezted volna a véleményét, vagy nagy változtatást hajtottál végre anélkül, hogy konzultáltál volna a csapatoddal. Rengeteg példa van. És az a helyzet, hogy még a tapasztalt mérnökök számára is ez tűnik jelenleg a helyes dolognak. De ez taktikai gondolkodás, ami csak rövid távon kifizetődő. Ha nagy dolgokat akarunk elérni, meg kell győződnünk arról, hogy csapatként tudunk együttműködni. Nem véletlen, hogy a csapatmunka közvetlenül a kommunikáció után következett. Ezek azok a dolgok, amelyek a leghatékonyabbá tesznek minket, ez az alapvető biológia. A nagy mérnökök nemcsak együttműködnek, konzultálnak, tanulnak, segítik, párosítják és tisztelik társaikat, hanem mentorálnak is, rámutatnak a problémákra, érdeklődést találnak és tanulnak mindenből, ami a csapatban történik, és proaktívan próbálnak segíteni még olyan dolgokban is, amelyek közvetlenül nem érintik őket. A csodálatos mérnökök tudják, mikor és hogyan kell olyan tervekkel előállni, amelyek megkönnyítik sok ember együttműködését olyan dolgokban, ahol sok munka várható.”
Keep it simple
A megoldás bonyolultsága lehet az egyik csendes gyilkosa a csapat továbblépési és alkalmazkodási képességének. Olyan ez, mint a magas vérnyomás. Az avatatlan szem számára úgy tűnik, hogy minden rendben van, és minden az elvárásoknak megfelelően működik, de valójában, mélyen belül, valami, ami közvetlenül nem érint semmilyen fő funkciót, lassan megöl téged. A jó mérnökök pragmatikus megoldásokat és olvasható kódot hoznak létre, még akkor is, ha több sornyi kódot írnak. Ne azzal mutasd meg, hogy mennyire “okos” vagy, hogy kihasználod a nyelv összes lehetőségét, redundáns absztrakciós szinteket hozol létre, vagy egy sorban olyan függvényt írsz, amit senki más nem érthet vagy hibakereshet. Ne legyen purista, ne dolgozza túl a megoldásokat ott, ahol nem feltétlenül szükséges, és soha ne féljen attól, hogy fogjon valamit, ami már eleve összetett, és megpróbálja egyszerűsíteni.
Priorizálás
Nem tudunk mindent megcsinálni. Nem tudunk minden problémát megoldani. Nem nyerhetünk meg minden vitát. Nem tehetünk mindent tökéletessé. Korlátozott időnk és korlátozott erőforrásaink vannak, és ezeket bölcsen kell felhasználnunk. Ez azt jelenti, hogy meg kell tudnunk különböztetni, hogy mihez kell ragaszkodnunk, mi az, amit elhalaszthatunk, és mi az, amit figyelmen kívül kell hagynunk. A fejlesztők naponta több tucatszor hozzák meg ezeket a döntéseket. Amikor mérlegeljük, hogy kivizsgáljunk-e egy hibát, amikor mérlegeljük, hogy elvégezzünk-e valamilyen refaktorálást, amikor mérlegeljük, hogy kezeljünk-e valamilyen használati esetet vagy éles esetet, amikor mérlegeljük, hogy tegyünk-e egy kitérőt a tervezett feladatunktól, és még akkor is, amikor időt szánunk arra, hogy meggyőzzünk valakit a véleményünkről. A jó mérnökök tudják, hogy fáradhatatlanul javítanak, vizsgálódnak, kutatnak vagy ragaszkodnak ahhoz, hogy érvényt szerezzenek a valóban fontos dolgoknak. Tudják, hogy jegyzetelni kell, és később visszatérni valamire, ha az fontos, de nem sürgős. És tudják, hogy békén kell hagyni valamit, vagy el kell fogadni valaki más véleményét, még akkor is, ha elégedetlenek vele, ha az valójában nem olyan fontos.
Időgazdálkodás
Amint fentebb említettük, létezésünk szomorú igazsága, hogy időhöz vagyunk kötve. Az általunk fejlesztett termékeknek előbb-utóbb élesben kell működniük, határidők, becslések és célok várnak ránk. A jó fejlesztőknek nemcsak intuíciót kell kifejleszteniük ahhoz, hogy megbecsüljék, mennyi időt vesznek igénybe a feladataik, hanem okosan kell cselekedniük abban is, hogyan bontják és rendszerezik a feladataikat még kisebb részekre. Bölcsen kell kezelniük a megszakításokat és a kontextusváltást. Az időbecslésnek ez az intuíciója elválaszthatatlan része annak, hogy a fentiekben leírtak szerint képesek legyenek rangsorolni. Ha például valami elég rövid, akkor érdemes lehet megcsinálni, még akkor is, ha nem szuper fontos. Ha pedig túl hosszú, akkor lehet, hogy jobb, ha egy kicsit elhalasztjuk, vagy konzultálunk a társainkkal vagy a menedzserünkkel.
Következtetés
Amint korábban említettük, úgy gondoljuk, hogy azok a mérnökök, akik a fentiek mindegyikében jártasak, a társaik befolyásolásával és inspirálásával 10x jobbá tehetik a csapatot. A nagy mérnököknek mindig emlékezniük kell arra, hogy ez a mindennapi munkájuk része: befolyásolni és inspirálni. Ez azt jelenti, hogy nemcsak arra kell időt találniuk, hogy a saját munkájukat végezzék, hanem arra is, hogy segítsenek másoknak a munkájuk elvégzésében. Ennek számos formája van: mentoráld a csapatodban dolgozókat, készíts forrásokat az emberek oktatásához, győződj meg róla, hogy minden jól dokumentált, mindig légy nyitott a magyarázkodásra és a párosításra az emberekkel, és még sok minden más. Jó mentornak és oktatónak lenni azt jelenti, hogy nem csak segítesz a csapattagjaidnak fejlődni, hanem elmélyíti a saját megértésedet is mindarról, amit csinálsz, és új perspektívát ad a dolgok tisztaságáról, a rendszer összetettségéről és azokról a helyekről, ahol a dolgok javulhatnak.
Ezek a 10x mérnökök jellemzői, nem csak az egyéni hatásukban, hanem a mindenki másra gyakorolt hatásukban is. Mindig kérdezd meg magadtól, mit tehetsz azért, hogy nagyobb legyen a hatásod, mindig van még hely a fejlődésre.