Late last week, I received an email from a fellow developer asking me if I had any thoughts on the pros and cons of using Vagrant versus Apache in in WordPress development.

At one point in my career, I would have spent extensive amount of time researching both, reading articles, and even testing out the two pieces of software along side one another because I didn’t want to respond with an “I don’t know.”

Years ago, I got over that attitude – in fact, I don’t think it’s possible to keep that mentality up and actually advance your career – but I responded with the following:

So I haven’t really done much with Vagrant, at least not right now. I’m hoping to eventually tinker around with it but I tend to work with things on a need-to-know basis so I pick them up as I go along.

Right now, my current projects are on the typical stack so I’ve yet to really need to pick up Vagrant or have the time to spend tinkering with it.

Wish I had more to offer, but that’s all I’ve got for you right now :).

It’s okay to say I don’t know, but that isn’t an excuse for laziness. I think that it’s important for developers to balance pragmatism with laziness when dealing with new technologies.

Being A Pragmatic Developer

I think that developers talk a lot about pragmatism – and that’s important – though I’m not actually sure how many of them strive for it. Then again, who am I to judge?

All I know is that I know that it’s something I try to practice, but I have my moments of weaknesses just like everyone else. I mean, it is fun to rabbit trail new things – just at the proper time, right?

Anyway, for the purposes of this post, here’s how I’m defining pragmatism:

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

To be honest, that definition still leaves something to be desired, but that’s what’s given so I’ll roll with it.

Diving in the Deep End

Here’s the thing: I think a lot of developers get sucked into all of the new technologies that are available and our curiosity gets the best of us so we end up like rocks skipping along to the top of the lake never really sinking into any particular field, just touching whatever comes along (and some even claiming that they’re experts after doing just that).

Skipping Rocks

But when we do that, I believe that we rob ourselves of gaining a significantly deep understanding of a set of tools, technologies, and languages that can ultimately make us incredibly capable developers with a smaller set of tools, and a larger base of knowledge off of which to solve problems using said tools.

Another way that I look at it is this: If we still have questions or gaps in our knowledge of the tools and technologies with which we’re currently working (and even making a living off of), what’s to stop us from continuing to dive deeply into said tools and technologies especially if we enjoy working with what we have?

Why should we move on to something new?

Breadth or Depth?

Of course, I’m not dissuading anyone from having fun tinkering with new things. I’m just as guilty as the next person at least when it comes to spending time off the clock; however, when it comes to work and serving in a professional capacity, the breadth of knowledge that I have is rather small.

I’m okay with that.

I’d rather the depth of my knowledge be greater than its breadth and that’s something that takes years to achieve (and I’m clearly still working on it).

Pragmatism in Practice

Practically speaking, what does this look like? After all, I’m not trying dissuade anyone from learning new technologies. In fact, it’s something that we need to do.

But I’d rather be someone who has a deep level of knowledge with a handful of tools rather than someone who has a little bit of knowledge over a wide array of tools.

In other words, I don’t want to be “a jack of all trades, master of none.”

So when it comes to learning new tools, languages, and technologies I may try to bring one new thing – such as CodeKit – into the fold of my current set of tools during a project, but you’ll never find me actually trying to build things using a set of tools, languages, and technologies that I barely know in order to solve someone else’s business need.

Ultimately, I want a deep understanding of what I’m working with, I want to do good work, and I want others to get their money’s worth. Personally, I believe that’s what a pragmatic developer is and it’s what I’m aiming to achieve.