Innhold
- 01. Koding kutter den ikke mer
- Bredde og dybde
- 02. Den store advarselen
- 03. Hva internett sier
- Forstå mediet
- 04. Tingene vi bygger med
- 05. Devops
- Forstå bunken
- Mystisk arbeid
- Praktiske verktøy
- 06. Dev ordner det ... kanskje
- Feilsøking
- 07. Hva brukerne vil ha
- Konkurranse marked
- 08. Tegning og skriving
- 09. Kos deg
- 10. Hold deg skarp
- Likte dette? Les disse!
Utviklere må være mer enn kodegenererende gruntarbeidere. Vi forventer mer av vårt digitale liv, og det er disse gutta som bygger det, så hva trenger de beste utviklerne å vite? Her er tingene jeg ser mangler fra for mange utviklere. Dette er ikke uttømmende, men det er disse egenskapene som gjør en rimelig kode til en fantastisk utvikler.
Men det er ikke en ting, og det er spesielt aldri muligheten til å analysere XML eller optimalisere kode. Det er en overraskende samling av ferdigheter som ikke blir undervist i bøkene om å skrive kode. De er litt ekstra.
Hvorfor lufte slik? Fordi utvikling betyr noe, men utviklere blir ofte sendt til en annen verden, ikke alltid av deres opprinnelse. Dette fungerer aldri. Utvikling - alt teknisk - trives alltid når de med kunnskapen forstår mer enn bare koden.
01. Koding kutter den ikke mer
Vi er i en verden der koding blir mindre imponerende. Alle bygger nettsteder, noen av dem koder, men du trenger ikke. Det er ikke lenger bare den nerdete som kan lage nettsteder, apper og funksjoner.
Siden nettet kom og folk kunne lære seg selv, har det vært selvlærte utviklere. Men selv kandidatene er truet. Jeg får CV-er med folk med informatikk, AI-kurs, forskjellige medier og koding under beltet, men det mangler fortsatt noe. Noen ganger mangler mye.
Jeg er ikke den første som sier dette. 'Coding don't cut it no more' er tittelen på kapittel 3 fra Den lidenskapelige programmereren, som sammen med bøker som Pragmatisk tenking og læring oppfordre programmerere til å forbedre seg utover koden; å bli resposible og helt menneskelige medlemmer av teamet.
Bredde og dybde
Utviklere må være bedre på to måter: bredde og dybde. De trenger å forstå bredden av menneskelig interaksjon i teamet sitt og med tingene de bygger. De trenger å forstå dybden i systemet de jobber med, helt ned til O / S.
Og det er ikke bare utviklere som skal lese disse tingene. Hvis du jobber med utviklere, tror jeg du bør forvente flere av dem. Få dem til å skissere hva de snakker om. Få dem til å forklare med bilder, gjenstander og (det fungerer) utklipp av mennesker nøyaktig hvordan systemet vil være for menneskene som bruker det.
02. Den store advarselen
Jeg skal snakke negativt om utviklere, men jeg tror jeg har lov fordi jeg er en. Også fordi minst én ting jeg snakker om her, er sant for mange av utviklerne jeg møter. Selv om arbeidet deres er bra, og de kjenner koden, er tidene konkurransedyktige. Du må ha en kant, og dette er:
- vær mer teknisk
og
- være mye mer menneskelig
03. Hva internett sier
Googling for viktige nettutviklingsferdigheter viser hva du forventer. Rammekunnskap, x-browser, CSS og JS. De viser rammer du bør kjenne til, plattformer du må skrive for og nye trender du bør holde øye med.
Dette er våre medier. Det er tingene vi bygger med, men det er ikke det som gir et prosjekt suksess. En utvikler kan forstå alle detaljene i systemet, fortelle deg alle funksjonene i et API og en ny CSS-teknologi, men fremdeles produsere noe ubrukelig.
Forstå mediet
Utviklere, som alle, trenger å forstå mediet sitt - men de må også forstå publikum, være at brukerne, teamet eller andre utviklere. De trenger å forstå hvordan mediet deres passer inn i verden (med andre ord produksjonsmiljøet) og hvilken effekt det har (hvordan folk bruker det).
Jeg har sett dette beskrevet som den 'brede og dype' personen. Bredt, fordi du trenger å forstå verden som et menneske som jobber med andre mennesker. Dypt fordi du trenger grundig teknisk kunnskap under nivået til din del av prosjektet. Disse utviklerne gir prosjektet ditt et enormt løft og endrer tempoet i prosjektet, uten som du ikke vil finne ikke-teknisk personale som er fast i kjedelige detaljer som renner over fra teknologiteamet.
04. Tingene vi bygger med
Jeg skrev nylig ned en liste over alt vi bruker for å bygge nettsteder, administrere hosting og få ting gjort slik at folk som blir med, kan ha et jukseark med teknologier å lære de første ukene. Vi tok det som lest at folk visste disse tingene, så for å gi nye rekrutter en hoppstart, vil vi liste opp alt vi bruker hver dag.
Jeg forventet et halvt dusin teknologier, men endte opp med langt mer. Denne listen - 'hva vi bruker' - inkluderer de vanlige CMS-ene, programmeringsspråkene og nettleserteknologiene, men også en rekke verktøy som teamet ikke engang husket at de brukte. Det hele var muskelminne. Ved å skrive 'git', 'phing', 'thor' på kommandolinjen, trodde vi ikke engang at noen kanskje ikke.
Bygg verktøy; CI; git for versjonskontroll ble tatt for gitt, men når man ser tilbake på CV-er, kom disse knapt til. De trendy vil fremstå (og er det kynisk at jeg tror visse byråer legger dem til ?!), men ofte uten konkret erfaring.
Disse verktøyene er viktige for å akselerere prosjektutvikling, så sørg for at du har et langt rikere verktøysett enn språket ditt, CMS og et par rammer. Du trenger distribusjon, testing, CI, sterk versjonskontroll (i team - ikke alene), og du må forstå kjernekonseptene i disse i stedet for bare noen få veiledninger.
05. Devops
Disse ekstra verktøyene og triksene passer pent inn i det folk kaller 'devops'. Devops flyr i møte med to tradisjonelle siloer: produksjon, som holder ting i gang, og utvikling, som gjør nye ting (og ofte stopper ting som kjører). Siloene resulterer i to leirer med liten sympati for hverandre.
Utviklere uten produksjonskunnskap produserer oftere kode som ikke er egnet for produksjon, ved å bruke konfigurasjoner eller funksjoner som ennå ikke er i produksjonsstakken. Fordi de ikke er klar over problemene i produksjonsmiljøet, koder de for å fullføre funksjonen i stedet for å distribuere den til produksjon.
Disse små detaljene kan skape smertefulle forsinkelser, forverret av trenden for å sende serveradministrasjonen til utlandet.
Forstå bunken
Devops er et stort felt i seg selv, som inkluderer kontinuerlig distribusjon og mye automatisering. Dette er et grundig sammendrag, men det viktigste utviklerne trenger å forstå er stakken de kjører på. Det er ikke nok å delegere dette til serveradministratoren, du må forstå implikasjonene plattformen har på koden din.
Hvis du jobber med Rails, kan du lese Rails-koden og vite hvordan Ruby utføres av Apache. Hvis du jobber i Java, må du vite om konfigurasjonsalternativene. Hvis du bruker Perl, må du forstå hvordan du installerer Perl-moduler og konfigurerer dem.
Mystisk arbeid
Listen over 'hva vi bruker' inneholder mange ting, og gode utviklere hopper på det for å forstå hvordan alt dette mystiske arbeidet gjøres. Og når de først får det, går distribusjonene raskere, arbeidet distribueres jevnere, og alle er bare lykkeligere.
Kontinuerlig distribusjon og tilhørende praksis av devops blir så standard at enhver utvikler eller selskap som ikke praktiserer dette, setter seg opp for å bli forbigått. Noen andre vil begynne å gjøre det, og så blir de raskere enn deg.
Praktiske verktøy
Googling for 'devops' gir deg en ide om verktøyene disse karene bruker. Det handler ikke om PHP og MySQL, eller Rails. Det handler om å sende programvare og holde de risikable delene av prosjekter risikofrie. De konsentrerer seg om distribusjon, automatisering og å holde rørledningen fra utvikler til produksjonsmiljø så raskt som mulig.
Du vil finne at denne utviklingsstilen gir deg utviklere som jobber bedre med hverandre og med andre avdelinger og selskaper. Hvis de jobber med en API fra en tredjepart, vil de forstå problemene som sannsynligvis vil komme opp på den andre siden. Når de jobber med serveradministratorene, forstår de hva de trenger installert og vet hvordan programvaresidene deres er på produksjonsservere. Det motsatte av dette kan være smertefullt ...
06. Dev ordner det ... kanskje
Det søket etter 'essensielle nettutviklerferdigheter' gir et hyggelig svar fra Michael Greer (The Onion's CTO) på Quora:
- Latskap: Nekter å gjøre noe to ganger: skriver et manus eller algo for det.
- Feighet: Tenker å teste, bekymringer for belastning og innvirkning på koden
- Uforsiktighet: Prøver hele tiden nye ting, lanserer ideer samme dag
Feighet er en fin måte å formulere 'oppmerksomhet på detaljer'. Feilsøking og testing er de 99 prosent av utviklernes levetid ingen nevnte da de traff W3Schools eller startet databehandlingskurset.
Evnen til å fikse apper krever gode problemer med å løse problemer, men ikke bare feilsøkingskode. Noen ganger er løsningen for at brukere ikke kan laste ned fakturaene sine, å gjøre siden utskrivbar, i stedet for å bruke en dag på å generere PDF-filer. Noen ganger kan en lenke erstatte en ukes utvikling, men den elegante løsningen vil ikke skje hvis devsene løser problemer bare ved å skrive mange kodelinjer.
Testing er et fantastisk blindspot for mange devs, til tross for mange verktøy der ute. Bruk enhetstester, selen, lastetesting og profileringsverktøy som xhprof. Analyse fra ting som New Relic for å holde appens fotavtrykk lite. Og vurder alt dette som en del av utviklerens jobb: det er koden din, sørg for at du vet at den fungerer etter hensikten i stedet for å håpe den gjør det.
Feilsøking
Feilsøking er også et sårt poeng. Ikke hvordan man bruker en feilsøking, men hvordan man feilsøker et problem - så jeg vil legge til Michael Greers liste:
- Utålmodighet: ignorerer aggressivt irrelevant informasjon for å finne og løse det virkelige problemet
Dette er hjørnesteinen i alle feilsøkingsteknikker. Å ignorere det irrelevante og finne mening i det aktuelle. Dessverre er mange tilbøyelige til å hamre det irrelevante slaverisk i flere timer eller dager, og fikse et problem ved å prøve det samme 10 ganger.
Det er mange bøker (dessverre ikke den jeg la til utgiveren jeg ikke vil nevne) om feilsøking, og hver utvikler bør lese dem alle. En virkelig god dev kan feilsøke problemer på et system uten å se en kodelinje.
07. Hva brukerne vil ha
Forstå hva menneskene rundt deg prøver å gjøre. Kos deg med koden - elske kunsten å innhente CSS-filer perfekt, eller optimalisere en rails-app - men husk at det hele er for et formål.
Utviklere trenger å forstå forretning, drift og forretningsprosesser fordi tingene deres hjelper til med å kjøre det. Devs med denne kunnskapen er i stand til å bygge programvare og apper som hjelper brukere, men de virker ofte uvanlig produktive. Dette kan være på grunn av deres hurtige belysning eller utrolig kunnskap om stabelen, men det er mer sannsynlig på grunn av deres kunnskap om hva brukerne vil ha.
Konkurranse marked
Når jeg går tilbake til mitt opprinnelige poeng, blir utviklingen enklere, og markedet for gode utviklere er mer konkurransedyktig for enhver utvikler som er i stand til å forstå forretningskravene og bringe noe utmerket for å møte dem, vil ha en fordel. Forstå markedet, kunder og hvorfor de mennesker skiller seg fra penger, hjelper alt.
Forstå dataene og hvordan de vil endres over tid. I utviklerens sinn bør de stille opp nye teknologier med utfordringene du har i dag eller ser komme. På denne måten, når du foreslår en fancy ny ide til MD eller en klient, vil den være basert på hva kundene virkelig ønsker, og du får budsjett / tid på det. (Derimot er det verste å være vitne til at utviklere pedd sin nye favorittteknologi som løsningen for alle våre sykdommer.)
Utviklere har mye kontroll - trenger de å vite hva hvert felt i databasen betyr for sluttbrukeren? Hvis vi endrer dataene, hva vil brukerne se? Finnes det en bedre måte å hjelpe brukerne på? Altfor ofte er synet til DB-administratorer at verden er en dårlig refleksjon av deres database i stedet for at deres database er en dårlig representasjon av den virkelige verden. Verden er rotete og overraskende full av kantsaker. Takle det, adm. DB.
08. Tegning og skriving
Tegning er den mest direkte måten å kommunisere hvordan ting vil være ut. Utviklere må kunne tegne ideene sine på tavle, papir og ølmatter.
Utviklere må være i stand til å prototype på papir, skrive ut skjermbilder og krangle på dem bare for å kommunisere intensjonen. Ikke stol på utvikleren som nikker, sier de har forstått og åpner redaktøren sin.
Mislykkes billig: den beste kodingen begynner med tegning som en rask prototype. Mislykkes oftere og sørg for at alle enhetene rundt deg gjør det samme som det er mer sannsynlig at du lykkes på den måten.
09. Kos deg
Og hva om du må bruke 10 timer på å løse et problem ved å flytte en lenke rundt? Kos deg med det - selv om det bare er utfordringen med å komme igjennom arbeidet.
Den aller verste holdningen fra utviklere (eller noen) er apati overfor hva teamet prøver å oppnå. Dessverre er dette vanlig, fordi utviklere ser på seg selv som utenfor det teamet oppnår. (Den lidenskapelige programmereren stiller spørsmålet, 'hvor mye morsommere kan du gjøre jobben din?' - prøv det.)
Og vær klar til å vise arbeidet ditt som det motsatte av dette er: ikke utvid etter å ha prøvd et par veiledninger om Ruby til 'Experience of Ruby'!
Nett- og apputvikling er fremdeles et ungt yrke, men ferdighetssettet som virkelig stort utviklingsbehov øker. Alle bør forvente mer av utviklere fordi jo tidligere vi alle kommer ut av det stygge bakrommet og blir involvert i den kreative prosessen, desto bedre blir resultatene.
10. Hold deg skarp
For å få dette til en fin runde 10 vil jeg legge til en siste ting. Hold deg skarp. Finn konkurranse. Den verste typen av noe er isolert.
"Vær alltid den verste fyren i hvert band du er i."
De verste - egentlig, veldig dårlige - programmerere, kodere, designere lærer sine ting og hviler på laurbærene. Uten pacemaker er det for lett å bremse, og uten å se konkurranse blir det vane å se deg selv over gjennomsnittet.
Så vær den verste du kan ved å finne bedre. Bli med på prosjekter utenfor arbeid, bidra og oppsøk tilbakemeldinger og kritikk, fordi jo mer kritikk du får, jo færre mennesker vil gi deg i fremtiden. Når du gjetter hva de vil ha bedre enn de er, så er du den ninjautvikleren alle vil ha.
Dan Frost er teknisk direktør for fullserviceselskapet 3EV, en offisiell AWS-partner. Han har jobbet med utvikling av CMS og webapp i sju år.
Likte dette? Les disse!
- Hvordan lage en app
- De beste gratis nettfonter for designere
- Oppdag hva som er neste for Augmented Reality
