One of the things that I’ve begun to think about as I move through my career in development is what it means to be truly pragmatic about the work that I do.

But first (and no, this is not an affiliate promotion), I think it’s worth noting that The Pragmatic Programmer is a book that I think every person who is a developer of some sort should reading (maybe several times, even). It’s an easy read and brings up a lot of good points as it relates to being the best programmer that you can be as it relates to best practices (whatever that may look like for your slice of the industry).

Anyway, I’ve talked about the tension of having to stay on top of every new technology that’s released as well as the importance of going deep rather than wide as it relates to the work that we’re doing on a day-to-day basis.

A Pragmatic Programmer

What does it mean to actually be pragmatic? According to the definition, being pragmatic or practicing pragmatism (or however you see it used) is defined as:

dealing with things sensibly and realistically in a way that is based on practical rather than theoretical considerations.

And yes, there’s an entire Wikipedia article about it, too (but is that really a surprise?). There are a lot of ways that this could be generalized to speak about generic programming, or web development, or mobile development, or .NET development, and so on.

But I’m obviously most interested in what this looks like as it relates to being a WordPress developer.

Pragmatism and WordPress

Speaking purely at the general level, because of the various languages that are needed to build working solutions in WordPress, we’ve a wide variety of tools that we can use. For example, some of the more popular ones (or some of the ones that have come to mind when drafting this) are as follows:

There’s obviously a lot of options that we have when it comes to managing the assets, dependencies, and build processes of our work. I don’t consider that a bad thing.

The thing is, the nature of our culture – that is, the development culture – is that we have some people who will aim to make you feel inferior if you’re not familiar with whatever tools they opt to use.

And that sucks.

Don’t let anyone let you feel like a lower quality developer because you know or you don’t use whatever tools they use. That’s immaturity on their part. You can always learn new tools (people do it everyday both in our industry and in others).

Anyway, regardless of if you’re a one man shop, a two man shop, or a medium-to-large team, there’s no silver bullet set of tools that you can find to maximize your productivity. Instead, there’s a suite of tools available from which you can pick to build your own toolbox that’s ideal for your team.

The only caveat, in my opinion, is whatever it is that you opt to use, make sure that it doesn’t misplace good engineering practices. When your tools override good engineering, the tool is likely creating more problems – like technical debt – than it is solving. But that’s content for another post.

Anyway, the point is: Part of being a pragmatic programmer is not necessarily becoming well-versed in every single thing that comes along. It’s knowing what’s available, determining whether or not it’s a good fit for you and/or your team’s workflow, and opting to use it.