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.

Category:
Articles
Tags:

Join the conversation! 15 Comments

  1. Bravo Tom,

    The rush to the latest buzz can be detrimental to our growth as Software professionals. We see the tweets, articles, online courses, and all the buzz about the new tool or thingy out there on the market. The “implied message” is “you are less of a software dev if you are not using xyz.” Wrong.

    Each of the utilities you listed above are simply and foremost just “tools”, tools to make our jobs easier. That’s it. None of them will make you a better developer. None will help you craft better, higher quality code. None will help you understand the code.

    Rather, these are simply just tools. Granted they will save you time, once you know how to use them. I use Sass to help me modularize my CSS. But if you do not know CSS, Sass will not help you.

    You start by knowing the code and implementing proven software design principles and patterns. Then you “can” (you don’t have to) use these tools to help you in your daily workflow.

    Let me share a quick story to illustrate.

    A family member was into carpentry. He went out and spent a bucket load of money on all the tools power tools and top of the line carpentry hand tools. Then we set out to build a hutch. He had no idea about inlay, dovetailing, or the fine-detail work that sets a quality piece of furniture apart from one at a rummage sale. He skipped the steps of learning the craft…first.

    Happy coding,

    Tonya

  2. It’s the loss of control that often bothers me. Or the apparent loss of control. Processes and skills get abstracted away by tools (as listed above), and you come to rely upon the tool and not your basic skills. Your new important skill becomes using the tool, not being able to create what you used to create by hand before you had the tool.

    I sound like a Luddite, right? It’s the reason I’ve resisted getting deeper into Laravel and prefer working with Processwire or a really basic framework like F3. Many WordPress plugins or themes leave me cold since they force you to rely on the custom code of others.

    Sure, there’s a compromise position, but so many tools require an all or nothing opt-in.

  3. I totally agree with Ross.

    And I’d go further as well: the abstracting tools get in the way too much. In my own experience I’ve been frustrated by having to achieve a basic mastery of tools like composer, grunt, gulp, ruby an so on… when I could be putting that time and energy into deepening my mastery of actual programming.

    In order to get a pre-processor running I typically have to install the correct version of node atop a version-managed ruby. So I have to know the basics of ruby, rvm or rbenv and node. This isn’t harmful. But it feels like an obstacle instead of a gateway.

    Of course, commercial productivity relies on using these toolsets.

    There’s no ideal solution. We just have to learn as much as we can of as many of these tools as we can. Perhaps one magical day the industry will have standardized on fewer abstracting tools. And perhaps those toolsets will “just work” one day, without me having to understand their depth. (gulp streams and the node event loop? I just want my scss to compile!)

    It all reminds me of my introduction to programming. It took me an embarrassingly long amount of time to build a “hello world” in Java because I couldn’t figure out how to make the classpath accessible. Decades later I still feel myself in a similar bind sometimes.

    • > And I’d go further as well: the abstracting tools get in the way too much.

      This is what happens when you rely too much on tooling, in my opinion. It’s about finding that balance of things that help you become more productive.

      > In my own experience I’ve been frustrated by having to achieve a basic mastery of tools like composer, grunt, gulp, ruby an so on… when I could be putting that time and energy into deepening my mastery of actual programming.

      Totally understand that. That’s why I have to be really careful when I decide to change tools or introduce something new. The learning curve has an inherent time value that can negatively impact what it is we’re trying to do.

      > In order to get a pre-processor running I typically have to install the correct version of node atop a version-managed ruby. So I have to know the basics of ruby, rvm or rbenv and node. This isn’t harmful. But it feels like an obstacle instead of a gateway.

      For sure. But there _are_ some solutions that bundle all of that into a single application so you don’t have to worry about those particular details, which I tend to favor.

      > There’s no ideal solution. We just have to learn as much as we can of as many of these tools as we can.

      Amen.

      > Perhaps one magical day the industry will have standardized on fewer abstracting tools. And perhaps those toolsets will “just work” one day, without me having to understand their depth. (gulp streams and the node event loop? I just want my scss to compile!)

      My guess is that it will only get more complicated but who knows?

      > It all reminds me of my introduction to programming. It took me an embarrassingly long amount of time to build a “hello world” in Java because I couldn’t figure out how to make the classpath accessible. Decades later I still feel myself in a similar bind sometimes.

      I also think that Java, as a language, has an inherently tough learning curve for first time programmers. That is, just for `main` you have to understand `public`, `static`, `void`, `String[]` — that’s a lot of stuff just to gloss over for the sake of getting `System.println` or whatever library they are using now.

    • Sunil: “And I’d go further as well: the abstracting tools get in the way too much. In my own experience I’ve been frustrated by having to achieve a basic mastery of tools like composer, grunt, gulp, ruby an so on… when I could be putting that time and energy into deepening my mastery of actual programming.”

      Exactly. And it’s a little annoying at times. It feels like a road block.

      I suspect what happens is people develop a copy & paste mentality. They simply use the demo Gulp/Composer, etc. setup scripts without really learning what’s going on. It works, so they shrug their shoulders and move on, satisfied they’ve jumped on the bandwagon, but they’ve just become reliant on something they don’t really understand, and that’s a huge future problem, and security issue. But who’s got the time? There’s still too many WP core functions I haven’t learned properly and that’s what I want to focus on.

      It’s always a compromise and we must choose wisely. That’s the trick. Resist the latest craze.

      Now what the hell is taking that Windows 10 download so long…?

      ;-)

  4. This post addresses a trend that is quite prevalent now, and I like the approach that was taken to address it.

    Even as a simple web “worker” who doesn’t consider themselves a developer per se, I’ve recently observed an increased layering of complexity on top simple processes, to the point where the original intent and purpose is lost in the myriad of tools and tooling.

    Part of me believes this to mostly be the result of a marketing tactic, aimed at “owning” and controlling the emotions of software makers, developers, and users, to the point where we’re emotionally invested in a “branded product” that (for example) does the same thing as “copy and paste”.

    So we evangelize the product, and proselytize its high values and efficiency benefits, above all other tools.

    Its just like what Uncle Bob explains in his talk to the COHAA (the Path to Agility Conference), back in 2012, about corporations trying to gather the “hearts and minds of programmers”.

    But here’s the thing: that product is usually built on top of something else. And there’s limitations to every kind of software.

    What happens when the limitations kick in?

    Its followers start looking for new clay feet….rapidly.

    Meanwhile, folks who have simply mastered the basics remain standing.

    Kudos on a great post, Tom.

  5. Well said Tom.

    The process is a journey, not a destination. Balancing the desire to chase “shiny new objects” over using the knowledge and tools I already have to solve a business problem – is not always easy.

    These distractions can sometimes paralyze creative thought and problem solving skills, because I feel I’m not using the best tool to complete the task. Every time I see a piece of code that I don’t understand, I ask myself – “Do I need to understand this right now? Is this something that will help me with the current project I am working on?” If not – I add it my list of things to explore when I do have time. Then I prioritize that list based on my plan that considers current needs and future development path.

    • I think the way you’re prioritizing things is spot on – I think it’s really pragmatic. I understand the paralyzation that comes with not necessarily understanding everything as you come across it.

      It’s tough – everything inside of me wants to know _exactly_ what’s going on, but the time required to actually dive deep into everything would far outweigh the amount of time I have to get _my_ things done.

      So, like you said, it’s a matter of really prioritizing and then going from there.

  6. This post is also very beneficial to new learning devs like myself. I feel so swamped with the amount of learning that seems to be required when in actual fact, newbies should take note on this and keep to the base fundamentals of programming whilst on our path to mastery.

    For any industry, I’m sure designers have this issue too, so same rule applies!

    I myself am going all in with php and learning the WordPress core as my beginning path.

    • This post is also very beneficial to new learning devs like myself. I feel so swamped with the amount of learning that seems to be required when in actual fact, newbies should take note on this and keep to the base fundamentals of programming whilst on our path to mastery.

      Exactly – it’s really tough to get into the game and then not to feel overwhelmed. The best advice I can give is to find a core set of tools and languages with which you want to work and then go after those with all you’ve got.

      Not fitting in with what you want to do? Try something new but repeat it with a level of intensity. It can be tough to find what it is you’re looking for with respect to all of this, but eventually you find your niche and when you do it’s a lot more fun to get your work done.

      I myself am going all in with php and learning the WordPress core as my beginning path.

      Go for it (and welcome :).

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.