Een van de meest overbelaste beroepen door idioten is managers die programmeurs aansturen. Niet allemaal, maar degenen die zelf nooit programmeurs zijn geweest. Degenen die denken dat je efficiëntie kunt 'verhogen' (of 'effectiviteit' verhogen?) met methoden uit boeken. Zelfs niet de moeite nemen om die boeken echt te lezen — er is toch een video beschikbaar.
Degenen die nooit code hebben geschreven. Degenen voor wie Hollywood-films over programmeurs worden gemaakt — nou, die waar ze hun e-mail via de opdrachtregel bekijken. Degenen voor wie niets anders belangrijk is dan cijfers, deadlines en hun eigen salaris.
Degenen die de meerderheid vormen.
Maar ze zijn idioten om een andere reden. Ze willen efficiëntie, of op zijn minst effectiviteit (kom op, manager, zoek op wat het verschil is), zonder er enige kennis van te hebben. Helemaal zonder te begrijpen wat de essentie is, het proces van resultaat behalen, de verliezen die optreden in dit proces, en de kosten van ontwikkeling. Kortom, werken met een programmeur alsof ze een zwarte doos zijn.
Ze zijn als de brandweer in de programmering gekomen en dat om één reden: hier is hype, geld, de markt en een hoop andere idioten. Er is genoeg plek om je te verstoppen.
Als er hype was in de machineassemblage — dan zouden ze daar ook heen rennen. Slechte universelen. Ik zou niet verrast zijn als de man die in december kerstbomen op ons plein verkoopt, een IT-manager op vakantie is.
Kortom, als je de kans hebt, stuur deze jongens dan weg. Maak je geen zorgen, ze zullen wel werk vinden. Geen van hen zal ooit iets fatsoenlijks doen, totdat ze zelf programmeur worden. Omdat ze de essentie, het mechanisme, de logica van het proces dat ze aansturen niet begrijpen.
Nu genoeg over managers. Laten we het eens hebben over het onderwerp voor programmeurs. Hoe de efficiëntie van ontwikkeling te verhogen door goed code te leren schrijven.
Om de efficiëntie te verhogen, moet je taken sneller oplossen, zonder in te boeten op kwaliteit. Om taken sneller op te lossen, moet je leren om gelijkwaardige code te schrijven. En 'kwaliteit', en 'schrijven', en 'onmiddellijk'. Ik zal het uitleggen met een metafoor.
Goed code schrijven is als goed spreken in een vreemde taal. Wanneer je de taal niet kent, kost het veel tijd om je gedachten daarin te formuleren.
Als je snel iets moet zeggen, plak je gewoon wat woorden aan elkaar, vaak niet de juiste, vergeet je de lidwoorden, de juiste woordvolgorde, om nog maar te zwijgen over de tijden van werkwoorden en een slecht voorkomen.
Als er tijd is om een antwoord te formuleren, moet je een woordenboek of online vertaler openen en veel tijd besteden aan het formuleren van je gedachten. Je hebt echter nog steeds een onaangenaam gevoel: je zegt een antwoord en je weet niet of het juist is of niet. Hetzelfde geldt voor code – het lijkt alsof het klopt, maar of het van goede kwaliteit is, weet je niet.
Het resultaat is een dubbel verlies van tijd. Er gaat tijd verloren met het bedenken van een antwoord. Er gaat ook tijd verloren aan het formuleren van dat antwoord – en dat is eigenlijk best veel.
Als de vaardigheid om kwaliteitscode te schrijven aanwezig is, kan je het antwoord meteen formuleren, zodra het in je hoofd is opgekomen, zonder extra tijd te besteden aan vertalen.
De vaardigheid om kwaliteitscode te schrijven helpt bij het ontwerpen van de architectuur. Je gaat simpelweg geen verkeerde, niet realiseerbare of handmatige opties overwegen.
Samenvattend: de vaardigheid om kwaliteitscode te schrijven versnelt het oplossen van problemen aanzienlijk.
Maar dat is nog niet alles. Dankzij de management-lepel, is er één probleem – we hebben eigenlijk geen reden om kwaliteitscode te schrijven. De manager kijkt niet naar de code, de klant kijkt niet naar de code. We tonen elkaar zelden de code, alleen soms, in enkele projecten waar een aangewezen 'code-reviewer' is of periodieke refactoring plaatsvindt.
Het resultaat is dat in de meeste gevallen rommelcode in productie of naar de klant gaat. De persoon die rommelcode heeft geschreven, ontwikkelt een sterke neurale verbinding – rommelcode schrijven is niet alleen toegestaan, maar zelfs gewenst – het wordt geaccepteerd en ze worden er nog voor betaald ook.
Uiteindelijk heeft de vaardigheid om kwaliteitscode te schrijven helemaal geen kans om zich te ontwikkelen. De code die door een bepaalde medewerker is geschreven, wordt nooit gecontroleerd. De enige reden waarom hij normaal zou leren programmeren, is interne motivatie.
Maar deze interne motivatie komt in conflict met de plannen en eisen voor efficiëntie en productiviteit. Dit conflict wordt op duidelijke wijze niet opgelost in het voordeel van kwaliteitscode, want voor rommelcode wordt niet eens bekritiseerd. Maar voor het niet halen van de plannen – oh zeker.
Wat te doen? Ik zie en stel twee wegen voor die gecombineerd kunnen worden.
De eerste is om je code aan iemand binnen het bedrijf te tonen. Niet reactief (wanneer ze vragen of je het verplicht), maar proactief (hé, kijk eens naar mijn code, alsjeblieft). Het belangrijkste hier is om geen suikeren woorden aan te brengen, niet te proberen de kritiek op de code in beleefde vorm te gieten. Als de code slecht is, dan zeggen we dat: de code is slecht. Met toelichtingen, natuurlijk, en aanbevelingen over hoe het beter te maken.
Maar deze weg is ook niet ideaal. De toepasbaarheid hangt af van het moment waarop de verbinding plaatsvond. Als het werk al in productie is en blijkt dat de code slecht is, heeft het geen zin om het opnieuw te maken. Sterker nog, de kans is groot dat de metrics eronder lijden. Dan komen de managers met eisen over de efficiëntie. En probeer ze niet uit te leggen dat slechte code onvermijdelijk terugkomt in de vorm van bugs — dat komt jou alleen maar slecht uit. Je kunt alleen maar beloven dat je dit niet meer zo zal doen.
Als het werk echter nog niet is ingeleverd, of pas net is begonnen, dan kan het bekritiseren van de code (of het project, het idee) een heel praktisch nut hebben – de persoon zal het goed maken.
De tweede weg, de beste – is om in je vrije tijd aan open source-ontwikkeling te doen. Het doel is immers om ervoor te zorgen dat een heleboel programmeurs, juist programmeurs, je code zien en er iets van vinden. Binnen het bedrijf heeft niemand tijd. Maar programmeurs over de hele wereld hebben niets te doen, en als je iets nuttigs schrijft vanuit een praktisch perspectief, zullen ze zeker eens binnenkomen.
De belangrijkste zaak, mijns inziens – is het schrijven van code in je vrije tijd, omdat er dan geen tegenstrijdigheid zal zijn tussen de kwaliteit van de code en de snelheid van het resultaat. Schrijf gerust een jaar aan je ontwikkeling. Niemand zal je onder druk zetten qua deadlines, specificaties, financiën of een baas. Volledige vrijheid en creativiteit.
Alleen in vrije creativiteit zal je begrijpen en voelen wat geweldige code is, de schoonheid van programmeertalen en technologieën zien, de charme van zakelijke taken ervaren. En je leert ook om kwalitatief goede code te schrijven.
Echter, dit zal persoonlijke tijd van je vergen. Net als elke andere vorm van ontwikkeling. Beschouw dit niet als een uitgave, maar als een investering – in jezelf.
Bron: habr.com
