Everything is a Variable



I like to say, that the job of a software engineer is to define variables, and honestly I don’t think it’s really much more than this. Everything in life starts off simple, and can end up as complex as you choose for it to be.

This process is traditionally called “architecting” and at one point in my career I was told I was a brilliant architect by someone I later came to admire quite a bit, Andrew Nacin. Whether or not that’s actually true, is irrelevant, because Andy said so and that’s all anyone should need to hear.

For most engineers, their accidental measure of success is how complex of a problem can I solve. This isn’t just true for software, but for all artists, makers, and creators – it’s a form of validating oneself to say you’ve leveled up and accomplished something more challenging than the time before. It’s learning, and evolving, and shaping your mind by enjoying new experiences, and it’s addicting like everything else in this world.

Ultimately, I think the thing that separates a good engineer from a bad engineer, is the ability to take complex ideas & relationships, and make them as simple to understand & interact with as possible, for as wide of an audience as possible.

In WordPress, this has traditionally meant introducing flexibility in the form of actions and filters, but for the future of WordPress development, this is about to change dramatically.

If you’re not familiar, WordPress developers have been living in a bubble compared to the rest of the PHP world, and this bubble is about to pop in a huge way when the ability to use versions of PHP higher than 5.2 becomes commonplace.

WordPress itself is a largely procedural codebase, meaning it’s relatively flat and simple. This was both by design, and by intention, because earlier versions of PHP had varying degrees of support for increasingly popular programming concepts. Future versions of WordPress will inevitably grow increasingly complex, but I for one am planning on sticking my neck out to ensure this happens only with great intention.

Once plugins and themes can (and will) start flexing more PHP muscle, the WordPress world has the potential to become a very scary place to work inside of, and it’s up to all of us to decide where to position the bar when it comes to code complexity and extensibility.

I’ve come across three WordPress based projects recently that appeared conceptually over-architected, re-solving problems in more complex ways than should have ever been required, considering the requirements and because APIs already existed to solve these problems in WordPress core.

I’m omitting the details from this post (we’re working it out, and my intention isn’t to negatively criticize) because I hope get people thinking deeply about what reusable code in WordPress has meant and should mean going forward. Here’s my take:

  • Code that others can quickly understand
  • Problems that others may need solving in their own projects
  • The ability to extend, unplug, replace, or override assumptions the code has made
  • Using existing code intended for it’s purpose, and sending upstream improvements if necessary to unblock your progress
  • It needs to be juice’able – shred it, direct it, blend it with any other code, and it will always act predictably

In the way that art mimics life, these rules are generally what I apply to real-life scenarios. If I can own (or build) a tool that solves many problems, and I can loan it out to someone that may need it, and that tool can be extended to suit many unique needs, it’s an obvious win. This might be a power drill, a table saw, a bucket, a car, a WordPress plugin, or just an idea I’ve had about some random life experience that’s worth sharing or blogging about.

If I can have 1 friend that I enjoy everything with, I’ll marry them so I can continue to enjoy everything they have to offer the world. <3

All of us are in different places, at different times, for different reasons, with different intentions and feelings and goals. We all have different experiences that lead us to unique conclusions about how to approach solving problems and addressing concerns and communicating our feelings. If you ask Mother Nature, this is not a bug, it’s a feature.

Each and every moment that passes results in new variables that require defining. What to eat, what to say, what not to say, how to say it, left or right, stop or go, yes or no. Engineers have trained their brains to quickly calculate the consequences of these rapid decisions, and we are difficult people to be around because we are 100 steps ahead and trying to think 101 steps backwards at the same time so what we do makes sense to the people around us.

So when I say that everything is a variable, I mean that it’s your responsibility to define the importance of the variables in your life to create a better tomorrow for the people around you. Hack the world, by being patient, and kind, considerate, and lovely. Learn how to recognize when someone needs help defining their own variables in their lives, and teach them how to in a healthy and constructive way.




2 responses to “Everything is a Variable”

  1. Very philosophical, reasonable and spiritual thoughts. WP and lofty matters – I like it! .Think global – act local.

  2. Great Thoughts John,

    As far as solving problems and building evolving tools, I think of how knowledge is structured and how tools that use these knowledge could evolve. You could say that when a context is applied to an abstract truth and developed, you get a branch of knowledge. But, only by working on the contextual knowledge do you get a better understanding on the abstract Truth.

    Similarly, people can built specific tools / plugins /…etc and contribute to the abstract / core software. The easier it is to push to the core when many specific tools repeat a feature / language ( as in a program talking to another ).

    There would be much less clutter, more clarity when general API pulls standardised specific APIs.