Øker utviklingen av programvare IQ?

Ja, programmeringsprogramvare kan delvis øke IQ, siden det direkte fordeler den logisk-matematiske og kreative intelligensen, som evalueres i IQ-testene.

Det er imidlertid viktig å huske på at utvikling av programvare vil favorisere våre kognitive evner så lenge de fostres i et miljø av god praksis og kontinuerlig læring.

• 1.- God praksis for programvareutvikling som påvirker tankegangen din
• 1.1.- Enkelhet
• 1.1.1.- Hvorfor krasjer datamaskiner så kontinuerlig?
• 1.1.2.- Hva er en dårlig programmerer?
• 1.1.3.- Hvordan bli en god programmerer?
• 1.1.4.- Er det vanskeligere å programmere på en forenklet måte?
• 1.2.- Tester
• 1.2.1.- Datamaskinfeil oppstod på grunn av fravær eller feil bruk av programvaretester
• 1.2.1.1.- Missildetektor radarfeil
• 1.2.1.2.- Ødeleggelse av Mariner I
• 1.2.1.3.- Therac-25, strålebehandling lineær akselerator
• 1.2.1.4.- Ship Yorktown (CG-48) og divisjonen med null
• 1.2.1.5.- Intel Pentium -prosessor med delingsfeil
• 1.2.2.- Eksempel på programvare som er nærmere perfeksjon
• 1.2.3.- Hva er det nåværende landskapet med programvaretesting?
• 1.2.3.1.- Programvaretestfeil og inkonsekvenser i dag
• 1.2.3.2.- Formell utvikling som en foreslått løsning på inkonsekvent programvaretesting
• 2.- Hvordan gagner kontinuerlig læring hjernen vår?
• 2.1.- Intelligens er basert på nevral effektivitet - Erhan Genç
• 2.2.- Hvordan påvirker programmering våre mentale evner?
• 2.2.1.- Verktøyene vi bruker til å programmere påvirker våre mentale modeller
• 2.2.1.1.- Hvorfor er IT -sektoren en av de mest anbefalte i 2021?
• 2.2.2.- Det er sunt for hjernen
• 2.2.3.- Mens du programmerer, stimulerer du opptil 5 områder av hjernen din.

God praksis for programvareutvikling som påvirker tankegangen din

Når vi allerede har litt erfaring med å utvikle programvareprosjekter, vi har allerede bygget en mental modell for hva et ideelt programvareprosjekt kan være. Men, hvilken vei å gå for å utvikle et programvareprosjekt riktig?

Det kan virke lite komplisert, for i dag kan vi finne rikelig informasjon på internett om metoder for utvikling av prosjekter, for eksempel SCRUM eller Extreme Programming. Begge gir oss retningslinjer som vi må følge under utviklingssyklusen til et prosjekt, for å garantere organisering, observasjon, tidsestimering og / eller teamarbeid.

Fra vårt synspunkt:

Å bli organisert (for å være svært produktiv) kan være mye vanskeligere enn å lære å programmere (for de som nettopp har startet), eller behersker en ny teknologi, siden det veldig vanskelige er å utvikle prosjekter i et strukturert, presis og fremfor alt, enkel måte å lese på.

Albert Einstein sa en gang:

Hvis du ikke kan forklare det enkelt, forstår du det ikke godt nok. Albert Einstein

Dette gjelder ethvert læringsområde, for eksempel spesielt innen programvareutvikling, hvis vi ikke er i stand til å forenkle koden vår og organisere den på en slik måte at en tredjepart kan forstå prosjektet vårt, vi gjør det ikke bra.

På denne måten må vi oppnå gjennom praksis forme vår måte å tenke og gjøre ting på. I tillegg må du ta hensyn til retningslinjer og retningslinjer gitt av forskjellige rammer, metoder og / eller anbefalinger fra eksperter som brukes på prosjektene våre. Imidlertid er det verken tilrådelig eller effektivt å følge slike retningslinjer til punkt og prikke, siden vi må være fleksible og ikke strenge.

Deretter vil jeg beskrive 2 god programvareutviklingspraksis som du må ta hensyn til når du gjennomfører prosjektene dine, og som jeg er sikker på vil ende opp med å endre tankegangen din.

Enkelhet

Gjør koden så enkel som mulig!

Det er ingen nyhet å si det et av de største problemene innen databehandling er kompleksitet. Derfor, enkelhet er kanskje den viktigste og verdsatte kvaliteten i programvareverdenen.

Over tid har datamaskiner blitt uunnværlige i våre liv, og har forårsaket en veldig viktig endring i samfunnet. Kort sagt, datamaskiner er nyttige fordi de lar oss gjøre mer med mindre, det vil si å gjøre mange oppgaver ved å bruke mindre menneskelige ressurser.

La oss forestille oss at en person ønsker å utføre alle operasjonene som en datamaskin utfører i løpet av et år. Sannsynligvis vil det ta årene han har igjen av livet, og det er at den virkelige verdien til en datamaskin er hastigheten og nøyaktigheten. Og det er flott!

Imidlertid kan det ikke være så perfekt, fordi datamaskiner har en stor feil: de har alltid feil. Kanskje har vi ennå ikke vært klar over hvor mange ganger de vanligvis har en programvarefeil. Hvis noe som brukes ofte var like feil som en datamaskin, er jeg sikker på at vi hadde blitt kvitt det nå.

De fleste, om ikke alle, av de jeg kjenner opplever minst 1 skade per uke, om ikke mer. Jeg kan si at jeg minst en gang i uken har opplevd en eller annen feil, eller at jeg har funnet ut at en venn eller kollega har gått gjennom det samme, det i omtrent 10 år.

Hvis vi teller, er det 480 forskjellige former for sammenbrudd bare etter min erfaring. Og det er ikke kult.

Hvorfor krasjer datamaskiner så kontinuerlig?

Når det gjelder programvare, er det bare en grunn: dårlige programmerere.

For ca 5 år siden hadde jeg en mistanke om at årsaken var dårlige programmerere; Imidlertid var jeg ikke veldig sikker. Nå, med noen få års erfaring innen IT -feltet og etter å ha konsultert mange eksperter gjennom publikasjonene, har jeg ikke lenger tvil.

Jeg kan fullt ut si at dårlige programmerere er skyld i utallige datafeil.

Hva er en dårlig programmerer?

Det virker litt urettferdig å skylde på programmerere, enda mer når de aller fleste mennesker jeg kjenner som er dedikert til programvareutvikling på høyt nivå er fagfolk som har ganske utviklet logisk tenkning.

Hvis de aller fleste programmerere er ganske logiske mennesker, hvorfor er det programvare med så mange feil? Hovedårsaken til datamaskinfeil er KOMPLEKSITET.

Å bygge en datamaskin er sannsynligvis den mest komplekse prosessen jeg vet om, for for hvert sekund som går, millioner av oppgaver kan utføres. I tillegg har den tusenvis av deler som må fungere synkronisert. Operativsystemet som en datamaskin bruker alene består av titalls millioner linjer med kode. Bare Windows 10 har mer enn 4 millioner filer og mer enn en halv million mapper. Bevis på dette er følgende fangst:

For å gi deg en enda mer komplett idé, beskriver jeg nedenfor antall linjer med kode per operativsystem:

Operativsystem	Kodelinjer
Linux 3.1 Kernel	15 millioner
Windows XP	40 millioner
Windows 7	40 millioner
Windows Vista	50 millioner
Debian 5.0 (grunnkode)	67 millioner
Mac OS X «Lion»	85 millioner

Jeg gir deg ytterligere informasjon:

Facebook har omtrent 61 millioner kodelinjer og Google har rundt 2 milliarder kodelinjer. Selvfølgelig begrunner det store antallet tjenester som tilbys av Google det.

Programvaren som en datamaskin fungerer på er så kompleks at sannsynligvis ingen vil kunne forstå koden i sin helhet.

Derfor må programmering eksistere i et miljø der den søker å redusere kompleksiteten og dermed oppnå enkelhet. På denne måten sikrer vi at enhver programmerer uten ekstraordinære talenter har muligheten til å fortsette å jobbe med en applikasjon. Ellers kan koden nå et så høyt kompleksitetsnivå at det vil være nesten umulig å jobbe med den.

Kort sagt, det er det programmering handler om: "Reduser kompleksiteten til enkelhet."

Hvordan bli en god programmerer?

En god programmerer lager ting som er enkle å forstå, vedlikeholde og lett å finne feil. Men ikke forveksle enkelhet med færre kodelinjer eller ikke lenger bruke moderne teknologi. Noen ganger kan forenkling av koden øke kodelinjene, bare sørg for å alltid dokumentere den.

Generelt har mer avanserte eller moderne teknologier en tendens til å være enkle. Du må bare lære å bruke dem riktig, noe som ofte er en utfordring.

Er det vanskeligere å programmere på en forenklet måte?

Generelt tror vi at programmering på en forenklet måte vil ta oss mer tid enn å gjøre det raskt. For eksempel, når vi må utføre noen oppgaver i arbeidet vårt, prøver vi generelt å gjøre det raskt, uten å stoppe for å tenke og planlegge. Vi kunne ikke tatt mer feil!

Det er mer effektivt å bruke mer tid på å tenke på problemet på jakt etter maksimal forståelse og på denne måten kunne foreslå en forenklet løsning, enn å begynne å skrive en løsning raskt og deretter stoppe innser at implementeringen ble unødvendig kompleks.

Du må bare se deg rundt og innse det store problemet som KOMPLEKSITET har blitt til i programmer.

Det er mange applikasjoner som har blitt stillestående når de prøver å legge til ny funksjonalitet til det fryktelige, stort og komplekst monster av kode som de har blitt.

Hvis du vil vite mer om grunnleggende og måter for forenklet programmering, anbefaler jeg å lese følgende bok. Jeg elsket det!

Tester

Kjør alltid tester. De er ikke valgfrie!

I virkeligheten burde de aldri ha vært et alternativ, men mange programmerere utvikler fortsatt applikasjoner uten å bruke noen form for programvaretesting, siden kodefeil rapporteres av sluttkunden. Dette er vanligvis tilfelle for den gjennomsnittlige frilanser.

Å programmere uten testing er som å kjøre uten bilbelte eller å gjøre trapesestunt uten sikkerhetsnett. For tiden gjenstår god praksis med å alltid teste programvare.

La oss se på noen antecedenter som oppstod på grunn av fravær eller feil bruk av programvaretester som har forårsaket millioner av dollar i økonomiske tap og i noen tilfeller har kostet livet til dusinvis av mennesker.

Datamaskinfeil oppstod på grunn av fravær eller feil bruk av programvaretester

Jeg er sikker på at hendelsene nevnt nedenfor vil få deg til å reflektere og gi programvare testing mye mer vekt.

Missildetektor radarfeil.

Det skjedde i 1983 da Sovjetunionens varslingssystem for missildeteksjon rapporterte at USA hadde skutt opp 5 missiler og de var i gang.

Heldigvis beordret ikke den ansvarlige ved intuisjon og / eller kriterier et umiddelbart angrep som svar, siden de anså angrepet som merkelig fordi det var ute av kontekst og også på grunn av antall missiler, siden de ikke var de som vanligvis ble brukt til et overraskelsesangrep.

Timer senere ble det bekreftet at alt var forårsaket av en missilradarsystemfeil. En feil som var litt vanskelig å oppdage den gangen, da systemet forvirret refleksjonen av solen i skyene i en bestemt posisjon med missiler. For litt og ender opp med å starte den tredje verdenskrig. Det kan imidlertid ha blitt unngått etter å ha gjort en grundig jobb med:

• Studie av miljøet som varslingssystemet skulle distribueres på
, og
• injeksjonen av alle typer inputvariabler som kan påvirke systemet.

Begge er praksis som er en del av programvaretesting.

Ødeleggelse av Mariner I

Forekommer i 1962 og forårsaker tap på omtrent 18,5 millioner dollar, Mariner I var det første oppdraget i Mariner -programmet for å prøve å fly over Venus, dessverre uten å lykkes.

293 sekunder etter avgang, a programvarefeil ble funnet. Denne feilen avledet sin bane. Sekunder senere måtte det sendes en kommando for å ødelegge den, og dermed forhindre at fallet forårsaket ytterligere skade.

Feilen ble senere bestemt: En formel i koden som ble programmert feil.

Therac-25, strålebehandling lineær akselerator

Du vil spørre deg selv, hva er en lineær akselerator for strålebehandling? Lineære akseleratorer er maskiner som avgir røntgenstråler rettet mot en svulst fra forskjellige vinkler. Det flotte er at disse enhetene er i stand til å tilpasse røntgenstrålene for å passe til svulstens form uten å påvirke området rundt.

Mellom juni 1985 og januar 1987 ble Therac-25 produsert av AECL (Atomic Energy of Canada Limited) var deltaker i minst 6 ulykker og 3 dødsfall etter å ha mottatt en overdose av stråling.

Etter undersøkelsene ble det konkludert med at hovedårsakene til Therac-25-ulykkene var som følger:

• Dårlig praksis for programvareutvikling.
• Dårlig kravanalyse.
• Dårlig programvaredesign.

Og hvis det ikke var nok, ble programvaren som Therac-25 kjørte på utviklet på en måte der det var nesten umulig å identifisere og fikser feil eller feil automatisk.

Andre årsaker funnet:

• AECL sendte aldri en uavhengig enhet for å gjennomgå kildekoden.
• Ingen funksjonalitet knyttet til risikostyring ble vurdert i designet.
• Systemet tillot ikke å kontrollere at sensorene fungerer som de skal.
• Det var flaggvariabler som endret verdien i stedet for å holde konstante verdier.
• Variabel "class3" overløp.
• Blant andre.

Ship Yorktown (CG-48) og divisjonen med null

Tro det eller ei, Yorktown Ship, et krigsskip som vant utallige priser for sin fremragende kamp og spesielt for sitt teknologiske utstyr, endte med å bli tauet på grunn av en programvarefeil.

I september 1997 angav et besetningsmedlem et nullpunkt i et databasefelt som fikk systemet til å utføre en divisjon med null internt, som forårsaket feil, til slutt genererte et bufferoverløp og til slutt en feil i skipets fremdriftssystem.

Intel Pentium -prosessor med delingsfeil

I 1993 ga Intel ut en ny prosessor med feilberegninger. Selv om de var veldig vanskelige å legge merke til, for for å kunne se feilen måtte du utføre operasjoner som krever et ganske eksakt resultat.

Til tross for dette hadde Intel et tap på omtrent 350 millioner dollar, uten å telle skaden på bildet som knapt kunne kvantifiseres.

De 5 sakene som jeg nettopp nevnte for deg, er bare noen av de utallige datafeilene som dessverre har koste menneskeliv og er et tydelig bevis på behovet for å skrive riktig programvare.

Programvareingeniører, så vel som konstruksjonsingeniører eller sivilingeniører, bør kunne demonstrere med en metode, påliteligheten og oppfyllelsen av nødvendige funksjoner.

Som du kanskje har lagt merke til, er testing en grunnleggende del av ethvert prosjekt. De er ikke valgfrie!

I følge Ilene Burnstein i boken hennes: “Praktisk programvaretesting”, programvaretesting har 3 hovedprosesser:

• Test case utvikling
• Gjennomføring av prøvesaker
• Analyse av resultater

Hvis du ikke tar deg tid til å bygge testcases, gjør du det ikke riktig. Det er viktig å bygge testcases med ulike scenarier som simulerer så mange saker som mulig. Til vår uflaks er det umulig å simulere 100% av scenariene.

Godt sagt Edsger Dijkstra:

Testen kan vise tilstedeværelsen av feil i et program, men ikke deres fravær Edsger Dijkstra (Turing -prisen i 1972)

Men akkurat som det er mange tilfeller av datafeil forårsaket av feil testutførelse, er det også suksesshistorier som er verdig en premie.

Eksempel på programvare som er nærmere perfeksjon

I dag er det mulig å utvikle så pålitelig programvare som alle andre produkter, enda mer med økningen i automatiseringskapasiteten.

Linje 14 i Paris metro er helautomatisk. Togene er førerløse og drives av programvare. Denne toglinjen ble satt i drift i 1998.

Selv om det er sant, kan dets perfeksjon ikke garanteres, dusinvis av år har gått og ingen feil er oppdaget, takket være uttømmende testarbeid, som endte med å utføre rundt 86 tusen instruksjoner i testprosessen.

Generelt kreves strenge testprosesser som kan garantere feilfri programvare i noen land bare for systemer som kan forårsake menneskelige tap.

De aller fleste programvareselskaper nekter å implementere slike strenge testprosesser på grunn av de høye kostnadene at dette innebærer og også fordi det er vanskelig å finne fagfolk dedikert til testing med tilstrekkelig opplæring og erfaring for en slik oppgave, siden implementeringen av programvaretestprosessene kan koste det samme eller mer enn utviklingen av selve programvaren.

Selvfølgelig, "Du lærer ikke før din tur", slik tilfellet er med INTEL, som måtte tape rundt 350 millioner dollar på grunn av en beregningsfeil i prosessorprogramvaren. Feil som førte til at det ble et av IT -selskapene med det høyeste budsjettet for forskning på programvaretesting.

Hva er det nåværende landskapet med programvaretesting?

Veien til å utvikle et programvareprosjekt består av tre veldefinerte stadier:

• Spesifikasjoner
• Design og koding
• Valideringer

I valideringstrinnet sørger ansvarlige ingeniører for at programvaren overholder det som er planlagt i spesifikasjonene, måten de gjør det på er ved å "teste".

Når programvaren er validert, antas det at den oppfyller alle spesifikasjonene og valideringssyklusen gjentas for siste gang for å bekrefte korrekt validering.

Det som er beskrevet ovenfor har et stort problem med inkonsekvens, jeg skal forklare det for deg nedenfor:

Programvaretestfeil og inkonsekvenser i dag

Det viktigste problemet med den nåværende valideringsmetoden "testing" er at den ikke sikrer at programvaren overholder det som er angitt i spesifikasjonene. Dette er fordi utformingen av spesifikasjonene er gjort på naturlig språk, med termer som alltid vil ha en individuell tolkning, som genererer uklarheter som sikkert vil bli lagt merke til på slutten av prosjektet.

Et annet problem er det du får aldri testet alle mulige saker. Anta at vi har en liten programvare som:

• mottar et hvilket som helst tall som inndata,
• legg til 10 og
• returnerer verdien av summen som et resultat.

Det ville være umulig å teste alle mulige tilfeller siden inndataene er uendelige. Derfor kjøres programvaretestene bare på et utvalg utvalgte saker, som noen ganger er veldig små prøver. Årsaken til disse dårlige praksisene er begrunnet av økonomiske og tidsmessige begrensninger. Avslutningsvis kan vi ikke si at en programvare er riktig etter å ha fullført testfasen, ettersom det ikke er tilstrekkelig bevis for et slikt krav.

Hvis vi prøver å være logiske (som vi burde være hvis vi er dedikert til databehandling), ved å bekrefte at en programvare er riktig etter at vi har fullført testfasen og ikke har funnet noen feil, pådrar vi oss det som kalles: “Kall til uvitenhet feil”.

I logikken er et argument ad ignorantiam, eller argumentum ad ignorantiam, også kjent som et kall til uvitenhet, er en feil som består i å opprettholde sannheten (eller falskheten) i et forslag som hevder at det ikke er bevis for det motsatte, eller påstå at en motstander ikke er i stand til eller nektet å presentere overbevisende bevis for det motsatte. Denne utålmodigheten med tvetydighet blir ofte kritisert med uttrykket: "fravær av bevis er ikke bevis på fravær", det vil si at denne feilen er begått når sannheten eller usannheten i et forslag blir antatt basert på den eksisterende uvitenheten om det. Kall til uvitenhet feil

Som du kanskje har lagt merke til, gjør vi mange feil når vi bruker programvaretester på en konvensjonell måte og mange ganger vi er ikke klar over kostnadene dette medfører.

Bare for å gi deg en idé:

• Den konvensjonelle metoden for programvaretesting innebærer å oppdage defekter i programvaren.
• Deretter angis feilsøkingsfasen, det vil si gjennomgang av koden for å forstå årsakene til feilene og til slutt korrigere programvarefeilene.
• På denne måten bruker programmerere i gjennomsnitt 49,9% av tiden på å feilsøke sine egne feil.
• Dette innebærer en verdensomspennende utgift på 156 milliarder dollar per år.

Formell utvikling som en foreslått løsning på inkonsekvent programvaretesting

Som vi allerede har sett, er et av hovedproblemene tvetydigheten til spesifikasjonene som, når de uttrykkes i naturlig språk, mangler nøyaktighet og logisk matematisk sans. En løsning er å bruke formelt språk, der det ikke er rom for tvetydighet.

Ved å bruke en formell metode for utvikling av våre programvareprosjekter, vissheten om egenskapene og / eller funksjonalitetene til programvaren er garantert gjennom fradrag, med andre ord gjennom matematikk (p -> q).

Denne formelle metoden krever mye mer tid og budsjett for utarbeidelsen, siden det er nødvendig med mye mer presisjon i utarbeidelsen av spesifikasjoner, som igjen må fjernes fra uklarheter, slik at den når den oppretter kode kan demonstrere sin pålitelighet basert på spesifikasjonene.

Det virker ganske langt fra virkeligheten å nå denne grensen for etterspørsel for å lage kvalitetsprogramvare. Imidlertid er det for tiden selskaper som baserer systemene sine på formell utvikling, vanligvis med selskaper som er dedikert til kritiske områder der en liten feil kan bety tap av menneskeliv umiddelbart.

Imidlertid er et slikt etterspørselsnivå i liten skala ikke lønnsomt; i det minste må vi overholde konvensjonelle tester.

Nedenfor deler jeg en serie publikasjoner om god praksis som du ikke bør gå glipp av hvis du ønsker å utvikle kvalitetsprosjekter.

Hvordan gagner kontinuerlig læring hjernen vår?

Læring er som drivstoff for hjernen vår.

På høyskole eller universitet har vi ofret kontinuerlig studier, og ingenting av det har vært nok, fordi hvert minutt som passerer ny informasjon kommer ut uavhengig av karrieren du har studert.

Det vil alltid være noe nytt å lære.

Noe å huske på er at når vi lærer, blir hjernen vår påvirket av endringer i nevrale strukturer.

Moderne forskning har vist det hjernen har evnen til å permanent forandre seg og deformeres (plastisitet), og ikke bare hos barn, men også hos voksne.

Disse endringene i hjernen kan skyldes god praksis for kontinuerlig læring, omstrukturere synaptiske forbindelser og noen ganger opprette nye.

Tidligere ble det antatt at jo større eller tyngre hjernen til en person var, jo mer intelligent var den. Nyere studier har imidlertid bestemt at mennesker med høyere IQ har et mindre tett nevralnettverk, men samtidig mye mer organisert.

For denne forskningen har IQ blitt beregnet på følgende faktorer:

• Analysekapasitet
• Refleksjonsevne
• Problemløsning

Her er litt mer informasjon om den aktuelle forskningen:

Intelligens er basert på nevroneffektivitet - Erhan Genç

Teamet ledet av Erhan Genç analyserte hjernen til 259 menn og kvinner mellom 18 og 40 år, og ved god helse, for å måle dendritter i hjernebarken, det vil si utvidelser av nerveceller som cellene brukte til å kommunisere med hverandre i utførelsen av intelligens.

Før studien gjennomgikk alle deltakerne en IQ -test. Etter å ha studert dendritter, det ble bestemt at jo høyere IQ, jo færre dendritter er det i hjernebarken.

Med andre ord ble det konkludert med at smartere mennesker ikke bare har flere nevroner, men også har færre dendritiske forbindelser mellom nevroner på erkjennelsestidspunktet. Noe som betyr at de har et mindre tett nevrale nettverk.

Studiene ble validert med et utvalg på 500 personer, og de samme konklusjonene ble nådd.

Erhan Genç, hovedforfatter av studien konkluderte med:

Intelligente hjerner er preget av et tynt, men svært effektivt nevrale nettverk. Dette bidrar til å oppnå et høyt tankenivå samtidig som nevral aktivitet minimeres. Erhan Genç

Hvordan påvirker programmering våre mentale evner?

Som jeg allerede har nevnt i tidligere avsnitt, programmering påvirker tankegangen til de som praktiserer den, på den måten påvirker det vår direkte mentale evner.

Men på hvilken måte gjør det det? La oss se.

En programmerer tenker veldig annerledes enn andre, fordi de generelt har en tendens til å være mer logiske og mer rasjonelle enn gjennomsnittet, men ikke nødvendigvis.

Siden vi bestemte oss for å lære å programmere, må vi velge hvilket språk vi skal begynne med. Selv om et slikt valg ikke er helt sant, fordi generelt de aller fleste av de som dedikerer seg til en verden av programvareutvikling, velger vårt første språk uten erfaring eller har blitt utsatt for og praktisk talt tvunget til å starte med et pålagt programmeringsspråk. av en lærer, enten på høyskole og / eller universitet.

Slike begrensninger er imidlertid sjeldnere og mindre hyppige på grunn av mengden informasjon vi kan finne på internett og høy insentiv og promotering av selvlært læring.

Paradigmene til programmeringsspråk har allerede formet mange sinn, i noen tilfeller med flere begrensninger enn i andre, avhengig av språket den ble startet med. Med dette mener jeg ikke at ditt morsmål definerer din suksess eller fiasko, men jeg mener paradigmene man starter med i programmeringsverdenen, setter inn mønstre i vår tenkning.

Jeg nevner deg nedenfor 3 måter programmering påvirker hjernen din:

1. Verktøyene vi bruker til å programmere påvirker våre mentale modeller

Programmeringsspråket som vi startet med er ikke annet enn et verktøy, som ledsages av paradigmer og idiomer som direkte påvirker tankegangen din. Ikke for ingenting, Edsger

Dijkstra, en av pionerene i etableringen av distribuert programmering sa:

Verktøyene vi bruker har en dyp (og avskyelig) innflytelse på vår tenkevaner og, derfor i vår tenkeferdigheter. Edsger Dijkstra

Nå som du vet hvor viktig programmeringsspråket vi starter med er og generelt settet med verktøy vi bruker når vi programmerer, anbefaler jeg deg at det første du må ta i betraktning når du velger ditt første programmeringsspråk, er din komfort.

Hvis du bare har begynt, ikke la deg rive med av penger. Det er sant at det er programmeringsspråk som er bedre betalt enn andre, men penger bør ikke være målet ditt. I så fall kan jeg råde deg til å begynne å programmere med COBOL, PASCAL, FORTRAN, språk som har svært lite dokumentasjon, og at det for øyeblikket er veldig få som praktiserer det, og derfor er de veldig godt betalt der de kreves.

I virkeligheten gir det ikke bare fordeler med tankevaner og kognitive ferdigheter ved å dedikere deg selv til programvareutvikling, det kan også sikre en mer enn stabil økonomisk fremtid, siden det er en veldig godt betalt sektor som for tiden vokser.

I dag er den beste tiden å starte. La oss se hvorfor:

Hvorfor er IT -sektoren en av de mest anbefalte i 2021?

I følge Economic Commission for Latin America and the Caribbean (ECLAC) vil latinamerikanske land begynne å vokse etter den økonomiske lavkonjunkturen i 2020.

Det er estimert en vekst på 3,7% for 2021, hvor hovedpersonene vil være de som er dedikert til den digitale verden.

2. Det er sunt for hjernen

Som vi allerede har nevnt, har læring positive effekter på hjernen. I denne forstand teller programmering som en mental øvelse som direkte favoriserer hjernen.

La oss se på en bakgrunn som bekrefter fordelene med programmering for hjernens helse:

I 1991 studerte en undersøkelse effekten av dataprogrammering på kognitive utfall og bestemte det studenter i programmeringsrelaterte områder får 16 prosentilpoeng høyere enn gjennomsnittet på IQ-tester.

En annen større studie i 1999 endte opp med å bekrefte at intellektuelt engasjerende aktiviteter tjener til å buffre individer mot kognitiv tilbakegang.

Senere i 2009 fant en studie at personer som driver med hjernestimulerende aktiviteter senere år kan redusere risikoen og til og med forsinke utbruddet av Alzheimers og andre typer demens.

3. Mens du programmerer, stimulerer du opptil 5 områder av hjernen din

I 2014 en studie med tittelen “Understanding Source Code Understanding with Functional Magnetic Resonance Imaging” brukte funksjonell magnetisk resonansavbildning for å observere hjerneaktivitet mens programmererne prøvde å jobbe og forstå kodebiter.

Det ble konkludert med at fem områder av hjernen var involvert:

• BA 6: Midtfrontal gyrus (oppmerksomhet, språk, arbeidsminne)
• BA 21: Mean temporal gyrus (semantic memory retrieval)
• BA 40: Nedre parietallapp (arbeidsminne)
• BA 44: Inferior frontal gyrus (arbeidsminne)
• BA 47: Inferior frontal gyrus (språk, arbeidsminne)

Vi må huske på at deltakerne ble gjennomgått en kodebit på 20 linjer, noe som ikke er en stor utfordring. Og det er derfor ingen aktivitet ble oppdaget i områder av hjernen knyttet til matematiske beregninger.

Det man kunne legge merke til var den høye intervensjonen av deler av hjernen som normalt er forbundet med språkbehandling, minne og oppmerksomhet.

Programming is the closest thing to having superpowers. Drew Houston, Administrerende direktør i Dropbox