Er is een vreemd fenomeen ontstaan onder software-uitgevers. Mensen lijken de neiging te hebben om hun begrip van wat een kwaliteitsproduct beter maakt om te keren, of dat is tenminste waar als het gaat om degenen die de marketing doen. Het gaat ongeveer in de trant van: "Hun product heeft een miljoen regels code, maar dat van ons twee miljoen, dus daarom moet ons product beter zijn."
Niemand weet waar dit 'meer is meer'-denken vandaan kwam, toen iedereen vroeger zo hard werkte om een' minder is meer'-filosofie te creëren. Waarschijnlijk begon het met journalistiek van consumentenkwaliteit, want veel schrijvers proberen indruk te maken op het publiek door grote aantallen te citeren. Voor de meeste dingen werkt dit - deze kleine flashdrive kan 200 terabyte aan gegevens bevatten, die CPU kan 48 miljard instructies per seconde verwerken - en schrijvers zijn niet altijd technologisch onderlegd genoeg om te begrijpen dat hetzelfde niet van toepassing is op de broncode.
Maar efficiëntie in coderen gaat niet alleen over het maken van strakke algoritmen. Het gaat ook om het kunnen verminderen van verspilling. Dit betekent verspilling in termen van hoeveel tijd je kwijt bent aan het oplossen van problemen, verspilling in termen van het verbruiken van te veel computerhulpmiddelen en zelfs verspilling in termen van het aantal pizzadozen dat je team tegen het einde van de week op kantoor heeft gestapeld. In het ideale geval wilt u al deze dingen beperken.
Dus wat we in dit artikel zullen bekijken, zijn de dingen die je zou kunnen doen om de efficiëntie te verbeteren en de productiviteit te verhogen.
1. Bouw een gunstige werkomgeving
Elke codeur werkt in unieke omstandigheden en onze lezers zijn een zeer diverse groep, dus het zal voor sommigen van jullie gemakkelijker zijn om deze suggesties te implementeren dan voor anderen.
Als je een freelancer bent, gefeliciteerd, omdat je je eigen werkomgeving al beheerst. Dat gaat natuurlijk veranderen als je een klant gaat bezoeken en ter plekke moet werken, maar het is nog steeds een mooie positie om erbij te zijn als je er een succes van kunt maken.
Als u de manager bent van een ontwikkelingsteam, kunnen deze suggesties ook helpen om uw team maximale efficiëntie te geven. Of als u een medewerker van een ontwikkelingsteam bent, wilt u misschien een aantal van deze ideeën aan uw manager voorleggen of hem op zijn minst een link naar deze pagina sturen en er het beste van hopen.
Overweeg om teamleden te laten telewerken
Programmeren is deels een oefening in logica, maar het is zelfs meer een creatieve uitdaging. De beste programmeurs kunnen beide zijden van hun brein gebruiken in gelijk welke taak. De wetenschap heeft al lang erkend dat creatieve mensen hun best doen om 's nachts te werken, en het is iets dat we allemaal hebben meegemaakt. Dus waarom dringen de meeste managers aan op een traditionele 9 naar 5 routine?
Eigenlijk weten we al het antwoord daarop. Het gaat deels om controle, en het gaat er deels om zaken handiger te maken vanuit een zakelijk oogpunt (of op zijn minst een management-oogpunt). Maar dat aandringen op routine en locatie is schadelijk voor de efficiëntie en productiviteit van het team.
Wat je moet beseffen is dat je programmeurs waarschijnlijk de hele nacht de nieuwste game hebben uitgeprobeerd, of misschien gingen feesten of simpelweg moesten socializen met familie. Het betekent dat wanneer ze op maandagochtend op het werk verschijnen, je hen niet alleen op hun hoogste productiviteitsniveau krijgt, maar ze zijn nu al uitgeput van energie en moe van de hond.
Door werknemers een keuze te geven over wanneer ze werken - en idealiter ook waar - is dit een uitstekende manier om de productiviteit en het moreel te verbeteren. Zolang ze de klus hebben geklaard en uitstekende uitstekende resultaten hebben behaald, zou u zich niet moeten bekommeren om wanneer, waar of hoe ze dit bereiken.
De uitzondering is wanneer je nauwe samenwerking nodig hebt, maar in werkelijkheid doen de meeste coders het beter als ze dingen op hun eigen manier doen, en de noodzaak van nauwe samenwerking is zeldzaam. De mogelijkheid om naar kantoor te komen moet er nog steeds zijn, maar er is geen realistische reden waarom dit nodig zou zijn, tenzij je werkt aan geheime militaire projecten.
Als een freelancer zie je ook het belangrijkste punt hier is dat als je het meeste van je echte codeerwerk 's nachts doet, je waarschijnlijk meer gedaan krijgt. Er zijn minder afleidingen 's avonds laat, het is stiller en je zult je creatiever voelen.
Vermijd muziek
We hebben allemaal die waanzinnige filmstereotypen gezien waarbij een paar superfreaks überhacker hun koptelefoon opdoen en jammen op death-metal terwijl ze moeiteloos schermvullingen van code draaien zonder zelfs maar te stoppen om te ademen. En iedereen die echt in de echte wereld codeert, weet hoe belachelijk dat beeld is.
Maar als je tijdens het werken naar muziek luistert, wees dan voorzichtig. Het is vrij gemakkelijk om te merken dat je aan de muziek denkt in plaats van aan je werk, en sommige soorten muziek kunnen een slaapverwekkend effect hebben. Als je gaat trainen in de sportschool, kan de juiste soort muziek je inspireren om die extra paar herhalingen uit te drukken. Maar het is niemand ooit gelukt om muziek te maken die je zal inspireren om de lijn met de ontbrekende puntkomma te vinden, of om de juiste keuze te maken tussen een for-lus of een while-lus. Het dichtsbijzijnde dat we ooit zijn tegengekomen, is Electric Dreams.
Probeer netjes te houden
Rommel kan vreemd genoeg geruststellend zijn, maar het kan je ook vertragen. Je kunt gemakkelijk 20 minuten verliezen op zoek naar iets dat verloren is gegaan in de puinhoop, en dan vergeten waarom je het in de eerste plaats wilde hebben.
Dus, ondanks al het ongemak dat het veroorzaakt, waarom zijn we - sommigen van ons tenminste - zo verslaafd aan rommel? Organisatiedeskundige en auteur, Julie Morgenstern, beweert dat dit komt omdat dit spul ons verbindt met ons verleden en een rol speelt bij het bepalen van onze identiteit. Marcus Geduld, een leraar en regisseur gevestigd in New York City, suggereert dat rommel de voorkeur heeft boven een 'steriele' omgeving, en vergelijkt de chaos van rommel met een affirmvrijheid en creativiteit.
Het lijdt echter geen twijfel dat het verminderen van rommel u zal helpen afleiding en desorganisatie te voorkomen. Als zodanig is het een waardig doel om te bereiken. Houd in ieder geval een paar heilige voorwerpen in de buurt waardoor je je beter en minder gestrest voelt, maar overdrijf het niet. Opruimen is een van de moeilijkste dingen om te doen voor de meeste mensen, en het is niet alleen ons fysieke desktops die moeten worden opgeruimd, maar vaak onze computer desktops ook. Als je daar echt moeite mee hebt, zou je kunnen proberen een minimalistische DTE zoals Fluxbox te gebruiken, die je niet echt rommel toestaat.
Maar ga midden in dit opruimen niet overboord. Er is genoeg goede wetenschap die suggereert dat een beetje chaos in de omgeving in feite bevorderlijk kan zijn voor creativiteit. Een van de meest geciteerde stukjes onderzoek hiernaar is een dagboek in Psychological Science van Vohs, Redden & Rahinel voor de titel University of Minnesota Fysieke orde produceert gezonde keuzes, vrijgevigheid en conventionaliteit, terwijl stoornis creativiteit produceert. Waarschijnlijk is de reden waarom dit de papieren journalisten zijn die eraan vastklampen, dat er duidelijk wordt geconcludeerd dat: "... deelnemers in een wanordelijke kamer creatiever waren dan deelnemers in een ordelijke kamer."
Veel minder populair zijn afwijkende meningen, zoals Milieudisstoornis leidt tot zelfregulerend falen (Chaye & Zhu, 2014), gepubliceerd in het Journal of Consumer Research. Uit deze studie bleek dat mensen die in een ongeordende omgeving werkten, minder goed in staat waren om taken uit te voeren.
Waar ga je heen? Moet je in chaos of onvruchtbaarheid werken? Het antwoord lijkt te zijn om een balans te vinden waarbij het gewoon chaotisch genoeg is om je geïnspireerd te houden, maar niet zozeer dat je wordt afgeleid of problemen hebt om dingen te vinden.
Laat wat ruimte achter je om je gedachten te uiten
Het is een goed idee om voldoende ruimte te hebben om rond te dwalen als je overweegt. Veel van de beste admiraals en generaals in de geschiedenis stonden bekend om de lange tijd die ze brachten tijdens het plannen van gevechtsstrategieën.
Niet alleen vechtende mannen volgen deze praktijk. Veel boeddhistische monniken zijn ook voorstander van 'loopmeditatie' en geloven dat het helpt om de helderheid van de geest te bevorderen. Als je een bijzonder lastig programmeerprobleem hebt om op te lossen, kan het helpen om je benen een beetje te strekken met een meditatieve wandeling over het dek. Uiteraard helpt ook hier weer een gebrek aan rommel je om dit te doen zonder in het ziekenhuis te belanden.
Als een baas, neem een voorzichtige benadering van kritiek op creatieve inspanningen
Er is niets mis met constructieve kritiek, maar je moet het juiste moment kiezen en het op de juiste manier benaderen, of het kan averechts werken door je personeel in de toekomst minder productief te maken. In plaats van ze te inspireren en inzicht te geven, kun je ze in feite bang maken om risico's te nemen, wat een goede manier is om creativiteit de kop in te drukken. Marieke Roskes, in Beperkingen die helpen of Hinder creatieve prestaties: een motivationele aanpak, biedt een raamwerk voor het omgaan met motivatie van creatieve werknemers, en specifiek ook om te voorkomen dat ze onbedoeld worden gedemotiveerd (Creativity & Innovation Management, Vol 24, Iss 2, 2015).
2. Zorg voor een goede SOP
Er zijn veel pakkende trends in de bedrijfsvoering en programmeerprocedure die in theorie veel zinniger klinken dan ze in de praktijk blijken te zijn. Of een bepaalde aanpak voor u werkt of niet, hangt af van uw doel en wat u persoonlijk als een succesvol resultaat beschouwt.
Een voorbeeld van een methodologie die een bedrijf waar ik voor werkte probeerde - en net zo snel liet vallen - is pair-programmeren (niet te verwarren met PEAR-programmering). Terwijl sommige mensen deze werkmethodologie echt bewonderen en zijn plaats in het agile ontwikkelingsparadigma prijzen, vonden we dat het vreselijk inefficiënt was. Om te beginnen waren er twee programmeurs nodig voor elk werkstation, dus je betaalde twee keer zoveel voor minder echt ontwikkelingswerk. We ontdekten ook dat het veel langzamer was om op deze manier te werken vanwege de frequente stop / start-stroom en de neiging tot onnodige dialoog.
De voordelen van pair-programmering waren dat het resulteerde in meer natuurlijke documentatie en strengere documentatie. Het maakte het ook mogelijk om bugs gemakkelijker te herkennen en om suggesties te doen om een algoritme aan te scherpen. Tegelijkertijd leidden dezelfde voordelen echter ook tot problemen, omdat de aanpassingen en aanpassingen soms niet echt nodig waren.
Een ander risico met deze aanpak is dat je het effect kunt krijgen dat door Roskes is geïdentificeerd, waar programmeurs misschien aarzelend zijn om dingen te proberen omdat ze niet gecorrigeerd willen worden. Je kunt personageconflicten tegenkomen waarin de ene ontwikkelaar heel pedant en traditioneel is, maar de andere is creatiever en spontaner.
Programmeurs geven vaak aan dat ze liever programmeren met paren. Het is mogelijk dat dit komt omdat ze genieten van de sociale interactie die het biedt, maar dit draagt niets bij aan de efficiëntie van de productie, behalve misschien als een morele booster.
Dus wat u moet vaststellen, is wat echt werkt voor uw ontwikkelaars en wat niet. Voor de dingen die niet werken, is het beter om ze weg te gooien, zelfs als ze een fel trending practice zijn. Wat het team ook helpt om snel vooruitgang te boeken, is een goede zaak. Maar als ze worden belast met een methodiek die niet bij hun stijl past, zal dit uiteindelijk tot problemen leiden.
3. Moedig uitgebreide documentatie aan
Hoewel het lijkt alsof breedsprakigheid de inefficiëntie zou verhogen, kan de kleine hoeveelheid tijd die het kost om meer detail en precisie in opmerkingen te geven, veel problemen besparen wanneer het project meegaat of herzieningen ondergaat.
4. Ontmoedig onnodige documentatie
Goed geschreven code is vaak zelfdocumenterend. Als het volkomen duidelijk is wat een functie doet met de naam die je eraan geeft (wat bijna altijd het geval zou moeten zijn), dan is het toevoegen van meer beschrijving overbodig. Hetzelfde geldt voor variabele naam- en retourwaarden. Uit de naam moet duidelijk zijn wat ze doen en in die gevallen waarin dat niet mogelijk is, zou je een beschrijving daarvan in opmerkingen moeten opnemen.
5. Witte ruimte is je vriend
Het op de juiste manier gebruiken van witruimte in uw code is waardevol om te helpen de code leesbaarder, overzichtelijker en begrijpelijker te maken. Het gaat hand in hand met goede documentatie en het schrijven van zelfdocumenterende code. Elke ervaren programmeur - of misschien zelfs een niet-programmeur - zou een kopie van uw broncode moeten kunnen ophalen en onmiddellijk begrijpen wat het doel van elke functie is en hoe het werkt. Idealiter zou iemand moeten kunnen leren programmeren vanuit niets anders dan het bestuderen van je goed geschreven code.
6. Geef de voorkeur aan eenvoud boven complexiteit
Hoe complexer u uw code maakt, hoe moeilijker het kan zijn om het te ontwarren. Ironisch genoeg is dit van toepassing op het programmeren van snelkoppelingen, zoals het gebruik van steno-voorwaardes in plaats van ze volledig uit te schrijven. Het bespaart tijd bij het schrijven, maar een minder ervaren programmeur die binnenkomt om uw code later te beoordelen, begrijpt mogelijk niet wat u van plan bent.
7. Test uitgebreid
Code moet stapsgewijs en vaak worden getest. Voordat u iets implementeert, moet u zoveel mogelijk interne tests uitvoeren, zelfs als uw eerste release wordt aangeduid als Alpha.
8. Gebruik versiebeheer
Je zou gek moeten zijn om geen versiebeheer te gebruiken voor een groot project. Zonder dit, bent u niet beschermd tegen uw eigen kleine fouten, en is het ook heel gemakkelijk voor een ander teamlid om uw code per ongeluk (of opzettelijk) te saboteren door deze te overschrijven met iets dat u niet bevalt.
Door rekening te houden met deze acht belangrijkste suggesties, zult u in staat zijn om uw eigen strategie te ontwikkelen voor het extraheren van de meest efficiënte manier voor u en alle teamleden waarmee u werkt. Je hoeft ze niet allemaal toe te passen, en sommige zijn misschien zelfs niet praktisch voor je, maar elke combinatie van hen zal er waarschijnlijk toe leiden dat je je werk gedaan krijgt met minder gedoe. Een productievere workflow zal zichzelf in de loop van de tijd terugbetalen, ook al is het alleen maar in termen van stressvermindering en geeft u meer tijd voor uzelf. Dat is een doel dat de moeite waard is om te werken.
Heb je vragen? Stel ze hier. 0 Reacties