Nëse punoni në dizajn, ilustrim, animacion ose në ndonjë disiplinë krijuese, herët a vonë do të hasni në të njëjtën pengesë: Softuerët dhe programet kompjuterike që përdorni çdo ditë nuk janë vetëm "mjete"por më tepër një ekosistem i tërë me rregullat, veçoritë dhe veçoritë e veta. Të kuptuarit e këtyre nuancave të vogla mund të bëjë diferencën midis vështirësisë me kompjuterin tuaj dhe ndjesisë sikur ai po bën magji tek ju.
Përtej shkurtesave të tastierës dhe disa trukeve të rastësishme, Ekziston një univers i tërë detajesh rreth sistemeve operative, programimit, debugging-ut, kulturës "teknologjike" dhe mënyrave të punës. Kjo ndikon në mënyrën se si janë projektuar dhe funksionojnë aplikacionet që përdorni si krijues. Të kuptuarit e kësaj bote nga brenda ju ndihmon të punoni më mirë me ekipet e zhvillimit, të kërkoni gjëra realiste… dhe të keni ide më të fuqishme sepse e dini se çfarë mund dhe çfarë nuk mund të ndërtohet.
Unix, Mac, Linux dhe pse sistemi ka më shumë rëndësi nga sa duket
Për shumë krijues, debati klasik është "Mac apo Windows për dizajn?"Por brenda botës së softuerëve, biseda shpesh shkon një hap më tej: Unix kundrejt çdo gjëje tjetër. macOS dhe shumica e shpërndarjeve të Linux trashëgojnë filozofinë Unix, duke i bërë ato platforma shumë të fuqishme për zhvillimin dhe automatizimin e detyrave që më pas ndikojnë drejtpërdrejt në mjetet që përdorni.
Programuesit shpesh thonë se "I gjithë sistemi Unix është si një mjedis i madh zhvillimi"Sepse gjithçka është projektuar për të lidhur së bashku shërbime të vogla dhe të fuqishme nga terminali: përpunimi i imazheve, automatizimi i eksporteve, nisja e skripteve të renderimit, menaxhimi i serverëve ose përpilimi i kodit pa u mbështetur në magjistarë grafikë. Kjo është arsyeja pse shumë suita krijuese të përparuara, motorë lojërash dhe mjete 3D janë projektuar duke pasur parasysh këto lloj mjedisesh.
Në të kundërt, gjërat janë më vizuale dhe miqësore për përdoruesit në Windows, por Historikisht, ka qenë më pak "miqësor" ndaj zhvillimit të thellë dhe punës në linjën e komandës.Sot, hendeku është ngushtuar ndjeshëm (WSL, PowerShell, etj.), por kultura Unix ende përshkon pjesën më të madhe të softuerit që përdorni pa e kuptuar fare.
Pse je i interesuar për këtë si krijues? Sepse Automatizimet, skriptet dhe shtojcat që ju kursejnë orë të tëra shpesh burojnë nga kjo botë Unix.Puna në ekipe që e kanë zotëruar atë shpesh rezulton në rrjedha pune më të forta dhe të qëndrueshme që janë më të lehta për t'u shkallëzuar ndërsa projekti rritet.
Programimi është një hibrid i rrallë: logjikë, inxhinieri… dhe shumë kreativitet.
Nga jashtë, programimi mund të duket si një llogaritje e pastër e ftohtë, por në realitet Është një përzierje e çuditshme e matematikës, inxhinierisë dhe krijimtarisë brutale.Ashtu siç krijoni një ilustrim ose një storyboard, një zhvillues krijon pjesë logjike në mënyrë që softueri të bëjë pikërisht atë që është imagjinuar.
Shumica e profesionistëve pajtohen që Aftësitë për zgjidhjen e problemeve dhe kreativiteti janë po aq të rëndësishme, nëse jo më shumë, sesa njohja e një milion gjuhëve.Për të njëjtin funksionalitet, zakonisht ka shumë mënyra për ta zbatuar atë, ashtu siç ka një mijë mënyra për të dizajnuar një kopertinë ose një logo; çelësi është të gjesh zgjidhjen më të pastër, më elegante dhe më të lehtë për t’u mirëmbajtur.
Kjo është arsyeja pse vlerësohet gjithnjë e më shumë që ekipet krijuese ta kuptojnë këtë Kodi është gjithashtu dizajnEkzistojnë vendime për arkitekturën e softuerit, rrjedhat e të dhënave dhe strukturat e brendshme që ndikojnë shumë në atë që mund të kërkoni nga një aplikacion, plugin ose faqe interneti pa e shndërruar projektin në një Frankenstein të papërshtatshëm për mirëmbajtje.
Dhe po, programimi është problematik: Shumë zhvillues e përshkruajnë punën e tyre si enigmën logjike më të mirë që ekziston.Një ku ti vendos rregullat dhe pjesët përbërëse, dhe kjo përshtatet shumë mirë me mentalitetin e dikujt që kënaqet duke krijuar gjëra nga e para.
Kompilimi, rreshti i komandës dhe "ritualet" e tjera të kodimit
Nëse keni dëgjuar ndonjëherë dikë të thotë "po kompilohet" dhe të zhduket nga karrigia me një kafe, dijeni këtë. Nuk është gjithmonë një justifikim, por është një justifikim i përsosur.Kompilimi do të thotë përkthimi i kodit burimor në një program të ekzekutueshëm, dhe në gjuhë si C++ ose në motorë të mëdhenj lojërash mund të duhen shumë minuta ose edhe orë.
Në ditë për ditë, Ajo kohë përpilimi është për të marrë frymë, për të rishikuar konceptet ose thjesht për të rivendosur mendjen tuaj.Në mjediset krijuese, kur punoni me motorë renderimi ose ndërtime të rënda lojërash, ndodh diçka e ngjashme: ka ndërprerje të punës që presin që makina të përfundojë dhe shumë ekipe i shfrytëzojnë ato për të diskutuar ide, për të përmirësuar dizajnet ose për të shqyrtuar detyrat.
Lidhur me këtë është rreshti i komandës, ai ekrani i zi që është i frikshëm në fillim, por, pasi ta zotëroni, Bëhet një lloj shkopi magjikAjo që po bën në të vërtetë atje është programim në miniaturë: shkruan udhëzime në një gjuhë skriptimi (si Bash) për të automatizuar veprime që do të ishin një bezdi në një ndërfaqe grafike.
Për një krijues të përparuar, të mësuarit e katër gjërave rreth terminalit mund të jetë e paçmuar: Riemërtoni mijëra skedarë, konvertoni formatet në grup, nisni skripte renderimi, zhvendosni kopje rezervë ose sinkronizoni projekte pa prekur mausin. Është një mënyrë tjetër për të "folur gjuhën" e kompjuterit dhe për t'u afruar me mënyrën se si mendojnë programuesit.
Ana e errët e kodit: pikëpresje, gabime dhe debugging i pafund
Një nga kuriozitetet më mizore të softuerëve është se Gjërat e vogla mund të thyejnë gjëra gjiganteNjë pikëpresje e vendosur gabim, një kllapë që mungon ose një kllapë që mbyllet në vendin e gabuar mund të prishë qindra rreshta të menduara në mënyrë të përsosur, ashtu si një shtresë e mbyllur gabimisht mund të shkatërrojë një PSD të tërë.
Zhvilluesit e kalojnë një pjesë të madhe të ditës së tyre në një mënyrë shumë të pahijshme, por thelbësore: gabimet e debuggingutGjuetia e defekteve është si gjuetia e krijesave që fshihen në vende absurde: ato nuk shkaktojnë gjithmonë bllokimin e një programi, ndonjëherë ato shkaktojnë gabime të çuditshme vetëm në kohë të caktuara, ose shfaqen me të dhëna të caktuara ose në pajisje të caktuara.
Në botën tuaj, kjo përkthehet në gjëra të tilla si Mjete që dështojnë vetëm me një lloj skedari, animacione që duken mirë në kompjuterin tuaj, por rrëzohen gjatë prodhimit, faqe interneti që prishen vetëm në një shfletues specifik....të cilat, çuditërisht, zakonisht janë pjesa e dukshme e një gabimi shumë më të thellë në kod.
Për t'i mbijetuar kësaj, shumica e programuesve zhvillojnë një arsenal teknikash debugging: Përdorni regjistra, debuggers grafikë, pikat e ndërprerjes dhe printimet e gjendjes së ndryshueshme....dhe madje ofrojnë shpërblime të brendshme për gjetjen e disa defekteve veçanërisht të pakapshme. Kjo është një arsye tjetër pse ndryshimet "e shpejta" pothuajse kurrë nuk janë kaq të shpejta.
Dhe po: ka humor. Shumë komente në kod shndërrohen në vepra të vogla arti sarkazme: “// Magji. Mos e prek.” , “// i dehur, rregulloje më vonë” ose “// hakim për shfletuesin ie (duke supozuar se ie është një shfletues)”Humori i guximshëm është një pjesë e rëndësishme e kulturës së zhvilluesve.
Dembelizmi, automatizimi dhe kontrolli i versioneve: virtyte të maskuara
Mund të tingëllojë e çuditshme, por është në zhvillim e sipër Dembelizmi, kur kuptohet siç duhet, konsiderohet një virtyt profesional.Ideja është e thjeshtë: nëse diçka është përsëritëse dhe manuale, dikush i zgjuar do të kërkojë një mënyrë për ta automatizuar atë në mënyrë që të mos i duhet ta bëjë më kurrë. Kjo "dembelizëm" është ajo që nxit skriptet, shtojcat, veprimet e automatizuara dhe makrot që ju më pas i përdorni çdo ditë pa e ditur se nga kanë ardhur.
Në projekte serioze, kjo filozofi mbështetet në një element tjetër kyç: kontroll versionesh, me Git si mbretin absolutFalë Git, ekipet mund të punojnë në të njëjtin projekt pa ndërhyrë te njëri-tjetri, të testojnë ide të çmendura në degë të ndara, të kthehen prapa kur diçka prish gjysmën e aplikacionit ose të shohin se kush çfarë preku dhe kur.
Për një profesionist krijues që bashkëpunon me zhvilluesit, të kuptuarit e bazave është thelbësore. Çfarë është një commit, një degëzim apo një bashkim? Ndihmon shumë: ju lejon të ndiqni progresin e zhvillimit, të monitoroni kur është prezantuar një ndryshim që ndikon në dizajnin tuaj dhe të koordinoni më mirë kur të përfshini veçori të reja dhe të përqendroheni në përmirësimin e asaj që është tashmë aty.
Për më tepër, kjo kulturë automatizimi vlen edhe për detyrat që në dukje janë më pak "teknike": Skripte vendosjeje, gjenerim automatik i dokumentacionit, teste që ekzekutohen automatikisht çdo natë, tubacione që konvertojnë asete, kompresojnë imazhe ose gjenerojnë versione për pajisje të ndryshme pa ndërhyrjen e njeriut. E gjithë kjo rrjedh nga dikush që refuzoi ta përsëriste të njëjtin proces me dorë njëqind herë.
Komente, emra të qartë dhe një obsesion me kodin e lexueshëm
Ashtu si një skedar dizajni me shtresa të emërtuara mirë dhe grupe të organizuara vlerësohet pafundësisht, Kodi ka nevojë për rend, kontekst dhe etiketa të mira.Përndryshe, bëhet një xhungël e pakalueshme, madje edhe për personin që e shkroi disa javë më parë.
Programuesit e mirë i kushtojnë shumë rëndësi dy gjërave: emra dhe komente kuptimplote që ofrojnë kontekst të vërtetëThirrja e një variabli userAge o totalCost Thotë shumë më tepër sesa x o tempDhe të vëresh pse është zgjedhur një algoritëm i caktuar ose çfarë truku po përdoret është pafundësisht më e dobishme sesa të komentosh "// mbledh dy numra".
Në praktikë, kjo krijon një lloj "skripti teknik" të brendshëm për projektin, të cilin zhvilluesit e tjerë mund ta lexojnë për ta kuptuar atë. vendimet e dizajnit të softuerit pas secilit modulKur kodi është i shkruar mirë, komenti më i mirë ndonjëherë është vetë kodi, i cili shpjegon veten falë atyre emrave të zgjedhur mirë.
Ajo obsesion me qartësinë përputhet shumë mirë me konceptet që mund të keni dëgjuar, si p.sh. Kod i pastër, rifaktorizim ose rregulli "mos e përsërit veten" (DRY)E gjithë kjo filozofi tregon të njëjtën gjë: që softueri duhet të jetë i lehtë për t’u kuptuar, ndryshuar, testuar dhe zgjeruar pa prishur gjithçka.
Testimi, TDD dhe pse "e vëmë në punë sot" nuk mjafton
Një aspekt tjetër më pak i dukshëm, por themelor i çdo programi që përdorni është ekosistemi i testimit që qëndron pasTestet e njësisë, testet e integrimit, testet e automatizuara ose manuale ekzistojnë pikërisht për të parandaluar që një ndryshim i vogël që shton një opsion që keni kërkuar të prishë në heshtje 20 pjesë të tjera të sistemit.
Ekzistojnë metodologji si TDD (Zhvillimi i Drejtuar nga Testi) ku Së pari shkruhen testet dhe pastaj kodi që i bën ato të kalojnë.Duket kundërintuitive, por e detyron zhvilluesin të mendojë që nga fillimi për sjelljen e dëshiruar, rastet anësore dhe si të verifikojë që gjithçka vazhdon të funksionojë siç duhet me kalimin e kohës.
Për ekipet krijuese, kjo përkthehet në diçka shumë konkrete: Kërkesa për "vetëm këtë ndryshim të vogël në buton" ose "shtimin e një efekti të ri" ka një kosto reale për sa i përket testimit dhe validimit.Nuk është se nuk duan t'ju ndihmojnë; është se çdo modifikim, sado i vogël që mund t'i duket ndërfaqes, mund të ketë efekte anësore dhe ata duhet të sigurohen që pjesa tjetër e aplikacionit të mos prishet.
Përveç kësaj, shumë kompani krijojnë suita testimi që funksionojnë ndërsa ekipi fle ose gjatë fundjavës: Kodi përpilohet, ekzekutohet një sërë testesh dhe rezultatet rishikohen.Nëse diçka shkon keq, ajo zbulohet shumë kohë përpara se të arrijë te përdoruesit fundorë… dhe kjo përfshin edhe krijuesit që mbështeten në këto mjete në prodhim.
Algoritmet, strukturat e të dhënave dhe shpejtësia: motori i padukshëm i mjeteve tuaja
Pas çdo kërkimi skedari, çdo filtri të aplikuar në një sekondë, ose çdo kanavacë që mbetet fluide edhe me mijëra shtresa, ka diçka që nuk e shihni: algoritme dhe struktura të të dhënave të zgjedhura me qëllim keqdashësPërdorimi i një liste, një pirgu, një radhëje ose një fjalori (hashmap) bën një ndryshim të madh në performancë.
P.sh. Nëse keni nevojë të gjeni artikuj shpejt, një fjalor është shumë më efikas sesa një listë bazë.Kjo i lejon redaktorit tuaj të gjejë një stil, simbol ose aset në milisekonda, madje edhe në një projekt të madh. E njëjta gjë vlen edhe për mënyrën se si ruhen pikselët, vektorët, rrjetat 3D ose gjurmët audio.
Kur një aplikacion krijues është i ngadaltë, nuk është gjithmonë faji i kompjuterit tuaj: Ndonjëherë pengesa qëndron në vendimet e dizajnit të softuerëve të marra vite më parë.ose në rrugë të shkurtra që u morën "përkohësisht" dhe më pas mbetën përgjithmonë, diçka që për fat të keq është e zakonshme në shumë projekte.
Kjo është arsyeja pse kaq shumë kolona me këshilla profesionale këmbëngulin në Shmangni optimizimin e parakohshëm, por zgjidhni algoritmet dhe strukturat e duhura që nga fillimi.Ky themel i fortë lejon shkallëzueshmëri: më shumë shtresa, më shumë efekte, më shumë përdorues, më shumë pajisje… pa u rrëzuar sistemi.
Kultura e programuesit: shaka të çuditshme, binare dhe "nuk ka lugë"
Nëse punoni me zhvilluesit, herët a vonë do të dëgjoni gjëra të tilla si "Ekzistojnë 10 lloje njerëzish: ata që e kuptojnë sistemin binar dhe ata që nuk e kuptojnë."Është një shaka klasike që luan me faktin se 10 në binar është 2 në decimal. Ky lloj humori teknik është pjesë e një nënkulture të tërë: meme, subreddits, referenca për Matrix, Star Wars, Starship Troopers…
Fraza e famshme "Nuk ka lugë" Analogjia e Matricës përdoret shpesh për të përshkruar atë ndjesi të të parit përmes ndërfaqes dhe të të kuptuarit se si është ndërtuar një aplikacion poshtë saj. Kur dini si të programoni, shikimi i një programi ose një faqeje interneti nuk është më thjesht konsumimi i tij: filloni të imagjinoni modulet e tij, arkitekturën e tij, mënyrën se si komunikojnë pjesët, ku diçka mund të jetë duke dështuar.
Gabimet diskutohen gjithashtu sikur të ishin Krijesa të Starship Troopers: të vogla në pamje, por të afta të shkaktojnë rrëmujë të madhe.Kjo gjuhë e përbashkët krijon komunitet; humori është një mënyrë për t'u përballur me presionin e të paturit sisteme të mëdha që varen pas kodit tuaj.
Për një profesionist krijues, lidhja me atë kulturë e bën marrëdhënien me programuesit më të qetë: për të kuptuar shakatë, referencat dhe çuditshmëritë e tij Kjo lehtëson shumë komunikimin kur diskutohen afatet, kufizimet teknike ose ndryshimet e minutës së fundit.
Si mësojnë (në të vërtetë) programuesit dhe çfarë do të thotë kjo për ju
Një fakt tjetër interesant është se, megjithëse ka diploma, kampe trajnimi dhe programe masteri, Pjesa më e madhe e të mësuarit të vërtetë në programim ndodh duke punuarËshtë më shumë si një zanat sesa një lëndë universitare: mëson duke bërë, duke prishur gjëra, duke i rregulluar ato dhe duke e përsëritur ciklin vazhdimisht.
Shumica e zhvilluesve bien dakord për një ide: Nuk keni nevojë të mësoni përmendësh gjithçkaEkziston dokumentacion zyrtar, forume, artikuj, libra si "97 Gjëra që Çdo Programues Duhet të Dijë" dhe shumë burime online, si p.sh. Tutoriale mbi gjuhët e programimit në spanjishtGjëja e rëndësishme është të dish si të kërkosh, përzgjedhësh dhe zbatosh atë njohuri për një problem specifik, ashtu siç nuk i di përmendësh të gjitha shkurtesat e Photoshop-it, por di ku të kërkosh kur ke nevojë për to.
Për më tepër, pothuajse të gjithë rekomandojnë specializimin: Zgjidh një zonë (ueb, celular, backend, të dhëna, videolojëra…) dhe hulumto më thellë Në vend që të përpiqeni të mbuloni të gjithë peizazhin teknologjik. E njëjta logjikë mund t'ju frymëzojë: të kuptuarit e vërtetë se si funksionon softueri në vendin tuaj krijues do t'ju bëjë shumë më të fuqishëm sesa të dini pak për gjithçka pa zotëruar asgjë.
Diçka që përsëritet edhe në shumë anketa të brendshme është rëndësia e mentorit dhe "programimit në çift": Programoni në çifte, lejoni që të tjerët të rishikojnë kodin tuaj, kërkoni ndihmë dhe pranoni kritika.Pikërisht njësoj si kur ndan një storyboard ose një tabelë humori me dikë tjetër dhe pranon reagime për ta përmirësuar pjesën.
Realiteti i punës me zhvilluesit: vetmia, përqendrimi dhe kufjet gjigante
Brenda, jeta e përditshme e një ekipi softuerësh ndan mjaft gjëra me një studio krijuese: Shumë orë para ekranit, periudha të gjata përqendrimi dhe një marrëdhënie dashurie-urrejtjeje me ndërprerjeNuk është e pazakontë të shohësh gjysmën e ekipit të veshur me kufje gjigante që anulojnë zhurmën, pothuajse sikur të ishin helmeta pune të detyrueshme.
Muzika bëhet një mjet produktiviteti: Lista të buta për të menduarit arkitektonik, diçka më e fuqishme për detyrat mekanike, heshtje totale për korrigjimin e gabimeve të ndërlikuaraKufjet nuk janë thjesht një tekë: ato janë një sinjal social i "mos më ndërprisni tani, jam në modalitetin e fokusit", ashtu si disa studio përdorin flamuj ose sinjale të vogla fizike në tavolinë.
Ekziston edhe një anë tjetër, më pak e dukshme: Të punosh kaq shumë kohë vetëm para kompjuterit mund të jetë izolueseShumë veteranë këmbëngulin se nuk duhet të lejosh veten të trajtohesh si robot dhe se është jetike të kultivosh një jetë jashtë kodimit: hobi, marrëdhënie, aktivitet fizik, pushim. Truri që harton zgjidhje dhe ai që harton ndërfaqe janë të njëjtë, dhe ka nevojë për hapësirë.
Paralelisht, ekziston diçka shumë reale e quajtur varësia nga programimiKur je vërtet i dhënë pas diçkaje, është e lehtë të kalosh netë të tëra "vetëm për të përfunduar këtë modul" dhe të harrosh të hash, të flesh ose edhe të ngrihesh nga karrigia. Ashtu si me çdo pasion krijues, duhet të mësosh të vendosësh kufij për të shmangur lodhjen.
Mënyra e të menduarit, sindroma e mashtruesit dhe konkurrenca e shëndetshme
Shumica e njerëzve që merren me programim vijnë nga fusha teknike, por Kjo nuk do të thotë që dikush me një sfond në "shkencat humane" nuk mund të rikualifikohet.Ajo që veteranët vlerësojnë më shumë nuk është lloji i diplomës së shkollës së mesme, por qëndrueshmëria, aftësia për të mësuar dhe njëfarë rehatie me të menduarit logjik.
Pothuajse të gjithë në industri jetojnë me diçka mjaft të përhapur: sindromi imposterNdjenja "Nuk di mjaftueshëm, do të më kapin, nuk jam në lartësinë e detyrës" mund të shfaqet pavarësisht se sa i vjetër jeni. Shumë veta e përdorin atë si motivim për të vazhduar të mësojnë, për sa kohë që nuk çon në ankth paralizues.
Konkurrenca është gjithashtu pjesë e peizazhit, por në formën e saj të shëndetshme është më shumë si "Rivaliteti" midis kolegëve për të parë se kush e optimizon më mirë një modul ose kush shkruan kodin më elegant Nuk është si një luftë për të parë se kush shkel mbi kë. Të kesh një programues që e admiron të vlerësojë punën tënde është shumë e ngjashme me të kesh një person tjetër krijues që admiron ilustrimin ose videon tënde.
Në këtë mjedis, të mësuarit për të pranuar reagimet është thelbësore: Kur të lavdërojnë, mos e humb rrugën; kur të kritikojnë, mos u dorëzo.Sektori ndryshon aq shpejt sa gjithmonë do të ketë teknologji që nuk i kontrolloni dhe njerëz që dinë më shumë rreth diçkaje specifike, dhe të jetosh me këtë është pjesë e lojës.
Pjesa që kërkon më shumë kohë: korrigjimi i gabimeve, menaxhimi i frustrimit dhe vendosja se kur të ndërrohet
Nëse shikoni vetëm rezultatet përfundimtare, mund të mendoni se zhvilluesit e kalojnë gjithë ditën duke shkruar veçori të reja, por në realitet Pjesa më e madhe e kohës shpenzohet duke debuguar gabimet dhe duke rregulluar gjërat që ekzistojnë tashmë.Të ecësh përpara me një projekt shpesh do të thotë të zhbllokosh gabime të vogla që pengojnë përparimin e pjesës tjetër të sistemit.
Kjo shkakton maja të konsiderueshme në zhgënjim: Probleme që sfidojnë zbulimin, ndërtime që dështojnë pa shpjegim të dukshëm, klientë që kërkojnë afate të pamunduraShumë profesionistë thonë se kanë pasur momente kur kanë dashur të lënë gjithçka dhe të ndryshojnë sektor, veçanërisht kur punojnë me produkte komplekse.
Strategjitë që ata rekomandojnë duken të njohura: Këmbëngulje, vetëmotivim, njëfarë krenarie për një punë të bërë mirë dhe një pasion i sinqertë për zanatinAshtu si në çdo disiplinë krijuese kërkuese, kjo përzierje është ajo që të bën të provosh përsëri kur diçka nuk funksionon dhe ajo që i ndan ata që qëndrojnë në sipërfaqe nga ata që bëhen vërtet të mirë.
Një shkallë e caktuar e ndërrimit të vendeve të punës është gjithashtu e zakonshme: Kandidatët e mirë marrin oferta vazhdimisht.Shumë këshilla këtu tregojnë të njëjtën gjë: kërkoni një kulturë të kompanisë që përputhet me vlerat tuaja dhe mos harroni se, në një intervistë, ju po vlerësoni edhe kompaninë. Do të kaloni shumë orë duke menduar për problemet e saj; të kesh një përshtatje të mirë ndërpersonale dhe vlera të përbashkëta ka më shumë rëndësi sesa mund të duket në CV-në tuaj.
Intervista teknike, integrim në ekip dhe komunikim
Brenda komunitetit të zhvilluesve, intervistat teknike janë mjaft të famshme… dhe gjithashtu kanë një reputacion mjaft të keq. Shumë veteranë besojnë se Ato janë të mbivlerësuara, dhe dështimi në njërën prej tyre nuk thotë shumë për potencialin tënd.Ato zakonisht matin një grup specifik aftësish nën presion, jo aftësinë tuaj aktuale për të mësuar, bashkëpunuar dhe përfunduar me sukses projekte në planin afatgjatë.
Në vend të kësaj, Aftësitë e buta shpesh bëjnë gjithë ndryshimin: të dish si të komunikosh, të bësh pyetje kur diçka nuk kuptohet, të integrosh reagimet, të bashkëpunosh me njerëz nga prejardhje të ndryshme (si ju, nëse jeni krijues) dhe të qëndrosh i qetë në momente tensioni.
Kur bashkoheni me një kompani, rekomandimi kryesor për çdo programues të ri është Mos kini frikë të bëni pyetje, por bëjeni këtë me kujdes.Caktoni orare specifike me një mentor për t'iu përgjigjur pyetjeve, shmangni ndërprerjen përveç nëse është urgjente dhe përgatitini pyetjet tuaja me kujdes. E njëjta gjë vlen edhe kur bashkoheni me një ekip teknik: sa më i qartë dhe i strukturuar të jetë komunikimi juaj, aq më mirë do të përshtateni.
Në mjediset ku nuk është caktuar një mentor, veprimi më i këshillueshëm është për të fituar besimin e dikujt me përvojë dhe për të krijuar një marrëdhënie të fortë profesionale me atë person. Në fund të fundit, projektet e mëdha varen po aq shumë nga cilësia e kodit dhe dizajnit sa edhe nga cilësia e marrëdhënieve midis atyre që i ndërtojnë ato.
Në fund të fundit, magjia e mjeteve që përdorni çdo ditë vjen nga një përzierje mjaft njerëzore: Njerëzit që mësojnë vazhdimisht, frustrohen, bëhen konkurrues, bashkëpunojnë, qeshin me shaka të çuditshme binare dhe gradualisht i shndërrojnë idetë në softuer.Kur ti, si një krijues, i kupton këto kuriozitete dhe mënyra pune, është shumë më e lehtë të flasësh të njëjtën gjuhë, të kërkosh atë që mund të ndërtohet në të vërtetë dhe të marrësh pjesë në atë proces pothuajse "magjik" të bërjes së një kompjuteri të bëjë pikërisht atë që imagjinon.