Innehåll
- 01. Kodning skär det inte längre
- Bredd och djup
- 02. Den stora påminnelsen
- 03. Vad internet säger
- Förstå mediet
- 04. De saker vi bygger med
- 05. Devops
- Förstå stacken
- Mystiskt arbete
- Praktiska verktyg
- 06. Dev fixar det ... kanske
- Felsökning
- 07. Vad användare vill ha
- Konkurrensutsatt marknad
- 08. Rita och skriva
- 09. Njut av dig själv
- 10. Håll dig skarp
- Gillade detta? Läs dessa!
Utvecklare måste vara mer än kodgenererande gruntarbetare. Vi förväntar oss mer av vårt digitala liv och det är dessa killar som bygger det, så vad behöver de bästa utvecklarna veta? Här är de saker jag ser saknas för många utvecklare. Detta är inte uttömmande men det är dessa egenskaper som gör en rimlig kodare till en fantastisk utvecklare.
Men det är inte en sak, och det är särskilt aldrig förmågan att analysera XML eller optimera kod. Det är en överraskande samling färdigheter som inte lärs ut i böckerna om att skriva kod. De är lite extra.
Varför ventilera så här? Eftersom utveckling är viktig men utvecklare skickas alltför ofta till en annan värld, inte alltid av deras skapande. Detta fungerar aldrig. Utveckling - allt tekniskt - trivs alltid när de med kunskapen förstår mer än bara koden.
01. Kodning skär det inte längre
Vi befinner oss i en värld där kodning blir mindre imponerande. Alla bygger webbplatser, några av dem kodar men du behöver inte. Det är inte längre bara den nördiga som kan skapa webbplatser, appar och funktioner.
Sedan webben kom och människor kunde lära sig själva har det funnits självlärade utvecklare. Men även akademikerna hotas. Jag får CV med personer med datavetenskapliga examen, AI-kurser, olika media och kodning under deras bälte men det finns fortfarande något som saknas. Ibland saknas mycket.
Jag är inte den första som säger detta. 'Coding don't cut it no more' är titeln på kapitel 3 från Den passionerade programmeraren, som tillsammans med böcker som Pragmatiskt tänkande och lärande uppmana programmerare att förbättra sig utanför koden; att bli ansvarsfulla och helt mänskliga medlemmar i laget.
Bredd och djup
Utvecklare måste bli bättre på två sätt: bredd och djup. De måste förstå bredden av mänskliga interaktioner i sitt team och med de saker de bygger. De måste förstå djupet i systemet de arbetar med, ner till O / S.
Och det är inte bara utvecklare som borde läsa det här. Om du arbetar med utvecklare tror jag att du borde förvänta dig fler av dem. Låt dem skissera vad de pratar om. Få dem att förklara med bilder, föremål och (det fungerar) utklipp av människor exakt hur systemet kommer att se ut för människor som använder det.
02. Den stora påminnelsen
Jag kommer att prata negativt om utvecklare, men jag tror att jag är tillåten eftersom jag är en. Också för att åtminstone en sak jag pratar om här är sant för många av utvecklarna jag möter. Även om deras arbete är bra och de känner till sin kod, är tiderna konkurrenskraftiga. Du måste ha en kant, och det här är:
- vara mer teknisk
och
- vara mycket mer mänsklig
03. Vad internet säger
Googling för "väsentliga webbutvecklingsfärdigheter" visar vad du förväntar dig. Ramkunskap, x-browser, CSS och JS. De listar ramar som du borde känna till, plattformar du måste skriva för och nya trender du bör hålla ett öga på.
Det här är våra medier. Det är de saker vi bygger med, men det är inte det som ger ett projekt framgång. En utvecklare kan förstå alla detaljer i systemet, berätta alla funktioner i ett API och en ny CSS-teknik men ändå producera något oanvändbart.
Förstå mediet
Utvecklare, som alla, måste förstå sitt medium - men de måste också förstå publiken, vara användarna, teamet eller andra utvecklare. De måste förstå hur deras medium passar in i världen (med andra ord produktionsmiljön) och vilken effekt det har (hur människor använder det).
Jag har sett detta beskrivas som den ”breda och djupa” personen. Brett, för du måste förstå världen som en människa som arbetar med andra människor. Djupt för att du behöver grundlig teknisk kunskap under nivån för din del av projektet. Dessa utvecklare ger ditt projekt ett enormt lyft och förändrar projektets takt, utan vilken du inte kommer att hitta icke-teknisk personal fast i tråkiga detaljer som flyter från teknologiteamet.
04. De saker vi bygger med
Jag skrev nyligen ner en lista över allt vi använder för att bygga webbplatser, hantera webbhotell och få saker gjorda så att människor som går med kan ha ett fuskark med teknik att lära sig under de första veckorna. Vi tog det som läst att människor visste dessa saker, så för att ge nya rekryter en start bör vi lista allt vi använder varje dag.
Jag förväntade mig ett halvt dussin teknologier men slutade med mycket mer. Den här listan - 'vad vi använder' - innehåller vanliga CMS, programmeringsspråk och webbläsarteknik, men också en massa verktyg som teamet inte ens kom ihåg att de använde. Det var allt muskelminne. Att skriva 'git', 'phing', 'thor' på kommandoraden, vi trodde inte ens att någon kanske inte.
Bygg verktyg; Cl; git för versionskontroll togs för givet, men när man tittar tillbaka på CV såg de knappast upp. De trendiga verkar (och är det cyniskt att jag tror att vissa byråer lägger till dem ?!) men ofta utan konkret erfarenhet.
Dessa verktyg är viktiga för att påskynda projektutvecklingen, så se till att du har ett mycket rikare verktyg än ditt språk, CMS och ett par ramar. Du behöver distribution, testning, CI, stark versionskontroll (i team - inte ensam), och du måste förstå kärnkoncepten i dessa snarare än bara några tutorials.
05. Devops
Dessa extra verktyg och knep passar snyggt in i vad folk kallar 'devops'. Devops flyger inför två traditionella silor: produktion, som håller saker igång och utveckling, som gör nya saker (och ofta stoppar saker). Silorna resulterar i två läger med liten sympati för varandra.
Utvecklare utan produktionskunskap producerar oftare kod som inte är lämplig för produktion genom att använda konfigurationer eller funktioner som ännu inte finns i produktionsstacken. Eftersom de inte är medvetna om problemen i produktionsmiljön kodar de för att slutföra funktionen snarare än för att distribuera den till produktion.
Dessa små detaljer kan skapa smärtsamma förseningar, som förvärras av trenden för att skicka serverhantering utomlands.
Förstå stacken
Devops är ett stort fält i sig som omfattar kontinuerlig distribution och massor av automatisering. Det här är en omfattande sammanfattning, men det viktigaste som utvecklare behöver förstå är stacken de kör på. Det räcker inte att delegera detta till serveradministratören, du måste förstå vilka konsekvenser plattformen har på din kod.
Om du arbetar på Rails, läs Rails-koden och vet hur Ruby körs av Apache. Om du arbetar i Java ska du veta om konfigurationsalternativen. Om du använder Perl ska du förstå hur du installerar Perl-moduler och konfigurerar dem.
Mystiskt arbete
Listan ”vad vi använder” innehåller massor av dessa saker, och bra utvecklare hoppar på det för att förstå hur allt detta mystiska arbete görs. Och när de förstår det går distributionen snabbare, arbetet distribueras smidigare och alla är bara lyckligare.
Kontinuerlig distribution och relaterade metoder för devops blir så standard att alla utvecklare eller företag som inte praktiserar detta ställer in sig för att bli förbi. Någon annan börjar göra det och då blir de snabbare än du.
Praktiska verktyg
Googling för 'devops' ger dig en uppfattning om de verktyg dessa killar använder. Det handlar inte om PHP och MySQL eller Rails. Det handlar om att skicka programvara och hålla de riskabla bitarna av projekt riskfria. De koncentrerar sig på distribution, automatisering och att hålla rörledningen från utvecklare till produktionsmiljö igång så snabbt som möjligt.
Du kommer att upptäcka att denna utvecklingsstil ger dig utvecklare som arbetar bättre med varandra och med andra avdelningar och företag. Om de arbetar med ett API från en tredje part kommer de att förstå de problem som troligen kan komma på andra sidan. När de arbetar med serveradministratörerna förstår de vad de behöver installera och vet hur deras mjukvaruplatser finns på produktionsservrar. Det motsatta av detta kan vara smärtsamt ...
06. Dev fixar det ... kanske
Att söka efter ”väsentliga webbutvecklarkunskaper” ger ett trevligt svar från Michael Greer (The Onions CTO) på Quora:
- Lathet: Vägrar att göra någonting två gånger: skriver ett manus eller algo för det.
- Feghet: Tänker testa, oro över belastning och kodpåverkan
- Hänsynslöshet: Försöker ständigt nya saker, lanserar idéer samma dag
Feghet är ett trevligt sätt att formulera 'uppmärksamhet på detaljer'. Felsökning och testning är de 99 procent av utvecklarens liv som ingen nämnde när de träffade W3Schools eller startade datorkursen 101.
Förmågan att fixa appar kräver utmärkta problemlösningskunskaper, men inte bara felsökningskod. Ibland är lösningen för användare som inte kan ladda ner sina fakturor att göra sidan utskrivbar snarare än att spendera en dag på att skapa PDF-filer. Ibland kan en länk ersätta en veckas utveckling, men den eleganta lösningen kommer inte att hända om utvecklarna löser problem enbart genom att skriva många kodrader.
Testning är en underbar blindfläck för många devs, trots de många verktygen där ute. Använd enhetstester, selen, belastningstestning och profileringsverktyg som xhprof. Analys från saker som New Relic för att hålla appens fotavtryck litet. Och betrakta allt som en del av utvecklarens jobb: det är din kod, se till att du vet att den fungerar som avsedd snarare än hoppas att den gör.
Felsökning
Felsökning är också en öm punkt. Inte hur man använder en felsökare, men hur man felsöker ett problem - så jag skulle lägga till Michael Greers lista:
- Otålighet: ignorerar aggressivt irrelevant information för att hitta och lösa det verkliga problemet
Detta är hörnstenen i alla felsökningstekniker. Ignorera det irrelevanta och hitta mening i det relevanta. Tyvärr är många benägna att slaviskt hamra det irrelevanta i timmar eller dagar och fixa ett problem genom att försöka samma sak tio gånger.
Det finns många böcker (tyvärr inte den jag slog till utgivaren som jag inte kommer att namnge) om felsökning och varje utvecklare bör läsa dem alla. En riktigt bra dev kan felsöka problem i ett system utan att se en kodrad.
07. Vad användare vill ha
Förstå vad människorna omkring dig försöker göra. Njut av koden - älska konsten att inrycka CSS-filer perfekt eller optimera en rails-app - men kom ihåg att allt är för ett ändamål.
Utvecklare måste förstå affärer, verksamhet och affärsprocesser eftersom deras grejer hjälper till att driva det. Devs med denna kunskap kan bygga programvara och appar som hjälper användare, men de verkar ofta ovanligt produktiva. Detta kan bero på snabb belysning eller fantastisk kunskap om stacken, men det är mer sannolikt på grund av deras kunskap om vad användarna vill ha.
Konkurrensutsatt marknad
När jag går tillbaka till min ursprungliga punkt, blir utvecklingen enklare och marknaden för fantastiska utvecklare är mer konkurrenskraftig för alla utvecklare som kan förstå affärsbehovet och få något utmärkt att möta dem kommer att ha en fördel. Förstå marknaden, kunder och varför de människor delar med pengar hjälper allt.
Förstå informationen och hur den kommer att förändras över tiden. I utvecklarens sinne borde de ställa upp ny teknik med de utmaningar du har idag eller ser komma. På det här sättet, när du föreslår en snygg ny idé till MD eller en klient kommer den att baseras på vad kunderna verkligen vill ha och du får budget / tid på det. (Däremot är det värsta att bevittna att utvecklare säljer sin nya favoritteknologi som lösningen för alla våra sjukdomar.)
Utvecklare har mycket kontroll - behöver de veta vad varje fält i databasen betyder för slutanvändaren? Om vi ändrar data, vad kommer användarna att se? Finns det ett bättre sätt att hjälpa användarna? Alltför ofta är DB-administratörernas uppfattning att världen är en dålig återspegling av deras databas snarare än att deras databas är en dålig representation av den verkliga världen. Världen är rörig och förvånansvärt full av edge-cases. Hantera det, DB-administratörer.
08. Rita och skriva
Ritning är det mest direkta sättet att kommunicera hur saker kommer att se ut. Utvecklare måste kunna rita sina idéer på whiteboard, papper och ölmattor.
Utvecklare måste kunna prototypa på papper, skriva ut skärmdumpar och klottra på dem bara för att kommunicera sin avsikt. Lita inte på utvecklaren som nickar, säger att de förstår och öppnar sin redaktör.
Misslyckas billigt: den bästa kodningen börjar med att rita som en snabb prototyp. Misslyckas oftare och se till att alla utvecklare runt dig gör detsamma eftersom du är mer benägna att lyckas på det sättet.
09. Njut av dig själv
Och vad händer om du måste spendera 10 timmar på att lösa ett problem genom att flytta en länk? Njut av det - även om det bara är utmaningen att komma igenom arbetet.
Den allra sämsta inställningen från utvecklare (eller någon annan) är apati gentemot vad teamet försöker uppnå. Tyvärr är detta vanligt, eftersom utvecklare ser sig vara utanför vad teamet uppnår. (Den passionerade programmeraren ställer frågan ”hur roligare kan du göra ditt jobb?” - prova det.)
Och var redo att visa ditt arbete eftersom motsatsen till detta är: expandera inte efter att ha testat ett par självstudier om Ruby till 'Experience of Ruby'!
Webb- och apputveckling är fortfarande ett ungt yrke, men kompetensuppsättningen som verkligen stort utvecklingsbehov växer ut. Alla borde förvänta sig mer av utvecklare för ju tidigare vi alla kommer ut ur det otäcka bakrummet och blir involverade i den kreativa processen desto bättre blir resultaten.
10. Håll dig skarp
För att få detta till en trevlig runda 10 kommer jag att lägga till en sista sak. Håll dig skarp. Hitta konkurrens. Den värsta typen av någonting är en i isolering.
"Var alltid den värsta killen i varje band du är i."
De värsta - verkligen, de mycket dåliga - programmerare, kodare, designers lär sig sina saker och vilar på sina lagrar. Utan en pacemaker är det för lätt att sakta ner och utan att se konkurrens blir det vana att se dig själv över genomsnittet.
Så var det värsta du kan genom att hitta bättre. Gå med i projekt utanför arbetet, bidra och sök feedback och kritik eftersom ju mer kritik du får, desto mindre kommer folk att ge dig i framtiden. När du gissar vad de vill ha bättre än de är, är du den ninjautvecklare som alla vill ha.
Dan Frost är teknisk chef för fullserviceföretaget 3EV, en officiell AWS-partner. Han har arbetat med utveckling av CMS och webbappar i sju år.
Gillade detta? Läs dessa!
- Hur man bygger en app
- De bästa gratis webbteckensnitt för designers
- Upptäck vad som är nästa för Augmented Reality
