Hvis du arbejder med design, illustration, animation eller en anden kreativ disciplin, vil du før eller siden støde ind i den samme væg: Den software og de computerprogrammer, du bruger dagligt, er ikke bare "værktøjer"men snarere et helt økosystem med sine egne regler, særheder og særheder. At forstå disse små nuancer kan gøre forskellen på at have svært ved at håndtere din computer og føle, at den udfører magi på dig.
Ud over tastaturgenveje og et par tilfældige tricks, Der er et helt univers af detaljer om operativsystemer, programmering, fejlfinding, "teknologisk" kultur og arbejdsmetoder. Dette påvirker, hvordan de applikationer, du bruger som kreativ, er designet og fungerer. At forstå denne verden indefra hjælper dig med at arbejde bedre med udviklingsteams, bede om realistiske ting ... og få mere kraftfulde ideer, fordi du ved, hvad der kan og ikke kan bygges.
Unix, Mac, Linux og hvorfor systemet betyder mere end det ser ud til
For mange kreative er den klassiske debat "Mac eller Windows til design?"Men inden for softwareverdenen går samtalen ofte et skridt videre: Unix versus alt andet. macOS og de fleste Linux-distributioner arver Unix-filosofien, hvilket gør dem til meget kraftfulde platforme til at udvikle og automatisere opgaver, der derefter direkte påvirker de værktøjer, du bruger.
Programmører siger ofte, at "Hele Unix-systemet er som ét stort udviklingsmiljø"Fordi alt er designet til at sammenkæde små, kraftfulde værktøjer fra terminalen: behandling af billeder, automatisering af eksport, lancering af renderingsscripts, administration af servere eller kompilering af kode uden at være afhængig af grafiske guider. Derfor er mange avancerede kreative suiter, spilmotorer og 3D-værktøjer designet med den slags miljøer i tankerne.
I modsætning hertil er tingene mere visuelle og brugervenlige i Windows, men Historisk set har den været mindre "venlig" over for dybdegående udvikling og kommandolinjearbejde.I dag er kløften blevet betydeligt mindre (WSL, PowerShell osv.), men Unix-kulturen gennemsyrer stadig meget af den software, du bruger, uden at du overhovedet er klar over det.
Hvorfor er du interesseret i dette som kreativ? Fordi Automatiseringer, scripts og plugins, der sparer dig timer, stammer ofte fra denne Unix-verden.At arbejde i teams, der har styr på det, resulterer ofte i mere robuste og stabile arbejdsgange, der er lettere at skalere, efterhånden som projektet vokser.
Programmering er en sjælden hybrid: logik, ingeniørvidenskab ... og en masse kreativitet
Udefra set kan programmering virke som ren og skær beregning, men i virkeligheden Det er en mærkelig blanding af matematik, ingeniørvidenskab og brutal kreativitetLigesom du laver en illustration eller et storyboard, skaber en udvikler logiske elementer, så softwaren gør præcis det, der blev forestillet sig.
De fleste fagfolk er enige om, at Problemløsningsevner og kreativitet er lige så vigtige, hvis ikke vigtigere, end at kunne en million sprog.For den samme funktionalitet er der normalt mange måder at implementere den på, ligesom der er tusind måder at designe et cover eller et logo på; nøglen er at finde den reneste, mest elegante og nemmeste løsning at vedligeholde.
Derfor værdsættes det i stigende grad, at kreative teams forstår det Kode er også designDer er softwarearkitekturbeslutninger, dataflows og interne strukturer, der i høj grad påvirker, hvad du derefter kan kræve af en app, et plugin eller et websted uden at forvandle projektet til en uvedligeholdelsesbar Frankenstein.
Og ja, programmering er vanedannende: Mange udviklere beskriver deres arbejde som det bedste logiske puslespil, der findes.En hvor du bestemmer reglerne og brikkerne, og det passer rigtig godt til tankegangen hos en person, der nyder at skabe ting fra bunden.
Kompilering, kommandolinje og andre kodnings-"ritualer"
Hvis du nogensinde har hørt nogen sige "det er kompilering" og forsvinde fra deres stol med en kop kaffe, så vid det. Det er ikke altid en undskyldning, men det er en perfekt en af slagsen.Kompilering betyder at oversætte kildekoden til et eksekverbart program, og i sprog som C++ eller i store spilmotorer kan det tage mange minutter eller endda timer.
I dag til dag, Den tid til at samle tingene er til at trække vejret, gennemgå koncepter eller blot at nulstille dit sind.I kreative miljøer, når man arbejder med renderingmotorer eller tunge spilbyggerier, sker der noget lignende: der er nedetid, mens man venter på, at maskinen bliver færdig, og mange teams udnytter det til at diskutere ideer, finpudse designs eller gennemgå opgaver.
Relateret til dette er kommandolinjen, den sorte skærm, der er skræmmende i starten, men når du først mestrer den, Det bliver en slags tryllestavDet, du rent faktisk laver der, er programmering i miniature: du skriver instruktioner i et scriptsprog (som Bash) for at automatisere handlinger, der ville være besværlige i en grafisk brugerflade.
For en avanceret kreativ person kan det være uvurderligt at lære fire ting om terminaler: Omdøb tusindvis af filer, batchkonverter formater, start render-scripts, flyt sikkerhedskopier eller synkroniser projekter uden at røre musen. Det er en anden måde at "tale computerens sprog" på og komme tættere på programmørers måde at tænke på.
Den mørke side af kode: semikolon, fejl og endeløs fejlfinding
En af de grusomste kuriositeter ved software er, at Små ting kan ødelægge store tingEt forkert placeret semikolon, en manglende parentes eller en parentes, der lukker på det forkerte sted, kan ødelægge hundredvis af perfekt udtænkte linjer, ligesom et forkert låst lag kan ødelægge en hel PSD.
Udviklere bruger en stor del af deres dag på en meget uglamourøs, men essentiel måde: fejlfindingsfejlInsektjagt er som at jage væsner, der gemmer sig absurde steder: de får ikke altid et program til at gå ned, nogle gange udløser de kun mærkelige fejl på bestemte tidspunkter eller vises med bestemte data eller på bestemte enheder.
I din verden kan dette oversættes til ting som Værktøjer, der kun fejler med én filtype, animationer, der ser fine ud på din computer, men går ned i produktion, websteder, der kun går ned i en bestemt browser...som overraskende nok normalt er den synlige del af en meget dybereliggende fejl i koden.
For at overleve dette udvikler de fleste programmører et arsenal af fejlfindingsteknikker: Brug logfiler, grafiske fejlfindingsprogrammer, breakpoints og udskrifter af variable tilstande....og endda tilbyde interne belønninger for at finde visse særligt flygtige fejl. Dette er en anden grund til, at "hurtige" ændringer næsten aldrig er så hurtige.
Og ja: der er humor. Mange kommentarer i koden bliver til små sarkasmekunstværker: "// Magi. Rør ikke.", "// fuld, ret senere" eller "// hack til IE-browser (forudsat at IE er en browser)"Den skyttegravshumor er en vigtig del af udviklerkulturen.
Dovenskab, automatisering og versionskontrol: dyder i forklædning
Det lyder måske mærkeligt, men det er under udvikling Dovenskab, når det forstås korrekt, betragtes som en professionel dyd.Ideen er enkel: Hvis noget er gentagende og manuelt, vil en klog person finde en måde at automatisere det på, så de aldrig behøver at gøre det igen. Det er den "dovenskab", der driver scripts, plugins, automatiserede handlinger og makroer, som du derefter bruger dagligt uden at vide, hvor de kommer fra.
I seriøse projekter er denne filosofi afhængig af et andet nøgleelement: versionskontrol, med Git som den absolutte kongeTakket være Git kan teams arbejde på det samme projekt uden at træde hinanden over tæerne, teste skøre idéer i separate branches, rulle tilbage, når noget ødelægger halvdelen af applikationen, eller se, hvem der rørte hvad og hvornår.
For en kreativ professionel, der samarbejder med udviklere, er det vigtigt at forstå det grundlæggende. Hvad er en commit, en branch eller en merge? Det hjælper meget: det giver dig mulighed for at spore udviklingsfremskridt, overvåge, hvornår en ændring, der påvirker dit design, blev introduceret, og bedre koordinere, hvornår du skal låse nye funktioner ind og fokusere på at polere det, der allerede er der.
Desuden gælder denne automatiseringskultur også for opgaver, der tilsyneladende er mindre "tekniske": Implementeringsscripts, automatisk dokumentationsgenerering, tests der kører automatisk hver nat, pipelines der konverterer aktiver, komprimerer billeder eller genererer versioner til forskellige enheder uden menneskelig indgriben. Alt dette stammer fra en person, der nægtede at gentage den samme proces i hånden hundrede gange.
Kommentarer, klare navne og en besættelse af læsbar kode
Ligesom en designfil med velnavngivne lag og organiserede grupper er uendeligt værdsat, Kode har brug for orden, kontekst og gode tags.Ellers bliver det en ufremkommelig jungle, selv for den person, der skrev den et par uger tidligere.
Gode programmører lægger stor vægt på to ting: betydningsfulde navne og kommentarer, der giver reel kontekstKald af en variabel userAge o totalCost Det siger meget mere end x o tempOg det er uendeligt mere nyttigt at bemærke, hvorfor en bestemt algoritme er blevet valgt, eller hvilket trick der bruges, end at kommentere "// læg to tal sammen".
I praksis skaber dette en slags intern "teknisk script" for projektet, som andre udviklere kan læse for at forstå det. softwaredesignbeslutningerne bag hvert modulNår koden er velskrevet, er den bedste kommentar nogle gange selve koden, hvilket forklarer sig selv takket være de velvalgte navne.
Den besættelse af klarhed passer rigtig godt til begreber, du måske har hørt om, som f.eks. Ren kode, refactoring eller "gentag ikke dig selv"-reglen (DRY)Hele den filosofi peger på det samme: at softwaren skal være let at forstå, ændre, teste og udvide uden at ødelægge alt.
Test, TDD, og hvorfor det ikke er nok at "få det til at virke i dag"
Et andet mindre synligt, men grundlæggende aspekt af ethvert program, du bruger, er tesøkosystemet bagvedEnhedstest, integrationstest, automatiserede eller manuelle test eksisterer netop for at forhindre, at en lille ændring, der tilføjer en indstilling, du har anmodet om, lydløst ødelægger 20 andre dele af systemet.
Der findes metoder som TDD (Test Driven Development), hvor Først skrives testene, og derefter den kode, der får dem til at bestå.Det virker kontraintuitivt, men det tvinger udvikleren til at tænke fra starten over den ønskede adfærd, kanttilfældene, og hvordan man verificerer, at alt fortsætter med at fungere korrekt over tid.
For kreative teams kan dette omsættes til noget meget konkret: At anmode om "bare denne lille ændring af knappen" eller "tilføjelse af en ny effekt" har en reel omkostning i form af test og validering.Det er ikke fordi, de ikke vil hjælpe dig; det er fordi enhver ændring, uanset hvor lille den end måtte synes for brugerfladen, kan have bivirkninger, og de skal sørge for, at resten af applikationen ikke går i stykker.
Derudover opretter mange virksomheder testsuiter, der kører, mens teamet sover eller i weekenden: Koden kompileres, en række tests køres, og resultaterne gennemgås.Hvis noget går galt, opdages det længe før det når slutbrugerne ... og det inkluderer de kreative, der er afhængige af disse værktøjer i produktionen.
Algoritmer, datastrukturer og hastighed: den usynlige motor i dine værktøjer
Bag hver filsøgning, hvert filter der anvendes på et sekund, eller hvert lærred der forbliver flydende selv med tusindvis af lag, er der noget, du ikke ser: algoritmer og datastrukturer valgt med ondsindet hensigtBrug af en liste, en stak, en kø eller en ordbog (hashmap) gør en kæmpe forskel i ydeevnen.
Fx Hvis du har brug for at finde elementer hurtigt, er en ordbog meget mere effektiv end en simpel liste.Dette gør det muligt for din editor at finde en stil, et symbol eller et element på millisekunder, selv i et stort projekt. Det samme gælder for, hvordan pixels, vektorer, 3D-masker eller lydspor gemmes.
Når en kreativ app er langsom, er det ikke altid din computers skyld: Nogle gange ligger flaskehalsen i softwaredesignbeslutninger, der blev truffet for år siden.eller i hurtige genveje, der blev taget "midlertidigt" og derefter forblev for evigt, noget der desværre er almindeligt i mange projekter.
Derfor insisterer så mange professionelle rådgivningsspalter på Undgå for tidlig optimering, men vælg de rigtige algoritmer og strukturer fra starten.Dette solide fundament muliggør skalerbarhed: flere lag, flere effekter, flere brugere, flere enheder ... uden at systemet går ned.
Programmørkultur: mærkelige vittigheder, binær teknologi og "der er ingen ske"
Hvis du arbejder med udviklere, vil du før eller siden høre ting som "Der er 10 typer mennesker: dem, der forstår binær teknologi, og dem, der ikke gør."Det er en klassisk joke, der spiller på det faktum, at 10 i binært tal er 2 i decimaltal. Denne type teknisk humor er en del af en hel subkultur: memes, subreddits, referencer til The Matrix, Star Wars, Starship Troopers…
Den berømte sætning "Der er ingen ske" Matrix-analogien bruges ofte til at beskrive følelsen af at se gennem brugerfladen og forstå, hvordan en applikation er bygget nedenunder. Når man ved, hvordan man programmerer, er det ikke længere bare at forbruge et program eller en hjemmeside: man begynder at forestille sig dets moduler, dets arkitektur, hvordan delene kommunikerer, hvor noget måske fejler.
Fejl diskuteres også, som om de var Starship Troopers-væsner: små af udseende, men i stand til at forårsage et stort rodDet fælles sprog skaber fællesskab; humor er en måde at håndtere presset ved at have enorme systemer, der holder fast i din kode.
For en kreativ professionel gør det at forbinde sig med den kultur forholdet til programmører mere gnidningsløst: at forstå hans vittigheder, hans referencer og hans særheder Det letter kommunikationen betydeligt, når man diskuterer deadlines, tekniske begrænsninger eller ændringer i sidste øjeblik.
Hvordan programmører (virkelig) lærer, og hvad det betyder for dig
En anden interessant kendsgerning er, at selvom der findes grader, bootcamps og kandidatuddannelser, Det meste af den virkelige læring i programmering sker ved at arbejdeDet er mere som et håndværk end et universitetsfag: du lærer ved at gøre, ødelægge ting, reparere dem og gentage cyklussen igen og igen.
De fleste udviklere er enige om én idé: Du behøver ikke at huske altDer er officiel dokumentation, fora, artikler, bøger som "97 ting, som enhver programmør bør vide", og tonsvis af online ressourcer, såsom Tutorials om programmeringssprog på spanskDet vigtige er at vide, hvordan man søger, vælger og anvender den viden på et specifikt problem, ligesom du ikke kender alle Photoshop-genvejene udenad, men du ved, hvor du skal lede, når du har brug for dem.
Desuden anbefaler næsten alle at specialisere sig: Vælg et område (web, mobil, backend, data, videospil…) og dyk dybere ned I stedet for at forsøge at dække hele det teknologiske landskab, kan den samme logik inspirere dig: at virkelig forstå, hvordan software fungerer i din kreative niche, vil gøre dig langt mere magtfuld end at vide lidt om alt uden at mestre noget.
Noget, der også går igen i mange interne undersøgelser, er vigtigheden af mentor og "parprogrammering": Programmér to og to, lad andre gennemgå din kode, bed om hjælp og tag imod kritik.Præcis det samme som når du deler et storyboard eller moodboard med en anden og accepterer feedback for at forbedre værket.
Udviklerarbejdets virkelighed: ensomhed, koncentration og kæmpe hovedtelefoner
Indeni har et softwareteams hverdag en del fællestræk med et kreativt studie: Mange timer foran skærmen, lange perioder med koncentration og et had-kærlighedsforhold med afbrydelserDet er ikke ualmindeligt at se halvdelen af holdet have enorme støjreducerende hovedtelefoner på, næsten som om de var obligatoriske arbejdshjelme.
Musik bliver et produktivitetsværktøj: Bløde lister til arkitektonisk tænkning, noget mere kraftfuldt til mekaniske opgaver, total stilhed til fejlfinding af komplicerede fejlHovedtelefoner er ikke bare en indfald: de er et socialt signal om "afbryd mig ikke nu, jeg er i fokustilstand", ligesom nogle studier bruger flag eller små fysiske signaler på bordet.
Der er også en anden, mindre synlig side: Det kan være isolerende at arbejde så meget alene foran en computer.Mange veteraner insisterer på, at man ikke skal lade sig behandle som en robot, og at det er vigtigt at dyrke et liv uden for kodning: hobbyer, forhold, fysisk aktivitet, hvile. Hjernen, der designer løsninger, og den, der designer grænseflader, er den samme, og den har brug for plads.
Parallelt er der noget meget virkeligt, der hedder programmeringsafhængighedNår man virkelig er vild med noget, er det nemt at bruge hele nætter "bare på at færdiggøre dette modul" og glemme at spise, sove eller endda rejse sig fra stolen. Ligesom med enhver kreativ passion skal man lære at sætte grænser for at undgå at brænde ud.
Tankegang, bedragersyndrom og sund konkurrence
De fleste, der starter med programmering, har en teknisk baggrund, men Det betyder ikke, at en person med en "humanistisk" baggrund ikke kan omskoles.Det, veteraner værdsætter mest, er ikke typen af gymnasial eksamen, men konsistens, evnen til at lære og en vis fortrolighed med logisk tænkning.
Næsten alle i branchen lever med noget ret udbredt: bedrager syndromDen følelse af "jeg ved ikke nok, jeg bliver opdaget, jeg er ikke opgaven voksen" kan opstå uanset hvor gammel man er. Mange bruger den som motivation til at blive ved med at lære, så længe det ikke fører til lammende angst.
Konkurrenceevne er også en del af landskabet, men i sin sunde form er det mere som "Rivalisering" blandt kolleger for at se, hvem der optimerer et modul bedst, eller hvem der skriver den mest elegante kode Det er ikke som en krig om, hvem der træder på hvem. At have en programmør, du beundrer, der værdsætter dit arbejde, minder meget om at have en anden kreativ person, der beundrer din illustration eller video.
I dette miljø er det afgørende at lære at acceptere feedback: Når du får ros, så far ikke vild; når du bliver kritiseret, så giv ikke op.Sektoren ændrer sig så hurtigt, at der altid vil være teknologier, man ikke kontrollerer, og folk, der ved mere om noget specifikt, og det er en del af spillet at leve med.
Den mest tidskrævende del: fejlfinding, håndtering af frustration og beslutning om, hvornår man skal skifte
Hvis man kun ser på slutresultaterne, skulle man tro, at udviklerne bruger hele dagen på at skrive nye funktioner, men i virkeligheden Meget af tiden går med at fejlfinde og justere ting, der allerede findes.At komme videre med et projekt betyder ofte at låse op for små fejl, der forhindrer resten af systemet i at komme videre.
Dette forårsager betydelige toppe i frustrationen: Problemer der trodser opdagelse, konstruktioner der fejler uden åbenlys forklaring, kunder der kræver umulige deadlinesMange fagfolk siger, at de har haft øjeblikke, hvor de har haft lyst til at opgive alt og skifte sektor, især når de arbejder med komplekse produkter.
De strategier, de anbefaler, lyder bekendte: Udholdenhed, selvmotivation, en vis stolthed over et veludført stykke arbejde og en oprigtig passion for håndværketLigesom i enhver krævende kreativ disciplin er det den blanding, der får dig til at prøve igen, når noget ikke fungerer, og det, der adskiller dem, der holder sig på overfladen, fra dem, der bliver virkelig gode.
En vis grad af jobudskiftning er også almindelig: Gode kandidater modtager løbende tilbud.Mange råd her peger på det samme: kig efter en virksomhedskultur, der stemmer overens med dine værdier, og husk, at du i en jobsamtale også evaluerer virksomheden. Du vil bruge mange timer på at tænke over dens problemer; at have et godt interpersonelt match og fælles værdier betyder mere, end det måske ser ud til på dit CV.
Tekniske interviews, teamintegration og kommunikation
Inden for udviklingsmiljøet er tekniske interviews ret berømte ... og har også et ret dårligt ry. Mange veteraner mener, at De er overvurderede, og at du ikke lykkes med én af dem siger ikke meget om dit potentiale.De måler normalt et specifikt sæt færdigheder under pres, ikke din faktiske evne til at lære, samarbejde og gennemføre projekter med succes på lang sigt.
I stedet Bløde færdigheder gør ofte hele forskellen: at vide, hvordan man kommunikerer, stille spørgsmål, når noget ikke er forstået, integrere feedback, samarbejde med mennesker fra forskellige baggrunde (som dig, hvis du er kreativ) og bevare roen i anspændte øjeblikke.
Når man ansøger i en virksomhed, er den vigtigste anbefaling til enhver juniorprogrammør Vær ikke bange for at stille spørgsmål, men gør det med omtanke.Planlæg specifikke tidspunkter med en mentor til at besvare spørgsmål, undgå at afbryde, medmindre det haster, og forbered dine spørgsmål grundigt. Det samme gælder, når du deltager i et teknisk team: jo klarere og mere struktureret din kommunikation er, jo bedre passer du ind.
I miljøer, hvor der ikke er tildelt en mentor, er den mest tilrådelige fremgangsmåde at vinde tilliden fra en person med erfaring og opbygge et solidt professionelt forhold med den person. I sidste ende afhænger store projekter lige så meget af kvaliteten af koden og designet som af kvaliteten af relationerne mellem dem, der bygger dem.
I sidste ende kommer magien ved de værktøjer, du bruger hver dag, fra en ret menneskelig blanding: Mennesker der konstant lærer, bliver frustrerede, bliver konkurrencemindede, samarbejder, griner af mærkelige binære vittigheder og gradvist forvandler ideer til softwareNår man som kreativ forstår disse kuriositeter og arbejdsmetoder, er det meget nemmere at tale det samme sprog, spørge efter det, der rent faktisk kan bygges, og deltage i den næsten "magiske" proces med at få en computer til at gøre præcis det, man forestiller sig.