Hvis du jobber med design, illustrasjon, animasjon eller en annen kreativ disiplin, vil du før eller siden støte på den samme veggen: Programvaren og dataprogrammene du bruker daglig er ikke bare «verktøy»men snarere et helt økosystem med sine egne regler, særegenheter og særegenheter. Å forstå disse små nyansene kan utgjøre forskjellen mellom å slite med datamaskinen din og å føle at den utfører magi på deg.
Utover snarveier og noen tilfeldige triks, Det finnes et helt univers av detaljer om operativsystemer, programmering, feilsøking, «teknologikultur» og arbeidsmåter. Dette påvirker hvordan applikasjonene du bruker som kreativ er utformet og fungerer. Å forstå denne verdenen fra innsiden hjelper deg å jobbe bedre med utviklingsteam, be om realistiske ting ... og få kraftigere ideer fordi du vet hva som kan og ikke kan bygges.
Unix, Mac, Linux og hvorfor systemet er viktigere enn det ser ut til
For mange kreative er den klassiske debatten «Mac eller Windows for design?»Men innenfor programvareverdenen går samtalen ofte et skritt videre: Unix kontra alt annet. macOS og de fleste Linux-distribusjoner arver Unix-filosofien, noe som gjør dem til svært kraftige plattformer for å utvikle og automatisere oppgaver som deretter direkte påvirker verktøyene du bruker.
Programmører sier ofte at «Hele Unix-systemet er som ett stort utviklingsmiljø»Fordi alt er designet for å koble sammen små, kraftige verktøy fra terminalen: behandling av bilder, automatisering av eksport, lansering av renderingsskript, administrasjon av servere eller kompilering av kode uten å være avhengig av grafiske veivisere. Det er derfor mange avanserte kreative pakker, spillmotorer og 3D-verktøy er designet med tanke på denne typen miljøer.
I motsetning til dette er ting mer visuelle og brukervennlige i Windows, men Historisk sett har den vært mindre «vennlig» til dyp utvikling og kommandolinjearbeid.I dag har gapet blitt betraktelig mindre (WSL, PowerShell, osv.), men Unix-kulturen gjennomsyrer fortsatt mye av programvaren du bruker uten at du engang er klar over det.
Hvorfor er du interessert i dette som kreativ? Fordi Automatiseringer, skript og plugins som sparer deg for timer, stammer ofte fra denne Unix-verdenen.Å jobbe i team som har mestret det, resulterer ofte i mer robuste og stabile arbeidsflyter som er enklere å skalere etter hvert som prosjektet vokser.
Programmering er en sjelden hybrid: logikk, ingeniørfag ... og mye kreativitet
Fra utsiden kan programmering virke som ren kald kalkulasjon, men i virkeligheten Det er en merkelig blanding av matematikk, ingeniørfag og brutal kreativitetAkkurat som du lager en illustrasjon eller et storyboard, lager en utvikler logikkbiter slik at programvaren gjør akkurat det som ble forestilt seg.
De fleste fagfolk er enige om at Problemløsningsevner og kreativitet er like viktige, om ikke viktigere, enn å kunne en million språk.For den samme funksjonaliteten finnes det vanligvis mange måter å implementere den på, akkurat som det finnes tusen måter å designe et omslag eller en logo på. Nøkkelen er å finne den reneste, mest elegante og enkleste løsningen å vedlikeholde.
Derfor verdsettes det stadig mer at kreative team forstår det Kode er også designDet finnes beslutninger om programvarearkitektur, dataflyter og interne strukturer som i stor grad påvirker hva du deretter kan be om av en app, plugin eller et nettsted uten å gjøre prosjektet til en uvedlikeholdbar Frankenstein.
Og ja, programmering er avhengighetsskapende: Mange utviklere beskriver arbeidet sitt som det beste logiske puslespillet som finnes.En der du bestemmer reglene og brikkene, og det passer veldig godt med tankegangen til en som liker å skape ting fra bunnen av.
Kompilering, kommandolinje og andre kode-"ritualer"
Hvis du noen gang har hørt noen si «det er kompilering» og forsvinne fra stolen med en kaffe, så vit at Det er ikke alltid en unnskyldning, men det er en perfekt en.Kompilering betyr å oversette kildekoden til et kjørbart program, og i språk som C++ eller i store spillmotorer kan det ta mange minutter eller til og med timer.
I dag til dag, Den samletiden er til for å puste, gjennomgå konsepter eller rett og slett tilbakestille tankene dine.I kreative miljøer, når man jobber med renderingsmotorer eller tunge spillbygg, skjer noe lignende: det er nedetid mens man venter på at maskinen skal bli ferdig, og mange team benytter seg av dette til å diskutere ideer, finpusse design eller gjennomgå oppgaver.
Relatert til dette er kommandolinjen, den svarte skjermen som er skummel i starten, men når du mestrer den, Det blir en slags tryllestavDet du faktisk gjør der er programmering i miniatyr: du skriver instruksjoner i et skriptspråk (som Bash) for å automatisere handlinger som ville vært et ork i et grafisk grensesnitt.
For en avansert kreativ person kan det være uvurderlig å lære fire ting om terminaler: Gi nytt navn til tusenvis av filer, konverter formater i batch, start renderingsskript, flytt sikkerhetskopier eller synkroniser prosjekter uten å berøre musen. Det er en annen måte å «snakke datamaskinens språk» på og komme nærmere måten programmerere tenker på.
Den mørke siden av kode: semikolon, feil og endeløs feilsøking
En av de grusomste kuriositetene ved programvare er at Små ting kan ødelegge store tingEt feilplassert semikolon, en manglende parentes eller en brakett som lukkes på feil sted kan ødelegge hundrevis av perfekt gjennomtenkte linjer, akkurat som et feil låst lag kan ødelegge en hel PSD.
Utviklere tilbringer en stor del av dagen sin i en svært lite glamorøs, men essensiell modus: feilsøkingsfeilInsektjakt er som å jakte på skapninger som gjemmer seg på absurde steder: de forårsaker ikke alltid at et program krasjer, noen ganger utløser de bare merkelige feil på bestemte tidspunkter, eller dukker opp med bestemte data eller på bestemte enheter.
I din verden betyr dette ting som Verktøy som bare feiler med én filtype, animasjoner som ser fine ut på datamaskinen din, men krasjer i produksjon, nettsteder som bare feiler i en bestemt nettleser....som overraskende nok vanligvis er den synlige delen av en mye dypereliggende feil i koden.
For å overleve dette utvikler de fleste programmerere et arsenal av feilsøkingsteknikker: Bruk logger, grafiske feilsøkingsprogrammer, avbruddspunkter og utskrifter av variabel tilstand....og til og med tilby interne belønninger for å finne visse spesielt unnvikende feil. Dette er en annen grunn til at "raske" endringer nesten aldri er så raske.
Og ja: det er humor. Mange kommentarer i koden blir til små sarkasmekunstverk: «// Magi. Ikke rør.», «// full, fiks senere» eller «// hack for IE-nettleser (forutsatt at IE er en nettleser)»Den skyttergravshumoren er en viktig del av utviklerkulturen.
Latskap, automatisering og versjonskontroll: dyder i forkledning
Det høres kanskje rart ut, men det er under utvikling Latskap, når det forstås riktig, regnes som en profesjonell dyd.Ideen er enkel: hvis noe er repetitivt og manuelt, vil noen smarte se etter en måte å automatisere det på, slik at de aldri trenger å gjøre det igjen. Denne «latskapen» er det som driver skript, programtillegg, automatiserte handlinger og makroer som du deretter bruker daglig uten å vite hvor de kommer fra.
I seriøse prosjekter er denne filosofien avhengig av et annet nøkkelelement: versjonskontroll, med Git som den absolutte kongenTakket være Git kan team jobbe med det samme prosjektet uten å tråkke hverandre på tærne, teste sprø ideer i separate grener, rulle tilbake når noe ødelegger halve applikasjonen, eller se hvem som rørte hva og når.
For en kreativ profesjonell som samarbeider med utviklere, er det viktig å forstå det grunnleggende. Hva er en commit, en branch eller en merge? Det hjelper mye: det lar deg spore utviklingsfremdriften, overvåke når en endring som påvirker designet ditt ble introdusert, og bedre koordinere når du skal låse inn nye funksjoner og fokusere på å polere det som allerede er der.
Videre gjelder denne automatiseringskulturen også oppgaver som tilsynelatende er mindre «tekniske»: Distribusjonsskript, automatisk generering av dokumentasjon, tester som kjører automatisk hver natt, pipelines som konverterer ressurser, komprimerer bilder eller genererer versjoner for forskjellige enheter uten menneskelig inngripen. Alt dette stammer fra noen som nektet å gjenta den samme prosessen for hånd hundre ganger.
Kommentarer, tydelige navn og en besettelse av lesbar kode
Akkurat som en designfil med velnavngitte lag og organiserte grupper blir satt uendelig stor pris på, Kode trenger orden, kontekst og gode tagger.Ellers blir det en ufremkommelig jungel, selv for personen som skrev den noen uker tidligere.
Gode ​​programmerere legger stor vekt på to ting: meningsfulle navn og kommentarer som gir reell kontekstKalle en variabel userAge o totalCost Det sier mye mer enn x o tempOg det å legge merke til hvorfor en bestemt algoritme er valgt eller hvilket triks som brukes, er uendelig mye mer nyttig enn å kommentere "// legg sammen to tall".
I praksis skaper dette et slags internt «teknisk skript» for prosjektet, som andre utviklere kan lese for å forstå det. programvaredesignbeslutningene bak hver modulNår koden er godt skrevet, er den beste kommentaren noen ganger selve koden, noe som forklarer seg selv takket være de velvalgte navnene.
Den besettelsen av klarhet passer veldig godt med konsepter du kanskje har hørt om, som for eksempel Ren kode, refaktorering eller «ikke gjenta deg selv»-regelen (DRY)All denne filosofien peker mot det samme: at programvaren skal være enkel å forstå, endre, teste og utvide uten å ødelegge alt.
Testing, TDD, og ​​hvorfor det ikke er nok å «få det til å fungere i dag»
Et annet mindre synlig, men grunnleggende aspekt ved ethvert program du bruker er testøkosystemet bakEnhetstester, integrasjonstester, automatiserte eller manuelle tester eksisterer nettopp for å forhindre at en liten endring som legger til et alternativ du ba om, i stillhet ødelegger 20 andre deler av systemet.
Det finnes metoder som TDD (Test Driven Development) der Først skrives testene, og deretter koden som sørger for at de består.Det virker kontraintuitivt, men det tvinger utvikleren til å tenke fra begynnelsen av om ønsket oppførsel, kanttilfeller og hvordan man kan bekrefte at alt fortsetter å fungere riktig over tid.
For kreative team blir dette noe veldig konkret: Å be om «bare denne lille endringen på knappen» eller «å legge til en ny effekt» har en reell kostnad når det gjelder testing og validering.Det er ikke det at de ikke vil hjelpe deg; det er det at enhver modifikasjon, uansett hvor liten den kan virke for grensesnittet, kan ha bivirkninger, og de må sørge for at resten av applikasjonen ikke bryter sammen.
I tillegg setter mange selskaper opp testsuiter som kjører mens teamet sover eller i helgen: Koden kompileres, en rekke tester kjøres, og resultatene gjennomgås.Hvis noe går galt, oppdages det lenge før det når sluttbrukerne … og det inkluderer de kreative personene som er avhengige av disse verktøyene i produksjonen.
Algoritmer, datastrukturer og hastighet: den usynlige motoren i verktøyene dine
Bak hvert filsøk, hvert filter som brukes på et sekund, eller hvert lerret som forblir flytende selv med tusenvis av lag, er det noe du ikke ser: algoritmer og datastrukturer valgt med ondsinnet hensiktÅ bruke en liste, en stabel, en kø eller en ordbok (hashmap) utgjør en stor forskjell i ytelse.
Eg Hvis du trenger å finne elementer raskt, er en ordbok mye mer effektivt enn en enkel liste.Dette lar redigeringsprogrammet finne en stil, et symbol eller et ressurselement på millisekunder, selv i et stort prosjekt. Det samme gjelder hvordan piksler, vektorer, 3D-nett eller lydspor lagres.
Når en kreativ app er treg, er det ikke alltid datamaskinens feil: Noen ganger ligger flaskehalsen i beslutninger om programvaredesign som ble tatt for mange år siden.eller i raske snarveier som ble tatt «midlertidig» og deretter forble for alltid, noe som dessverre er vanlig i mange prosjekter.
Det er derfor så mange profesjonelle rådgivningsspalter insisterer på Unngå for tidlig optimalisering, men velg riktige algoritmer og strukturer fra begynnelsen.Dette solide fundamentet muliggjør skalerbarhet: flere lag, flere effekter, flere brukere, flere enheter ... uten at systemet krasjer.
Programmerkultur: rare vitser, binærteknologi og «det finnes ingen skje»
Hvis du jobber med utviklere, vil du før eller siden høre ting som «Det finnes ti typer mennesker: de som forstår binært språk og de som ikke gjør det.»Det er en klassisk vits som spiller på det faktum at 10 i binært tall er 2 i desimaltall. Denne typen teknisk humor er en del av en hel subkultur: memer, subreddits, referanser til The Matrix, Star Wars, Starship Troopers…
Det berømte uttrykket «Det finnes ingen skje» Matrise-analogien brukes ofte for å beskrive følelsen av å se gjennom grensesnittet og forstå hvordan et program er bygget under. Når du vet hvordan man programmerer, er det å se på et program eller et nettsted ikke lenger bare å konsumere det: du begynner å forestille deg modulene, arkitekturen, hvordan delene kommuniserer, hvor noe kan feile.
Insekter diskuteres også som om de var Starship Troopers-skapninger: små av utseende, men i stand til å forårsake et stort rotDet delte språket skaper fellesskap; humor er en måte å håndtere presset ved å ha enorme systemer som henger på koden din.
For en kreativ profesjonell vil det å knytte bånd til den kulturen gjøre forholdet med programmerere smidigere: å forstå vitsene hans, referansene hans og særegenhetene hans Det forenkler kommunikasjonen betraktelig når man diskuterer tidsfrister, tekniske begrensninger eller endringer i siste liten.
Hvordan programmerere (egentlig) lærer og hva dette betyr for deg
Et annet interessant faktum er at selv om det finnes grader, bootcamps og masterprogrammer, Det meste av den virkelige læringen i programmering skjer ved å jobbeDet er mer som et yrke enn et universitetsfag: du lærer ved å gjøre, ødelegge ting, fikse dem og gjenta syklusen om og om igjen.
De fleste utviklere er enige om én idé: Du trenger ikke å memorere altDet finnes offisiell dokumentasjon, forum, artikler, bøker som «97 ting alle programmerere bør vite», og tonnevis av nettressurser, som for eksempel Veiledninger om programmeringsspråk på spanskDet viktigste er å vite hvordan man søker, velger og anvender den kunnskapen på et spesifikt problem, akkurat som du ikke kan alle Photoshop-snarveiene utenat, men du vet hvor du skal lete når du trenger dem.
Videre anbefaler nesten alle å spesialisere seg: Velg et område (nett, mobil, backend, data, videospill…) og fordyp deg I stedet for å prøve å dekke hele det teknologiske landskapet. Den samme logikken kan inspirere deg: å virkelig forstå hvordan programvare fungerer i din kreative nisje vil gjøre deg mye mektigere enn å vite litt om alt uten å mestre noe.
Noe som også går igjen i mange interne undersøkelser er viktigheten av mentor og «parprogrammering»: Programmer to og to, la andre gjennomgå koden din, be om hjelp og ta imot kritikk.Akkurat det samme som når du deler et storyboard eller moodboard med noen andre og tar imot tilbakemeldinger for å forbedre verket.
Realiteten av utviklerarbeid: ensomhet, konsentrasjon og gigantiske hodetelefoner
Innvendig deler hverdagen til et programvareteam en rekke ting med et kreativt studio: Mange timer foran skjermen, lange perioder med konsentrasjon og et kjærlighets-hatforhold med avbruddDet er ikke uvanlig å se halvparten av teamet bruke enorme støydempende hodetelefoner, nesten som om de var obligatoriske arbeidshjelmer.
Musikk blir et produktivitetsverktøy: Myke lister for arkitektonisk tenkning, noe kraftigere for mekaniske oppgaver, total stillhet for feilsøking av kompliserte feilHodetelefoner er ikke bare et innfall: de er et sosialt signal om «ikke avbryt meg nå, jeg er i fokusmodus», akkurat som noen studioer bruker flagg eller små fysiske signaler på bordet.
Det finnes også en annen, mindre synlig side: Å jobbe så mye tid alene foran en datamaskin kan være isolerende.Mange veteraner insisterer på at man ikke bør la seg behandle som en robot, og at det er viktig å dyrke et liv utenom koding: hobbyer, forhold, fysisk aktivitet, hvile. Hjernen som designer løsninger og den som designer grensesnitt er den samme, og den trenger plass.
Parallelt finnes det noe veldig reelt som kalles programmeringsavhengighetNår man virkelig er opptatt av noe, er det lett å bruke hele netter «bare på å bli ferdig med denne modulen» og glemme å spise, sove eller til og med reise seg fra stolen. Akkurat som med enhver kreativ lidenskap, må man lære å sette grenser for å unngå å bli utbrent.
Tankegang, impostersyndrom og sunn konkurranse
De fleste som begynner med programmering har teknisk bakgrunn, men Det betyr ikke at noen med en «humanistisk» bakgrunn ikke kan omskoleres.Det veteraner verdsetter mest er ikke typen videregående skolevitnemål, men konsistens, evnen til å lære og en viss komfort med logisk tenkning.
Nesten alle i bransjen lever med noe ganske utbredt: bedrager syndromDen følelsen av «jeg kan ikke nok, jeg kommer til å bli tatt, jeg er ikke oppgaven voksen» kan dukke opp uansett hvor eldre man er. Mange bruker det som motivasjon til å fortsette å lære, så lenge det ikke fører til lammende angst.
Konkurranseevne er også en del av landskapet, men i sin sunne form er det mer som "Rivalisering" blant kolleger for å se hvem som optimaliserer en modul best eller hvem som skriver den mest elegante koden Det er ikke som en krig om hvem som tråkker på hvem. Å ha en programmerer du beundrer som verdsetter arbeidet ditt er veldig likt å ha en annen kreativ person som beundrer illustrasjonen eller videoen din.
I dette miljøet er det avgjørende å lære å akseptere tilbakemeldinger: Når du får ros, ikke gå vill; når du blir kritisert, ikke gi opp.Sektoren endrer seg så raskt at det alltid vil finnes teknologier du ikke kontrollerer og folk som vet mer om noe spesifikt, og det å leve med det er en del av gamet.
Den mest tidkrevende delen: feilsøking, håndtering av frustrasjon og avgjørelse om når man skal bytte
Hvis du bare ser på sluttresultatene, kan du kanskje tro at utviklerne bruker hele dagen på å skrive nye funksjoner, men i virkeligheten Mye av tiden går med til å feilsøke feil og justere ting som allerede finnes.Å gå videre med et prosjekt betyr ofte å låse opp små feil som hindrer resten av systemet i å komme videre.
Dette forårsaker betydelige topper i frustrasjon: Problemer som ikke kan oppdages, bygg som feiler uten åpenbar forklaring, kunder som krever umulige tidsfristerMange fagfolk sier at de har hatt øyeblikk hvor de har hatt lyst til å slutte med alt og bytte sektor, spesielt når de jobber med komplekse produkter.
Strategiene de anbefaler høres kjente ut: Utholdenhet, selvmotivasjon, en viss stolthet over en godt utført jobb og en ærlig lidenskap for håndverketAkkurat som i enhver krevende kreativ disiplin, er det denne blandingen som får deg til å prøve igjen når noe ikke fungerer, og det som skiller de som holder seg på overflaten fra de som blir virkelig gode.
En viss grad av jobbutskiftning er også vanlig: Gode ​​kandidater mottar tilbud fortløpende.Mange råd her peker mot det samme: se etter en bedriftskultur som samsvarer med verdiene dine, og husk at du i et intervju også evaluerer bedriften. Du vil bruke mange timer på å tenke på problemene; å ha en god mellommenneskelig match og felles verdier er viktigere enn det kan virke på CV-en din.
Tekniske intervjuer, teamintegrasjon og kommunikasjon
Innenfor utviklingsmiljøet er tekniske intervjuer ganske berømte ... og har også et ganske dårlig rykte. Mange veteraner mener at De er overvurderte, og det å feile sier ikke mye om potensialet ditt.De måler vanligvis et spesifikt sett med ferdigheter under press, ikke din faktiske evne til å lære, samarbeide og fullføre prosjekter på lang sikt.
Stedet, Myke ferdigheter utgjør ofte hele forskjellen: å vite hvordan man kommuniserer, stille spørsmål når noe ikke er forstått, integrere tilbakemeldinger, samarbeide med mennesker fra ulik bakgrunn (som deg, hvis du er kreativ) og beholde roen i anspente øyeblikk.
Den viktigste anbefalingen for juniorprogrammerere når de blir med i et selskap Ikke vær redd for å stille spørsmål, men gjør det med omtanke.Planlegg spesifikke tidspunkter med en mentor for å svare på spørsmål, unngå å avbryte med mindre det haster, og forbered spørsmålene dine grundig. Det samme gjelder når du blir med i et teknisk team: jo tydeligere og mer strukturert kommunikasjonen din er, desto bedre vil du passe inn.
I miljøer der det ikke er tildelt en mentor, er den mest tilrådelige fremgangsmåten å å vinne tilliten til noen med erfaring og skape et solid profesjonelt forhold med den personen. Til syvende og sist avhenger store prosjekter like mye av kvaliteten på koden og designet som av kvaliteten på relasjonene mellom de som bygger dem.
Til syvende og sist kommer magien i verktøyene du bruker hver dag fra en ganske menneskelig blanding: Folk som lærer hele tiden, blir frustrerte, blir konkurransepregede, samarbeider, ler av rare binære vitser og gradvis gjør ideer om til programvareNår du, som kreativ, forstår disse kuriositetene og måtene å jobbe på, er det mye lettere å snakke samme språk, spørre etter hva som faktisk kan bygges, og delta i den nesten «magiske» prosessen med å få en datamaskin til å gjøre akkurat det du forestiller deg.