Ha designnal, illusztrációval, animációval vagy bármilyen kreatív szakmával foglalkozol, előbb-utóbb te is bele fogsz ütközni ugyanabba a falba: A naponta használt szoftverek és számítógépes programok nem csupán „eszközök”hanem inkább egy egész ökoszisztéma a saját szabályaival, furcsaságaival és sajátosságaival. Ezeknek az apró árnyalatoknak a megértése jelentheti a különbséget aközött, hogy küzdesz a számítógépeddel, vagy úgy érzed, mintha varázslatot művelne rajtad.
A billentyűparancsokon és néhány véletlenszerű trükkön túl, Egy egész univerzumnyi részlet található az operációs rendszerekről, a programozásról, a hibakeresésről, a „tech” kultúráról és a munkamódszerekről. Ez befolyásolja, hogy a kreatív szakemberként használt alkalmazások hogyan vannak megtervezve és működnek. Ha belülről megérted ezt a világot, jobban tudsz együttműködni a fejlesztőcsapatokkal, realisztikus dolgokat kérni... és erősebb ötleteid lehetnek, mert tudod, mit lehet és mit nem.
Unix, Mac, Linux, és miért fontosabb a rendszer, mint amilyennek látszik
Sok kreatív ember számára a klasszikus vita az, hogy „Mac vagy Windows a tervezéshez?”A szoftverek világában azonban a párbeszéd gyakran egy lépéssel tovább megy: Unix kontra minden más. A macOS és a legtöbb Linux disztribúció örökli az Unix filozófiáját, így nagyon hatékony platformot biztosítanak a fejlesztéshez és a feladatok automatizálásához, amelyek aztán közvetlenül befolyásolják a használt eszközöket.
A programozók gyakran mondják, hogy „Az egész Unix rendszer olyan, mint egy nagy fejlesztői környezet”Mivel mindent úgy terveztek, hogy a terminálból láncba lehessen kötni a kis, hatékony segédprogramokat: a képek feldolgozását, az exportálás automatizálását, a renderelési szkriptek indítását, a szerverek kezelését vagy a kód fordítását grafikus varázslók használata nélkül. Ezért számos fejlett kreatív csomag, játékmotor és 3D eszköz ilyen környezetekre lett tervezve.
Ezzel szemben a dolgok vizuálisabbak és felhasználóbarátabbak Windows alatt, de Történelmileg kevésbé volt "barátságos" a mélyfejlesztéssel és a parancssori munkával.Manapság a különbség jelentősen csökkent (WSL, PowerShell stb.), de a Unix kultúra még mindig áthatja a használt szoftverek nagy részét anélkül, hogy észrevennénk.
Miért érdekel ez téged, mint kreatív szakembert? Mert Az órákat megtakarító automatizálások, szkriptek és bővítmények gyakran ebből a Unix világból származnak.Az olyan csapatokban való munka, amelyek elsajátították, gyakran robusztusabb, stabilabb munkafolyamatokat eredményez, amelyek könnyebben skálázhatók a projekt növekedésével.
A programozás egy ritka hibrid: logika, mérnöki tudás… és rengeteg kreativitás
Kívülről a programozás hideg számításnak tűnhet, de a valóságban... Ez a matematika, a mérnöki tudományok és a brutális kreativitás különös keveréke.Ahogyan egy illusztrációt vagy egy storyboardot készítesz, a fejlesztő logikai elemeket alkot, hogy a szoftver pontosan azt tegye, amit elképzeltél.
A legtöbb szakember egyetért abban, hogy A problémamegoldó készség és a kreativitás ugyanolyan fontos, ha nem fontosabb, mint egymillió nyelv ismerete.Ugyanazt a funkcionalitást általában sokféleképpen lehet megvalósítani, ahogy egy borítót vagy egy logót is ezerféleképpen lehet megtervezni; a kulcs a legtisztább, legelegánsabb és legkönnyebben karbantartható megoldás megtalálása.
Ezért egyre inkább értékelik, hogy a kreatív csapatok megértsék, hogy A kód is designVannak olyan szoftverarchitektúrával kapcsolatos döntések, adatfolyamok és belső struktúrák, amelyek nagyban befolyásolják, hogy mit kérhetsz egy alkalmazástól, bővítménytől vagy weboldaltól anélkül, hogy a projekt egy karbantarthatatlan Frankensteinné válna.
És igen, a programozás függőséget okoz: Sok fejlesztő a munkáját a legjobb logikai rejtvénynek tartja.Olyasmit, ahol te döntöd el a szabályokat és a darabkákat, és ez nagyon jól illik annak a gondolkodásmódjához, aki élvezi a dolgok nulláról való alkotását.
Fordítás, parancssor és egyéb kódolási „rituálék”
Ha valaha hallottál már valakit azt mondani, hogy „fordítás alatt áll”, majd eltűnni a székéből egy kávéval, tudd, hogy Nem mindig kifogás, de tökéletes.A fordítás a forráskód futtatható programba fordítását jelenti, és olyan nyelveken, mint a C++ vagy a nagy játékmotorokban ez több percet vagy akár órát is igénybe vehet.
Napról napra, Ez a fordítási idő a lélegzetvételre, a koncepciók áttekintésére, vagy egyszerűen az elméd újragondolására szolgál.Kreatív környezetekben, amikor renderelőmotorokkal vagy nehéz játéképítésekkel dolgozunk, valami hasonló történik: vannak leállások, amíg a gép befejezi a munkát, és sok csapat kihasználja ezeket az időket ötletek megvitatására, tervek finomítására vagy feladatok áttekintésére.
Ehhez kapcsolódik a parancssor, az a fekete képernyő, ami elsőre ijesztő, de ha egyszer elsajátítod, Egyfajta varázspálcává válikAmit ott valójában csinálsz, az miniatűr programozás: utasításokat írsz egy szkriptnyelven (például Bash-ben), hogy automatizálj olyan műveleteket, amelyek egy grafikus felületen macerásak lennének.
Egy haladó kreatív szakember számára felbecsülhetetlen értékű lehet négy dolog elsajátítása a terminálokról: Nevezzen át több ezer fájlt, konvertáljon kötegelt formátumokat, indítson renderelési szkripteket, helyezze át a biztonsági mentéseket, vagy szinkronizálja a projekteket anélkül, hogy az egeret érintenénk. Ez egy másik módja annak, hogy „beszéljük a számítógép nyelvét”, és közelebb kerüljünk a programozók gondolkodásmódjához.
A kód sötét oldala: pontosvesszők, hibák és végtelen hibakeresés
A szoftverek egyik legkegyetlenebb kuriózuma, hogy Apró dolgok is összetörhetnek óriási dolgokatEgy rosszul elhelyezett pontosvessző, egy hiányzó zárójel vagy egy rossz helyen záródó szögletes zárójel több száz tökéletesen átgondolt sort tehet tönkre, ahogy egy helytelenül rögzített réteg is tönkretehet egy egész PSD-t.
A fejlesztők napjaik nagy részét egy igencsak jellegtelen, de annál lényegesebb módon töltik: hibakeresési hibákA hibavadászat olyan, mint az abszurd helyeken megbújó lények utáni hajsza: nem mindig okoznak programösszeomlást, néha csak bizonyos időpontokban idéznek elő furcsa hibákat, vagy bizonyos adatokkal vagy bizonyos eszközökön jelennek meg.
A te világodban ez olyan dolgokat jelent, mint például Eszközök, amelyek csak egyféle fájllal hibásodnak meg, animációk, amelyek jól néznek ki a számítógépen, de éles környezetben összeomlanak, weboldalak, amelyek csak egy adott böngészőben akadoznak le...amelyek meglepő módon általában egy sokkal mélyebb kódhiba látható részei.
Ennek túlélése érdekében a legtöbb programozó a hibakeresési technikák arzenálját fejleszti ki: Használjon naplókat, grafikus hibakeresőket, töréspontokat és változóállapot-kiírásokat....és még belső jutalmat is kínálnak bizonyos különösen nehezen megfogható hibák megtalálásáért. Ez egy másik oka annak, hogy a „gyors” változtatások szinte soha nem olyan gyorsak.
És igen: van humor. A kódban található számos megjegyzés a szarkazmus kis műalkotásává válik: „// Varázslat. Ne nyúlj hozzá.”, „// részeg vagyok, később javítom” vagy „// feltöröm az ie böngészőt (feltételezve, hogy az ie egy böngésző)”Ez a frontális humor a fejlesztői kultúra fontos része.
Lustaság, automatizálás és verziókövetés: álruhás erények
Furcsán hangozhat, de fejlesztés alatt áll A lustaság, ha megfelelően értik, szakmai erénynek számít.Az ötlet egyszerű: ha valami ismétlődő és manuális, egy okos ember keresni fogja a módját, hogy automatizálja, így soha többé nem kell majd megcsinálnia. Ez a „lustaság” az, ami szkripteket, bővítményeket, automatizált műveleteket és makrókat hajt, amelyeket aztán naponta használsz anélkül, hogy tudnád, honnan származnak.
Komoly projektekben ez a filozófia egy másik kulcsfontosságú elemre támaszkodik: verziókövetés, a Git az abszolút királyA Gitnek köszönhetően a csapatok ugyanazon a projekten dolgozhatnak anélkül, hogy egymás lábára lépnének, őrült ötleteket tesztelhetnek külön ágakban, visszavonhatják a folyamatot, ha valami elromlik az alkalmazás felénél, vagy láthatják, hogy ki mikor és mihez nyúlt.
Egy kreatív szakember számára, aki fejlesztőkkel működik együtt, elengedhetetlen az alapok ismerete. Mi az a commit, branch vagy merge? Sokat segít: lehetővé teszi a fejlesztési folyamat nyomon követését, annak megfigyelését, hogy mikor vezettek be egy, a dizájnt érintő változást, és jobban koordinálható, hogy mikor érdemes új funkciókat bevezetni, és a meglévők finomítására koncentrálni.
Továbbá, ez az automatizálási kultúra a látszólag kevésbé „technikai” feladatokra is vonatkozik: Telepítési szkriptek, automatikus dokumentációgenerálás, minden este automatikusan futó tesztek, eszközök konvertálására szolgáló folyamatok, képek tömörítése vagy verziók generálása különböző eszközökhöz emberi beavatkozás nélkül. Mindez valakinek köszönhető, aki nem volt hajlandó ugyanazt a folyamatot százszor kézzel megismételni.
Hozzászólások, egyértelmű nevek és az olvasható kód megszállottsága
Csakúgy, mint egy jól elnevezett rétegekkel és szervezett csoportokkal rendelkező tervfájl, végtelenül nagyra értékeljük, A kódnak rendre, kontextusra és jó címkékre van szüksége.Különben járhatatlan dzsungellé válik, még annak is, aki néhány héttel korábban írta.
A jó programozók két dologra nagy hangsúlyt fektetnek: értelmes nevek és megjegyzések, amelyek valós kontextust biztosítanakVáltozó meghívása userAge o totalCost Sokkal többet mond, mint x o tempÉs megjegyezni, hogy miért választottak egy adott algoritmust, vagy milyen trükköt használnak, végtelenül hasznosabb, mint kommentelni: "// adjunk össze két számot".
A gyakorlatban ez egyfajta belső „műszaki szkriptet” hoz létre a projekthez, amelyet más fejlesztők elolvashatnak a megértés érdekében. az egyes modulok mögött álló szoftvertervezési döntésekAmikor a kód jól meg van írva, a legjobb komment néha maga a kód, ami a jól megválasztott neveknek köszönhetően magyarázza önmagát.
A tisztánlátás megszállottsága nagyon jól illik azokhoz a fogalmakhoz, amelyekről talán már hallottál, például Tiszta kód, refaktorálás, vagy a „ne ismételd magad” (DRY) szabályMindez a filozófia ugyanarra a dologra mutat: a szoftvernek könnyen érthetőnek, módosíthatónak, tesztelhetőnek és bővíthetőnek kell lennie anélkül, hogy mindent elrontana.
Tesztelés, TDD, és miért nem elég, ha „ma működőképessé tesszük”
Egy másik kevésbé látható, de alapvető szempontja bármely programnak, amit használsz, az a mögötte álló tesztelési ökoszisztémaAz egységtesztek, integrációs tesztek, automatizált vagy manuális tesztek pontosan azért léteznek, hogy megakadályozzák, hogy egy apró módosítás, amely egy általad kért opciót ad hozzá, észrevétlenül összetörje a rendszer 20 másik részét.
Vannak olyan módszertanok, mint a TDD (Test Driven Development), ahol Először a teszteket írják meg, majd a kódot, ami átmegy rajtuk.Ez ellentmondásosnak tűnik, de arra kényszeríti a fejlesztőt, hogy a kezdetektől fogva gondolkodjon a kívánt viselkedésről, a szélső esetekről, és arról, hogyan ellenőrizhető, hogy minden továbbra is megfelelően működik-e az idő múlásával.
Kreatív csapatok számára ez valami nagyon kézzelfoghatót jelent: Az „egy apró gombmódosítás” vagy az „új effektus hozzáadása” kérése valódi költségekkel jár a tesztelés és az érvényesítés szempontjából.Nem arról van szó, hogy nem akarnak segíteni, hanem arról, hogy bármilyen módosításnak, bármilyen aprónak is tűnik a kezelőfelületen, lehetnek mellékhatásai, és gondoskodniuk kell arról, hogy az alkalmazás többi része ne romoljon el.
Ezenkívül sok vállalat olyan tesztcsomagokat állít fel, amelyek akkor is futnak, amikor a csapat alszik, vagy hétvégén: A kódot lefordítják, egy sor tesztet futtatnak le, és az eredményeket felülvizsgálják.Ha valami rosszul sül el, azt jóval azelőtt észlelik, hogy elérné a végfelhasználókat… és ez vonatkozik azokra a kreatív szakemberekre is, akik a gyártás során ezekre az eszközökre támaszkodnak.
Algoritmusok, adatszerkezetek és sebesség: az eszközeid láthatatlan motorja
Minden fájlkeresés, minden másodperc alatt alkalmazott szűrő vagy minden vászon mögött, amely több ezer réteggel is folyékony marad, van valami, amit nem látsz: rosszindulatúan kiválasztott algoritmusok és adatstruktúrákEgy lista, egy verem, egy sor vagy egy szótár (hashmap) használata óriási teljesítménybeli különbséget jelent.
Pl. Ha gyorsan kell megtalálni a keresett elemeket, egy szótár sokkal hatékonyabb, mint egy egyszerű lista.Ez lehetővé teszi a szerkesztő számára, hogy milliszekundumok alatt megtaláljon egy stílust, szimbólumot vagy elemet, még egy hatalmas projektben is. Ugyanez vonatkozik a pixelek, vektorok, 3D hálók vagy hangsávok tárolására is.
Ha egy kreatív alkalmazás lassú, az nem mindig a számítógép hibája: A szűk keresztmetszet néha az évekkel ezelőtt meghozott szoftvertervezési döntésekben rejlik.vagy gyors, „ideiglenesen” meghozott, majd örökre megmaradt megoldásokban, ami sajnos sok projektben gyakori.
Ezért ragaszkodik annyi szakmai tanácsadó rovat ahhoz, hogy Kerüld a korai optimalizálást, de a megfelelő algoritmusokat és struktúrákat válaszd ki már a legelején.Ez a szilárd alap lehetővé teszi a skálázhatóságot: több réteg, több effekt, több felhasználó, több eszköz… a rendszer összeomlása nélkül.
Programozói kultúra: furcsa viccek, bináris kód és a „nincs kanál”
Ha fejlesztők között dolgozol, előbb-utóbb olyan dolgokat fogsz hallani, mint például „Tízféle ember van: aki érti a bináris számrendszert, és aki nem.”Ez egy klasszikus vicc, ami arra a tényre játszik, hogy a bináris számrendszerben a 10 az tizedesjegyben a 2. Ez a fajta technikai humor egy egész szubkultúra része: mémek, subredditek, utalások a Mátrixra, a Star Warsra, a Starship Troopersre…
A híres mondat „Nincs kanál” A Mátrix analógiát gyakran használják annak az érzésnek a leírására, amikor átlátjuk a felhasználói felületet, és megértjük, hogyan épül fel alatta egy alkalmazás. Amikor tudjuk, hogyan kell programozni, egy program vagy weboldal megtekintése már nem csupán elfogyasztása: elkezdjük elképzelni a moduljait, az architektúráját, az alkatrészek kommunikációját, és azt, hogy hol lehet valami hiba.
A hibákat is úgy tárgyalják, mintha azok lennének Csillagközi rohamosztagosok lényei: kicsik megjelenésűek, de hatalmas rendetlenséget képesek okozniEz a közös nyelv közösséget teremt; a humor egy módja annak, hogy megbirkózzunk azzal a nyomással, hogy hatalmas rendszerek ragaszkodnak a kódunkhoz.
Egy kreatív szakember számára az adott kultúrával való kapcsolat gördülékenyebbé teszi a programozókkal való kapcsolatot: hogy megértsem a poénjait, az utalásait és a furcsaságait Nagyban megkönnyíti a kommunikációt a határidők, technikai korlátok vagy az utolsó pillanatban végrehajtott változtatások megvitatásakor.
Hogyan tanulnak (valójában) a programozók, és mit jelent ez számodra?
Egy másik érdekes tény, hogy bár vannak diplomák, kiképzőtáborok és mesterképzések, A programozásban a valódi tanulás nagy része munka közben történik.Inkább szakmára, mint egyetemi tantárgyra hasonlít: úgy tanulsz, hogy csinálod, elrontasz dolgokat, megjavítod őket, és újra meg újra ismételgeted a ciklust.
A legtöbb fejlesztő egy dologban egyetért: Nem kell mindent megjegyeznedVannak hivatalos dokumentációk, fórumok, cikkek, könyvek, mint például a „97 dolog, amit minden programozónak tudnia kell”, és rengeteg online forrás, például Oktatóanyagok spanyol nyelvű programozási nyelvekrőlA lényeg az, hogy tudjuk, hogyan keressünk, válasszunk ki és alkalmazzuk ezt a tudást egy adott problémára, ahogyan azt sem tudjuk fejből az összes Photoshop gyorsbillentyűt, de tudjuk, hol keressük, amikor szükségünk van rájuk.
Továbbá szinte mindenki a specializálódást javasolja: Válassz egy területet (web, mobil, backend, adat, videojátékok…) és merülj el mélyebben Ahelyett, hogy megpróbálnád lefedni a teljes technológiai tájképet. Ugyanez a logika inspirálhat téged is: ha valóban megérted, hogyan működnek a szoftverek a kreatív területeden, sokkal erősebbé válsz, mintha mindent tudnál egy kicsit anélkül, hogy bármit is elsajátítanál.
Valami, ami számos belső felmérésben is ismétlődik, a mentor és a „páros programozás” fontossága: Párokban programozzatok, hagyjátok, hogy mások is átnézzék a kódotokat, kérjetek segítséget, és fogadjátok el a kritikát.Pontosan ugyanaz, mint amikor megosztasz egy storyboardot vagy hangulattáblát valakivel, és visszajelzéseket fogadsz el a darab fejlesztése érdekében.
A fejlesztői munka valósága: magány, koncentráció és óriási fejhallgatók
Belülről egy szoftverfejlesztő csapat mindennapi élete számos dologban hasonlít egy kreatív stúdióéhoz: Sok óra a képernyő előtt, hosszú koncentrációs időszakok és egy szeretet-gyűlölet kapcsolat megszakításokkalNem ritka, hogy a csapat fele hatalmas zajszűrő fejhallgatót visel, mintha kötelező munkasisakot viselnének.
A zene a hatékonyság növelésére szolgáló eszközzé válik: Lágy listák az architekturális gondolkodáshoz, valami erősebb a mechanikai feladatokhoz, teljes csend a bonyolult hibák hibakereséséhezA fejhallgató nem csupán szeszély: társadalmi jelzésként szolgál: „most ne szakíts félbe, fókuszált üzemmódban vagyok”, ahogyan egyes stúdiók zászlókat vagy apró fizikai jeleket is használnak az asztalon.
Van egy másik, kevésbé látható oldala is: A számítógép előtt töltött sok idő elszigetelő lehetSok veterán ragaszkodik ahhoz, hogy nem szabad hagyni, hogy robotként bánjanak velünk, és hogy létfontosságú a kódoláson kívül is élni: hobbik, kapcsolatok, testmozgás, pihenés. Az agy, amely megoldásokat tervez, és az agy, amelyik interfészeket tervez, ugyanaz, és térre van szüksége.
Ezzel párhuzamosan van valami nagyon is valóságos, ún. programozási függőségAmikor valamibe igazán belemerülsz, könnyű egész éjszakákat tölteni „csak azért, hogy befejezd ezt a modult”, és közben elfelejteni enni, aludni, vagy akár felkelni a székről. Mint minden kreatív szenvedély esetében, itt is meg kell tanulnod határokat szabni, hogy elkerüld a kiégést.
Gondolkodásmód, szélhámos szindróma és egészséges verseny
A programozással foglalkozók többsége műszaki háttérrel rendelkezik, de Ez nem jelenti azt, hogy egy „bölcsészettudományi” háttérrel rendelkező személyt nem lehet átképezni.A veteránok nem a középiskolai végzettséget értékelik a legjobban, hanem a következetességet, a tanulási képességet és a logikus gondolkodással járó bizonyos fokú kényelmet.
Az iparágban szinte mindenki egy meglehetősen elterjedt dologgal él együtt: imposztor szindrómaAz „Én nem tudok eleget, lebukom, nem vagyok elég jó a feladathoz” érzése bármikor előfordulhat, függetlenül attól, hogy milyen magas beosztású vagy. Sokan motivációként használják a folyamatos tanuláshoz, amíg nem vezet bénító szorongáshoz.
A versenyképesség is része a környezetnek, de egészséges formájában inkább olyan, mint Kollégák közötti „rivalizálás” annak eldöntésére, hogy ki optimalizálja a legjobban a modult, vagy ki írja a legelegánsabb kódot Nem olyan, mint egy háború, hogy ki kire tapos. Az, hogy egy programozó, akit csodálsz, értékeli a munkádat, nagyon hasonlít ahhoz, mintha egy másik kreatív ember csodálná az illusztrációdat vagy videódat.
Ebben a környezetben kulcsfontosságú megtanulni elfogadni a visszajelzéseket: Amikor dicsérnek, ne térj el az utadattól; amikor kritizálnak, ne add fel.Az ágazat olyan gyorsan változik, hogy mindig lesznek olyan technológiák, amelyeket nem irányítasz, és olyan emberek, akik többet tudnak egy adott dologról, és az ezzel való együttélés a játék része.
A legidőigényesebb rész: a hibakeresés, a frusztráció kezelése és a váltás időpontjának eldöntése
Ha csak a végeredményt nézzük, azt gondolhatnánk, hogy a fejlesztők egész nap új funkciók írásával foglalkoznak, de a valóságban... Az idő nagy részét hibák kijavításával és a már meglévő dolgok módosításával töltjük.Egy projekttel való előrelépés gyakran azt jelenti, hogy kijavítjuk azokat a kisebb hibákat, amelyek megakadályozzák a rendszer többi részének fejlődését.
Ez jelentős frusztrációs csúcsokat okoz: Észrevétlen problémák, magyarázat nélkül meghiúsuló építmények, elérhetetlen határidőket követelő ügyfelekSok szakember mondja, hogy voltak olyan pillanatok, amikor legszívesebben mindent abbahagytak volna és szektort váltottak volna, különösen, ha összetett termékeken dolgoztak.
Az általuk javasolt stratégiák ismerősen hangzanak: Kitartás, önmotiváció, egyfajta büszkeség a jól elvégzett munka iránt, és őszinte szenvedély a szakma irántMint minden igényes kreatív szakmában, ez a keverék az, ami arra késztet, hogy újra próbálkozz, amikor valami nem sikerül, és ami megkülönbözteti azokat, akik a felszínen maradnak, azoktól, akik igazán jók lesznek.
Bizonyos mértékű munkahelyi fluktuáció is gyakori: A jó jelöltek folyamatosan kapnak ajánlatokat.Sok tanács ugyanarra utal: keress olyan vállalati kultúrát, amely összhangban van az értékeiddel, és ne feledd, hogy egy interjún a céget is értékeled. Sok órát fogsz eltölteni a problémáinak átgondolásával; a jó interperszonális illeszkedés és a közös értékek fontosabbak, mint amilyennek az önéletrajzodban látszhat.
Technikai interjúk, csapatintegráció és kommunikáció
A fejlesztői közösségen belül a technikai interjúk meglehetősen híresek… és meglehetősen rossz hírnévnek örvendenek. Sok veterán úgy véli, hogy Túl vannak értékelve, és ha valamelyikben kudarcot vallasz, az nem sokat mond a benned rejlő lehetőségekről.Általában egy adott készségkészletet mérnek nyomás alatt, nem pedig a tényleges tanulási, együttműködési és hosszú távú projektek sikeres befejezési képességedet.
Ehelyett, A soft skillek gyakran mindent megváltoztatnak: a kommunikáció tudása, kérdések feltevése, ha valami nem érthető, a visszajelzések integrálása, együttműködés különböző hátterű emberekkel (mint te, ha kreatív vagy), és a nyugalom megőrzése feszült pillanatokban.
Amikor egy céghez csatlakozol, a legfontosabb ajánlás minden junior programozó számára a következő: Ne félj kérdéseket feltenni, de tedd azt átgondoltan.Ütemezzetek be konkrét időpontokat egy mentorral a kérdések megválaszolására, kerüljétek a félbeszakítást, kivéve, ha sürgős, és alaposan készüljetek fel a kérdéseitekkel. Ugyanez vonatkozik arra is, ha egy technikai csapathoz csatlakoztok: minél világosabb és strukturáltabb a kommunikációtok, annál jobban beilleszkedtek.
Olyan környezetben, ahol nincs mentor kijelölve, a legcélszerűbb eljárás a következő: hogy elnyerje egy tapasztalt személy bizalmát és szilárd szakmai kapcsolatot alakítson ki azzal a személlyel. Végső soron a nagy projektek ugyanúgy függenek a kód és a design minőségétől, mint a készítőik közötti kapcsolatok minőségétől.
Végső soron a mindennapi eszközeid varázsa egy meglehetősen emberi keverékből fakad: Olyan emberek, akik folyamatosan tanulnak, frusztráltak, versengenek, együttműködnek, nevetnek furcsa bináris vicceken, és fokozatosan szoftverré alakítják az ötleteiket.Amikor kreatív emberként megérted ezeket a kuriózumokat és munkamódszereket, sokkal könnyebb ugyanazt a nyelvet beszélni, megkérdezni, hogy mi építhető meg valójában, és részt venni abban a szinte „varázslatos” folyamatban, amelynek során egy számítógép pontosan azt teszi, amit elképzelsz.