Indhold
- 01. Kodning klipper det ikke mere
- Bredde og dybde
- 02. Den store advarsel
- 03. Hvad internettet siger
- Forstå mediet
- 04. De ting, vi bygger med
- 05. Devops
- Forstå stakken
- Mystisk arbejde
- Praktiske værktøjer
- 06. Dev ordner det ... måske
- Fejlretning
- 07. Hvad brugerne ønsker
- Konkurrencepræget marked
- 08. Tegning og skrivning
- 09. Nyd dig selv
- 10. Bliv skarpe
- Kan du lide dette? Læs disse!
Udviklere skal være mere end kodegenererende gruntarbejdere. Vi forventer mere af vores digitale liv, og det er disse fyre, der bygger det, så hvad skal de bedste udviklere vide? Her er de ting, jeg ser mangler fra for mange udviklere. Dette er ikke udtømmende, men det er disse kvaliteter, der forvandler en rimelig kode til en fantastisk udvikler.
Men det er ikke en ting, og det er især aldrig evnen til at analysere XML eller optimere kode. Det er en overraskende samling af færdigheder, der ikke undervises i bøgerne om at skrive kode. De er lidt ekstra.
Hvorfor lufte sådan her? Fordi udvikling betyder noget, men udviklere sendes for ofte til en anden verden, ikke altid af deres oprettelse. Dette fungerer aldrig. Udvikling - alt teknisk - trives altid, når de med knowhow forstår mere end bare koden.
01. Kodning klipper det ikke mere
Vi er i en verden, hvor kodning bliver mindre imponerende. Alle bygger websteder, nogle af dem koder, men det behøver du ikke. Det er ikke længere bare den nørdede, der kan oprette websteder, apps og funktioner.
Siden internettet kom, og folk kunne lære sig selv, har der været selvlærte udviklere. Men selv kandidaterne er truet. Jeg får CV'er med folk med datalogi, AI-kurser, forskellige medier og kodning under deres bælte, men der mangler stadig noget. Nogle gange mangler meget.
Jeg er ikke den første til at sige dette. 'Coding don't cut it more more' er titlen på kapitel 3 fra Den lidenskabelige programmør, som sammen med bøger som f.eks Pragmatisk tænkning og læring opfordre programmører til at forbedre sig ud over koden; at blive ansvarlige og helt menneskelige medlemmer af holdet.
Bredde og dybde
Udviklere skal være bedre på to måder: bredde og dybde. De har brug for at forstå bredden af menneskelige interaktioner i deres team og med de ting, de bygger. De har brug for at forstå dybden af det system, de arbejder med, ned til O / S.
Og det er ikke kun udviklere, der skal læse disse ting. Hvis du arbejder med udviklere, synes jeg, du skal forvente flere af dem. Få dem til at skitsere, hvad de taler om. Få dem til at forklare med billeder, objekter og (det fungerer) udskæringer af mennesker præcis, hvordan systemet vil være for de mennesker, der bruger det.
02. Den store advarsel
Jeg vil tale negativt om udviklere, men jeg tror, jeg har lov, fordi jeg er en. Også fordi mindst én ting, jeg taler om her, gælder for mange af de udviklere, jeg møder. Selvom deres arbejde er fantastisk, og de kender deres kode, er tiderne konkurrencedygtige. Du skal have en kant, og dette er:
- vær mere teknisk
og
- være meget mere menneskelig
03. Hvad internettet siger
Googling efter 'væsentlige webudviklingsevner' bringer det, du forventer. Framework-viden, x-browser, CSS og JS. De viser rammer, du bør kende, platforme, du skal skrive og nye tendenser, du skal holde øje med.
Dette er vores medier. Det er de ting, vi bygger med, men det er ikke det, der giver et projektsucces. En udvikler kan forstå alle detaljer i systemet, fortælle dig alle funktioner i en API og en ny CSS-teknologi, men producerer stadig noget ubrugeligt.
Forstå mediet
Udviklere skal, som alle, forstå deres medium - men de skal også forstå publikum, være brugerne, teamet eller andre udviklere. De har brug for at forstå, hvordan deres medium passer ind i verden (med andre ord produktionsmiljøet) og hvilken effekt det har (hvordan folk bruger det).
Jeg har set dette beskrevet som den 'brede og dybe' person. Bredt, fordi du har brug for at forstå verden som et menneske, der arbejder med andre mennesker. Dybt, fordi du har brug for grundig teknisk viden under niveauet for din del af projektet. Disse udviklere giver dit projekt et kæmpe løft og ændrer tempoet i projektet, uden hvilket du ikke finder ikke-teknisk personale fast i kedelige detaljer, der flyder over fra teknologiteamet.
04. De ting, vi bygger med
Jeg skrev for nylig en liste over alt, hvad vi bruger til at opbygge websteder, administrere hosting og få ting gjort, så folk, der deltager, kunne have et snydeark af teknologier at lære i deres første par uger. Vi tog det som læst, at folk vidste disse ting, så for at give nye rekrutter et spring, ville vi liste alt, hvad vi bruger hver dag.
Jeg forventede et halvt dusin teknologier, men endte med langt mere. Denne liste - 'hvad vi bruger' - inkluderer de sædvanlige CMS'er, programmeringssprog og browserteknologier, men også en masse værktøjer, som teamet ikke engang huskede at have brugt. Det var alt muskelhukommelse. At skrive 'git', 'phing', 'thor' på kommandolinjen troede vi ikke engang, at nogen måske ikke gjorde det.
Byg værktøjer; CI; git til versionskontrol blev taget for givet, men når man ser tilbage på CV'er, kom disse næppe frem. De trendy ser ud (og er det kynisk, at jeg tror, at visse bureauer tilføjer dem ?!), men ofte uden konkret erfaring.
Disse værktøjer er vigtige for at fremskynde projektudviklingen, så sørg for at have et langt rigere værktøjssæt end dit sprog, CMS og et par rammer. Du har brug for implementering, test, CI, stærk versionskontrol (i teams - ikke alene), og du skal forstå kernebegreberne i disse snarere end blot et par tutorials.
05. Devops
Disse ekstra værktøjer og tricks passer pænt ind i, hvad folk kalder 'devops'. Devops flyver over for to traditionelle siloer: produktion, der holder tingene i gang, og udvikling, som gør nye ting (og ofte stopper tingene i at køre). Siloer resulterer i to lejre med ringe sympati for hinanden.
Udviklere uden produktionskendskab producerer oftere kode, der ikke er egnet til produktion, ved hjælp af konfiguration eller funktioner, der endnu ikke er på produktionsstakken. Fordi de ikke er opmærksomme på problemerne i produktionsmiljøet, koder de for at fuldføre funktionen i stedet for at implementere den til produktion.
Disse små detaljer kan skabe smertefulde forsinkelser, forværret af tendensen til at sende serveradministrationen til udlandet.
Forstå stakken
Devops er et stort felt i sig selv, der omfatter kontinuerlig implementering og masser af automatisering. Dette er et gennemgribende resumé, men det vigtigste, som udviklere skal forstå, er den stak, de kører på. Det er ikke nok at delegere dette til serveradministratoren, du skal forstå de implikationer, platformen har på din kode.
Hvis du arbejder på Rails, skal du læse Rails-koden og vide, hvordan Ruby udføres af Apache. Hvis du arbejder i Java, skal du vide om konfigurationsindstillingerne. Hvis det er Perl, du bruger, skal du forstå, hvordan du installerer Perl-moduler og konfigurerer dem.
Mystisk arbejde
Listen 'hvad vi bruger' indeholder masser af disse ting, og gode udviklere springer videre for at forstå, hvordan alt dette mystiske arbejde udføres. Og når de først har fået det, går implementeringerne hurtigere, arbejdet implementeres mere jævnt, og alle er bare lykkeligere.
Kontinuerlig implementering og tilknyttet praksis for devops bliver så standard, at enhver udvikler eller virksomhed, der ikke praktiserer dette, sætter sig op til at blive overhalet. En anden vil begynde at gøre det, og så bliver de hurtigere end dig.
Praktiske værktøjer
Googling efter 'devops' giver dig en idé om de værktøjer, disse fyre bruger. Det handler ikke om PHP og MySQL eller Rails. Det handler om at sende software og holde de risikable bits af projekter risikofrie. De koncentrerer sig om implementering, automatisering og at holde rørledningen fra udvikler til produktionsmiljø kørende så hurtigt som muligt.
Du finder ud af, at denne udviklingsstil giver dig udviklere, der arbejder bedre med hinanden og med andre afdelinger og virksomheder. Hvis de arbejder med en API fra en tredjepart, forstår de de problemer, der sandsynligvis vil komme op på den anden side. Når de arbejder med serveradministratorer, forstår de, hvad de har brug for installeret, og ved, hvordan deres softwaresites på produktionsservere. Det modsatte af dette kan være smertefuldt ...
06. Dev ordner det ... måske
Denne søgning efter 'væsentlige webudviklerfærdigheder' bringer et godt svar fra Michael Greer (The Onions CTO) på Quora:
- Dovenskab: nægter at gøre noget to gange: skriver et script eller algo for det.
- Fejhed: Tænker at teste, bekymrer sig over belastning og kodestød
- Hensynsløshed: Prøver konstant nye ting, lancerer ideer samme dag
Fejhed er en god måde at formulere 'opmærksomhed på detaljer'. Fejlfinding og test er de 99 procent af en udviklers liv, som ingen nævnte, da de ramte W3Schools eller startede computing 101-kurset.
Evnen til at rette apps kræver fremragende færdigheder til problemløsning, men ikke kun fejlretningskode. Undertiden er løsningen for brugere, der ikke kan downloade deres fakturaer, at gøre siden udskrivelig i stedet for at bruge en dag på at generere PDF-filer. Nogle gange kan et link erstatte en uges udvikling, men den elegante løsning sker ikke, hvis udviklerne løser problemer udelukkende ved at skrive mange linjer med kode.
Test er et vidunderligt blindspot for mange devs, på trods af de mange værktøjer derude. Brug enhedstest, selen, belastningstestning og profilering af værktøjer såsom xhprof. Analyse fra ting som New Relic for at holde din apps fodaftryk lille. Og overvej alt dette som en del af udviklerens job: det er din kode, sørg for at du ved, at den fungerer som beregnet snarere end at håbe den gør.
Fejlretning
Fejlfinding er også et ømt punkt. Ikke hvordan man bruger en debugger, men hvordan man debugger et problem - så jeg vil føje til Michael Greers liste:
- Utålmodighed: ignorerer aggressivt irrelevante oplysninger for at finde og løse det virkelige problem
Dette er hjørnestenen i alle fejlretningsteknikker. Ignorerer det irrelevante og finder mening i det relevante. Desværre er mange tilbøjelige til at hamre det irrelevante slavisk i timevis eller dage og løse et problem ved at prøve det samme 10 gange.
Der er mange bøger (desværre ikke den jeg slog til udgiveren, som jeg ikke vil nævne) om fejlretning, og enhver udvikler bør læse dem alle. En rigtig god dev kan fejle problemer på et system uden at se en kode.
07. Hvad brugerne ønsker
Forstå hvad folk omkring dig prøver at gøre. Nyd koden - elsk kunsten at indrykke CSS-filer perfekt eller optimere en rails-app - men husk, at det hele er til et formål.
Udviklere har brug for at forstå forretning, drift og forretningsprocesser, fordi deres ting hjælper med at køre det. Devs med denne viden er i stand til at oprette software og apps, der hjælper brugere, men de virker ofte usædvanligt produktive. Dette kan være på grund af deres hurtige typebelysning eller fantastiske kendskab til stakken, men det er mere sandsynligt på grund af deres viden om, hvad brugerne ønsker.
Konkurrencepræget marked
Når jeg går tilbage til mit oprindelige punkt, bliver udviklingen lettere, og markedet for store udviklere er mere konkurrencedygtig for enhver udvikler, der er i stand til at forstå forretningskravene og bringe noget fremragende til at imødekomme dem, vil have en fordel. Forstå markedet, kunderne, og hvorfor de mennesker deler med penge, hjælper alt sammen.
Forstå dataene, og hvordan de vil ændre sig over tid. I udviklerens sind skal de stille nye teknologier sammen med de udfordringer, du har i dag eller ser komme. På denne måde, når du foreslår en fancy ny idé til MD eller en klient, vil den være baseret på, hvad kunderne virkelig ønsker, og du får budgettet / tiden på det. (I modsætning hertil er det værste at være vidne til, at udviklere forkæler deres nye yndlingsteknologi som løsningen på alle vores sygdomme.)
Udviklere har meget kontrol - har de brug for at vide, hvad hvert felt i databasen betyder for slutbrugeren? Hvis vi ændrer dataene, hvad vil brugerne se? Findes der en bedre måde at hjælpe brugerne på? Alt for ofte er DB-admins opfattelse, at verden er en dårlig afspejling af deres database, snarere end at deres database er en dårlig repræsentation af den virkelige verden. Verden er rodet og overraskende fuld af kant-sager. Håndter det, DB admins.
08. Tegning og skrivning
Tegning er den mest direkte måde at kommunikere på, hvordan ting vil være. Udviklere skal være i stand til at tegne deres ideer på tavle, papir og ølmåtter.
Udviklere skal være i stand til at prototype på papir, udskrive skærmbilleder og klatre på dem bare for at kommunikere deres hensigt. Stol ikke på udvikleren, der nikker, siger at de har forstået og åbner deres redaktør.
Mislykkes billigt: den bedste kodning begynder med at tegne som en hurtig prototype. Mislykkes oftere og sørg for, at alle devs omkring dig gør det samme, da du er mere tilbøjelig til at få succes på den måde.
09. Nyd dig selv
Og hvad nu hvis du skal bruge 10 timer på at løse et problem ved at flytte et link rundt? Nyd det - selvom det bare er udfordringen at komme igennem arbejdet.
Den aller værste holdning fra udviklere (eller nogen) er apati over for, hvad holdet forsøger at opnå. Desværre er dette almindeligt, fordi udviklere ser sig selv som uden for det, holdet opnår. (Den lidenskabelige programmør stiller spørgsmålet, 'hvor meget sjovere kunne du gøre dit job?' - prøv det.)
Og vær klar til at vise dit arbejde, da det modsatte er: Udvid ikke efter at have prøvet et par tutorials om Ruby til 'Experience of Ruby'!
Web- og appudvikling er stadig et ungt erhverv, men det dygtige sæt, der er stort behov for devs, udvides. Alle bør forvente mere af udviklere, for jo hurtigere vi alle kommer ud af det grimme bagrum og bliver involveret i den kreative proces, desto bedre bliver resultaterne.
10. Bliv skarpe
For at bringe dette op til en dejlig runde 10 vil jeg tilføje en sidste ting. Bliv skarp. Find konkurrence. Den værste form for noget er isoleret.
"Vær altid den værste fyr i hvert band, du er i."
De værste - virkelig de meget dårlige - programmører, kodere, designere lærer deres ting og hviler på deres laurbær. Uden en pacemaker er det for let at bremse, og uden at se konkurrence bliver det vane at se dig selv over gennemsnittet.
Så vær den værste du kan ved at finde det bedre. Deltag i projekter uden for arbejdet, bidragsyd og søg feedback og kritik, fordi jo mere kritik du får, jo færre mennesker vil give dig i fremtiden. Når du gætter på, hvad de vil have bedre, end de er, så er du den ninjaudvikler, som alle ønsker.
Dan Frost er teknisk direktør for fullservicevirksomheden 3EV, en officiel AWS-partner. Han har arbejdet i CMS og webapp-udvikling i syv år.
Kan du lide dette? Læs disse!
- Sådan bygger du en app
- De bedste gratis webskrifttyper til designere
- Oplev hvad der er næste for Augmented Reality
