Teambaserad pragmatism och teknik
När det gäller att göra någon typ av utveckling – jag bryr mig inte om det är för webben, för mobilen eller för någon annan plattform – det finns massor av böcker, onlinekurser och så vidare som gör det otroligt enkelt att lära sig vad som helst det är du vill lära dig.
För att vara tydlig, jag knackar inte på något av de sätt som finns att lära, heller. När allt kommer omkring lär vi alla på olika sätt, eller hur? Och vem är jag att säga vilket sätt är bättre än något annat sätt, särskilt med tanke på att jag dagligen skriver om ämnen här på och på andra webbplatser?
Men jag kan definitivt säga för mig – någon som har njutit av både att lära sig genom formell utbildning, handledningar, kurser och så vidare – det bästa sättet att skaffa sig erfarenhet i den här branschen har varit tvåfaldigt:
- arbeta med andra människor,
- bryta saker och lära sig att fixa dem.
Menar jag att göra det i den här specifika ordningen? Nej. Betyder detta att jag ligger steget före andra? Det är skrattretande.
Men eftersom jag har haft nöjet att arbeta med andra i flera projekt, prata med andra via Twitter, konferenser och så vidare och upplevt både bra och dåliga, är det något jag tycker att alla borde ha möjlighet att göra någon gång.
Om jag måste sammanfatta det skulle jag säga att det handlar om att hitta en balans mellan lagbaserad pragmatism och ingenjörskonst. Men varför, om inget av ovanstående är nytt (med tanke på att mjukvaruföretag har funnits i decennier) bryr jag mig om att skriva om detta nu?
Teambaserad pragmatism och teknik
Jag skulle förmodligen kunna komma med en tvättlista med anledningar till varför jag tycker att just detta ämne är viktigt, men det finns tre specifika saker jag skulle vilja nämna i det här inlägget. Och för längden (läs: tiden) ska jag göra vad jag kan göra och hålla dem korta.
Faktum är att TL;DR för det jag ska prata om har att göra med pragmatism och ingenjörsskicklighet. Ursprungligen tänkte jag ta med ett perspektiv på affärer i allmänhet, men det tog det allmänna inlägget lite utanför ämnet.
1 Pragmatism
Jag har skrivit om att balansera ingenjörskonst och pragmatism tidigare. Så jag kanske inte har så mycket att erbjuda i form av något nytt, men jag börjar ändra mitt perspektiv lite.
Det vill säga, vid ett tillfälle handlade det strikt om att hitta en balans mellan att hitta en lösning som fungerar för seden, som är välbyggd och som löser deras problem. Och jag prenumererar fortfarande på det.
Och naturligtvis finns det något att säga om hur koden är organiserad så att den kan underhållas över tid. Det är nyckeln. Men hur koden är byggd skrivs och lösningen byggs är där saker som kan bli lite mer suddiga med avseende på pragmatism.
Det vill säga att det är lätt att skriva grundläggande objektorienterad kod, dokumentera den, låta några klasser eller funktioner anropa varandra, ansluta till WordPress och sedan kalla det en dag.
2 Teknisk skicklighet
Men är den nivån av att balansera leverans av lösningen och att utforma lösningen en fin linje att gå. Jag tror dock att det finns en fara med att försöka vara för pragmatisk: om du strävar efter att vara så pragmatisk som möjligt hela tiden och lämnar dina ingenjörskunskaper på en viss nivå, kan du misslyckas med att utvecklas som utvecklare.
Även om jag föredrar att använda objektorienterad programmering i den typ av arbete jag gör, är jag inte en sådan som hamnar i ett religionskrig eller kommer in i vilken version av vilket språk, vilken teknik eller om det är funktionellt, processuellt eller objektorienterat. programmering är bättre.
Enkelt uttryckt: det handlar om den allmänna kompetensnivån du kan uppnå under hela din karriär.
Och när jag arbetar med utvecklare som har arbetat med projekt med olika kompetens, som har utbildats på olika sätt och som har löst olika typer av problem, upptäcker jag att jag hela tiden lär mig nya saker.
Detta är inte att säga att det inte finns konversationer om saker vi kan implementera som ett team eller som ett partnerskap, men det är att säga att det kan förhindra att potentialen att växa som programmerare försvagas.
Jag skulle kunna fortsätta om detta, men det korta är det här: Om du ska arbeta med andra, se till att de är erfarna, njut av att använda samma typ av paradigm som du gör, är öppen för genomtänkta samtal och ta med en olika erfarenheter till bordet.
I slutändan kan detta bidra till att förbättra både din förmåga och kvaliteten på det du och ditt team kommer med till bordet.
Det finns alltid mer
Som jag sa tidigare i inlägget, det finns alltid mer. Jag kommer förmodligen att prata mer om affärsaspekten av det i framtida inlägg.
Än så länge lämnar jag det jag skrivit där det står och går därifrån senare.