- Programvareutvikling kombinerer logikk, kreativitet og samarbeid, langt fra stereotypen om den enslige programmereren.
- Mange myter om databehandling avlives når man ser mangfoldet av roller og tilgjengeligheten til å lære å programmere.
- Vanlige begreper som skadelig programvare, trojaner eller WordPress har svært spesifikke historiske og kulturelle opprinnelser.
- Utviklingen av AI, nettet og bedriftsprogramvare demonstrerer hvordan kode former hverdagen vår.
Programvare- og programmeringsverdenen er full av anekdoter, myter, merkelige begreper og små historier som sjelden fortelles, men som forklarer hvorfor vi bruker teknologi slik vi kjenner den i dag. Fra hvordan ordet «programvare» ble laget til hvorfor mange programmerere elsker terminalen og avskyr semikolon, er sannheten at bak hver kodelinje er det vanligvis mer enn bare ren logikk.
Videre har informatikk og programmering utviklet seg i et forrykende tempo: de har gått fra å være domenet til noen få eksperter i laboratorier til å bli grunnlaget for videospill, mobilapper, nettet, bedriftsprogramvare og til og med musikken vi strømmer. Å forstå noen interessante fakta om programvare og programmer er ikke bare morsomt; det hjelper oss også å se at denne verden ikke er så utilgjengelig eller kald som den ofte virker.
Informasjonskapsler, brukeropplevelse og hvordan et nettsted gjenkjenner deg
Når du besøker et nettsted og den typiske informasjonskapselmeldingen dukker opp, er det ikke bare en kjedelig formalitet: informasjonskapsler er små filer som nettstedet lagrer i nettleseren din for å huske hvem du er og hvordan du bruker nettstedet. Takket være dem kan nettstedet vite om du allerede er logget inn, hvilket språk du foretrekker eller hvilke seksjoner som er mest interessante for besøkende.
I praksis betyr dette at nettstedet kan «gjenkjenne» deg når du kommer tilbake , tilpasse bestemt innhold og samle inn anonyme data slik at teamet vet hvilke seksjoner som fungerer best og hvilke som sjelden besøkes. Disse funksjonene er viktige for å forbedre brukeropplevelsen, men de reiser også bekymringer om personvern og sporing på tvers av nettsteder.
Bak denne enkle juridiske merknaden ligger et helt system med nettleserlagring , øktadministrasjon, analyseverktøy og preferanseinnstillinger. Dette er alle programmer som kjører både på enheten din og på nettstedets servere, koordinert for å gjøre nettlesingen smidig og personlig.
Kunstig intelligens og endringen i måten programvare brukes på
Kunstig intelligens (KI) er sannsynligvis det raskest endrede programvarefeltet i disse dager. I løpet av få måneder dukker det opp nye språkmodeller (LLM-er), fantastiske verktøy og forskjellige måter å integrere dem i alle slags applikasjoner – fra virtuelle assistenter til anbefalingssystemer.
I årevis var den typiske interaksjonen med AI veldig enkel: spørsmål og svar . Du stilte en forespørsel til systemet, og det returnerte et generert resultat. Imidlertid er denne dynamikken nå i ferd med å bli utilstrekkelig. Multimodale grensesnitt dukker opp i økende grad, og kombinerer tekst, tale, bilder, video og til og med direkte handlinger på programmer eller enheter.
Dette betyr at AI ikke lenger bare er en «skjult komponent» av programvare , men en synlig del av brukeropplevelsen. Modeller som forstår konteksten til det du gjør, assistenter som foreslår endringer i koden mens du programmerer, og systemer som automatiserer oppgaver i bakgrunnen endrer måten applikasjoner designes på.
Samtidig betyr hastigheten AI utvikler seg med at mange verktøy virker revolusjonerende den ene dagen og utdaterte den neste . For programvareutviklere betyr dette kontinuerlig tilpasning av arbeidsflyter, læring av nye API-er og nytenkning av hvordan brukergrensesnitt utformes.
Lære å programmere: mye mer enn å skrive kode
Å begynne med programmering handler ikke bare om å lære et språk; det er nesten som å åpne en dør til et helt nytt mentalt univers . Blandingen av logikk, matematikk, ingeniørfag og kreativitet gjør at programmering føles både som å løse gåter og å bygge noe fra bunnen av med deler du finner opp selv.
Programmering er ganske likt det å lære et språk : det finnes vokabular (funksjoner, variabler), grammatiske regler (syntaks) og måter å uttrykke komplekse ideer på med relativt enkle strukturer. Forskjellen er at i stedet for å snakke med en person, kommuniserer du med maskiner og enheter, som følger instruksjonene dine til punkt og prikke.
Når du deltar på en bootcamp, tar en grad eller lærer på egenhånd, memorerer du ikke bare kommandoer; du trener logikken og problemløsningsevnen din . Du begynner å se mønstre i alt: hvordan en app er strukturert, hvordan lagene i et system er atskilt, hva som kan automatiseres ... og du oppdager også hvor fengslende det kan være å se noe du har skrevet bli levende.
Mange begynner med programmering og tror at man må være et matematisk geni. I virkeligheten er det viktigste holdning og konstant øvelse : å løse små utfordringer, gjøre feil tusen ganger, rette feil og fortsette å iterere. Etter hvert som man utvikler seg, får man den sterke følelsen av «hvis det kan uttrykkes logisk, kan jeg sannsynligvis programmere det».
Unix, Mac, Linux og den evige kontrasten med Windows
Innenfor utviklermiljøet finnes det en slags intern vits: for mange programmerere er Unix og dens etterfølgere (som Linux, macOS eller BSD) praktisk talt integrerte utviklingsmiljøer i seg selv. Faktisk sies det ofte at «Unix er et IDE», på grunn av antallet kraftige verktøy det inkluderer.
Mens Windows krever at du installerer og konfigurerer mange programmer separat, tilbyr Unix-baserte systemer terminaler, kompilatorer, pakkebehandlere og finjusterte verktøy for å automatisere oppgaver, overvåke prosesser og kjede kommandoer. Dette gjør dem spesielt praktiske for daglig utviklingsarbeid, og forklarer hvorfor mange søker å bruke Photoshop på Linux og native alternativer.
Programmerere verdsetter dette økosystemet fordi de kan tilpasse arbeidsflyten sin , og fordi de fleste verktøy med åpen kildekode opprinnelig ble utviklet for Unix. Selv om Windows har blitt betydelig forbedret i dag (med ting som WSL), er utviklingskulturen fortsatt tett knyttet til Linux og Unix-filosofien om å lage små, spesialiserte og kombinerbare programmer.
Alt dette betyr ikke at Windows er «ubrukelig», langt ifra; det er mye brukt i bedrifter og av sluttbrukere, men når det gjelder å skrive og distribuere programvare , gjøres mye av det kritiske arbeidet fortsatt i Unix-miljøer eller miljøer som er sterkt inspirert av dem.
Kompilering: når datamaskinen fungerer og du venter
I mange språk må et program gjennomgå en kompileringsprosess før det kan kjøres. Dette innebærer å oversette kildekoden til et format som maskinen kan forstå direkte. Språk som C eller C++ krever kompilering, og dette kan ta alt fra noen få sekunder til flere minutter eller mer, avhengig av prosjektets størrelse.
I løpet av den tiden kan datamaskinen bli så travel at programmereren i praksis benytter anledningen til å ta en improvisert pause . Derav den klassiske vitsen «Jeg jobber, den kompilerer», som mange har brukt som en unnskyldning for å stå opp for en kaffe mens fremdriftslinjen sakte går fremover.
Moderne webutvikling bruker språk og tolker som ikke krever den typen tung kompilering, men selv der finnes det byggeprosesser for å pakke kode, minimere filer eller generere optimaliserte versjoner som også kan være noe trege.
Til syvende og sist er kompilering en viktig del av utviklingssyklusen: den tjener til å oppdage feil, optimalisere ytelsen og sikre at koden blir riktig oversatt til maskinspråk . Selv om det noen ganger føles som en pause, er det en del av den daglige rutinen for mange team.
Kommandolinjen og muligheten til å snakke direkte til systemet
For nybegynnere kan kommandolinjen virke arkaisk, men når du først har blitt vant til den, blir den et avhengighetsskapende verktøy. Å jobbe i kommandolinjen betyr å samhandle med systemet ved å skrive instruksjoner, i stedet for å klikke på ikoner og knapper.
I hovedsak er bruk av terminalen en annen måte å programmere på: kommandoer kjedes sammen, skript (som de i Bash) brukes, og repeterende oppgaver automatiseres. Dette gir svært fin kontroll over systemet , slik at du kan gjøre ting på sekunder som ville vært trege eller nesten umulige med et tradisjonelt grafisk grensesnitt.
Mange utviklere føler at når de først har blitt vant til konsollen, blir musebaserte grensesnitt klumpete og begrensende . Det er i terminalen de installerer avhengigheter, distribuerer applikasjoner, administrerer prosesser eller kontrollerer eksterne servere.
Kommandolinjen er langt fra å være en levning fra fortiden, men er fortsatt kjernen i mange moderne verktøy, og det er en av grunnene til at det å lære Bash eller PowerShell kan gjøre en stor forskjell i enhver programmerers produktivitet.
Feil på grunn av punktum og komma, parenteser og hakeparenteser
Få ting er mer frustrerende enn å bruke timevis på å finpusse en kodeblokk, kjøre den og oppdage at den ikke fungerer på grunn av en liten detalj. I mange språk kan et manglende semikolon , en feil lukket parentes eller en hakeparentes plassert på feil sted føre til at alt går i stykker.
Disse syntaksfeilene er spesielt frustrerende fordi problemet ikke ligger i logikken, men snarere i et enkelt tegn som går tapt blant hundrevis av linjer . Kompilatoren eller tolken kaster vanligvis feilmeldinger, men ikke alltid på den nøyaktige plasseringen av feilen, noe som tvinger deg til å granske koden nøye.
Mange programmerere har kastet bort utallige timer på å lete etter denne forræderske figuren. Over tid har rammeverk, linterprogrammer og intelligente editorer hjulpet med å finne dem før programmet kjøres, men realiteten er at de fortsatt er en av de vanligste årsakene til mindre feil.
Denne konstante kampen mot syntaks lærer oss å verdsette gode utviklingsverktøy mye høyere, og oppmuntrer også til vanen med å skrive ren og godt innrykket kode , der det er vanskeligere for en manglende parentes å snike seg inn uten at noen legger merke til det.
Latskap som en dyd i utvikling
Innenfor programvarekulturen finnes det en merkelig idé: «produktiv latskap» er en positiv egenskap. Sitatet tilskrevet Bill Gates, om at han foretrekker en lat person til en vanskelig jobb fordi de vil finne den enkleste måten å gjøre det på, oppsummerer denne tilnærmingen ganske godt.
I programmering er det meningsløst å finne opp hjulet på nytt. Derfor finnes det åpen kildekode-prosjekter , biblioteker og rammeverk, som lar deg gjenbruke velprøvde løsninger. En god utvikler prøver ikke å bygge alt fra bunnen av; de ser etter eksisterende verktøy, evaluerer dem og programmerer bare det som er absolutt nødvendig.
Denne «latskapen» driver frem opprettelsen av enkel, gjenbrukbar og automatisert kode . Hvis en oppgave gjentas, er programmererens instinkt å skrive et skript eller verktøy som vil gjøre det for dem i fremtiden. Over tid sparer denne tankegangen innsats, reduserer feil og akselererer utviklingen.
På denne måten blir latskap omgjort til effektivitet: i stedet for å jobbe brutalt, er målet å jobbe mer intelligent , ved å stole på fellesskapet, eksisterende prosjekter og delte beste praksiser.
Kommentarer i koden: dokumentasjon og humoristiske detaljer
Kommentarer i kode er linjer som programmet ignorerer, men som mennesker bruker til å legge igjen notater, forklaringer eller advarsler. En velskrevet kommentar kan spare timer med arbeid for den som må vedlikeholde koden senere (ofte forfatteren selv måneder senere).
De tjener til å avklare komplekse beslutninger, forklare hvorfor en bestemt løsning ble valgt, eller advare om sensitive deler som ikke bør berøres uten først å forstå dem. I store systemer er kommentarer nesten som innebygd dokumentasjon som følger med koden etter hvert som den utvikler seg.
Samtidig bruker mange utviklere kommentarer til å snike inn interne vitser og nerdete referanser : fra meldinger som «Stopp; // Hammertime!» til notater som «// Magi. Ikke rør» eller «// full, fiks senere». Denne typen blunker har blitt en del av programmeringsfolkloren.
Den blandingen av alvor og humor gjenspeiler at kode ikke skrives av maskiner, men av mennesker, og at selv i svært komplekse prosjekter er det rom for å humanisere teknisk arbeid gjennom små vitser og skjulte budskap.
Koden som fungerer «som magi»
En av de vanligste opplevelsene blant programmerere er å støte på eldre kodeblokker som ingen forstår fullt ut, men som fungerer og ingen tør å røre ved. Det kan være en gammel modul, en kritisk integrasjon eller en patch som fikset en mystisk feil for mange år siden.
Over tid blir systemer skrevet, omskrevet og modifisert så mange ganger at det er normalt å ende opp med områder der logikken har floket seg . Noen ganger er den gjenværende koden et resultat av prøving og feiling, av desperate tester inntil noe sluttet å feile.
Mange team opererer med seksjoner mentalt merket som «ikke berør», fordi selv om ingen vet nøyaktig hvorfor de gjør det de gjør, er resultatet riktig. Det er en konstant påminnelse om at programvare i den virkelige verden er langt fra den teoretiske perfeksjonen som læres i bøker.
Denne situasjonen understreker også viktigheten av god dokumentasjon og automatiserte tester , som kan gi trygghet ved refaktorering uten frykt for å bryte atferd som inntil da virket nesten magisk.
«Bare endre én liten ting»: illusjonen av rask endring
Sett utenfra tror mange at det å legge til en funksjon eller endre et system handler om å «berøre to linjer». Men enhver programmerer vet at selv en tilsynelatende liten endring kan innebære å forstå avhengigheter, gjennomgå arkitektur, oppdatere databaser, tilpasse grensesnittet og teste alt.
Nesten alltid er funksjonaliteten som er synlig på overflaten bare toppen av isfjellet . Under den ligger forretningslogikk, valideringer, integrasjoner med andre tjenester og regler som ikke kan brytes uten å forårsake bivirkninger.
Derfor skaper uttrykket «gjør en rask endring» ofte en viss spenning: det indikerer manglende hensyn til systemets kompleksitet og tiden som trengs for å bekrefte at ingenting annet påvirkes. Selv små modifikasjoner bør gå gjennom testing og kodegjennomgangssykluser.
Å anta at programvare er skjør innvendig hjelper med å forstå hvorfor tidsfrister noen ganger forlenges, og hvorfor utviklere insisterer så mye på å planlegge godt og teste grundig før de ferdigstiller en ny versjon.
Å være programmerer: mellom logikk og magi
Å begynne å programmere er litt som å bli invitert til en magiskole . I starten virker alt overveldende: nye språk, merkelige konsepter, ukjente verktøy. Men litt etter litt ser du hvordan noen få kodelinjer får veldig spesifikke ting til å skje på en skjerm.
For mange er ideen om at noen kan bygge en tilpasset applikasjon, et spill eller et verktøy nesten uforståelig, så de har en tendens til å se programmerere som om de har spesielle krefter . Denne oppfatningen av «teknologitrollmannen» forsterkes når du viser dem noe du har laget, og de ikke aner hvordan det fungerer internt.
Med erfaring innser du at magi rett og slett er vel anvendt logikk og mange timer med øvelse . Følelsen av å kunne lage ting fra bunnen av er imidlertid fortsatt veldig reell, og det er en av grunnene til at så mange blir hekta på programmering.
I dagens samfunn er programvareutviklere i stor grad ansvarlige for verktøyene vi bruker daglig : fra bankapper til sosiale medier og forretningsstyringssystemer. Svært få ser koden, men vi lever alle med dens effekter.
Feil: små feil med store konsekvenser
De beryktede «feilene» eller programvarefeilene kan virke som små detaljer, men de har et enormt potensial til å forårsake problemer i verst tenkelige øyeblikk. Noen manifesterer seg som åpenbare feil, men mange forblir inaktive og forårsaker uvanlig oppførsel bare i svært spesifikke situasjoner.
En av grunnene til at de er så vanskelige å oppdage, er at de ikke alltid forårsaker at programmet krasjer. Noen ganger genererer de rett og slett feil eller inkonsistente resultater , som bare blir lagt merke til når noen legger merke til et tall som ikke summerer seg eller en handling som ikke burde vært tillatt.
Utviklere kan bruke uker på å jakte på en feil : reprodusere instanser, gjennomgå logger, legge til feilsøkingsspor, teste hypoteser og eliminere muligheter helt til de finner synderen. Det er ikke uvanlig at belønninger (ekte eller symbolske) tilbys til den som klarer å fange en spesielt unnvikende feil.
Dette grundige feilsøkingsarbeidet er en viktig del av den faglige utviklingen og forklarer hvorfor så mange prosjekter bruker en stor andel av tiden sin på å teste, fikse og forbedre i stedet for å skrive nye funksjoner.
Programmering som det ultimate logiske puslespillet
Hvis du liker gåter, vil du føle deg hjemme i programmering. Ethvert programvareproblem er i hovedsak et logisk gåte der du vet utgangspunktet (inndata) og hva du vil oppnå til slutt (utdata), men du må finne veien imellom.
I motsetning til spill som Sudoku, finnes det i programmering nesten ingen faste regler for hvordan man løser det : du kan dele problemet inn i moduler, bruke forskjellige algoritmer, endre tilnærmingen fullstendig ... og fortsatt komme frem til gyldige og effektive løsninger.
Dessuten finnes det sjelden ett riktig svar. Ulike programmerere kan komme frem til svært forskjellige implementeringer som fungerer like bra, hver med sine egne fordeler og ulemper når det gjelder ytelse, lesbarhet eller vedlikeholdbarhet.
Denne kombinasjonen av intellektuell utfordring og kreativ frihet gjør programmering svært avhengighetsskapende: det finnes alltid et litt vanskeligere problem, en litt mer elegant løsning eller en optimalisering som kunne gjorts bedre.
Geekhumor og programmerersubkultur
Over tid har utviklermiljøet skapt sin egen nerde-subkultur . Det finnes massevis av interne vitser, memer om feil, bygg, trendy rammeverk og selvfølgelig klassiske ordspill om binære og tallsystemer.
En av de mest kjente vitsene sier at «det finnes 10 typer mennesker i verden: de som forstår binært tall og de som ikke gjør det.» Trikset her er at «10» i binært tall betyr «2» i desimaltall, så det handler faktisk om to kategorier mennesker , men forkledd som binære tall.
Disse blunkene og nikkene dukker opp i forum, kodelager, Stack Overflow-tråder og subreddits dedikert til programmererhumor . De er en form for kameratskap blant de som deler de samme daglige kampene med kompilatorer, klienter og tidsfrister.
Den humoristiske sansen, ofte ironisk og noe sarkastisk, hjelper til med å takle komplekse dager, uforklarlige feil og endringer i krav i siste liten. Latter er i denne sammenhengen også en del av arbeidsverktøyene.
Se «matrisen»: forstå hvordan applikasjonene fungerer
Etter hvert som du får erfaring, blir du ikke lenger i stand til å bruke et program uten å lure på hvordan det er bygget opp internt . Det er som om du ser koden flyte bak grensesnittet, akkurat som i den berømte scenen med regnet av grønne figurer i The Matrix.
Når en programmerer støter på et nytt program eller nettsted, begynner de umiddelbart å forestille seg hvilke teknologier som har blitt brukt, hvordan tilstanden administreres, hvilken arkitektur som ligger bak den, eller hvordan visse design- og ytelsesdetaljer har blitt løst.
Dette «tekniske» perspektivet forvandler mange ting fra magi til designbeslutninger, kodelinjer og arkitektoniske mønstre . Det er en merkelig følelse: du mister noe av mystikken, men du får en enorm evne til å forstå og gjenskape løsninger.
Samtidig kan den dypere innsikten gjøre det vanskelig å nyte visse dårlig laget grensesnitt, fordi du ikke kan unngå å oppdage brukervennlighetsfeil, ytelsesfeil eller tvilsomme utviklingsbeslutninger.
Hvorfor tar det så lang tid før videospill kommer ut (og hvorfor er de så imponerende)?
Moderne videospill er sannsynligvis noen av de mest komplekse programmene som bygges i dag. Selv et enkelt spill inkluderer grafikk, lyd, spilllogikk, fysikk, nettverk, kunstig intelligens og synkronisering av flere komponenter.
Når det gjelder storskala titler med massive åpne verdener, flerspiller, filmsekvenser og hundrevis av mekanikker, skyter mengden arbeid bak kulissene i været. Det er derfor, selv om det utenfra kan virke som «bare» underholdning, teamene og tidsfristene er sammenlignbare med de i store programvareprosjekter for bedrifter.
De som programmerer forstår godt hvorfor et spill kan bli forsinket i måneder eller år : å stabilisere en så stor interaktiv opplevelse, polere feil, optimalisere for forskjellige plattformer og justere spillingen er en enorm oppgave.
Å vite at hver eneste detalj som er synlig på skjermen, fra animasjonen av en karakter til oppførselen til en meny, har måttet programmeres, testes og gjennomgås, gjør at videospill virker som tekniske og kreative milepæler snarere enn bare underholdningsprodukter.
Følelsen av å kunne lage hva som helst med kode
En av de kraftigste effektene av å lære å programmere er fremveksten av en konstant følelse av muligheter . Hvert nytt verktøy eller språk du mestrer åpner døren til en annen type prosjekt: en mobilapp, en bot, et automatiseringssystem, et enkelt spill ...
Mange programmerere samler sideprosjekter i arkiver som GitHub: halvferdige ideer, eksperimenter, små verktøy til eget bruk. Hvert og ett av dem stammer fra vissheten om at hvis noe ikke eksisterer, kan de kanskje bygge det selv.
Noen ganger er de verktøy for å løse hverdagsproblemer, andre ganger er de kreative ideer de rett og slett hadde lyst til å prøve. Uansett er denne drivkraften til stadig å skape en del av utviklingskulturen og er en av grunnene til at teknologien utvikler seg så raskt.
Over tid blir den følelsen av «jeg kan gjøre nesten hva som helst med riktig kode» en veldig sterk motivasjon til å fortsette å lære og forbedre seg, selv utenom jobb eller skoletid.
Hva en dataforsker og en programvareingeniør egentlig gjør
Det er en utbredt myte om at alle som studerer informatikk er programmerere . I virkeligheten omfatter informatikk et bredt spekter av områder: systemadministrasjon, nettverk, databaser, systemanalyse, prosjektledelse, sikkerhet, teknisk støtte ... og programvareutvikling er bare ett av dem.
Noen kan jobbe profesjonelt innen IT, med fokus på infrastruktur, servere eller nettverk, uten å skrive mye kode daglig. På samme måte kan en programvareingeniør ha en dyp forståelse av logikk, designmønstre og arkitektur, men ikke være ekspert på å konfigurere rutere eller vedlikeholde en server.
Programvareingeniører spesialiserer seg vanligvis på å løse problemer gjennom programmer , noe som krever at de mestrer svært spesifikke konsepter: datastrukturer, algoritmer, beste praksis, testing, API-design osv. Det gir ingen mening å forvente at de også skal være avanserte systemadministratorer hvis det ikke er deres ekspertiseområde.
Å forstå dette mangfoldet innen informatikk bidrar til å bryte ned stereotypen om at «hvis du jobber med systemer, vet du hvordan du gjør alt» og fremhever den tekniske spesialiseringen til hver rolle innen teknologisektoren.
Er programmering så komplisert som det ser ut til?
En annen vanlig myte er at programmering er ekstremt vanskelig og bare egnet for begavede personer. Realiteten er at det å lære å programmere krever innsats, øvelse og tålmodighet, men det er ikke et magisk talent som er forbeholdt noen få utvalgte.
I de senere årene har det dukket opp språk og verktøy som gjør det mer tilgjengelig å komme inn i kodeverdenen: Python, JavaScript, Kotlin , eller til og med No Code- og Low Code-plattformer lar deg bygge nyttige ting med en rimelig læringskurve.
Som enhver profesjonell ferdighet har programmering sine kompleksiteter, men det drar også stor nytte av samarbeid og fellesskap . Forum, veiledninger, dokumentasjon og åpen kildekode-prosjekter gjør det enklere å finne løsninger på problemer som tidligere virket umulige å løse alene.
Til syvende og sist er det ikke så mye medfødt talent som utgjør forskjellen, men mer konsistens, holdning og øvelse . De som bruker tid på å løse utfordringer, lese god kode og bygge prosjekter, utvikler etter hvert flyt i språket, akkurat som noen som lærer et nytt språk gjennom bruk og eksponering.
Er programmererens liv ensomt?
Filmer og TV-serier har forsterket bildet av programmereren som en isolert person, alltid i mørket foran flere skjermer. I det virkelige liv jobber de fleste programvareingeniører i tverrfaglige team og bruker mye tid på å snakke med andre mennesker.
Å bygge nyttige applikasjoner krever forståelse av kundenes eller brukernes behov , og koordinering med designere, testere, forretningsinteressenter og andre utviklere. Viktige tekniske beslutninger diskuteres kollektivt og involverer ofte omfattende kommunikasjon.
Videre er programvaresektoren avhengig av svært aktive fellesskap: møter, konferanser, samarbeidende databaser og fora der kunnskap deles og spørsmål besvares. Langt fra å være et ensomt miljø, er det et svært sosialt økosystem.
I det daglige krever det å skrive god kode også myke ferdigheter: tydelig kommunikasjon, samarbeidstenkning og empati for å forstå hvordan arbeidet ditt vil påvirke andre teammedlemmer eller sluttbrukere. Faktisk er det nesten umulig å gjøre denne jobben uten å stadig samhandle med andre mennesker.
Interessante fakta om utviklingen av bedriftsprogramvare
Når vi tenker på programvare, tenker vi vanligvis på forbrukerapper, men programvare for bedriftsadministrasjon har også sin egen fascinerende historie. Fra de første løsningene som kjører på store stormaskiner til dagens skybaserte systemer, har utviklingen vært enorm.
Mange selskaper startet med å bruke banebrytende, spesialbygde programmer , som over tid ble referanseprodukter innen sektorer som regnskap, logistikk og personaladministrasjon. Hver nye generasjon verktøy har lagt til muligheter: mer omfattende rapporter, prosessautomatisering og integrasjon med andre plattformer.
Bak disse systemene ligger historier om viktige tekniske beslutninger, komplekse migreringer og fascinerende detaljer om hvordan visse moduler ble de facto standarder i et marked. Fremveksten av Software as a Service (SaaS) endret alt fullstendig, og muliggjorde konstante oppdateringer uten lokale installasjoner.
Å utforske utviklingen av disse løsningene er en fin måte å forstå hvordan bedrifter har gått fra å administrere prosessene sine med bunker med papir til å gjøre det med tilkoblede applikasjoner og sanntidsdata , bygd på flere tiår med stille innovasjon.
12 interessante fakta om programvareuttrykk
Over tid har det dukket opp ord og uttrykk som vi nå tar for gitt, men som har en ganske merkelig opprinnelse . Her er et dusin eksempler relatert til databehandling og programvare som bidrar til å bedre forstå dette unike språket.
8-bit og pikselkunstestetikken: De såkalte «8-bit»-videospillene ble ikke oppkalt etter nostalgi, men på grunn av ordbredden prosessorene deres kunne håndtere: 8 biter. Konsoller som NES hadde denne begrensningen, som begrenset antall farger, oppløsningen og kompleksiteten til lyden, men til gjengjeld ga det opphav til den ikoniske pikselkunstestetikken som fortsatt inspirerer mange skapere i dag.
Spotify og et nesten tilfeldig navn: Musikkstrømmetjenesten Spotify ble født i Sverige i 2006 som en lovlig respons på massiv piratkopiering av musikk . Navnet, som historien forteller, kom fra et feilhørt ord under en idédugnad; det ble deretter tolket på nytt som en kombinasjon av «spot» (å finne) og «identifisere», noe som ga det en mer elegant betydning.
Rootkit, superbrukerpakken: En rootkit er et sett med verktøy som er utformet for å få og skjule administratortilgang (root) på et system. Begrepet dukket opp på 90-tallet, inspirert av de legitime programvare-"kittene" som administratorer brukte til å administrere systemer, men som ble tilpasset av angripere for å skjule sin tilstedeværelse.
Trojansk hest og den digitale trojaneren: Innen datasikkerhet er en trojansk hest et program som utgir seg for å være legitim programvare for å lure brukeren og infiltrere datamaskinen deres. Navnet kommer direkte fra den trojanske hesten fra gresk mytologi , som skjulte soldater inne for å erobre byen innenfra.
WordPress og webdomenet: WordPress startet i 2003 som en forbedring av et annet bloggsystem kalt b2/cafelog. Det som startet som en enkel plattform for personlige dagbøker endte opp med å bli et av de mest vellykkede åpen kildekode-prosjektene i historien, til det punktet at det i dag anslås at mer enn 40 % av alle nettsteder er bygget med det.
Skadelig programvare, paraplybetegnelsen for skadelig programvare: Ordet skadelig programvare kommer fra «skadelig programvare», som betyr programvare som er utviklet for skadelige formål . Dette begrepet omfatter virus, trojanere, spionprogrammer, løsepengevirus og mange andre typer ondsinnede programmer. Selv om virus har eksistert siden 70-tallet, ble ikke begrepet «skadelig programvare» utbredt før på 90-tallet.
Second Life og den virtuelle økonomien: Second Life ble lansert i 2003 og er ikke et klassisk videospill: det mangler definerte mål og lineære oppdrag. Det er en vedvarende virtuell verden der brukere lager, kjøper og selger digitale varer og sosialiserer. På sitt meste flyttet den interne økonomien hundrevis av millioner av ekte dollar.
Opphavsrett og smittsom frihet: Begrepet opphavsrett ble foreslått som et alternativ til tradisjonell opphavsrett. Under opphavsrettslisenser er det mulig å kopiere, endre og redistribuere et verk, forutsatt at avledede verk opprettholder den samme friheten. Ideen ble popularisert spesielt takket være Richard Stallman og fri programvarebevegelsen.
HTML5 og den offisielle logoen: I 2011 introduserte W3C en offisiell logo for HTML5 i form av et stilisert skjold . Hensikten var å formidle robusthet og modernitet, og forsterke budskapet om at HTML5 var klar for komplekse webapplikasjoner, og til og med i stand til å erstatte mange tradisjonelle skrivebordsapplikasjoner.
ICQ og ordspillet «I Seek You»: ICQ var et av de første populære direktemeldingsprogrammene på 90-tallet. Navnet uttales som «I seek you», noe som understreker hovedfunksjonen: å finne og kontakte folk fra hvor som helst i verden, lenge før WhatsApp eller Messenger eksisterte.
HTTP, nettets postmann: HTTP står for Hypertext Transfer Protocol og ble laget av Tim Berners-Lee sammen med World Wide Web på slutten av 80-tallet. Denne protokollen fungerer som en budbringer mellom nettleseren din og serverne , ber om sider og returnerer svar. Senere dukket HTTPS, den krypterte versjonen, opp for å beskytte informasjon under overføring.
Opprinnelsen til ordet programvare: Frem til slutten av 50-tallet var programmer ganske enkelt kjent som «kode» eller «instruksjoner». Statistikeren John Tukey skapte begrepet «programvare» i 1958 for å skille programmer (den myke delen) fra maskinvaren (den fysiske delen) av datamaskiner. Siden den gang har ordet blitt essensielt i enhver teknologisk diskusjon.
Å se på disse små historiene bak konseptene vi bruker daglig hjelper oss å se programvareverdenen som noe levende, fullt av menneskelige ideer, beslutninger og anekdoter , og ikke bare som et sett med abstrakte begreper.
Samlet sett viser alle disse interessante faktaene om programvare og programmer at bak hver app, hvert språk, hver lisens eller hvert verktøy finnes det en blanding av historie, humor, prøving og feiling, samarbeid og mye teknisk kreativitet. Å forstå dem lar oss nyte teknologi mer, miste frykten for programmering og sette pris på det usynlige arbeidet til millioner av mennesker som, linje for linje, har bygget det digitale universet vi beveger oss i hver dag.
