One of the things I read – and learned – early on in my career was the term Architecture Astronaut. It was coined by Joel Spolsky (as far as I know) and it goes something like this:
These are the people I call Architecture Astronauts. It’s very hard to get them to write code or design programs, because they won’t stop thinking about Architecture. They’re astronauts because they are above the oxygen level, I don’t know how they’re breathing. They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don’t contribute to the bottom line.
Don’t Let Architecture Astronauts Scare You
I really liked the definition because then, just as I am now, I am surrounded by incredibly smart people from whom I can learn.
And for those of us in this field, it allows us all to:
- learn great engineering techniques,
- the reason why engineers write code a certain way,
- and how to approach problem solving in a pragmatic way (pragmatic being the keyword here, but more on that in a moment).
But that’s not how it always is, is it? Not in other fields; not in WordPress. And the more segmented WordPress is becoming between frontend technologies and backend technologies, the more different these discussions are becoming.
For the purposes of this post, the whole architecture astronaut thing is something I hope all backend engineers pay attention to regardless of where they are in their career. (Let’s avoid architecture astronauts of WordPress.)
And here’s why.
Architecture Astronauts of WordPress
A Digression on Terms
I know that the word “coder” is a blanket term to refer to anyone who writes code, but I find the breakdown of terminology between coder, developer, engineer, programming, and what not a little more nuanced.
Coder is too much of a blanket term to describe exactly what a person does. It could be, as those of us in the 90s once said, a script-kiddie, or it could be someone who’s a developer. I don’t know. And that’s why I like precision in terms. This is my short digression.
Back to My Point
If you’re someone who writes code for a living and are considered a developer by yourself and/or your peers, then it’s important to recognize the feeling you get when you’re writing code and you think “this could be done better.”
Here’s the thing though: Recognizing that said thing could be done better and not doing it is healthier than trying to architect the thing into near-perfection – out into the proverbial atmosphere – because that’s where you end up having a hard time coming back down to earth.
It’s where you never finish your work because of he what-about-ism and the just-one-more-thing thing.
This is not saying we ignore feedback from our peers when issuing PRs so don’t take it as that. Instead, I’m saying that when you’re working on something for WordPress that, say, uses add_action
to subscribe to a specific hook and then use an anonymous function as what it invokes may be sufficient for the problem at hand.
Not everything has to be or needs to be object-oriented and needs to use some type of Composer-based, Registry/Subscriber/Service architecture. That can be overkill.
And the reason I’m writing this is because I was reminded this morning, when going through of my own repositories (1, 2), that there are times when one format works just as well and another is more applicable. If you browse the code, I’m sure you’ll see where I’ve made decisions to go with one strategy over the other.
It was deliberate.
But it takes a level of pragmatism, restraint, and understanding of the problem at hand before being able to do that.
- Don’t try to make every solution work within the confines of procedural programming.
- Don’t try to make every solution work within the confines of object-oriented programming.
Ultimately, both of them can work but not every one of them needs to work that way. If you don’t take anything else away from this article, remember this from Spolsky:
Remember that the architecture people are solving problems that they think they can solve, not problems which are useful to solve.
Solving the problem is what’s useful. How you solve it is useful, too, but the architecture can be secondary to how it’s solved. I believe this is something that will you serve you well in your career depending on the task you’re aiming to build.
It’s certainly served me well and continues to do so.