Een van de meest idiote beroepen zijn managers die programmeurs aansturen. Niet allemaal, maar degenen die zelf geen programmeur waren. Degenen die denken dat het mogelijk is om de efficiëntie te ‘verhogen’ (of de ‘efficiëntie’ te vergroten?) met behulp van methoden uit boeken. Zonder zelfs maar de moeite te nemen om dezelfde boeken te lezen, is de video een zigeunervideo.
Degenen die nog nooit code hebben geschreven. Degenen voor wie Hollywood-films over programmeurs zijn gemaakt - nou ja, degenen voor wie ze e-mail bekijken via de opdrachtregel. Degenen die in niets anders geïnteresseerd zijn dan indicatoren, deadlines en hun eigen salaris.
Zij die de meerderheid vormen.
Maar ze zijn om een andere reden idioten. Ze willen efficiëntie, of op zijn minst effectiviteit (kom op, manager, Google, wat is het verschil), zonder het een of het ander te begrijpen. Zonder in het algemeen de essentie te begrijpen, het proces om het resultaat te verkrijgen, de verliezen die in dit proces optreden, de ontwikkelingskosten. Kortom, samenwerken met een programmeur alsof hij een black box is.
Ze kwamen om precies één reden in aanraking met het management van programmeurs: er is een hype, geld, de markt en een stel dezelfde idioten. Er is een plek om te verdwalen.
Als er een hype zou zijn in de productie van mechanische assemblages, zouden we daarheen gaan. Stationwagons zijn waardeloos. Het zou mij niet verbazen als de man die in december bij ons in de buurt kerstbomen verkoopt, een IT-manager op vakantie is.
Kortom, schiet deze jongens indien mogelijk in de nek. Maak je geen zorgen, ze zullen wel een baan vinden. Geen van hen zal ooit iets fatsoenlijks doen totdat ze zelf programmeur worden. Omdat hij de essentie, het mechanisme en de logica van het proces dat hij controleert niet begrijpt.
Oké, genoeg over managers. Nu ter zake, voor programmeurs. Hoe u de ontwikkelingsefficiëntie kunt verhogen door code van hoge kwaliteit te leren schrijven.
Om de efficiëntie te vergroten, moet je problemen sneller oplossen zonder kwaliteitsverlies. Om problemen sneller op te lossen, moet je direct code van hoge kwaliteit kunnen schrijven. En “hoge kwaliteit”, en “schrijven”, en “onmiddellijk”. Laat me het uitleggen met een metafoor.
Het schrijven van code van hoge kwaliteit is als het correct spreken van een vreemde taal. Als je een taal niet kent, besteed je veel tijd aan het formuleren van je gedachten daarin.
Als je dringend iets moet zeggen, blijf je gewoon een paar woorden aanhouden, vaak niet de juiste, vergeet je lidwoorden, de juiste woordvolgorde, om nog maar te zwijgen van de werkwoordstijden en een slechte uitspraak.
Als je tijd hebt om een antwoord te formuleren, zul je een woordenboek of een online vertaler moeten openen en veel tijd moeten besteden aan het formuleren van je gedachten. Het gevoel zal echter nog steeds onaangenaam zijn: je zegt het antwoord en je weet niet of het juist is of niet. Hetzelfde geldt voor de code: het lijkt geschreven te zijn, het lijkt te werken, maar of het van goede kwaliteit is of niet, is een raadsel.
Het blijkt een dubbele tijdverspilling te zijn. Het kost tijd om tot een antwoord te komen. Het kost ook tijd om dit antwoord te formuleren – en niet zo weinig.
Als de vaardigheid om code van hoge kwaliteit te schrijven aanwezig is, kan het antwoord onmiddellijk worden geformuleerd, zodra het in het hoofd is gerijpt, zonder extra tijd aan vertaling te besteden.
De vaardigheid om code van hoge kwaliteit te schrijven, helpt bij het ontwerpen van architectuur. Je zult eenvoudigweg geen onjuiste, onrealiseerbare of afgedankte opties in je hoofd overwegen.
Samenvattend: de vaardigheid om code van hoge kwaliteit te schrijven versnelt het oplossen van problemen aanzienlijk.
Maar dat is niet alles. Dankzij de viltlaarzenmanagers is er één probleem: we hebben geen reden om code van hoge kwaliteit te schrijven. De manager kijkt niet naar de code, de klant kijkt niet naar de code. We laten zelden code aan elkaar zien, slechts af en toe, in sommige projecten waar sprake is van een aangewezen code-‘checker’ of periodieke refactoring.
Het blijkt dat in de meeste gevallen de waardeloze code naar productie of naar de klant gaat. Iemand die waardeloze code heeft geschreven, vormt een stabiele neurale verbinding – het is niet alleen mogelijk om waardeloze code te schrijven, maar het is ook noodzakelijk – het wordt geaccepteerd en ze betalen er zelfs voor.
Als gevolg hiervan heeft de vaardigheid om code van hoge kwaliteit te schrijven helemaal geen kans om zich te ontwikkelen. De code geschreven door een voorwaardelijke medewerker wordt door niemand gecontroleerd. De enige reden dat hij normaal zal leren programmeren is interne motivatie.
Maar deze interne motivatie is in strijd met plannen en eisen voor efficiëntie en productiviteit. Deze tegenstrijdigheid wordt duidelijk niet opgelost ten gunste van code van hoge kwaliteit, omdat mensen mensen niet eens bekritiseren vanwege waardeloze code. En voor het niet uitvoeren van het plan – en toch.
Wat moet ik doen? Ik zie en stel twee wegen voor die gecombineerd kunnen worden.
De eerste is om uw code aan iemand binnen het bedrijf te laten zien. Niet reactief (wanneer gevraagd/geforceerd), maar proactief (uh, kerel, kijk naar mijn code, alsjeblieft). Het belangrijkste hier is om geen suikerachtig snot te posten, niet om te proberen kritiek op de code in een beleefde vorm te formuleren. Als de code onzin is, zeggen wij dat: de code is onzin. Met uitleg uiteraard en aanbevelingen hoe het beter kan.
Maar dit pad is ook zo-zo. De toepasbaarheid ervan hangt af van het punt waarop het contact plaatsvond. Als het werk al in productie is gegaan en blijkt dat de code waardeloos is, heeft het geen zin om het opnieuw te doen. Meer precies, de redenen: de statistieken zullen ook verzakken. Managers zullen naar binnen stormen en u verpletteren met efficiëntie-eisen. En probeer ze niet eens uit te leggen dat de waardeloze code zeker terug zal komen in de vorm van bugs - het zal een averechts effect op je hebben. U kunt alleen een toezegging doen om dit niet nog een keer te doen.
Als het werk nog niet is opgeleverd, of net is begonnen, kan het over de code (of het project, idee) ervan praten een behoorlijk praktische betekenis hebben: de persoon zal het normaal doen.
De tweede, de coolste manier, is om open source-ontwikkeling te doen buiten werktijd. Wat is het doel: dat een groep programmeurs, namelijk programmeurs, jouw code zien en erover praten. Iedereen binnen het bedrijf heeft geen tijd. Maar programmeurs over de hele wereld hebben nog steeds niets te doen, en als je vanuit een toepassingsoogpunt iets nuttigs schrijft, zullen ze zeker naar binnen kijken.
De belangrijkste truc is naar mijn mening het schrijven van code buiten werktijd, omdat de tegenstelling tussen de kwaliteit van de code en de snelheid van het leveren van het resultaat niet zal werken. Schrijf je ontwikkeling op voor minimaal een jaar. Noch deadlines, noch technische specificaties, noch geld, noch baas zullen druk op je uitoefenen. Volledige vrijheid en creativiteit.
Alleen in vrije creativiteit zul je begrijpen en voelen wat geweldige code is, de schoonheid van taal en technologie zien en de charme van zakelijke taken voelen. Welnu, je leert code van hoge kwaliteit schrijven.
Het is waar dat je hiervoor persoonlijke tijd moet doorbrengen. Net als elke andere ontwikkeling. Zie het niet als een kostenpost, maar als een investering – in jezelf.
Bron: www.habr.com