Våra färdigheters måsten
När jag bestämde mig för att jag skulle satsa min karriärs resa på att bygga lösningar på WordPress var jag – vid den tiden – all in. Det vill säga att HTML, CSS, JavaScript, PHP och MySQL var på en plats där Jag kunde hålla mig involverad i dem alla och arbeta kompetent ner i stacken efter behov för vad det än är jag byggde.
Men eftersom både min familj [och jag] har växt och som WordPress har förändrats under det senaste halvt decenniet (låt vara decennium), har hela det perspektivet förändrats.
Inte bara det dock.
HTML har förändrats, CSS har förändrats, JavaScript har förändrats (med andra ord, hela gränssnittet har förändrats), PHP utvecklas (till stor del till det bättre, enligt min mening), och arbetar med olika databasteknologier utöver MySQL men även API:er, andra datakällor, GraphQL och så vidare blir en större uppgift.
För ett tag sedan var jag inte säker på att jag gillade det. Jag tyckte om att känna till alla detaljer i alla de olika delarna av stiftelsen som jag arbetade med. Jag säger inte att vi ska ignorera alla utom vissa delar av tillämpningen, men det är vid en punkt nu där jag tycker att det är värt att veta var du vill fokusera dina ansträngningar för att se till att du kan lösa problemet, eller hjälpa till att lösa problemet problem, på bästa möjliga sätt.
- Om du är en solid React- utvecklare vet du var dina ansträngningar är bäst fokuserade.
- Om du är intresserad av PHP och objektorienterad och/eller procedurprogrammering är back-end platsen att vara.
- Om tillgänglighet är något du brinner för, så finns det en plats för det i WordPress också.
- Och detta är bara tre exempel.
Poängen jag försöker få fram, om något, är denna: Om du är orolig för att det är för svårt att hänga med i de olika delarna av WordPress, gör inte. Fokusera istället på de delar som du tycker om att arbeta med och fokusera sedan mycket av din tid och ansträngning på att bli den bästa möjliga utvecklaren du kan för det området.
Omvänt, vill jag bli bättre med React? Ja, det vore trevligt. Men är det det viktigaste för mig eller för min karriär vid det här laget? Nej.
Inom mjukvaruutveckling pratar vi mycket om måste-has och nice-to-haves. Och om vi ska prata om det externt med hänsyn till våra kunder, varför inte göra samma sak internt med avseende på vår egen kompetens?
Jag hävdar fortfarande att det i detta sammanhang är bättre att veta mycket om något än lite om mycket.