Kiedy zdecydowałem, że zamierzam poświęcić swoją karierę na budowanie rozwiązań na WordPressie, byłem – w tamtym czasie – całkowicie. To znaczy, że HTML, CSS, JavaScript, PHP i MySQL były w miejscu, w którym Mógłbym pozostać zaangażowany we wszystkie z nich i pracować kompetentnie w miarę potrzeb, niezależnie od tego, co budowałem.
Ale wraz z rozwojem mojej rodziny [i ja] i zmianą WordPressa przez ostatnie pół dekady (nie mówiąc już o dekadzie), zmieniła się cała perspektywa.
Ale nie tylko to.
Zmienił się HTML, zmienił się CSS, zmienił się JavaScript (innymi słowy zmienił się cały front-end), PHP ewoluuje (moim zdaniem w dużej mierze na lepsze) i pracuje z różnymi technologiami bazodanowymi poza MySQL, ale także z API, inne źródła danych, GraphQL itd. stają się coraz większym zadaniem.
Jakiś czas temu nie byłam pewna, czy mi się to podobało. Lubiłem znać wszystkie tajniki wszystkich różnych części fundacji, nad którą pracowałem. Nie mówię, że powinniśmy zignorować wszystko oprócz niektórych części aplikacji, ale myślę, że teraz jest to punkt, w którym warto wiedzieć, na czym chcesz skoncentrować swoje wysiłki, aby upewnić się, że możesz rozwiązać problem lub pomóc rozwiązać problem problem, w najlepszy możliwy sposób.
- Jeśli jesteś solidnym programistą React, wiesz, na czym najlepiej skoncentrować swoje wysiłki.
- Jeśli interesujesz się PHP oraz programowaniem obiektowym i/lub proceduralnym, back-end jest odpowiednim miejscem.
- Jeśli dostępność to coś, co Cię interesuje, w WordPressie jest na to miejsce.
- A to tylko trzy przykłady.
Jeśli w ogóle, chcę zwrócić uwagę na to, że: Jeśli martwisz się, że trudno jest nadążyć za różnymi częściami WordPressa, nie rób tego. Zamiast tego skoncentruj się na częściach, z którymi lubisz pracować, a następnie skoncentruj większość swojego czasu i wysiłku na zostaniu najlepszym możliwym programistą w tym obszarze.
I odwrotnie, czy chcę być lepszy z Reactem? Tak, byłoby miło. Ale czy jest to najważniejsza rzecz dla mnie, czy dla mojej kariery w tym momencie? Nie.
W tworzeniu oprogramowania dużo mówimy o tym, co trzeba mieć i co miło mieć. A jeśli zamierzamy rozmawiać o tym na zewnątrz w odniesieniu do naszych klientów, dlaczego nie zrobić tego samego wewnętrznie w odniesieniu do naszych własnych umiejętności?
Nadal twierdzę, że w tym kontekście lepiej wiedzieć dużo o czymś, niż trochę o dużo.