Ett av de mest idiottyngda yrkena är chefer som hanterar programmerare. Inte alla, utan de som inte var programmerare själva. De som tror att det är möjligt att "höja" effektiviteten (eller öka "effektiviteten"?) med metoder från böcker. Utan att ens bry sig om att läsa samma böcker är videon en zigenare.
De som aldrig har skrivit kod. De för vilka Hollywood-filmer om programmerare görs - ja, de där de tittar på e-post med hjälp av kommandoraden. De som inte är intresserade av annat än indikatorer, deadlines och egen lön.
De som är majoriteten.
Men de är idioter av en annan anledning. De vill ha effektivitet, eller åtminstone effektivitet (kom igen, chef, Google vad skillnaden är), utan att förstå varken det ena eller det andra. Utan att allmänt förstå essensen, processen att erhålla resultatet, förlusterna som uppstår i denna process, kostnaderna för utveckling. Kort sagt, att arbeta med en programmerare som om han vore en svart låda.
De kom springande in i ledningen för programmerare av exakt en anledning: det finns hype, pengar, marknaden och ett gäng samma idioter. Det finns en plats att gå vilse.
Om det var hajp i tillverkningen av mekanisk montering skulle vi köra dit. Stationcars suger. Jag skulle inte bli förvånad över att killen som säljer julgranar i vårt grannskap i december är en IT-chef på semester.
Kort sagt, om möjligt, skjut de här killarna i nacken. Oroa dig inte, de kommer att hitta ett jobb. Ingen av dem kommer någonsin att göra något anständigt förrän de själva blir programmerare. Eftersom han inte förstår essensen, mekanismen, logiken i den process han kontrollerar.
Okej, nog om chefer. Nu till saken, för programmerare. Hur man ökar utvecklingseffektiviteten genom att lära sig skriva högkvalitativ kod.
För att öka effektiviteten måste du lösa problem snabbare utan att tappa kvalitet. För att lösa problem snabbare måste du omedelbart kunna skriva högkvalitativ kod. Och "hög kvalitet", och "skriv" och "omedelbart". Låt mig förklara med en metafor.
Att skriva högkvalitativ kod är som att tala ett främmande språk korrekt. När du inte kan ett språk lägger du mycket tid på att försöka formulera dina tankar i det.
Behöver du säga något akut så håller du bara på några ord, ofta inte de rätta, du glömmer bort artiklar, rätt ordföljd, för att inte tala om verbtid och dåligt uttal.
Om du har tid att formulera ett svar måste du öppna en ordbok eller en onlineöversättare och lägga ner mycket tid på att formulera dina tankar. Känslan kommer dock fortfarande att vara obehaglig: du säger svaret och du vet inte om det är korrekt eller inte. Det är samma sak med koden – den verkar ha skrivits, den verkar fungera, men om den är av bra kvalitet eller inte är ett mysterium.
Det visar sig vara dubbelt slöseri med tid. Det tar tid att komma med ett svar. Det tar också tid att formulera detta svar – och inte så lite.
Om färdigheten att skriva högkvalitativ kod är närvarande, kan svaret formuleras omedelbart, så snart det har mognat i huvudet, utan att spendera ytterligare tid på översättning.
Förmågan att skriva högkvalitativ kod hjälper till vid design av arkitektur. Du kommer helt enkelt inte att överväga felaktiga, orealiserbara eller hand-me-down alternativ i ditt huvud.
För att sammanfatta: skickligheten att skriva högkvalitativ kod påskyndar problemlösningen avsevärt.
Men det är inte allt. Tack vare filtstövlarnas chefer finns det en hake - vi har ingen anledning att skriva högkvalitativ kod. Chefen tittar inte på koden, klienten tittar inte på koden. Vi visar sällan kod för varandra, bara ibland, i vissa projekt där det finns en utsedd kod "checker" eller periodisk refactoring.
Det visar sig att i de flesta fall går den taskiga koden till produktionen eller till kunden. En person som har skrivit taskig kod bildar en stabil neural anslutning - det är inte bara möjligt att skriva taskig kod, utan det är också nödvändigt - det accepteras, och de betalar till och med för det.
Som ett resultat har färdigheten att skriva högkvalitativ kod ingen chans att utvecklas alls. Koden som skrivits av en villkorlig anställd kontrolleras aldrig av någon. Den enda anledningen till att han lär sig att programmera normalt är inre motivation.
Men denna inre motivation strider mot planer och krav på effektivitet och produktivitet. Denna motsägelse är uppenbarligen inte löst till förmån för högkvalitativ kod, eftersom folk inte ens kritiserar folk för taskig kod. Och för underlåtenhet att uppfylla planen - trots det.
Vad ska jag göra? Jag ser och föreslår två vägar som kan kombineras.
Det första är att visa din kod för någon inom företaget. Inte reaktivt (när du blir tillfrågad/tvingad), utan proaktivt (äh, du, titta på min kod, tack). Huvudsaken här är att inte posta sockersnurr, inte försöka sätta kritik mot koden i en artig form. Om koden är skit säger vi det: koden är skit. Med förklaringar förstås och rekommendationer om hur man kan göra det bättre.
Men den här vägen är också si som så. Dess tillämplighet beror på den punkt där kontakten inträffade. Om arbetet redan har gått i produktion och det visar sig att koden är skit, är det ingen idé att göra om den. Mer exakt, skälen - måtten kommer också att sjunka. Chefer kommer att rusa in och krossa dig med effektivitetskrav. Och försök inte ens förklara för dem att den taskiga koden definitivt kommer tillbaka i form av buggar - det kommer att slå tillbaka på dig. Du kan bara göra ett åtagande att inte göra detta igen.
Om arbetet ännu inte har levererats, eller precis har börjat, kan det ha en ganska praktisk betydelse att hälla skit på koden (eller dess projekt, idé) - personen kommer att göra det normalt.
Det andra sättet, det coolaste, är att utveckla öppen källkod under icke-arbetstid. Vad är målet: att ett gäng programmerare, nämligen programmerare, ska se din kod och prata om den. Alla inom företaget har inte tid. Men programmerare över hela världen har fortfarande ingenting att göra, och om du skriver något användbart ur tillämpningssynpunkt kommer de definitivt att titta in.
Huvudtricket, enligt min mening, är att skriva kod under icke-arbetstid, eftersom motsättningen mellan kodens kvalitet och hastigheten på att leverera resultatet inte kommer att fungera. Skriv din utveckling under minst ett år. Varken deadlines, tekniska specifikationer, pengar eller chef kommer att sätta press på dig. Fullständig frihet och kreativitet.
Endast i fri kreativitet kommer du att förstå och känna vad bra kod är, se skönheten i språk och teknik och känna charmen med affärsuppgifter. Tja, du kommer att lära dig att skriva högkvalitativ kod.
Det är sant att detta kräver att du spenderar personlig tid. Precis som vilken annan utveckling som helst. Se det inte som en kostnad, utan som en investering – i dig själv.
Källa: will.com