Software wordt gebruikt door mensen, en ontwikkeld voor mensen.  

Analysten en klanten vragen om bepaalde kennis om te zetten in software.  Het is als een ware een digitalisering van deze kennis, onmogelijk zonder begrip van deze kennis.
Dus als developer moet je dus kunnen leren van mensen en mensen begrijpen wat ze willen.  En daarvoor heb je nodig, yep, social skills.

Sterker nog, kwaliteit is tegenwoordig gegarandeerd door communicatie tussen developers.

Enkele voorbeelden:

• Pair programming

• Mob programming

• Code reviews

• Rubber ducking

• Testing

• Software quality tools als flikkerlichten

• Scrum en aanverwanten

Pair programming.  In ons dagelijks leven maken we gebruik van pair programming zodra we aan iets complex moeten werken of iets waar we wat langer op moeten zoeken.  
Met 2 mensen achter 1 keyboard samenwerken, kijken naar dezelfde code en als gelijken discussiëren over een oplossing. 

Mob programming gaat zelfs verder en zit je tot wel met 5 mensen achter 1 scherm te werken.

Code reviews, waarbij je code nakijkt op bugs, verbeteringen, foutjes en dergelijke en dan feedback geeft aan de auteur van die code vraagt takt, respect en de nodige communicatieskills.

Rubber ducking, een beproefde methode waarbij je je code moet uitleggen aan persoon (of een rubberen eendje, vandaar de naam), zodat je confirmatie krijgt van je begrip van de code en waar het eventueel mis kan gaan.  Of welke scenarios je voorzien hebt.  Veel gebruikt tijdens het debuggen en soms ook lang uit 'rubber duck debugging' genoemd.  Bij One16 verkiezen rubber ducking boven googelen. 

Testing, kwaliteit zonder testing het bestaat niet.  Wat je kan testen, hoe je kan testen, het vraagt begrip van requirements van de gebruiker, begrip van het grotere plaatje. Bovendien zullen deze testen geautomatiseerd worden in een CI oplossing draaien. Wat ons weer brengt naar standaarden, guidelines en code quality tools enzoverder.
Bij de keuze van een component, framework of wat dan ook hebben we bij One16 enkele voorwaarden, namelijk het moet geautomatiseerd kunnen gebeuren.  Beslissingen hieromtrent vragen overleg.

Standaarden worden je uitgelegd, code quality tools geven je feedback.  Vulnerability scans geven rapporten, daar komen actiepunten uit.  Je neemt deze als developer nooit alleen op, maar als team. 
Al deze software tools werken als flikkerlichten, je moet over deze flikkerlichten communiceren om ze structureel op te lossen.  

Scrum en ander populaire methodologieën steunen op informatie door communicatie tussen het team.
Waarom gaat iets langer duren?
Waarom zit je vast, geblokkeerd?  
Wat ging er goed afgelopen sprint?  
Wat kunnen we verbeteren volgende keer?
Het argument "contra" tegen methodologieën zoals waterval is net het gebrek aan communicatie of althans de eenrichtingsverkeer in deze.

Bovenstaande voorbeelden, zijn nog maar een kleine greep, maar telkens niet mogelijk als je in je eentje in het donker zit te programmeren.

Daarom! Ben je een beginnend software developer?  
Start dan met werken aan je social skills!  Zeker zo belangrijk als je programmeer skills.