Hvordan man tænker som en programmør - lektioner i problemløsning

Hvis du er interesseret i programmering, har du muligvis set dette tilbud før:

"Alle i dette land bør lære at programmere en computer, fordi det lærer dig at tænke." - Steve Jobs

Du spekulerede sandsynligvis også på, hvad betyder det nøjagtigt at tænke som en programmør? Og hvordan gør man det ??

I det væsentligedet handler om en mere effektiv måde til problemløsning .

I dette indlæg er mit mål at lære dig den måde.

I slutningen af ​​det ved du nøjagtigt, hvilke skridt du skal tage for at blive en bedre problemløser.

Hvorfor er dette vigtigt?

Problemløsning er metafærdigheden.

Vi har alle problemer. Store og små. Hvordan vi håndterer dem er undertiden, ja ... temmelig tilfældigt.

Medmindre du har et system, er det sandsynligvis sådan, du “løser” problemer (hvilket jeg gjorde, da jeg begyndte at kode):

  1. Prøv en løsning.
  2. Hvis det ikke virker, så prøv en anden.
  3. Hvis det ikke virker, skal du gentage trin 2, indtil du er heldig.

Se, nogle gange har du held ud. Men det er den værste måde at løse problemer på! Og det er et enormt, enormt spild af tid.

Den bedste måde involverer a) at have en ramme og b) øve sig på den.

"Næsten alle arbejdsgivere prioriterer problemløsningskompetencer først. Problemløsningsevner er næsten enstemmigt den vigtigste kvalifikation, som arbejdsgivere ser efter ... mere end programmeringssprogs færdigheder, debugging og systemdesign. Demonstration af beregningstænkning eller evnen til at nedbryde store , komplekse problemer er lige så værdifulde (hvis ikke mere) end de basale tekniske færdigheder, der kræves for et job. ” - Hacker Rank (rapport om udviklingsfærdigheder for 2018)

Har en ramme

For at finde de rigtige rammer fulgte jeg rådene i Tim Ferriss 'bog om læring, "The 4-Hour Chef".

Det fik mig til at interviewe to virkelig imponerende mennesker: C. Jordan Ball (rangeret 1. eller 2. ud af 65.000+ brugere på Coderbyte) og V. Anton Spraul (forfatter til bogen "Think Like a Programmer: An Introduction to Creative Problem Solving" ”).

Jeg stillede dem de samme spørgsmål, og gæt hvad? Deres svar var ret ens!

Snart vil du også kende dem.

Sidenote: dette betyder ikke, at de gjorde alt på samme måde. Alle er forskellige. Du bliver anderledes. Men hvis du starter med principper, som vi alle er enige om, er gode, kommer du meget længere meget hurtigere.

"Den største fejl, jeg ser, at nye programmører laver, er at fokusere på at lære syntaks i stedet for at lære at løse problemer." - Anton Spraul

Så hvad skal du gøre, når du støder på et nyt problem?

Her er trinene:

1. Forstå

Ved nøjagtigt hvad der bliver bedt om. De fleste hårde problemer er svære, fordi du ikke forstår dem (derfor hvorfor dette er det første trin).

Hvordan ved jeg, hvornår du forstår et problem? Når du kan forklare det på almindeligt engelsk.

Kan du huske, at du sidder fast i et problem, begynder du at forklare det, og du ser øjeblikkeligt huller i den logik, du ikke så før?

De fleste programmører kender denne følelse.

Dette er grunden til at du skal skrive dit problem ned, tegne et diagram eller fortælle en anden om det (eller ting ... nogle mennesker bruger en gummiand).

"Hvis du ikke kan forklare noget i enkle vendinger, forstår du det ikke." - Richard Feynman

2. Planlæg

Dyk ikke lige ind i løsningen uden en plan (og håb på en eller anden måde, at du kan blande dig igennem). Planlæg din løsning!

Intet kan hjælpe dig, hvis du ikke kan skrive de nøjagtige trin ned.

I programmering betyder det ikke at starte hacking med det samme. Giv din hjerne tid til at analysere problemet og behandle oplysningerne.

For at få en god plan, besvar dette spørgsmål:

"Givet input X, hvad er de trin, der er nødvendige for at returnere output Y?"

Sidenote: Programmører har et fantastisk værktøj til at hjælpe dem med dette ... Kommentarer!

3. Opdel

Vær opmærksom. Dette er det vigtigste trin af alle.

Forsøg ikke at løse et stort problem. Du græder.

Del det i stedet op i underproblemer. Disse delproblemer er meget lettere at løse.

Løs derefter hvert underproblem en efter en. Begynd med det enkleste. Enkleste betyder, at du kender svaret (eller er tættere på det svar).

Derefter betyder det enkleste, at dette delproblem, der løses, ikke afhænger af, at andre løses.

Når du har løst hvert underproblem, skal du forbinde prikkerne.

Tilslutning af alle dine "underløsninger" giver dig løsningen på det oprindelige problem. Tillykke!

Denne teknik er en hjørnesten i problemløsning. Husk det (læs dette trin igen, hvis du skal).

”Hvis jeg kunne lære hver begyndende programmør en færdighed til problemløsning, ville det være" reducer problemteknikken. "Antag for eksempel, at du er en ny programmør, og du bliver bedt om at skrive et program, der læser ti tal og tal ud hvilket nummer er det tredje højeste. For en helt ny programmør kan det være en hård opgave, selvom det kun kræver grundlæggende programmeringssyntaks. Hvis du sidder fast, skal du reducere problemet til noget enklere. I stedet for det tredje højeste tal, hvad med at finde det højeste samlet? Stadig for hård? Hvad med at finde det største af kun tre tal? Eller det største af to? Reducer problemet til det punkt, hvor du ved, hvordan du løser det og skriver løsningen. Udvid derefter problemet lidt, og omskriv løsningen, så den passer, og fortsæt, indtil du er tilbage, hvor du startede. ” - Anton Spraul

4. Fast?

Nu sidder du sandsynligvis og tænker "Hey Richard ... Det er sejt og alt, men hvad hvis jeg sidder fast og ikke engang kan løse et underproblem?"

Først skal du trække vejret dybt. For det andet er det retfærdigt.

Bare rolig, ven. Dette sker for alle!

Forskellen er, at de bedste programmører / problemløsere er mere nysgerrige efter bugs / fejl end irriteret.

Faktisk er her tre ting at prøve, når du står over for en whammy:

  • Fejlfinding: Gå trin for trin gennem din løsning og forsøg at finde, hvor du gik galt. Programmører kalder dette debugging (faktisk er det alt, hvad en debugger gør).
"Kunsten til fejlfinding er at finde ud af, hvad du virkelig har bedt dit program om at gøre, snarere end hvad du troede, du bad det om at gøre." "- Andrew Singer
  • Revurder:Tag et skridt tilbage. Se på problemet fra et andet perspektiv. Er der noget, der kan abstraheres til en mere generel tilgang?
”Nogle gange går vi så vild i detaljerne i et problem, at vi overser generelle principper, der ville løse problemet på et mere generelt niveau. […] Det klassiske eksempel på dette er naturligvis opsummeringen af ​​en lang liste af sammenhængende heltal, 1 + 2 + 3 + ... + n, som en meget ung Gauss hurtigt genkendte var simpelthen n (n + 1) / 2 og dermed undgå indsatsen for at skulle tilføje tilføjelsen. ” - C. Jordan Ball

Sidenote: En anden måde at revurdere på er at starte forfra. Slet alt og start igen med friske øjne. Jeg er seriøs. Du bliver forbavset over, hvor effektiv dette er.

  • Forskning:Ahh, god ol 'Google. Du læste det rigtigt. Uanset hvilket problem du har, har nogen sandsynligvis løst det. Find den person / løsning. Faktisk gør dette, selvom du har løst problemet! (Du kan lære meget af andres løsninger).

Advarsel: Se ikke efter en løsning på det store problem. Se kun efter løsninger på underproblemer. Hvorfor? For medmindre du kæmper (endda en smule), lærer du ikke noget. Hvis du ikke lærer noget, spildte du din tid.

Øve sig

Forvent ikke at være fantastisk efter bare en uge. Hvis du vil være en god problemløser, skal du løse mange problemer!

Øve sig. Øve sig. Øve sig. Det vil kun være et spørgsmål om tid, før du erkender, at "dette problem let kunne løses med."

Hvordan træner man? Der er muligheder ude i wazoo!

Skakpuslespil, matematiske problemer, Sudoku, Go, Monopol, videospil, cryptokitties, bla ... bla ... bla….

Faktisk er et almindeligt mønster blandt succesrige mennesker deres vane med at øve "mikroproblemløsning". For eksempel spiller Peter Thiel skak, og Elon Musk spiller videospil.

”Byron Reeves sagde 'Hvis du vil se, hvordan forretningsledelse kan se ud om tre til fem år, skal du se på, hvad der sker i onlinespil.' Fremad i dag. Elon [Musk], Reid [Hoffman], Mark Zuckerberg og mange andre siger, at spil har været grundlæggende for deres succes med at opbygge deres virksomheder. ” - Mary Meeker (2017 internet trends rapport)

Betyder dette, at du bare skal spille videospil? Slet ikke.

Men hvad handler videospil om? Det er rigtigt, problemløsning!

Så hvad du skal gøre er at finde et afsætningsmulighed for at øve dig. Noget der giver dig mulighed for at løse mange mikroproblemer (ideelt set noget, du nyder).

For eksempel nyder jeg at kode udfordringer. Hver dag prøver jeg at løse mindst en udfordring (normalt på Coderbyte).

Som jeg sagde, deler alle problemer lignende mønstre.

Konklusion

Det var alt folkens!

Nu ved du bedre, hvad det betyder at "tænke som en programmør."

Du ved også, at problemløsning er en utrolig færdighed at dyrke (metafærdigheden).

Som om det ikke var nok, bemærk hvordan du også ved hvad du skal gøre for at øve dine færdigheder til problemløsning!

Phew ... Temmelig sej, ikke?

Endelig vil jeg ønske, at du støder på mange problemer.

Du læste det rigtigt. I det mindste ved du nu, hvordan du løser dem! (også, du lærer, at du forbedrer med hver løsning).

”Lige når du tror, ​​at du har navigeret en hindring med succes, kommer en anden til. Men det er det, der holder livet interessant. […] Livet er en proces til at bryde igennem disse hindringer - en række befæstede linjer, som vi skal bryde igennem. Hver gang lærer du noget. Hver gang udvikler du styrke, visdom og perspektiv. Hver gang falder lidt mere af konkurrencen væk. Indtil alt, hvad der er tilbage, er dig: den bedste version af dig. ” - Ryan Holiday (Hindringen er vejen)

Gå nu og løs nogle problemer!

Og held og lykke?

Særlig tak til C. Jordan Ball og V. Anton Spraul. Alle de gode råd her kom fra dem.

Tak for læsningen! Hvis du nød det, skal du teste, hvor mange gange du kan ramme på 5 sekunder. Det er en god cardio til dine fingre OG vil hjælpe andre mennesker med at se historien.