nya programmerare, Välkommen till industrin för mjukvaruutveckling, utan att behöva investera ett decennium lång karriär för att lära sig dessa lektioner den hårda vägen.
Nu kan vissa saker bara läras av erfarenhet. Jag kan säga att dessa saker är viktiga, eller att de verkligen händer i branschen, men du kanske inte tror mig förrän du ser dem hända i din egen karriär. Beslutet är upp till dig, men här är tipsen till din fördel, om du väljer att lära dig dem på ett enkelt sätt.
1. Människor färdigheter är viktiga för programmerare också
Du är frisk ut ur college. Ditt huvud är en trädgård där du planterar massor av intressanta och kreativa saker — trots allt kommer du att bo där resten av ditt liv, så varför inte? Du är ovillig att släppa in människor eftersom de kan krossa och förstöra allt ditt hårda arbete med sina egna olika sätt att tänka och göra saker. Du är bra på att assimilera-hitta nya ideer, bryta ner dem och analysera dem och sedan plantera dem i den stora datalagret i din programmeringshjärna. Detta beskriver de flesta programmerare ganska bra, och det beskrev mig verkligen. Om så är fallet, du är i för en ganska justering.
det tog nästan hälften av min decennielånga karriär inom datorer att inse att människor kan vara svåra att arbeta med ibland, och att en programmerares jobb innehåller mycket mer än bara att arbeta med datorer. Innan du arbetar med datorer måste någon ta reda på vad det är de faktiskt vill spendera sina pengar på — de pengar du får betalt med. När de väl har räknat ut det kommer det att spenderas mycket tid på möten som diskuterar allt och allt om det — hur lång tid det kommer att ta, vad rätt sätt att designa det är och vem som behöver vara involverad. Dessa diskussioner är sällan snabba eller enkla, och om du redan kämpar för att kommunicera effektivt och övertyga människor om dina övertygelser, kommer det inte att bli lättare när du måste använda tekniska termer som inte alla kommer att förstå. Om du, som den typiska programmeraren som beskrivits tidigare, är blyg eller reserverad och undviker att tala upp i möten, är det ännu ett hinder i din väg.
kasta sedan in i mixen det faktum att inte alla är lätta att komma överens med, och du har ett recept på problem. De flesta programmerare saknar redan människors färdigheter, så de föreställer sig spänningen att bara arbeta med datorer, något de förstår mycket bättre än människor. Som föregående stycke förklarar är det tvärtom. Gilla det eller inte, du kommer att spendera mycket mer tid på att arbeta med människor än med datorer. När du äntligen får rulla upp ärmarna och börja ”koda som vinden” kommer du förmodligen att vara trött på möten och trött på att bli behandlad som en resurs snarare än värderad för din expertis. Medan varje företag är annorlunda, företag med en vänlig, bekväm företagskultur är svåra att hitta. Inte bara det, men saker och ting förändras även från dag till dag.
2. Expertis utan auktoritet
Mycket ofta, dina tankar om vad som kommer att vara en användbar mjukvarulösning konflikt dramatiskt med de människor som faktiskt gör dessa beslut. Du måste kunna leva med det, arbeta med fruktade/tråkiga projekt och ta dina klumpar som en vuxen. Fred Brooks i den mytiska Manmånaden kallade denna expertis utan auktoritet.
det är mycket mer troligt att du kommer att sluta behålla någon annans dåligt skrivna kod från 10 år sedan, väckt av en personsökare som surrar klockan 3 på ditt supportskifte än att bli vald för att skriva en snygg ny full-stack webbapplikation från grunden, med alla de saftiga nya verktygen du har läst om och saliverat över. När allt kommer omkring kan nya verktyg vara dyra, och du är vanligtvis inte den som fattar besluten.
Visst, det är en dum ide att klippa en hel gräsmatta med en ogräsätare. Men när du ber om en gräsklippare och får höra ”nej” kan du antingen kasta in handduken eller nöja dig med ogräsätaren.
3. Naturlig nyfikenhet att experimentera är ett måste
att ha ett bra grepp om syntax, semantik och språk — som du kan vinna på att vara en engelsk, matematik eller teknisk major — går långt för att göra dig till en bra programmerare, men det är inte allt.
större än det är inte att vara rädd för att prova saker — att trycka på knappar — för att göra misstag — för att se vad som händer. Peta runt lite. Skriv lite dålig kod och se den falla platt på ansiktet. Det är det primära och det bästa sättet att lära sig om datorer. Om du litar på andra för att räkna ut det för dig, begränsar du bara dig själv. Du måste vara villig att prova själv och lära av resultaten, bra eller dåliga.
4. Kompilatorn / datorn kräver absolut perfektion
Föreställ dig att du inte kan skicka ett e-postmeddelande förrän du har korrigerat varje grammatikfel, felstavat ord och saknat komma. Låter löjligt? Med en dator som din chef beskriver detta varje e-post. Förutom i stället för ett e-postmeddelande pratar vi om att skriva ett datorprogram.att nå perfektion kräver mycket engagemang, motivation och uthållighet — mer än många människor har. Den blivande programmeraren kanske inte är motiverad eller ihållande för att slå igenom hinder, fel, buggar, tekniska specifikationer på 100 sidor och felsökningsutmaningar för att äntligen nå det sista steget i absolut perfektion. Det är en lång väg att gå, särskilt utan naturlig nyfikenhet och språkförmåga.
5. Ideer är enkla; datorprogram är komplexa
När du programmerar instruerar du datorn att göra något. Datorn kan göras för att göra nästan vad som helst du kan tänka dig. Du arbetar med abstrakta tanke-saker-rena ideer. Det kan låta som himlen, och det finns säkert bra saker om det; men som allt annat har det sina nackdelar.
ofta verkar ideer mycket enkla. En enda ny ide låter enkelt nog för människor som har inneboende intellekt om verkliga världskoncept. Datorer saknar detta inneboende intellekt, så även den enklaste ideen, översatt till datorspråk, blir snabbt komplicerad. Att hitta rätt instruktioner är en svår uppgift även för experter, veteranprogrammerare — särskilt för något som inte har gjorts tidigare. Och om det har gjorts tidigare, varför inte bara köpa det programmet istället för att skriva ett nytt? En programmerares tid är dyr-vanligtvis $30 / timme eller mer. Om ett program kostar $30 per användare kan det programmet vanligtvis köpas permanent. Även om det kostar $300 per användare är det fortfarande mycket billigare än $30/timme.
6. Inte varje fel är en bugg
många nya programmerare är avskräckta första gången de bygger eller kompilerar något, bara för att ha 50 röda märken, skarpa linjer eller fel och varningar dyker upp. För att göra saken värre, varje enskilt fel är något kryptiskt nonsens som ”icke-statisk medlem kan inte nås från ett statiskt sammanhang.”
mitt råd till dig: slappna av! Bara slappna av en sekund. Inte varje fel är en bugg. Inte alla fel är ditt fel. Inte alla fel behöver ens åtgärdas direkt. Dessutom kan fel åtgärdas.
de flesta moderna kodredigerare kommer att vara så upptagna att hitta fel, även innan du är klar med att skriva in koden, att det snabbt kan verka som en omöjlig uppgift att sätta parenteserna på rätt ställen. Återigen-bara lugna dig, gå tillbaka och inse att det inte är så illa som det verkar.
Jag har programmerat i mer än ett decennium, och jag tror inte att jag en gång har skrivit ett program som fungerade felfritt första gången jag försökte det. Det kommer att finnas fel i din kod! Vänja dig vid tanken på att se de irriterande, röda, skarpa märkena överallt.
därefter är ett fel inte nödvändigtvis ett fel. Ja, felen behöver åtgärdas så småningom innan du kan köra ditt program. Ansträngningen att ta bort buggar är dock sekundär bredvid uppgiften att skriva koden. Och som tidigare nämnts kommer de flesta redaktörer idag att hitta alla fel som är möjliga långt innan du är klar med att skriva koden. Det gör inte dessa fel viktigare än vad du redan gjorde. Låt dem inte resa dig; de kommer att hända, så var redo och lär dig att sätta dem i väntan tills du har fått tag på saker. När du lär dig att tänka som en dator börjar du förstå vilka fel som är viktiga och vilka som bara saknar bitar av ditt program som du inte har slutfört ännu.
för att sammanfatta: röd, squiggly och irriterande (ett fel) översätts inte automatiskt till viktigt.
7. Inga fel betyder inte inga buggar
Tänk dig att sitta tillbaka efter mycket hårt arbete, nöjd med att du äntligen fixade alla dessa irriterande fel. Nu kan du vara på din glada väg, eller hur? Fel.
inte alla fel är ett fel, och det omvända är också sant: brist på fel är inte nödvändigtvis brist på buggar. Bara för att din kod har inga fel betyder inte att det kommer att fungera korrekt. Generellt måste du anta att din kod inte fungerar korrekt, även efter att du har fixat alla fel.
det finns två allmänna typer av fel: kompilera fel (den röda, squiggly typ), och runtime eller logiska fel. Det senare är vad vi pratar om nu.
säg att din kod faktiskt körs. Det betyder att datorn förstår det och kan utföra det, men det betyder inte att instruktionerna själva inte är felaktiga. Vad din hjärna kommer upp med första gången är vettigt för dig, men en dator behöver vanligtvis mer detaljer än en mänsklig hjärna gör för att förstå en process eller algoritm.
ett perfekt exempel är att dividera med noll. Detta matematiska uttryck är odefinierat, men problemet är inte uppenbart om du bara delar x med y. antingen x eller y kan vara vad som helst. Först när programmet körs har y ett verkligt värde, vilket kanske eller kanske inte är noll.
8. Lös problemet, inte bara ett problem
det är otroligt enkelt när felsökning eller felsökning blir förvirrad över vad det verkliga problemet egentligen är — att få dina ledningar korsade och spendera timmar oproduktivt, jagar en gås som inte har något att göra med det faktiska problemet till hands.
att bli en bättre programmerare har mycket att göra med att snabbt kunna identifiera orsaken till ett problem — och sedan fixa det. Som jag vill säga, åtgärda problemet.
i processen stöter du ofta på mindre, relaterade problem som också kan behöva åtgärdas — ett problem, men inte problemet. Luta dig inte tillbaka bara för att du löst något. Det krävs mycket fokus för att lösa ett problem hela vägen till slutet.
felsökning anses ofta vara 99% gjort, för det mesta som felsökning tar. Detta beror på att, tills grundorsaken faktiskt är känd, att veta hur lång tid det tar att fixa det är en omtvistad diskussion. Att hitta grundorsaken kan ofta ta mycket tid i sig.
Kom ihåg dessa enkla regler för felsökning och felsökning:
A) testa alltid din kod
B) Sanity check och validera allt-speciellt saker du tror inte behöver det
C) försök att inte göra ”knä-jerk”-ändringar, en slumpmässig gissning för att locka felet till att gå bort; dessa introducerar ofta fler problem
D) då dubbelkontroll
Felsökning i sig är ett enkelt bevis på att datorer eller robotar aldrig kommer att ta över världen. Visa mig en dator som kan felsöka sig själv, och jag ska visa dig en värld som inte behöver programmerare.
9. Det grundläggande problemet med mjukvaruutveckling
oavsett hur bra ditt program eller programvara, kommer någon att hitta ett sätt att använda det fel, men kommer att vara helt övertygad om att det ska fungera på det sättet. Tror du mig inte? Utveckla lite programvara, publicera den och läs kommentarerna och e-postmeddelandena du får. Du kommer snart att upptäcka att detta är helt sant.
alla har sitt eget sätt att arbeta. En storlek kan aldrig passa alla, men tyvärr för dig som programmerare är en storlek mycket billigare och effektivare än tre eller fyra storlekar. Du får sällan chansen att implementera alla möjliga funktioner — Alla klockor och visselpipor du kan tänka dig. Ofta är det bara motsatsen som ledningen frågar dig. De vill ha en bare-bones, minimum viable product (MVP) för att testa konceptet och se om kunderna gillar det och om den fullfjädrade versionen till och med kommer att vara värt att bygga alls.
10. Teknik är ett oförutsägbart, rörligt mål
Ibland kan människor inte bestämma sig för vad de vill ha — och du måste ta itu med konsekvenserna, eller till och med städa upp röran. Edward Berard uttryckte det så här: ”att gå på vatten och utveckla programvara från en specifikation är lätt om båda är frysta.”Ibland kommer kraven att förändras i mitten av projektet, och du måste justera och anpassa, som om du kör på motorn i en bil medan du kör på motorvägen. Galen, men sant.
När du har slutfört ditt projekt kan det hända att det har blivit föråldrat eller onödigt. Kanske ett bibliotek eller ramverk det beror på behov uppdaterade, och ditt företag vill inte finansiera uppgraderingen. Kanske levererar du det faktiskt till kunderna och de vill inte ens använda det (jag har sett detta hända med mitt eget projekt).
tekniken beror på den framgångsrika interaktionen mellan människor och andra människor, människor och datorer och datorer med andra datorer. Både människor och datorer kan vara oförutsägbara, och all denna inneboende oförutsägbarhet kommer inte att försvinna helt enkelt för att du vill ha det.
11. Uppskattning är svårt
de mest intressanta och värdefulla projekten är normalt de som aldrig har gjorts tidigare. Eftersom de aldrig har gjorts, uppskatta hur lång tid de kommer att ta är en särskild punkt av frustration, svårigheter, och smärta. Oförutsägbarhet (punkt 10 ovan) är per definition svårt att förutsäga!
företagsledare vill aldrig höra hur lång tid något kommer att ta. De är vanligtvis intresserade av hur man får det gjort snabbare och med en minimal budget.
programmerare vill aldrig höra hur lite tid eller hur få resurser de kommer att ha. De behöver fritid för innovation och forskning. De behöver dyra nya verktyg för att koda snabbare och bättre med. Programmering är lika delar teknisk och kreativ, och det kan inte skyndas utan att förstöra slutresultatet — men det är ofta. En monteringslinje fungerar bara med en process som är enkel, förändras lite och kan upprepas oändligt — varav ingen gäller mjukvaruutveckling. Det verkar aldrig hindra chefer från att försöka göra det till en monteringslinje.
uppskattningsinsatsen är den oändliga striden du håller på att inleda som programmerare. När jag avslutar denna karriäröversikt kan jag bara säga: Glöm inte att skratta och ha kul. Du kan en dag upptäcka att humor är det som fick dig till slutet med din sanity intakt.
P. S. programmerare är nu mer värdefulla för företag än pengar. Var inte för hård mot dig själv; datorn kommer att ta hand om det. Ge dig själv en klapp på ryggen för att vara intresserad av ett så svårt men givande yrke.