Fordelene og faldgruberne ved parprogrammering på arbejdspladsen

Parprogrammering er to programmører, der arbejder sammen på en arbejdsstation.

Formelt er en programmør driver og skriver kode. Den anden er observatøren eller navigatoren, der gennemgår hver kodelinje, når den er indtastet.

Uformelt sidder de sammen på en kodebase og snakker om ting og nedbryder problemer. En af dem kan skrive kode, og ingen af ​​dem gør noget andet som at tjekke telefonen.

Parprogrammering er bredt vedtaget af nogle organisationer og undgås af andre. Det er altid et emne for debat, og folk vil have deres præferencer. Vi er alle mennesker, og der er tidspunkter, hvor næsten alle kan drage fordel af parprogrammering.

Alligevel ser det ud som en ineffektiv anvendelse af ressourcer. Vi har to programmører. De kunne begge bygge forskellige funktioner i en uge, i slutningen vil vi have dobbelt så mange funktioner. Men dette er ikke tilfældet, og du kan meget vel ende med 2 sæt med 95% udførte funktioner, der ikke kan sendes. Programmering sammen kan øge nettomængden af ​​faktisk komplette funktioner, du sender.

Fordelene

Færre fejl og fejltagelser

Vi har alle haft skøre hårde bugs. Disse kan være fra grundlæggende fejl i hele tilgangen eller en skrivefejl, en forkert installation eller behovet for en genstart.

Som et hold er chancerne for, at en af ​​jer har lavet en lignende fejltagelse før. Eller det er sandsynligt, at en af ​​jer kender en anden, der har stødt på problemet. Og du er mere tilbøjelige til at afsætte den rigtige tid til et problem, før du går tilbage til tegnebrættet.

Du kan diskutere bedre strategier. Dette er bedre end at holde problemet skjult hele dagen uden at dele det med andre.

Lettere at fortsætte - Moralsk støtte

At arbejde som et team kan ofte øge positiviteten omkring et problem. Når nogen deler et problem, du går igennem, føler du dig mindre besejret og mere positiv til at prøve igen og igen og igen ...

Sværere at udsætte

At arbejde som et team betyder, at du ikke kan stoppe og kontrollere din e-mail, slap eller Whatsapp for enhver ønsket distraktion.

Dette virker som en lille ting. Men du kan firdoble det antal timer, en koder bruger i redaktøren og kode, i stedet for at sidde ved et skrivebord, der spiser timer på dagen indtil tid til at gå hjem.

Delt bedste praksis

Kodning sammen er en fantastisk måde at dele viden i din virksomhed. Kodere kan give hinanden tip, når de går sammen for at forbedre deres tilgang og øge deres hastighed.

Samarbejde kan muligvis afsløre viden, der muligvis ikke findes i din nye medarbejderhåndbog.

Hurtigere ombordstigning

Nye medarbejdere kan komme hurtigere op ved at parre dem med en erfaren teammedlem.

Identificer og reducer dårlige ansættelser

Det kan hjælpe med at identificere dårlige ansættelser tidligt, hvis nogen ikke passer til en virksomhed eller blev ansat til den forkerte rolle. Du kan gøre noget ved det tidligt, før du spilder begge parters tid.

Under et ansættelsesinterview vil et team, der er fortrolig med programmering af par, være bedre til at vurdere, om kandidaten kan programmere med andre. Hvis den normale fyr, der afholder interviewsessioner, er fraværende, kan du være sikker på, at en anden kan erstatte ham og give en retfærdig analyse.

Forøg medarbejdertilfredsheden

Kodning sammen kan bringe medarbejderne tættere på, når de deler erfaringer og har flere emner at tale om. Når andre mennesker forstår, hvad du holder på med, har du mere til fælles. Dette kan påvirke mange vigtige forretningsområder. Det kan endda forbedre samtaleemnerne til frokost for at reducere medarbejdernes churn.

Kodning kan være en ensom forfølgelse, når du står bag en computer alene og bliver bedt om at producere funktioner. Det er vigtigt at reducere enhver fremmedgørelse i en virksomhed. Dette er en af ​​grundene til, at jeg vil foreslå at have et system med parprogrammering til start-ups såvel som store virksomheder.

Problemer - når parring går dårligt

Parprogrammering kan ødelægge tingene og har brug for en fornuftig tilgang.

Overdriv det ikke (eller under gør det)

At tvinge folk til at tilbringe hele dagen sammen er ikke fornuftigt, og de kan godt ende med at hade hinanden.

1,5-2,5 timers burst fungerer normalt bedst. Less er for kort, og det er spild af tid.

Delt bidrag til belønning

Hvis du har givet vigtige deadlines til to programmører og derefter tildele den ene til at hjælpe den anden med hans opgave, er du på vej mod en potentiel katastrofe. Når du gennemgår, hvem der har afsluttet deres opgaver, og man føler, at de ikke har gjort noget, lider de personlige målinger. Mentalt er dette dårligt. Men hvis det er knyttet til et belønningssystem, skyder du dig selv i foden. Som scrummaster skal du sørge for, at du redegør for parring og tildele opgaver retfærdigt.

Trætte kodere

Mere kaffe og parring er ikke altid svaret. Når du er træt og stresset, kommunikerer du muligvis ikke ordentligt.

Dette kan forårsage flere problemer i koden og imellem hinanden. Nogle mennesker klarer sig bedre på denne måde, og andre gør det ikke, så du kan tage en risiko.

Kompleks kode - Parring eller diskussion

For mere kompleks kode kan det være en distraktion, der forsøger at parre sammen. Nogle gange kan det være mere fordelagtigt at sidde ned og forklare problemet.

Formelt at sidde sammen og skrive kode linje for linje kunne faktisk være distraherende.

Andre tanker

Men hvad med fjernarbejdere?

Medarbejdere, der arbejder eksternt, kan parre program med online skærmdelingsværktøjer. Jeg har debugged vennekode i Bruxelles, mens jeg sad på en cafe i Kasakhstan. Tro mig, det er muligt.

Noget bevis?

Dette er refleksioner fra mine oplevelser. Jeg har opfattet disse fordele, mens jeg arbejder med forskellige virksomheder og forskellige bootcamps.

Som videnskabsmand accepterer jeg, at jeg aldrig har lavet en dobbeltblind prøve på fordelene. Selvfølgelig har det aldrig været en stor nok prioritet i forhold til bare at få ting gjort.

Men jeg ville elske en undersøgelse med over 100 deltagere, der arbejder på det samme sæt problemer. Den ene gruppe på 50 kunne arbejde parvis, og den anden gruppe kunne arbejde alene. Jeg vil gerne se, hvad der sker. Det kan være en god undersøgelse for enhver datalogiprofessor at gøre.

Konklusion

Så som du kan se, er jeg fan af parprogrammering. Nogle kodere føler ikke, at det er en effektiv brug af deres tid. Hvis du er manager, er det op til dig at vurdere situationen og få mest muligt ud af dit team. Uanset hvad er det bestemt noget, som alle virksomheder til tider skal tillade.

Det skal implementeres dynamisk snarere end håndhæves. Enhver boot-camp skal inkorporere den i deres kurs for at opbygge en velafrundet kode.

Vi bruger det ofte i mit eget udviklingsagentur, fra at tackle vores sværeste problemer til at gå ombord på nyt personale. Det er en proces, vi nyder at bruge til at øge ydeevne og viden i hele virksomheden. Selvfølgelig håndhæver vi det ikke hele dagen og hver dag! Men vi kan lide det, og vi holder det.

Som det gamle ordsprog siger “ Et problem deles, er et problem halveret.

Jeg kører en podcast om væksttankegang og teknisk opstart. Hvis du nød dette, lærer du mere ved at abonnere.

Hvis du har brugt parprogrammering, vil jeg meget gerne høre dine tanker om det. Hvilke fremgangsmåder eller tip bruger du til at beslutte, hvornår du skal parre eller ej?