Om du arbetar med design, illustration, animation eller någon annan kreativ disciplin, kommer du förr eller senare att stöta på samma vägg: Programvaran och datorprogrammen du använder dagligen är inte bara "verktyg"utan snarare ett helt ekosystem med sina egna regler, egenheter och egenheter. Att förstå dessa små nyanser kan göra skillnaden mellan att kämpa med din dator och att känna att den utför magi på dig.
Utöver kortkommandon och några slumpmässiga knep, Det finns ett helt universum av detaljer om operativsystem, programmering, felsökning, "teknikkultur" och arbetssätt. Detta påverkar hur de applikationer du använder som kreatör är utformade och fungerar. Att förstå den här världen inifrån hjälper dig att arbeta bättre med utvecklingsteam, be om realistiska saker ... och få mer kraftfulla idéer eftersom du vet vad som kan och inte kan byggas.
Unix, Mac, Linux och varför systemet är viktigare än det verkar
För många kreatörer är den klassiska debatten "Mac eller Windows för design?"Men inom mjukvaruvärlden går samtalet ofta ett steg längre: Unix kontra allt annat. macOS och de flesta Linux-distributioner ärver Unix-filosofin, vilket gör dem till mycket kraftfulla plattformar för att utveckla och automatisera uppgifter som sedan direkt påverkar de verktyg du använder.
Programmerare säger ofta att "Hela Unix-systemet är som en enda stor utvecklingsmiljö"Eftersom allt är utformat för att kedja samman små, kraftfulla verktyg från terminalen: bearbetning av bilder, automatisering av exporter, lansering av renderingsskript, hantering av servrar eller kompilering av kod utan att förlita sig på grafiska guider. Det är därför många avancerade kreativa programsviter, spelmotorer och 3D-verktyg är utformade med den här typen av miljöer i åtanke.
Däremot är saker och ting mer visuella och användarvänliga i Windows, men Historiskt sett har den varit mindre "vänlig" mot djuputveckling och kommandoradsarbete.Idag har klyftan minskat avsevärt (WSL, PowerShell, etc.), men Unix-kulturen genomsyrar fortfarande mycket av den programvara du använder utan att du ens inser det.
Varför är du intresserad av detta som kreatör? För att Automatiseringar, skript och plugins som sparar timmar har ofta sitt ursprung i Unix-världen.Att arbeta i team som bemästrar det resulterar ofta i mer robusta och stabila arbetsflöden som är lättare att skala allt eftersom projektet växer.
Programmering är en sällsynt hybrid: logik, ingenjörskonst ... och mycket kreativitet
Utifrån sett kan programmering verka som ren kall beräkning, men i verkligheten Det är en märklig blandning av matematik, ingenjörskonst och brutal kreativitetPrecis som du skapar en illustration eller en storyboard, skapar en utvecklare logik så att programvaran gör exakt vad som föreställdes.
De flesta yrkesverksamma är överens om att Problemlösningsförmåga och kreativitet är lika viktiga, om inte viktigare, än att kunna en miljon språk.För samma funktionalitet finns det vanligtvis många sätt att implementera den, precis som det finns tusen sätt att designa ett omslag eller en logotyp; nyckeln är att hitta den renaste, mest eleganta och lättast underhållna lösningen.
Därför värderas det alltmer att kreativa team förstår det Kod är också designDet finns beslut om programvaruarkitektur, dataflöden och interna strukturer som i hög grad påverkar vad du sedan kan kräva av en app, ett plugin eller en webbplats utan att förvandla projektet till en ounderhållbar Frankenstein.
Och ja, programmering är beroendeframkallande: Många utvecklare beskriver sitt arbete som det bästa logiska pusslet som finns.En där du bestämmer reglerna och delarna, och det passar väldigt bra in i tankesättet hos någon som tycker om att skapa saker från grunden.
Kompilering, kommandoradshantering och andra kodnings"ritualer"
Om du någonsin hört någon säga "det är kompilering" och försvinna från sin stol med en kaffe, så vet det. Det är inte alltid en ursäkt, men det är en perfekt sådan.Kompilering innebär att översätta källkoden till ett körbart program, och i språk som C++ eller i stora spelmotorer kan det ta många minuter eller till och med timmar.
I dag till dag, Den sammanställningstiden är till för att andas, granska koncept eller helt enkelt återställa ditt sinneI kreativa miljöer, när man arbetar med renderingsmotorer eller tunga spelbyggen, händer något liknande: det finns driftstopp i väntan på att maskinen ska slutföras, och många team utnyttjar dem för att diskutera idéer, finslipa design eller granska uppgifter.
Relaterat till detta är kommandoraden, den där svarta skärmen som är läskig till en början men när du väl bemästrar den, Det blir ett slags trollstavDet du faktiskt gör där är programmering i miniatyr: du skriver instruktioner i ett skriptspråk (som Bash) för att automatisera åtgärder som skulle vara besvärliga i ett grafiskt gränssnitt.
För en avancerad kreatör kan det vara ovärderligt att lära sig fyra saker om terminaler: Byt namn på tusentals filer, batchkonvertera format, starta renderingsskript, flytta säkerhetskopior eller synkronisera projekt utan att röra musen. Det är ett annat sätt att "tala datorns språk" och komma närmare programmerares sätt att tänka.
Kodens mörka sida: semikolon, buggar och oändlig felsökning
En av de grymmaste kuriositeterna med programvara är att Små saker kan förstöra stora sakerEtt felplacerat semikolon, en saknad parentes eller en hakparentes som stängs på fel ställe kan förstöra hundratals perfekt genomtänkta rader, precis som ett felaktigt låst lager kan förstöra en hel PSD.
Utvecklare tillbringar en stor del av sin dag i ett mycket oglamoröst men viktigt läge: felsökningsfelInsektsjakt är som att jaga varelser som gömmer sig på absurda platser: de orsakar inte alltid att ett program kraschar, ibland utlöser de bara konstiga fel vid specifika tidpunkter, eller dyker upp med viss data eller på vissa enheter.
I din värld kan detta översättas till saker som Verktyg som bara misslyckas med en typ av fil, animationer som ser bra ut på datorn men kraschar i produktion, webbplatser som bara kraschar i en specifik webbläsare...vilket, överraskande nog, vanligtvis är den synliga delen av en mycket djupare bugg i koden.
För att överleva detta utvecklar de flesta programmerare en arsenal av felsökningstekniker: Använd loggar, grafiska felsökare, brytpunkter och utskrifter av variabelt tillstånd....och till och med erbjuda interna belöningar för att hitta vissa särskilt svårfångade buggar. Detta är ytterligare en anledning till att "snabba" förändringar nästan aldrig är så snabba.
Och ja: det finns humor. Många kommentarer i koden blir små sarkasmiska konstverk: ”// Magi. Rör inte.”, ”// berusad, fixa senare” eller ”// hacka för IE-webbläsare (förutsatt att IE är en webbläsare)”Den där skyttegravshumorn är en viktig del av utvecklarkulturen.
Lathet, automatisering och versionshantering: förklädda dygder
Det kanske låter konstigt, men det är under utveckling Lathet, när det förstås på rätt sätt, anses vara en professionell dygd.Idén är enkel: om något är repetitivt och manuellt, kommer någon smart att leta efter ett sätt att automatisera det så att de aldrig behöver göra det igen. Den "latheten" är det som driver skript, plugins, automatiserade åtgärder och makron som du sedan använder dagligen utan att veta var de kommer ifrån.
I seriösa projekt bygger den filosofin på ett annat viktigt element: versionshantering, med Git som den absoluta kungenTack vare Git kan team arbeta med samma projekt utan att trampa varandra på tårna, testa galna idéer i separata grenar, rulla tillbaka när något går sönder halva applikationen, eller se vem som rörde vad och när.
För en kreativ yrkesperson som samarbetar med utvecklare är det viktigt att förstå grunderna. Vad är en commit, en branch eller en merge? Det hjälper mycket: det låter dig spåra utvecklingsframsteg, övervaka när en förändring som påverkar din design introducerades och bättre koordinera när du ska låsa in nya funktioner och fokusera på att finslipa det som redan finns.
Dessutom gäller denna automatiseringskultur även uppgifter som till synes är mindre "tekniska": Distributionsskript, automatisk dokumentationsgenerering, tester som körs automatiskt varje natt, pipelines som konverterar resurser, komprimerar bilder eller genererar versioner för olika enheter utan mänsklig inblandning. Allt detta härrör från någon som vägrade att upprepa samma process för hand hundra gånger.
Kommentarer, tydliga namn och en besatthet av läsbar kod
Precis som en designfil med välnamngivna lager och organiserade grupper är oändligt uppskattad, Kod behöver ordning, kontext och bra taggar.Annars blir det en oframkomlig djungel, även för den som skrev den några veckor tidigare.
Bra programmerare lägger stor vikt vid två saker: betydelsefulla namn och kommentarer som ger verklig kontextAnropa en variabel userAge o totalCost Det säger mycket mer än x o tempOch att notera varför en viss algoritm har valts eller vilket trick som används är oändligt mycket mer användbart än att kommentera "// addera två tal".
I praktiken skapar detta ett slags internt "tekniskt manus" för projektet, som andra utvecklare kan läsa för att förstå det. programvarudesignbesluten bakom varje modulNär koden är välskriven är den bästa kommentaren ibland själva koden, vilket förklarar sig självt tack vare de väl valda namnen.
Den där besattheten av tydlighet passar väldigt bra in i begrepp som du kanske har hört talas om, som t.ex. Ren kod, refactoring eller "Don't Repeat Yourself"-regeln (DRY)All den filosofin pekar mot samma sak: att programvaran ska vara lätt att förstå, ändra, testa och utöka utan att allt går sönder.
Testning, TDD och varför det inte räcker med att "få det att fungera idag"
En annan mindre synlig men grundläggande aspekt av alla program du använder är testningsekosystemet bakomEnhetstester, integrationstester, automatiserade eller manuella tester finns just för att förhindra att en liten ändring som lägger till ett alternativ du begärt tyst förstör 20 andra delar av systemet.
Det finns metoder som TDD (Test Driven Development) där Först skrivs testerna, och sedan koden som gör att de blir godkända.Det verkar kontraintuitivt, men det tvingar utvecklaren att från början tänka på det önskade beteendet, edge-fallen och hur man verifierar att allt fortsätter att fungera korrekt över tid.
För kreativa team kan detta innebära något väldigt konkret: Att begära "bara den här lilla ändringen av knappen" eller "lägga till en ny effekt" har en verklig kostnad i form av testning och validering.Det är inte så att de inte vill hjälpa dig; det är så att alla modifieringar, hur små de än må verka för gränssnittet, kan ha biverkningar, och de måste se till att resten av applikationen inte går sönder.
Dessutom upprättar många företag testsviter som körs medan teamet sover eller på helgen: Koden kompileras, en uppsättning tester körs och resultaten granskas.Om något går fel upptäcks det långt innan det når slutanvändarna ... och det inkluderar de kreatörer som förlitar sig på dessa verktyg i produktionen.
Algoritmer, datastrukturer och hastighet: den osynliga motorn i dina verktyg
Bakom varje filsökning, varje filter som appliceras på en sekund, eller varje arbetsyta som förblir flytande även med tusentals lager, finns det något du inte ser: algoritmer och datastrukturer valda med ond avsiktAtt använda en lista, en stack, en kö eller en ordbok (hashmap) gör en enorm skillnad i prestanda.
T.ex. Om du behöver hitta saker snabbt är en ordbok mycket effektivare än en enkel lista.Detta gör att din redigerare kan hitta en stil, symbol eller resurs på millisekunder, även i ett stort projekt. Detsamma gäller hur pixlar, vektorer, 3D-nät eller ljudspår lagras.
När en kreativ app är långsam är det inte alltid datorns fel: Ibland ligger flaskhalsen i beslut om mjukvarudesign som fattades för flera år sedan.eller i snabba genvägar som togs "provisoriskt" och sedan stannade kvar för alltid, något som tyvärr är vanligt i många projekt.
Det är därför så många professionella rådgivningskolumner insisterar på Undvik för tidig optimering, men välj rätt algoritmer och strukturer från början.Denna solida grund möjliggör skalbarhet: fler lager, fler effekter, fler användare, fler enheter… utan att systemet kraschar.
Programmerarkultur: konstiga skämt, binärt språk och "det finns ingen sked"
Om du arbetar med utvecklare kommer du förr eller senare att höra saker som "Det finns 10 typer av människor: de som förstår binärt språk och de som inte gör det."Det är ett klassiskt skämt som spelar på det faktum att 10 i binärt tal är 2 i decimaltal. Den här typen av teknisk humor är en del av en hel subkultur: memes, subreddits, referenser till The Matrix, Star Wars, Starship Troopers…
Den berömda frasen "Det finns ingen sked" Matrisanalogin används ofta för att beskriva känslan av att se igenom gränssnittet och förstå hur en applikation är byggd under. När man vet hur man programmerar är det inte längre bara att titta på ett program eller en webbplats som konsumerar det: man börjar föreställa sig dess moduler, dess arkitektur, hur delarna kommunicerar, var något kan vara felaktigt.
Buggar diskuteras också som om de vore Starship Troopers-varelser: små till utseendet, men kapabla att orsaka en enorm röraDet delade språket skapar gemenskap; humor är ett sätt att hantera pressen av att ha enorma system som håller fast vid din kod.
För en kreativ yrkesperson gör kontakten med den kulturen relationen med programmerare smidigare: att förstå hans skämt, hans referenser och hans egenheter Det underlättar kommunikationen avsevärt när man diskuterar deadlines, tekniska begränsningar eller ändringar i sista minuten.
Hur programmerare (verkligen) lär sig och vad det betyder för dig
Ett annat intressant faktum är att även om det finns examina, bootcamps och masterprogram, Det mesta av det verkliga lärandet inom programmering sker genom att arbetaDet är mer som ett yrke än ett universitetsämne: man lär sig genom att göra, ha sönder saker, laga dem och upprepa cykeln om och om igen.
De flesta utvecklare är överens om en idé: Du behöver inte memorera alltDet finns officiell dokumentation, forum, artiklar, böcker som "97 saker varje programmerare borde veta" och massor av online-resurser, som till exempel Handledningar om programmeringsspråk på spanskaDet viktiga är att veta hur man söker, väljer och tillämpar den kunskapen på ett specifikt problem, precis som du inte kan alla Photoshop-genvägar utantill, men du vet var du ska leta när du behöver dem.
Dessutom rekommenderar nästan alla specialisering: Välj ett område (webb, mobil, backend, data, videospel…) och fördjupa dig Istället för att försöka täcka hela det tekniska landskapet. Samma logik kan inspirera dig: att verkligen förstå hur programvara fungerar i din kreativa nisch kommer att göra dig mycket kraftfullare än att veta lite om allt utan att behärska någonting.
Något som också upprepas i många interna undersökningar är vikten av mentorn och "parprogrammering": Programmera parvis, låt andra granska er kod, be om hjälp och ta emot kritik.Precis samma sak som när du delar en storyboard eller moodboard med någon annan och tar emot feedback för att förbättra stycket.
Verkligheten med utvecklingsarbete: ensamhet, koncentration och gigantiska hörlurar
Inomhus har ett mjukvaruteams vardag en hel del gemensamt med en kreativ studio: Många timmar framför skärmen, långa perioder av koncentration och en hatkärleksrelation med avbrott.Det är inte ovanligt att se halva teamet bära enorma brusreducerande hörlurar, nästan som om de vore obligatoriska arbetshjälmar.
Musik blir ett produktivitetsverktyg: Mjuka listor för arkitektoniskt tänkande, något kraftfullare för mekaniska uppgifter, total tystnad för felsökning av komplicerade buggarHörlurar är inte bara ett infall: de är en social signal om "avbryt mig inte nu, jag är i fokusläge", precis som vissa studior använder flaggor eller små fysiska signaler på bordet.
Det finns också en annan, mindre synlig sida: Att arbeta så mycket tid ensam framför en dator kan vara isolerandeMånga veteraner insisterar på att man inte ska låta sig behandlas som en robot och att det är viktigt att odla ett liv utanför kodningen: hobbyer, relationer, fysisk aktivitet, vila. Hjärnan som designar lösningar och den som designar gränssnitt är densamma, och den behöver utrymme.
Parallellt finns det något väldigt verkligt som kallas programmeringsberoendeNär man verkligen är inne på något är det lätt att spendera hela nätter "bara för att avsluta den här modulen" och glömma att äta, sova eller ens resa sig från stolen. Precis som med all kreativ passion måste man lära sig att sätta gränser för att undvika att bli utbränd.
Tankesätt, bedragarsyndrom och sund konkurrens
De flesta som börjar med programmering har en teknisk bakgrund, men Det betyder inte att någon med en "humanistisk" bakgrund inte kan omskolas.Det veteraner värdesätter mest är inte typen av gymnasieexamen, utan konsekvens, förmågan att lära sig och en viss bekvämlighet med logiskt tänkande.
Nästan alla i branschen lever med något ganska utbrett: bedragare syndromDen där känslan av "jag vet inte tillräckligt, jag kommer att bli ertappad, jag är inte uppgiftsmättad" kan dyka upp oavsett hur högskoleutbildad man är. Många använder den som motivation att fortsätta lära sig, så länge det inte leder till förlamande ångest.
Konkurrenskraft är också en del av landskapet, men i sin sunda form är det mer som "Rivalitet" bland kollegor för att se vem som optimerar en modul bäst eller vem som skriver den mest eleganta koden Det är inte som ett krig där man ska se vem som trampar på vem. Att ha en programmerare man beundrar som värdesätter ens arbete är väldigt likt att ha en annan kreativ person som beundrar ens illustration eller video.
I den här miljön är det avgörande att lära sig att acceptera feedback: När du får beröm, gå inte vilse; när du får kritik, ge inte upp.Sektorn förändras så snabbt att det alltid kommer att finnas teknologier man inte kontrollerar och personer som vet mer om något specifikt, och att leva med det är en del av spelet.
Den mest tidskrävande delen: felsökning, hantering av frustration och beslut om när man ska byta
Om man bara tittar på slutresultaten kanske man tror att utvecklarna lägger hela dagen på att skriva nya funktioner, men i verkligheten Mycket av tiden går åt till att felsöka fel och justera sådant som redan finns.Att gå vidare med ett projekt innebär ofta att låsa upp små buggar som hindrar resten av systemet från att utvecklas.
Detta orsakar betydande toppar i frustration: Problem som trotsar upptäckt, byggen som misslyckas utan uppenbar förklaring, kunder som kräver omöjliga deadlinesMånga yrkesverksamma säger att de har haft stunder då de velat lämna allt och byta sektor, särskilt när de arbetar med komplexa produkter.
Strategierna de rekommenderar låter bekanta: Uthållighet, självmotivation, en viss stolthet över ett väl utfört arbete och en ärlig passion för hantverketPrecis som i alla krävande kreativa discipliner är det den mixen som får dig att försöka igen när något inte fungerar och det som skiljer dem som håller sig på ytan från dem som blir verkligt bra.
En viss grad av personalomsättning är också vanligt: Bra kandidater får erbjudanden kontinuerligt.Många råd här pekar mot samma sak: leta efter en företagskultur som överensstämmer med dina värderingar och kom ihåg att du i en intervju också utvärderar företaget. Du kommer att spendera många timmar med att fundera över dess problem; att ha en god interpersonell matchning och gemensamma värderingar är viktigare än det kan verka på ditt CV.
Tekniska intervjuer, teamintegration och kommunikation
Inom utvecklingsgemenskapen är tekniska intervjuer ganska kända ... och har också ett ganska dåligt rykte. Många veteraner tror att De är överskattade, och att misslyckas med en säger inte mycket om din potential.De mäter vanligtvis en specifik uppsättning färdigheter under press, inte din faktiska förmåga att lära sig, samarbeta och framgångsrikt slutföra projekt på lång sikt.
Istället, Mjuka färdigheter gör ofta hela skillnaden: att veta hur man kommunicerar, ställa frågor när något inte förstås, integrera feedback, samarbeta med människor från olika bakgrunder (som du, om du är kreativ) och behålla lugnet i spända stunder.
När man börjar på ett företag är den främsta rekommendationen för alla juniorprogrammerare Var inte rädd för att ställa frågor, men gör det med eftertanke.Schemalägg specifika tider med en mentor för att ta itu med frågor, undvik att avbryta om det inte är brådskande och förbered dina frågor noggrant. Detsamma gäller när du går med i ett tekniskt team: ju tydligare och mer strukturerad din kommunikation är, desto bättre passar du in.
I miljöer där ingen mentor är tilldelad är den mest lämpliga åtgärden att att vinna förtroendet hos någon med erfarenhet och skapa en solid professionell relation med den personen. I slutändan är stora projekt lika mycket beroende av kodens och designens kvalitet som av kvaliteten på relationerna mellan dem som bygger dem.
I slutändan kommer magin med de verktyg du använder varje dag från en ganska mänsklig blandning: Människor som ständigt lär sig, blir frustrerade, tävlingsinriktade, samarbetar, skrattar åt konstiga binära skämt och gradvis förvandlar idéer till programvaraNär man, som kreatör, förstår dessa kuriositeter och arbetssätt är det mycket lättare att tala samma språk, fråga efter vad som faktiskt kan byggas och delta i den där nästan "magiska" processen att få en dator att göra exakt vad man föreställer sig.