Technisch schrijven voor ontwikkelaars

HTML, CSS, JavaScript, Python, PHP, C++, Dart - er zijn zoveel programmeertalen en misschien spreek je er zelfs helemaal vloeiend in! Maar naarmate we meer en betere code willen schrijven, wordt de manier waarop we schrijven en communiceren in alledaagse taal steeds belangrijker... en misschien zelfs over het hoofd gezien.

De manier waarop we over en rond code schrijven, is aantoonbaar net zo belangrijk als de code zelf. En ondanks waar je op die lijn valt, zijn we het er allemaal over eens dat onze woorden de potentie hebben om zowel de effectiviteit van de code te helpen als te schaden.

In dit artikel wil ik schetsen hoe deze twee schijnbaar verschillende velden - programmeren en schrijven - samen kunnen komen en onze ontwikkelaarsvaardigheden naar een hoger niveau kunnen tillen.

Wacht, technisch schrijven? Ja, dat is precies wat ik bedoel. Ik geloof echt dat we in de een of andere zin allemaal schrijvers zijn. En ik ben hier om je een inleiding te geven met schrijftips, advies en voorbeelden over hoe het je zowel een betere ontwikkelaar als communicator kan maken.

Technisch schrijven is overal

Vorig jaar heeft het team achter de populaire Mac Git-client, Tower, ondervroeg meer dan 4,000 ontwikkelaars en ontdekte dat bijna 50% van hen tussen de 3-6 uur per dag aan het schrijven van code besteedde.

En ja, dat is een enquête die een mooie nichegroep peilt, maar ik kan me voorstellen dat velen van ons ergens in dat bereik vallen. Hoe dan ook, een ontwikkelaar schrijft niet 24/7 code, want zoals deze peiling suggereert, besteden we veel tijd aan andere dingen.

Dat kan zijn:

• een nieuwe functie demonstreren,
• het documenteren van die nieuwe functie,
• het bijwerken van een werkticket gerelateerd aan die nieuwe functie, of
• achterstallig werk om die nieuwe functie te ondersteunen.

Natuurlijk is er altijd tijd voor badkamerpauzes en ook voor Wordle.

Hoe dan ook, de meeste dingen die we doen, zijn communicatie met mensen zoals uw team, collega's, klanten, gebruikers en andere ontwikkelaars.

Dus we besteden een groot deel van onze tijd aan het communiceren met mensen via woorden naast de communicatie die we met computers hebben via code. Woorden zijn geschreven taal. En als we onze woorden beter zouden schrijven, zouden we beter communiceren. Als we beter communiceren, is de kans groter dat we krijgen wat we willen.

Dat is technisch schrijven 101.

En hier stopt het niet eens. Sommige programmeurs maken ook graag hun eigen producten, wat betekent dat ze marketing een deel van hun werk moeten maken. Technisch schrijven speelt daar ook een grote rol in. Dus ja. Ik denk dat het redelijk is om te zeggen dat technisch schrijven is inderdaad overal.

Wat is goede grammatica?

Met zoveel programmeertalen die er zijn, is het laatste wat we willen een andere leren.

Grammatica is een integraal onderdeel van het Engels en ontsluit het volledige potentieel van communicatie. Het maakt ons formeler, professioneler en coherenter.

Laat me je een kort overzicht geven van taal.

De Engelse syntaxis

Net als programmeertalen heeft Engels een goed gedefinieerde syntaxis en begint het met woorden.

Woorden zijn de bouwstenen van het Engels en vallen in acht emmers:

Denk aan deze als UI componenten: het zijn modulaire stukken die u kunt verplaatsen om een ​​complete en robuuste zin te construeren, op dezelfde manier waarop u een complete en robuuste zin zou samenstellen UI. Moeten alle componenten er altijd zijn? Zeker niet! Stel een zin samen met de stukjes die je nodig hebt om de ervaring te voltooien, net zoals je zou doen met een interface.

Stem en toon

Woordenschat, interpunctie, zinsbouw en woordkeuze. Dit zijn alle ingrediënten van het Engels. We gebruiken ze om ideeën uit te wisselen, te communiceren met onze vrienden en familie en om e-mails naar onze collega's te sturen.

Maar het is cruciaal om rekening te houden met de geluid van onze berichten. Het is verbazingwekkend hoe één uitroepteken de toon van een bericht volledig kan veranderen:

1. Ik hou van programmeren.
2. I als programmeren! :)

Het is gemakkelijk om stem voor toon te verwarren, en vice versa.

Stem is wat onze woordkeuze betreft, die van de context afhangt. Een tutorial voor beginners zal bijvoorbeeld eerder straattaal en informele taal gebruiken om een ​​vriendelijke stem over te brengen, terwijl documentatie op een formele, serieuze en professionele manier kan worden geschreven in een poging om meteen ter zake te komen.

Dezelfde boodschap, geschreven in twee verschillende stemmen:

• Lol: "Breid je sociale netwerk uit en blijf op de hoogte van wat er nu trending is."
• Echt: "Vind banen op een van de grootste apps voor sociale netwerken en de online banenmarkt."

Het is niet ongebruikelijk om per ongeluk berichten te schrijven die neerbuigend, beledigend en onprofessioneel overkomen. Dit is waar toon in het spel komt. Lees je berichten hardop voor, laat andere mensen ze voor je lezen en experimenteer met je interpunctie en zinsbouw. Zo scherp je je toon aan.

Hier is een andere manier om erover na te denken: je stem verandert nooit, maar je toon wel. Je stem is verwant aan wie je bent als persoon, terwijl toon is hoe je reageert in een bepaalde situatie.

Actieve en passieve stem

Een zin bevat altijd een acteur, een werkwoord en een doelwit. De volgorde waarin deze komen bepaalt of de zin met een actieve of passieve stem is geschreven.

De acteur komt op de eerste plaats in een actieve stem. Bijvoorbeeld: "CSS schildert de achtergrond."

Zinnen die een actieve stem gebruiken, zijn eenvoudiger dan hun tegenhangers. Ze zijn duidelijker, korter en begrijpelijker — perfect voor een professionelere stem die meteen ter zake komt.

Met een lijdende vorm, de acteur komt als laatste. (Zie je wat ik daar deed?) Dat betekent dat onze acteur - in dit geval CSS - aan het einde als volgt komt: "De achtergrond is geschilderd door CSS."

Lezers zetten een passieve stem meestal om in een actieve stem in hun hoofd, wat resulteert in meer verwerkingstijd. Als je ooit hebt gehoord dat schrijven met een actieve stem beter is, is dit meestal de reden waarom. Technische schrijvers geven meestal de voorkeur aan de actieve stem, op enkele uitzonderingen na, zoals het citeren van onderzoek: "Er is gesuggereerd dat ..."

Maar dat betekent niet dat je altijd moet streven naar een actieve stem. Als u van de ene naar de andere overschakelt - zelfs in dezelfde alinea - kan uw inhoud naadloos van de ene zin naar de andere vloeien als deze effectief wordt gebruikt.

Fouten vermijden

Grammatica heeft alles te maken met de structuur en correctheid van taal, en er is niets beters om dat te bereiken dan een snelle proeflezing van uw document. Het is erg belangrijk om je geschriften te ontdoen van spelfouten, grammaticale problemen en semantische onvolkomenheden.

Aan het einde van dit artikel laat ik je de onschatbare tools zien die professionals gebruiken om schrijffouten te voorkomen. Het is duidelijk dat er tegenwoordig in bijna alles ingebouwde spellingcontrole is; onze code-editors hebben zelfs plug-ins voor spellingcontrole en pluizen om fouten te voorkomen. 

Maar als u op zoek bent naar een alles-in-één hulpmiddel voor grammatica, Grammarly is een van de meest gebruikte tools. Ik krijg er geen smeergeld voor of zo. Het is gewoon een geweldig hulpmiddel dat veel redacteuren en schrijvers gebruiken om schone en duidelijke inhoud te schrijven - vergelijkbaar met hoe je Emmet, eslint of een andere linter zou kunnen gebruiken om schone en duidelijke code te schrijven.

Code-opmerkingen schrijven

De dingen die we voor andere ontwikkelaars schrijven, kunnen een grote impact hebben op de algehele kwaliteit van ons werk, of het nu gaat om wat we in de code schrijven, hoe we de code uitleggen of hoe we feedback geven op een stuk code.

Het is interessant dat elke programmeertaal wordt geleverd met een standaard set functies om een ​​opmerking te schrijven. Ze moeten uitleggen wat de code doet. Daarmee bedoel ik niet vage opmerkingen als deze:

red *= 1.2 // Multiply `red` by 1.2 and re-assign it

Gebruik in plaats daarvan opmerkingen die meer informatie geven:

red *= 1.2 // Apply a 'reddish' effect to the image

Het draait allemaal om context. “Wat voor programma ben ik aan het bouwen?” is precies het soort vraag dat je jezelf zou moeten stellen.

Opmerkingen moeten waarde toevoegen

Voordat we kijken naar wat een "goede" codecommentaar maakt, volgen hier twee voorbeelden van luie opmerkingen:

const age = 32 // Initialize `age` to 32

filter: blur(32px); /* Create a blur effect with a 32px radius */

Onthoud dat het doel van een opmerking is om waarde toe te voegen aan een stuk code, niet om het te herhalen. Als je dat niet kunt, kun je de code beter laten zoals hij is. Wat deze voorbeelden "lui" maakt, is dat ze alleen maar herhalen wat de code duidelijk doet. In dit geval zijn de opmerkingen overbodig omdat ze ons vertellen wat we al weten - ze voegen geen waarde toe!

Opmerkingen moeten de huidige code weerspiegelen

Achterhaalde opmerkingen zijn geen zeldzaamheid bij grote projecten; durf ik te zeggen in meest projecten.

Laten we ons David voorstellen, een programmeur en een allround coole kerel om mee om te gaan. David wil een lijst met strings alfabetisch van A tot Z sorteren, dus hij doet het voor de hand liggende in JavaScript:

cities = sortWords(cities) // sort cities from A to Z

David realiseert zich dan dat sortWords() eigenlijk lijsten sorteert van Z naar A. Dat is geen probleem, omdat hij de uitvoer eenvoudig kan omkeren:

cities = sortWords(cities) // sort cities from A to Z
cities = reverse(cities)

Helaas heeft David zijn codecommentaar niet bijgewerkt.

Stel je nu voor dat ik je dit verhaal niet heb verteld, en alles wat je zag was de bovenstaande code. Je zou natuurlijk denken dat na het uitvoeren van die tweede regel code, `steden` ​​van Z naar A zouden worden gesorteerd! Dit hele verwarringsfiasco werd veroorzaakt door een muffe opmerking.

Hoewel dit misschien een overdreven voorbeeld is, kan iets soortgelijks gebeuren (en gebeurt dat vaak ook) als je tegen een krappe deadline racet. Gelukkig kan dit worden voorkomen door één simpele regel te volgen... verander uw opmerkingen op hetzelfde moment dat u de code wijzigt.

Dat is een simpele regel die jou en je team een ​​hoop ellende zal besparen technische schuld.

Nu we weten hoe slecht geschreven opmerkingen eruit zien, laten we eens kijken naar enkele goede voorbeelden.

Opmerkingen moeten unidiomatische code verklaren

Soms het natuurlijk manier van doen is niet goed. Programmeurs moeten de standaarden misschien een beetje "breken", maar als ze dat doen, is het raadzaam om een ​​kleine opmerking achter te laten waarin hun redenering wordt uitgelegd:

 function addSetEntry(set, value) {    
  /* Don't return `set.add` because it's not chainable in IE 11. */  
  set.add(value);
  return set;
}

Dat is handig, toch? Als u verantwoordelijk was voor het controleren van deze code, bent u misschien in de verleiding gekomen om deze te corrigeren zonder dat die opmerking daar uitlegt wat er aan de hand is.

Opmerkingen kunnen toekomstige taken identificeren

Een ander nuttig ding om met opmerkingen te doen, is toegeven dat er meer werk aan de winkel is.

// TODO: use a more efficient algorithm
linearSort(ids)

Zo blijf je gefocust op je flow. En op een later tijdstip kunt u (of iemand anders) terugkomen om het te repareren.

Opmerkingen kunnen teruglinken naar de bron

Dus je hebt zojuist een oplossing voor je probleem gevonden op StackOverflow. Nadat u die code hebt gekopieerd en geplakt, is het soms een goede zaak om een ​​link te bewaren naar het antwoord dat u heeft geholpen, zodat u er later op terug kunt komen.

// Adds handling for legacy browsers
// https://stackoverflow.com/a/XXXXXXX

Dit is belangrijk omdat oplossingen kunnen veranderen. Het is altijd goed om te weten waar uw code vandaan komt voor het geval deze ooit breekt.

Pull-verzoeken schrijven

Pull-verzoeken (PRs) vormen een fundamenteel aspect van elk project. Ze vormen de kern van coderecensies. En code-reviews kunnen snel een knelpunt worden in de prestaties van uw team zonder goede bewoordingen.

Een goede PR beschrijving vat samen wat verandering wordt gemaakt en Waarom het wordt gemaakt. Grote projecten hebben een pull-aanvraagsjabloon, zoals deze aangepast van a echt voorbeeld:

## Proposed changes
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request.

## Types of changes
What types of changes does your code introduce to Appium?
 - [ ] Bugfix (non-breaking change which fixes an issue)
 - [ ] New feature (non-breaking change which adds functionality)
 - ...

## Checklist
 - [ ] I have read the CONTRIBUTING doc
 - [ ] I have signed the CLA
 - [ ] Lint and unit tests pass locally with my changes

## Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc…

Vermijd vaag PR titels

Vermijd titels die er als volgt uitzien:

• Bouw repareren.
• Probleem oplossen.
• Voeg pleister toe.

Deze doen het niet eens poging om te beschrijven met welke build, bug of patch we te maken hebben. Een beetje extra detail over welk deel van de build is gerepareerd, welke bug is geplet of welke patch is toegevoegd, kan een grote bijdrage leveren aan het tot stand brengen van betere communicatie en samenwerking met uw collega's. Het niveau-sets en krijgt mensen op dezelfde pagina.

PR titels worden traditioneel geschreven in gebiedende wijs. Ze zijn een samenvatting in één regel van het hele PR, en ze zouden moeten beschrijven wat wordt gedaan door de PR.

Hier zijn enkele goede voorbeelden:

• Ondersteuning van aangepaste srcset-attributen in NgOptimizedImage
• Standaard afbeeldingsconfiguratie tot 75% beeldkwaliteit
• Expliciete selectors toevoegen voor alle ingebouwde ControlValueAccessors

Vermijd lang PRs

Een grote PR betekent een enorme beschrijving, en niemand wil honderden of duizenden regels code bekijken, soms om uiteindelijk het hele ding af te wijzen!

In plaats daarvan kunt u:

• communiceer met je team via Problemen,
• een plan maken,
• het probleem opsplitsen in kleinere stukjes, of
• werk aan elk stuk afzonderlijk met zijn eigen PR.

Is het nu niet veel schoner?

Geef details in de PR lichaam

In tegenstelling tot het PR titel, het lichaam is de plaats voor alle details, waaronder:

• Waarom is de PR klaar zijn?
• Waarom is dit de beste aanpak?
• Eventuele tekortkomingen in de aanpak en ideeën om deze indien mogelijk op te lossen
• Het bug- of ticketnummer, benchmarkresultaten, enz.

Fouten melden

Bugrapporten zijn een van de belangrijkste aspecten van elk project. En alle geweldige projecten zijn gebaseerd op feedback van gebruikers. Meestal, zelfs na talloze tests, zijn het de gebruikers die de meeste bugs vinden. Gebruikers zijn ook geweldige idealisten en soms hebben ze ideeën voor functies; luister alsjeblieft naar ze!

Voor technische projecten wordt dit allemaal gedaan door problemen te melden. Een goed geschreven probleem kan een andere ontwikkelaar gemakkelijk vinden en erop reageren.

De meeste grote projecten worden bijvoorbeeld geleverd met: een sjabloon:

 <!-- Modified from angular-translate/angular-translate -->
 ### Subject of the issue
 Describe your issue here.

 ### Your environment
 * version of angular-translate
 * version of angular
 * which browser and its version

 ### Steps to reproduce
 Tell us how to reproduce this issue.

 ### Expected behavior
 Tell us what should happen.

 ### Actual behavior
 Tell us what happens instead.

Schermafbeeldingen verzamelen

Leg het probleem vast met uw het hulpprogramma voor schermopnamen van het systeem.

Als het een screenshot is van een CLI programma, zorg ervoor dat de tekst duidelijk is. Als het een UI programma, zorg ervoor dat de schermafbeelding de juiste elementen en toestanden vastlegt.

Mogelijk moet u een daadwerkelijke interactie vastleggen om het probleem aan te tonen. Als dat het geval is, probeer dan neem GIF's op met een tool voor schermopname.

Hoe het probleem te reproduceren?

Het is veel gemakkelijker voor programmeurs om een ​​bug op te lossen als deze live op hun computer staat. Daarom moet een goede commit komen met de stappen om het probleem precies te reproduceren.

Hier is een voorbeeld:

Update: you can actually reproduce this error with objects:

 ```html
 <div *ngFor="let value of objs; let i = index">
   <input [ngModel]="objs[i].v" (ngModelChange)="setObj(i, $event)" />
 </div>
 ```

 ```js
 export class OneComponent {
   obj = {v: '0'};
   objs = [this.obj, this.obj, this.obj, this.obj];
 ​
  setObj(i: number, value: string) {
     this.objs[i] = {v: value};
  }
 }
 ```

 The bug is reproducible as long as the trackBy function returns the same value for any two entries in the array. So weird behavior can occur with any duplicate values.

Stel een oorzaak voor

Jij bent degene die de bug heeft ontdekt, dus misschien kun je enkele mogelijke oorzaken suggereren waarom het er is. Misschien treedt de bug alleen op nadat je een bepaalde gebeurtenis tegenkomt, of misschien gebeurt het alleen op mobiel.

Het kan ook geen kwaad om de codebase te verkennen en misschien te achterhalen wat het probleem veroorzaakt. Dan wordt uw probleem veel sneller gesloten en wordt u waarschijnlijk toegewezen aan de gerelateerde PR.

Communiceren met klanten

Je werkt misschien als solo-freelancer, of misschien ben je de hoofdontwikkelaar van een klein team. Laten we in beide gevallen zeggen dat u verantwoordelijk bent voor de interactie met klanten op een project. 

Het stereotype van de programmeur is dat we slechte communicators zijn. Het is bekend dat we overdreven technisch jargon gebruiken, anderen vertellen wat wel en niet mogelijk is, en zelfs defensief worden als iemand onze aanpak in twijfel trekt.

Dus, hoe verminderen we dat stereotype? Vraag klanten wat ze willen en luister altijd naar hun feedback. Hier is hoe dat te doen.

Stel de juiste vragen

Begin door ervoor te zorgen dat u en de klant op dezelfde pagina staan:

• Wie is je doelgroep?
• Wat is het doel van de website?
• Wie is je naaste concurrent en wat doen ze goed?

Vragen stellen is ook een goede manier om positief te schrijven, vooral in situaties waarin u het niet eens bent met de feedback of beslissing van een klant. Door vragen te stellen, dwingt u die persoon om zijn eigen beweringen te ondersteunen in plaats van dat u hem aanvalt door uw eigen positie te verdedigen:

• Vindt u dat goed, zelfs als het gepaard gaat met extra prestatiekosten?
• Helpt het verplaatsen van het onderdeel ons om ons doel beter te bereiken?
• Geweldig, wie is verantwoordelijk om dat na de lancering te onderhouden? 
• Weet je toevallig of het contrast tussen die twee kleuren voldoet aan de WCAG AA-normen?

Vragen zijn veel onschuldiger en bevorderen nieuwsgierigheid boven vijandigheid.

Verkoop jezelf

Als u een pitch maakt voor een potentiële klant, moet u hen overtuigen om u in dienst te nemen. Waarom zou de klant voor jou moeten kiezen? Het is belangrijk om het volgende op te geven:

• Wie je bent
• Wat doe je
• Waarom jij geschikt bent voor de baan
• Links naar relevant werk dat je hebt gedaan

En als je eenmaal de baan hebt en een contract moet opstellen, onthoud dan dat er geen inhoud is die meer intimiderend is dan een stel juridische teksten. Ook al is het geschreven voor ontwerpprojecten, de Contractmoordenaar kan een mooi startpunt zijn om iets veel vriendelijkers te schrijven.

Uw aandacht voor detail kan het verschil zijn tussen u en een andere ontwikkelaar die hetzelfde project probeert te winnen. In mijn ervaring zullen klanten net zo gemakkelijk een ontwikkelaar inhuren waarvan ze denken dat ze het leuk vinden om mee te werken als degene die technisch het meest competent of ervaren is voor de baan.

Microkopie schrijven

Microkopie is de kunst van het gebruiksvriendelijk schrijven UI berichten, zoals fouten. Ik durf te wedden dat er tijden zijn geweest dat je als ontwikkelaar foutmeldingen moest schrijven omdat ze op een laag pitje stonden tot aan de starttijd.

Dat is misschien de reden waarom we soms fouten zoals deze zien:

Error: Unexpected input (Code 693)

Fouten zijn het laatste waar u uw gebruikers mee wilt laten omgaan. Maar ze gebeuren en we kunnen er niets aan doen. Hier zijn enkele tips om uw microkopievaardigheden te verbeteren.

Vermijd technisch jargon

De meeste mensen weten niet wat een server is, terwijl 100% van de programmeurs dat wel weten. Daarom is het niet ongebruikelijk om ongebruikelijke termen in een foutmelding te zien, zoals: API of "time-outuitvoering".

Tenzij u te maken heeft met een technische klant of gebruikersbestand, is het waarschijnlijk dat de meeste van uw gebruikers geen cursus informatica hebben gevolgd en niet weten hoe internet werkt en waarom een ​​bepaald ding niet werkt. Vandaar de fout.

Daarom zou een goede foutmelding niet moeten verklaren Waarom er is iets misgegaan, omdat voor dergelijke verklaringen misschien enge technische termen nodig zijn. Daarom is het erg belangrijk om technisch jargon te vermijden.

Geef nooit de gebruiker de schuld

Stelt u zich eens voor: ik probeer in te loggen op uw platform. Dus ik open mijn browser, bezoek uw website en voer mijn gegevens in. Dan krijg ik te horen: "Uw e-mail/wachtwoord is onjuist."

Ook al lijkt het dramatisch om te denken dat dit bericht vijandig is, het geeft me onbewust een dom gevoel. Microcopy zegt dat het nooit oké is om de gebruiker de schuld te geven. Probeer je bericht te veranderen in iets dat minder vingerpuntig is, zoals dit voorbeeld aangepast van de login van Mailchimp: “Sorry, die e-mail-wachtwoordcombinatie is niet juist. Wij kunnen u helpen uw account te herstellen.”

Ik wil er ook aan toevoegen hoe belangrijk het is om ALLE HOOFDLETTERS en uitroeptekens te vermijden! Natuurlijk kunnen ze worden gebruikt om opwinding over te brengen, maar in microkopie creëren ze een gevoel van vijandigheid jegens de gebruiker.

Overweldig de gebruiker niet

Het gebruik van humor in uw microkopie is een goed idee! Het kan de stemming verlichten en het is een gemakkelijke manier om de negativiteit te beteugelen die wordt veroorzaakt door zelfs de ergste fouten.

Maar als je het niet gebruikt volmaakt, kan het neerbuigend en beledigend overkomen op de gebruiker. Dat is gewoon een groot risico te nemen.

Mailchimp zegt het goed:

[D] ga niet uit de weg om een ​​grap te maken - geforceerde humor kan erger zijn dan helemaal geen. Als je het niet zeker weet, houd dan een strak gezicht.

(benadruk de mijne)

Toegankelijke opmaak schrijven

We zouden gemakkelijk een heel artikel kunnen besteden aan toegankelijkheid en hoe dit verband houdt met technisch schrijven. Heck, toegankelijkheid wordt vaak opgenomen in gidsen voor inhoudsstijlen, inclusief die voor Microsoft en MailChimp.

Je bent een ontwikkelaar en weet waarschijnlijk al zoveel over toegankelijkheid. Misschien ben je zelfs een van de meer ijverige ontwikkelaars die toegankelijkheid tot een essentieel onderdeel van je workflow maakt. Toch is het ongelooflijk hoe vaak toegankelijkheidsoverwegingen op een laag pitje worden gezet, ongeacht hoe belangrijk we allemaal weten dat het is om toegankelijke online ervaringen te maken die alle mogelijkheden omvatten.

Dus als u merkt dat u de copywriting van iemand anders in uw code implementeert, documentatie schrijft voor andere ontwikkelaars of zelfs schrijft UI kopieer jezelf, houd rekening met enkele fundamentele best practices voor toegankelijkheid, aangezien ze al het andere advies voor technisch schrijven completeren.

Dingen zoals:

Andy Bell biedt wat relatief kleine dingen die u kunt doen om inhoud toegankelijker te maken, en het is de moeite waard om ze te bekijken. En, gewoon voor de kick, John Rhea pronkt met een aantal handige bewerkingstrucs die mogelijk zijn als we met semantische HTML-elementen werken.

Conclusie

Dat waren zes manieren die laten zien hoe technisch schrijven en ontwikkelen samenvallen. Hoewel de voorbeelden en het advies misschien geen raketwetenschap zijn, hoop ik dat je ze nuttig vond, of het nu gaat om samenwerking met andere ontwikkelaars, het onderhouden van je eigen werk, je eigen exemplaar in een mum van tijd moeten schrijven, of zelfs het opstellen van een projectvoorstel, onder andere dingen.

Waar het op neerkomt: het aanscherpen van je schrijfvaardigheid en een beetje extra moeite doen om te schrijven, kan je zelfs een betere ontwikkelaar maken.

Hulpmiddelen voor technisch schrijven

Als je geïnteresseerd bent in technisch schrijven:

Als je geïnteresseerd bent in copywriting:

Als u geïnteresseerd bent in microkopie:

Als u geïnteresseerd bent in het gebruik van een professionele stijlgids om uw schrijven te verbeteren:

Als u geïnteresseerd bent om te schrijven voor toegankelijkheid: