Inhoud
- 01. Codering snijdt het niet meer
- Breedte en diepte
- 02. Het grote voorbehoud
- 03. Wat het internet zegt
- Begrijp het medium
- 04. De dingen waarmee we bouwen
- 05. Devops
- Begrijp de stapel
- Mysterieus werk
- Handige tools
- 06. De ontwikkelaar lost het op ... misschien
- Foutopsporing
- 07. Wat gebruikers willen
- Concurrerende markt
- 08. Tekenen en schrijven
- 09. Geniet ervan
- 10. Blijf scherp
- Vond dit leuk? Lees deze!
Ontwikkelaars moeten meer zijn dan code-genererende gruntwerkers. We verwachten meer van ons digitale leven en het zijn deze jongens die het bouwen, dus wat moeten de beste ontwikkelaars weten? Dit zijn de dingen die ik zie ontbreken bij te veel ontwikkelaars. Dit is niet uitputtend, maar het zijn deze kwaliteiten die van een redelijke coder een geweldige ontwikkelaar maken.
Maar het is niet één ding, en het is vooral nooit de mogelijkheid om XML te ontleden of code te optimaliseren. Het is een verrassende verzameling vaardigheden die niet in de boeken over het schrijven van code worden geleerd. Ze zijn iets extra's.
Waarom zo ventileren? Omdat ontwikkeling er toe doet, maar ontwikkelaars worden te vaak naar een andere wereld verwezen, niet altijd van hun makelij. Dit werkt nooit. Ontwikkeling - al het technische - gedijt altijd als degenen met de knowhow meer begrijpen dan alleen de code.
01. Codering snijdt het niet meer
We bevinden ons in een wereld waarin coderen steeds minder indrukwekkend wordt. Iedereen bouwt sites, sommige coderen maar dat hoeft niet. Het is niet langer alleen de nerdy die sites, apps en functies kan maken.
Sinds het internet opkwam en mensen zichzelf konden leren, zijn er autodidactische ontwikkelaars. Maar zelfs de afgestudeerden worden bedreigd. Ik krijg cv's van mensen met een informatica-diploma, AI-cursussen, verschillende media en codering onder hun riem, maar er ontbreekt nog iets. Soms ontbreekt er veel.
Ik ben niet de eerste die dit zegt. ‘Codering snijdt het niet meer’ is de titel van hoofdstuk 3 uit De gepassioneerde programmeur, die samen met boeken zoals Pragmatisch denken en leren moedig programmeurs aan om zichzelf te verbeteren buiten de code om; om verantwoordelijke en volledig menselijke leden van het team te worden.
Breedte en diepte
Ontwikkelaars moeten op twee manieren beter zijn: breedte en diepte. Ze moeten de breedte van menselijke interacties in hun team en de dingen die ze bouwen, begrijpen. Ze moeten de diepte begrijpen van het systeem waarmee ze werken, tot aan de O / S toe.
En het zijn niet alleen ontwikkelaars die dit materiaal zouden moeten lezen. Als je met ontwikkelaars werkt, denk ik dat je er meer van mag verwachten. Laat ze schetsen waar ze het over hebben. Laat ze met afbeeldingen, objecten en (het werkt) uitsneden van mensen precies uitleggen hoe het systeem eruit zal zien voor de mensen die het gebruiken.
02. Het grote voorbehoud
Ik ga negatief praten over ontwikkelaars, maar ik denk dat ik dat mag omdat ik er een ben. Ook omdat tenminste één ding waar ik het hier over heb, waar is voor veel van de ontwikkelaars die ik ontmoet. Hoewel hun werk geweldig is en ze hun code kennen, zijn de tijden competitief. Je moet een voorsprong hebben, en dit is:
- wees meer technisch
en
- worden veel meer menselijk
03. Wat het internet zegt
Door te zoeken naar ‘essentiële vaardigheden op het gebied van webontwikkeling’ komt u naar voren wat u zou verwachten. Framework kennis, x-browser, CSS en JS. Ze bevatten frameworks die u moet kennen, platforms waar u voor moet schrijven en nieuwe trends die u in de gaten moet houden.
Dit zijn onze media. Het zijn de dingen waarmee we bouwen, maar ze zijn niet wat een projectsucces geeft. Een ontwikkelaar kan elk detail van het systeem begrijpen, u elke functie van een API en een nieuwe CSS-technologie vertellen, maar toch iets onbruikbaar maken.
Begrijp het medium
Ontwikkelaars moeten, net als iedereen, hun medium begrijpen, maar ze moeten ook het publiek begrijpen, of dat nu de gebruikers, het team of andere ontwikkelaars zijn. Ze moeten begrijpen hoe hun medium in de wereld past (met andere woorden, de productieomgeving) en welk effect het heeft (hoe mensen het gebruiken).
Ik heb dit beschreven als de ’brede en diepe’ persoon. Breed, omdat je de wereld moet begrijpen als een mens die met andere mensen werkt. Diep omdat je gedegen technische kennis nodig hebt onder het niveau van jouw deel van het project. Deze ontwikkelaars geven uw project een enorme boost en veranderen het tempo van het project, zonder welke u niet-technisch personeel vastloopt in vervelende details die overlopen van het technische team.
04. De dingen waarmee we bouwen
Ik heb onlangs een lijst opgeschreven van alles wat we gebruiken om sites te bouwen, hosting te beheren en dingen gedaan te krijgen, zodat mensen die meedoen een spiekbriefje van technologieën kunnen krijgen om in hun eerste paar weken te leren. We gingen ervan uit dat mensen deze dingen wisten, dus om nieuwe rekruten een vliegende start te geven, hebben we alles opgesomd dat we elke dag gebruiken.
Ik verwachtte een half dozijn technologieën, maar eindigde met veel meer. Deze lijst - ‘wat we gebruiken’ - bevat de gebruikelijke CMS'en, programmeertalen en browsertechnologieën, maar ook een heleboel tools waarvan het team zich niet eens herinnerde dat ze ze gebruikten. Het was allemaal spiergeheugen. Door ’git’, ’phing’, ’thor’ op de opdrachtregel te typen, dachten we niet eens dat iemand dat misschien niet zou doen.
Bouw tools; CI; git voor versiebeheer werd als vanzelfsprekend beschouwd, maar terugkijkend op cv's verschenen deze nauwelijks. De trendy versies zouden verschijnen (en is het cynisch dat bepaalde bureaus ze volgens mij toevoegen ?!) maar vaak zonder concrete ervaring.
Deze tools zijn belangrijk voor het versnellen van projectontwikkeling, dus zorg ervoor dat je een veel rijkere toolset hebt dan je taal, het CMS en een paar frameworks. U hebt implementatie, testen, CI, sterk versiebeheer (in teams - niet alleen) nodig, en u moet de kernconcepten hiervan begrijpen in plaats van slechts een paar tutorials.
05. Devops
Deze extra tools en trucs passen perfect in wat mensen ‘devops’ noemen. Devops staat haaks op twee traditionele silo's: productie, die ervoor zorgt dat alles draait, en ontwikkeling, die nieuwe dingen maakt (en vaak stopt met draaien). De silo's resulteren in twee kampen met weinig sympathie voor elkaar.
Ontwikkelaars zonder productiekennis produceren vaker code die niet geschikt is voor productie, door gebruik te maken van configuratie of features die nog niet op de productiestack staan. Omdat ze zich niet bewust zijn van de problemen van de productieomgeving, coderen ze om de functie te voltooien in plaats van deze in productie te nemen.
Deze kleine details kunnen voor pijnlijke vertragingen zorgen, nog versterkt door de trend om het serverbeheer naar het buitenland te sturen.
Begrijp de stapel
Devops is een enorm veld op zich, dat continue inzet en veel automatisering omvat. Dit is een allesomvattende samenvatting, maar het belangrijkste dat ontwikkelaars moeten begrijpen, is de stack waarop ze draaien. Het is niet voldoende om dit aan de serverbeheerder te delegeren, u moet de implicaties van het platform voor uw code begrijpen.
Als je aan Rails werkt, lees dan de Rails-code en weet hoe Ruby wordt uitgevoerd door Apache. Als u in Java werkt, weet dan wat de configuratie-opties zijn. Als u Perl gebruikt, moet u weten hoe u Perl-modules installeert en configureert.
Mysterieus werk
De lijst ‘wat we gebruiken’ bevat veel van dit soort dingen, en goede ontwikkelaars springen erop in om te begrijpen hoe al dit mysterieuze werk wordt gedaan. En als ze het eenmaal hebben, gaan de implementaties sneller, wordt het werk soepeler uitgevoerd en is iedereen gewoon gelukkiger.
Voortdurende inzet en aanverwante praktijken van devops worden zo standaard dat elke ontwikkelaar of bedrijf dat dit niet beoefent, zichzelf wil ingehaald worden. Iemand anders zal het gaan doen en dan zijn ze sneller dan jij.
Handige tools
Googelen naar ’devops’ geeft je een idee van de tools die deze jongens gebruiken. Het gaat niet om PHP en MySQL, of Rails. Het gaat om het verzenden van software en het risicovrij houden van de risicovolle stukjes van projecten. Ze concentreren zich op implementatie, automatisering en het zo snel mogelijk laten verlopen van de pijplijn van ontwikkelaar naar productieomgeving.
U zult merken dat deze stijl van ontwikkeling u ontwikkelaars geeft die beter met elkaar en met andere afdelingen en bedrijven samenwerken. Als ze werken met een API van een derde partij, zullen ze de problemen begrijpen die zich waarschijnlijk aan de andere kant zullen voordoen. Wanneer ze met de serverbeheerders werken, zullen ze begrijpen wat ze moeten installeren en weten ze hoe hun softwaresites op productieservers staan. Het omgekeerde hiervan kan pijnlijk zijn ...
06. De ontwikkelaar lost het op ... misschien
Die zoektocht naar 'essentiële vaardigheden voor webontwikkelaars' levert een mooi antwoord op van Michael Greer (de CTO van The Onion) op Quora:
- Luiheid: weigert iets twee keer te doen: schrijft er een script of algo voor.
- Lafheid: denkt om te testen, maakt zich zorgen over belasting en code-impact
- Roekeloosheid: Probeert constant nieuwe dingen, lanceert ideeën voor dezelfde dag
Lafheid is een leuke manier om ‘aandacht voor detail’ te verwoorden. Foutopsporing en testen is de 99 procent van het leven van een ontwikkelaar die niemand noemde toen ze op W3Schools kwamen of aan de computer 101-cursus begonnen.
De mogelijkheid om apps te repareren vereist uitstekende probleemoplossende vaardigheden, maar niet alleen het debuggen van code. Soms is de oplossing voor gebruikers die hun facturen niet kunnen downloaden, om de pagina afdrukbaar te maken in plaats van een dag bezig te zijn met het genereren van pdf's. Soms kan een link een ontwikkelingsweek vervangen, maar die elegante oplossing zal niet gebeuren als de ontwikkelaars problemen oplossen door puur veel regels code te schrijven.
Testen is een geweldige blinde vlek voor veel ontwikkelaars, ondanks de vele tools die er zijn. Gebruik unit tests, selenium, load testing en profileringstools zoals xhprof. Analyse van zaken als New Relic om de voetafdruk van uw app klein te houden. En beschouw dit allemaal als onderdeel van de taak van de ontwikkelaar: het is jouw code, zorg ervoor dat je weet dat het werkt zoals bedoeld in plaats van te hopen dat het werkt.
Foutopsporing
Foutopsporing is ook een pijnlijk punt. Niet hoe je een debugger moet gebruiken, maar hoe je een probleem moet debuggen - dus ik zou aan de lijst van Michael Greer toevoegen:
- Ongeduld: negeert agressief irrelevante informatie om het echte probleem te vinden en op te lossen
Dit is de hoeksteen van alle foutopsporingstechnieken. Het irrelevante negeren en betekenis vinden in het relevante. Helaas zijn velen geneigd om uren of dagen slaafs op het irrelevante te hameren en een probleem op te lossen door 10 keer hetzelfde te proberen.
Er zijn veel boeken (helaas niet degene die ik voor de uitgever heb gepitcht die ik niet zal noemen) over foutopsporing en elke ontwikkelaar zou ze allemaal moeten lezen. Een echt geweldige ontwikkelaar kan problemen op een systeem debuggen zonder een regel code te zien.
07. Wat gebruikers willen
Begrijp wat de mensen om je heen proberen te doen. Geniet van de code - hou van de kunst van het perfect inspringen van CSS-bestanden of het optimaliseren van een rails-app - maar onthoud dat het allemaal met een doel is.
Ontwikkelaars moeten het bedrijf, de bedrijfsvoering en de bedrijfsprocessen begrijpen, want hun spullen helpen het uitvoeren ervan. Ontwikkelaars met deze kennis kunnen software en apps bouwen die gebruikers helpen, maar ze lijken vaak buitengewoon productief. Dit kan zijn vanwege hun bliksemsnelle typen of geweldige kennis van de stapel, maar het is waarschijnlijker vanwege hun kennis van wat gebruikers willen.
Concurrerende markt
Terugkomend op mijn oorspronkelijke punt: die ontwikkeling wordt gemakkelijker en de markt voor geweldige ontwikkelaars is competitiever. Elke ontwikkelaar die de zakelijke vereisten begrijpt en iets uitstekends brengt om eraan te voldoen, zal een voorsprong hebben. Begrijp de markt, klanten en waarom zij mensen afscheid nemen van geld helpt allemaal.
Begrijp de gegevens en hoe deze in de loop van de tijd zullen veranderen. In de ogen van de ontwikkelaar moeten ze nieuwe technologieën in lijn brengen met de uitdagingen die je vandaag hebt of ziet aankomen. Op deze manier, wanneer u een leuk nieuw idee voorstelt aan de arts of aan een klant, wordt het gebaseerd op wat de klanten echt willen en krijgt u er het budget / de tijd voor. (Het ergste dat je kunt zien, is daarentegen dat ontwikkelaars hun nieuwe favoriete technologie verkopen als de oplossing voor al onze kwalen.)
Ontwikkelaars hebben veel controle - moeten ze weten wat elk veld in de database betekent voor de eindgebruiker? Als we de gegevens wijzigen, wat zullen de gebruikers dan zien? Is er een betere manier om de gebruikers te helpen? Te vaak is de mening van DB-beheerders dat de wereld een slechte weerspiegeling is van hun database in plaats van dat hun database een slechte weergave is van de echte wereld. De wereld is een puinhoop en verrassend vol met randgevallen. Regel het maar, DB-beheerders.
08. Tekenen en schrijven
Tekenen is de meest directe manier om te communiceren hoe dingen eruit zullen zien. Ontwikkelaars moeten hun ideeën kunnen tekenen op whiteboard, papier en bierviltjes.
Ontwikkelaars moeten prototypen op papier kunnen maken, schermafbeeldingen kunnen afdrukken en erop kunnen krabbelen om hun intentie kenbaar te maken. Vertrouw de ontwikkelaar niet die knikt, zegt dat hij het begrijpt en zijn editor opent.
Goedkoop mislukken: de beste codering begint met tekenen als een snel prototype. Faal vaker en zorg ervoor dat alle ontwikkelaars om je heen hetzelfde doen, want op die manier is de kans groter dat je succes hebt.
09. Geniet ervan
En wat als u 10 uur moet besteden aan het oplossen van een probleem door een link te verplaatsen? Geniet ervan - ook al is het maar een uitdaging om door het werk te komen.
De ergste houding van ontwikkelaars (of wie dan ook) is apathie voor wat het team probeert te bereiken. Helaas komt dit vaak voor, omdat ontwikkelaars zichzelf zien als buiten het bereik van het team. (De gepassioneerde programmeur stelt de vraag: 'hoeveel leuker zou je je baan kunnen maken?' - probeer het.)
En wees voorbereid om je werk te laten zien, want het omgekeerde hiervan is: breid niet uit nadat je een paar tutorials over Ruby hebt uitgeprobeerd tot ’Experience of Ruby’!
Web- en app-ontwikkeling is nog een jong beroep, maar de vaardigheden die echt groot zijn voor ontwikkelaars, worden steeds groter. Iedereen zou meer van ontwikkelaars moeten verwachten, want hoe eerder we allemaal uit de vervelende achterkamer komen en betrokken raken bij het creatieve proces, hoe beter de resultaten zullen zijn.
10. Blijf scherp
Om dit tot een mooie ronde 10 te brengen, zal ik nog een laatste ding toevoegen. Blijf scherp. Zoek concurrentie. Het ergste van alles is er een op zichzelf staand.
"Wees altijd de slechtste man in elke band waar je in zit."
De ergste - echt, de ergste - programmeurs, programmeurs, ontwerpers leren hun spullen en rusten op hun lauweren. Zonder pacemaker is het te gemakkelijk om te vertragen en zonder concurrentie te zien wordt het een gewoonte om jezelf bovengemiddeld te zien.
Wees dus het ergste wat je kunt door betere te vinden. Doe mee aan projecten buiten het werk, draag bij en zoek feedback en kritiek, want hoe meer kritiek je krijgt, hoe minder mensen je in de toekomst zullen geven. Als je raadt wat ze beter willen dan ze zijn, dan ben jij de ninja-ontwikkelaar die iedereen wil.
Dan Frost is technisch directeur van fullservice webbedrijf 3EV, een officiële AWS-partner. Hij werkt al zeven jaar in de ontwikkeling van CMS en webapps.
Vond dit leuk? Lees deze!
- Hoe een app te bouwen
- De beste gratis weblettertypen voor ontwerpers
- Ontdek wat de toekomst biedt voor Augmented Reality
