Sådan bliver du en succesrig softwareingeniør

For de unge, lysøjne softwareingeniører, der begynder i deres karriere, er her nogle af de bedste tip, som jeg enten har læst eller modtaget som softwareingeniør.

De fleste af rådene her henvender sig til software engineering crowd, men jeg tror, ​​der er mange tip, der er relevante uanset dit erhverv.

Bedste rådgivning om karriere og liv, jeg har modtaget

Kort sagt, mit bedste råd er:

  • Underpromise, overleverer
  • Perfekt er det gode fjende
  • Bliv på en sti
  • Saml feedback tidligt
  • Søg inden du spørger
  • Optimer for enkelhed

Hvis du foretrækker at se dette i et videoformat, har jeg lavet en Youtube-video her:

Underpromise, Overleverer

Undervurdering af mængden af ​​arbejde, der er nødvendigt for at udføre en funktion, er en ekstremt almindelig fejltagelse blandt nye og endda erfarne ingeniører.

Hvis du ser på antallet af projekter, der er for store og / eller leveret sent, bliver du meget overrasket. Det er et vanvittigt tal, noget på 50%.

Lad os overveje det i et sekund: 50% af alle projekter er enten overbudget eller leveres sent.

Det betyder, at hver 1000 projekter, 500 eller halvdelen af ​​dem, leveres sent eller over det anslåede budget. Det forvirrer bare mig.

Jeg husker tydeligt under mit første tech-projekt, at jeg fik autonomi til at lede funktionsudviklingen. Det betød, at jeg var den go-to fyr, der ville skrive et teknisk designdok med detaljerede oplysninger om, hvor lang tid det ville tage at udvikle hele funktionen, hvor mange ingeniører vi ville have brug for osv.

Da jeg var den ivrige, unge ingeniør, undervurderede jeg groft den tid, der var brug for at få tingene gjort. Noget på melodien 2–3x.

Jeg var ret skuffet over mig selv på det tidspunkt, og som et resultat heraf havde jeg et anstrengt forhold til nogle af mine kolleger.

Min manager satte mig derefter ned og gav mig nogle livsændrende råd. Han sagde til mig, altid underpromise og overleverer.

Hvad det betyder er, at du skal være konservativ med dine skøn, sørge for tilstrækkelig buffer til, at dine skøn for forskellige ting går galt (fordi alt, hvad der kan gå galt, vil), og sigter mod at levere dit projekt i forvejen / under omkostningerne.

Fordelene:

  1. Giver dig god tid til at udvikle og refactor efter behov. Funktionudvikling er altid et godt tidspunkt at gå tilbage og ordne noget af den tekniske gæld, du (eller teamet før du) har akkumuleret gennem årene.
  2. Giver tid til at finde ud af det bedste design og ikke kun et fungerende design.
  3. Der er mange ting, der kan gå galt under funktionsudvikling. En medarbejder rejser på ferie, du bliver syg, møder, dit barn bliver syge, din bil bliver ramt, og listen fortsætter. Det er vigtigt at erkende, at ting kan gå galt, og du vil sikre dig, at du har en buffer i din tidsplan.
  4. Når du er i stand til at producere arbejde af høj kvalitet konsekvent som et resultat af nr. 2, og i stand til at levere til tiden hver eneste gang som et resultat af # 3, er du nu anerkendt som en højtydende inden for virksomheden, der ved, hvad du vi taler om og kan regnes med. Win-win!

Du kan muligvis hævde, at ulempen ved under-lovende er, at andre vil tro, at du er doven ved at estimere 10 ugers arbejde værd for noget, der kan gøres om 2 uger.

For at være ærlig, kæmpede jeg også med dette i et stykke tid. Dog indså jeg derefter, at så længe du kommunikerer åbent og forbliver konsistent med interessenterne under hele processen, har du det godt.

Du er den person, der er ansvarlig for at levere omkostningerne, fordi andre stoler på din ekspertise. De ved, at du er den mest intime med kodebasen, og de stoler på, at du giver et bedste gæt. Forskellige ting kan ske under funktionsudvikling, og så længe du åbner kommunikation, vil alt være i orden.

Perfekt er det gode fjende

Som softwareingeniør har du en tendens til at opdage, at et projekt mangler dette eller har brug for det, før det kan gå ud af døren. Et projekt kan være et kodningsprojekt eller bare et teknisk designdokument, som du har brug for at skrive.

Hvad der ofte sker, er, at når du dykker dybere ned i projektet, begynder du at finde ud af, at der er flere ting, som du ikke har tegnet for. Derefter ruller du ærmerne op og sætter dit syn på at komme til bunden af ​​tingene. Du besluttede at bruge de næste par timer på at undersøge og forsøge at få alt sammen pakket.

Ti timer ind bliver der faktisk ikke gjort noget, og du hoper mere arbejde end før.

Hvis dette lyder velkendt for dig, er du ikke alene.

Dette sker for alle - og det sker med de bedste af os. Jeg tror, ​​at vi fra en ung alder er blevet konditioneret til at fremstille arbejde, der er "perfekt" eller "komplet." Men i virkeligheden er der ikke sådan noget som en perfekt løsning.

Vi lever i en verden af ​​begrænsninger, og der er en kompromis for enhver vigtig beslutning, vi træffer.

Nøglen her er at erkende, at vi ikke ved alt. Du er måske ikke klar over det, men der er et utal af alternativer bag de fleste beslutninger, du træffer.

For eksempel, som computervidenskabelig major, hvad skal du gøre for et første job på universitetet? Bortset fra at arbejde for en startup eller et større tech-selskab, kan du også arbejde i udlandet som freelancer, starte en Youtube-kanal, undervise computervidenskab på Udemy, starte en blog eller starte din egen virksomhed. Listen over indstillinger er ubegrænset, og den beslutning, du træffer i dag, vil være baseret på flere nøglekriterier.

Du vil til sidst tage en beslutning, der er bedst for dig og ikke nødvendigvis objektivt bedst, fordi alle er unikke og der ikke er nogen i størrelse.

Det bedste, vi kan gøre i en sådan situation, er at samle så meget information som muligt, anerkende risikoen i det, vi ikke kender, og tage den bedste beslutning derfra.

Sandsynligheden for at mislykkes

Den måde, jeg tænker på, er at jeg tildeler en sandsynlighed for det værste tilfælde og bruger det til min beslutningsproces. Dette er noget, jeg lærte fra en bog kaldet Principles af Ray Dalio, som er en dejlig bog, som jeg varmt kan anbefale.

Hvis sandsynligheden for, at noget forfærdeligt går galt, er statistisk signifikant, er jeg enten:

  1. Se efter en bedre løsning eller
  2. Find måder til at afbøde risikoen for, at de ikke længere er statistisk signifikante.

Når en beslutning er truffet, udfører jeg den og går videre.

Skyl, og gentag for alle problemer, som jeg støder på. Jeg finder glæde ved at løse disse problemer, og på nogle måder er livsglæden ved at løse problemer af varierende størrelse og kompleksitet.

Hvis du gerne vil lære mere om, hvordan man lander et job som softwareingeniør, underviser jeg i en lille klasse, der fokuserer på at tage det tekniske interview. Du kan finde ud af mere om det her eller på min hjemmeside: zhiachong.com

Rammer for beslutningstagning

Bliv på sti

Feature krybning er en, der naturligt kommer til at tænke som et modeksempel.

Du ønsker fortsat at tilføje flere funktioner, fordi du føler, at den nuværende ser ud som om den blev downloadet fra 90'erne på verdensplan. Du føler, at det ikke er klar. Du tror, ​​at ingen nogensinde ønsker at bruge dit produkt.

Bemærk dog, at alle disse ting foregår i dit eget hoved. Intet af dette er valideret. Du ved ikke, hvad folk vil have, før du lægger noget i deres hænder.

Hvad du skal sigte mod er at sætte et fast mål i begyndelsen af ​​dit projekt og stræbe efter at nå det uanset hvad.

Fordelene er to gange:

  1. Dette reducerer funktionskryp og tvinger dig til at fokusere. Mængder af bøger er skrevet om dette, og jeg vil ikke kede dig med de specifikke detaljer. At være laserfokus er afgørende, uanset din position.
  2. Vi mennesker elsker øjeblikkelig tilfredsstillelse. Hvis du kan frigive noget på 2 uger, så gør det! Planlæg forud for, hvad dit projekt skal være i stand til at opnå om 2 uger, og læg det derefter i dine brugere! Det er en meget tilfredsstillende følelse, og selvom det ikke mislykkes, holder du dig i det mindste ved dit mål, og du har nu indsamlet værdifuld feedback for at gentage det.

Dette bringer mig til mit næste punkt.

Saml feedback tidligt

Jeg synes personligt, at vi altid bør sigte mod at frigive tidligt, frigive ofte og samle feedback så hurtigt som muligt.

Naturligvis anerkender jeg, at dette primært er muligt til softwareprojekter. Men hør mig ud.

Hvis du frigiver ofte og frigiver tidligt, kan du indsamle feedback tidligt. At have en sund feedbacksløjfe er et meget vigtigt, hvis ikke det vigtigste aspekt af dit projekt.

Feedback loop for produkt

Du bør indarbejde en feedback-loop tidligt i din produktudvikling, så du ved, at du udvikler det rigtige produkt til de rigtige mennesker med de rigtige begrænsninger.

Det er lige så vigtigt at bemærke, at frigivelse tidligt ikke betyder at frigive et ødelagt produkt. Et ødelagt produkt er aldrig nyttigt for nogen, og det er bare respektløst over for dine brugere.

Du skal finde ud af og levere et minimum-levedygtigt produkt (MVP), hvilket betyder den blotte minimumsmåde, som dit produkt skal gå ud for at tilfredsstille et behov.

En ting at bemærke er, at indsamling af feedback ikke betyder, at det skal være feedback fra hver enkelt bruger.

Overvej at segmentere dine brugere. Få et lille sæt brugere, ideelt set fra forskellige baggrunde (og ikke kun venner og familie). Få dit produkt i deres hænder, så hvis du roterer, i det mindste dine andre brugere ikke har klar over det endnu, og du får tid til at ordne det.

Søg inden du spørger

Mange yngre ingeniører stiller ofte spørgsmål uden at forsøge at finde svarene selv. Når de støder på noget, de ikke har stødt på før, er deres første instinkt at spørge en senioringeniør, hvordan det er gjort, og hvordan man kan udføre noget.

Det vil gøre dig meget godt at selv søge svaret, før du spørger nogen. Årsagen er dobbelt:

  1. Dykning dybt giver dig mulighed for at udforske områder, du måske aldrig har udforsket før. Det giver dig en mulighed for at få eksponering og være fortrolig med en anden kodebase.
  2. Når du flytter til en mere seniorposition, stoler folk på dig for vejledning. Du bliver senior i gruppen over tid. Folk går til dig for at få hjælp, og du skal alligevel lære denne færdighed senere.

Mange udviklere spøger med, at det meste af deres tid bruges på Googling og StackOverflow. Jeg er helhjertet enig i dette, men ikke af grunde, du måske tænker.

Evnen til at finde svar på et tvetydigt problem er en meget eftertragtet færdighed. Internettet har over tid udviklet sig til en let tilgængelig skattekiste af information, som du kan tilslutte til enhver tid og hvor som helst på enhver enhed.

Alligevel er evnen til at stille de rigtige spørgsmål meget vanskeligere at tilegne sig end evnen til at besvare dem.

Når du bevæger dig gennem din professionelle karriere, vil du begynde at indse, at det at finde ud af de rigtige spørgsmål vil være en færdighed, du har brug for at lære, og hvis du mestrer det, vil det gøre dig vidundere.

Optimer for enkelhed

Stræb efter enkelhed i dit arbejde og i dit liv.

Ofte ser jeg, at juniorudviklere arbejder på et kodningsprojekt, og de bruger abstraktion, arv, grænseflader og nogle meget interessante rammer. På trods af al denne fantasi skriver de endnu en ny kode, der tilføjer mere komplikation end nødvendigt.

Mennesker, der opretholder denne kode, vil ikke være de samme mennesker, der skriver den, for det meste. Ethvert ekstra lag med kompleksitet, der tilføjes, vil gøre det meget vanskeligere at komme ombord på nye ingeniører.

Når du modnes som softwareingeniør, er du klar over, at det at skrive kode ikke kun er et spørgsmål om at optimere til ydeevne, men også at optimere for mennesker. Det er lige så vigtigt at skrive kode, som andre nemt kan resonnere om.

Det er her kodelæsbarhed og kodeorganisation kommer i spil.

Medmindre ydeevne er et reelt problem, skal du altid vælge en enklere og renere tilgang.

Jeg tror, ​​at enkelhed også strækker sig over livet uden for arbejdet. Hold dit liv fri for distraktioner. Reducer antallet af unødvendige ejendele, du har i dit liv. Fokuser på ting, der betyder noget for dig. Optimer dit liv til oplevelser og ikke til ejendele. Dette er nogle af de ting, du skal huske på, når du bevæger dig gennem livet.

Bøger, jeg har læst, og ressourcer, jeg har haft

  • Principper af Ray Dalio - En af de bedste bøger, jeg har læst på et stykke tid. Forfatteren taler om principper, vi kan anvende både i livet og på arbejdet. Jeg inkorporerede hans rammer for at løse problemer i min daglige liv
  • DailyCodingProblem: Det er en service, der sender daglige kodningsproblemer til din e-mail, og har nogle af de seneste spørgsmål fra top-tier tech-virksomheder. Brug min kuponkode, zhiachong, for at få $ 10 rabat!
  • Sådan vinder du venner og påvirker mennesker - Klassisk bog om opbygning og styring af forhold til mennesker . Denne bog hjalp mig med at forstå, hvordan man styrer mine relationer på arbejdspladsen.
  • Senior softwareingeniør - Fantastisk bog med handlingsemner om, hvordan man modnes som softwareingeniør. Det er her jeg lærte, hvordan man søger, inden du spørger.
  • Afgørende samtaler - Fantastisk bog om, hvordan man skal håndtere mennesker i en situation, der er meget interesseret. Meget anvendelig på tværs af forskellige aspekter af livet. Uanset om det forhandles om en højere løn eller finde ud af kommunikationsproblemer med din ægtefælle , har denne bog nogle gode tip til at løse disse problemer.
  • Lean Startup - God bog om, hvordan man bruger et minimum-levedygtigt produkt (MVP) til at afprøve en idé, inden man investerer videre. Jeg har brugt dette til at teste flere opstartideer i fortiden.
  • Purple ko - elskede denne bog. Brugte hovedsageligt dette til at teste forskellige opstartideer, jeg har i tankerne. Den taler om, hvordan du markedsfører din opstart, og hvad der gør det enestående fra resten.
  • Evernote - Bedste note-holder app Jeg har nogensinde brugt. Anbefaler det stærkt!
  • Moleskin notebook - Jeg kan virkelig lide denne. Kvaliteten på den er ekstremt høj. Prisen er lidt højere, men da jeg bruger den dagligt, betragter jeg den som en god investering. At have en smuk notesbog i mine hænder hver dag gør mig mere glade for at skrive flere notater.
  • Pilot G2 (sort) - Nemt de bedste penne, jeg nogensinde har brugt, og kun penner, jeg vil bruge. Jeg køber dem i bulk fra Amazon og holder dem rundt overalt, hvor jeg går. Jeg har en i min rygsæk, en på kontoret og en på min hjemmekontor, så jeg altid har en pen rundt. Det skriver godt, blækket flyder jævnt, og jeg elsker bare fornemmelsen af ​​at skrive i det. Sammen med Moleskin vil jeg sommetider bare hente G2 for at notere tilfældige ting derpå, fordi disse to er så perfekte sammen.

Følg mig på Twitter, Facebook og LinkedIn. Tilmeld mig min postliste, hvor jeg regelmæssigt sender tip, tricks og erhvervslæring.

Hvis du nød denne artikel, skal du kommentere nedenfor: hvad er dit bedste tip nr. 1 til en softwareingeniør?