Let's say you're a developer who has started working locally.
If you don't already, the idea is pretty simple. You do all your development on your own computer and then push it to the server (or the staging environment) when you're ready to review it.
But that means you'll need a local web server, a local database and more. And maybe you've not worked that way before. So it all seems a bit scary.
The good news is that there are simple products that can make it easy – especially if you're doing local WordPress development.
So you check out ServerPress‘ Desktop Server.
And you discover it saves you lots of time. It's so fast and easy to do your work.
You wonder why you didn't do it before!
Just when you get the handle of Desktop Server…
So, you're spinning up sites left and right and you're having no trouble at all. But you start hearing that some people are doing something with the Command Line.
In other words, they're becoming more efficient by skipping all the browser clicks and writing a few commands at a command prompt.
This command prompt thing is kind of cool, WP-CLI (WordPress Command Line Interface), because you can download themes and plugins, install them and activate them.
Until then, you'd been using ServerPress' blueprint feature where you could save a snapshot of a site configuration (the key plugins and theme you needed). It made you faster. But now you're thinking that a few different scripts might make you faster with greater flexibility.
You discover it saves you lots of time. You wonder why you didn't do it before!
So after you embrace WP-CLI…
Someone tells you that what you really want is several different environments on your local computer that match the different server infrastructures where you'll deploy code to.
So they start using terms like virtual box, vagrant, vvv, and mercury.
You discover that there's more to learn. Much more!
And each of these technologies will help you get faster because they reduce the friction that exists in your development workflow.
[Tweet “Every developer I know loves to reduce friction in their development process.”]
This is why so many people write “workflow” posts when it's hard to imagine that their customers might care. It's because they're so incredibly relieved at having found a way to get more efficient that they have to tell their friends, and everyone else they know.
This isn't a bad thing. It's a good thing.
You start using Mercury, so that you can run your local sites on HHVM, and suddenly everything is even faster.
You wonder why you didn't do it before!
This is the developer's dilemma…
The cost of learning each of these new approaches to your workflow is that it takes time to figure it out, configure it, and get used to it.
And your customers want you to be efficient. But they also want you to work on their projects, not your workflow.
Another challenge here is that if you use Desktop Server for just a month, or use Mercury for just a couple weeks, there's a good amount of the features or commands that you may never learn.
So every time you jump to a new workflow, you're also giving up some additional efficiency that could have been possible.
[Tweet “So every time you jump to a new workflow, you're also giving up some additional efficiency that could have been possible.”]
You're giving up an opportunity at expertise – which is good for you and good for your clients.
But you're doing it for efficiency's sake. And that's good for you and good for your clients.
Efficiency or Expertise (Experience) – which is better?
Both.
Isn't that what we all want to hear? But it's not true. Ever.
Because it's a constant trade-off we have to make. In a world where it's easy to feel like an impostor, hearing others using tools you don't know how to use takes you there fast!
[Tweet “In a world where it's easy to feel like an impostor, hearing others using tools you don't know how to use takes you there fast!”]
And we haven't even gotten into:
Feeling like there's not enough time to get this efficient?
I know.
So what do you do?
I recommend the following three guidelines. Take them for what they are…just my suggestions.
First, learn the tools you're using. Before you get into the race of learning the next tools, really master what you have in front of you. I used to have a horrible habit of collecting new books. You know, you go to the bookstore, see something awesome and buy it. But it comes home to a pile of unread books. So now, I read them first before I get to buy new ones. The same should be true for your tools. Learn what you have.
Second, automate what's easy to automate. Let's be honest – not everything is worth automating. If you spend a week optimizing a script that saves you 15 minutes per site, you'll be coding a lot of sites to break even. But if you're finding yourself spending a lot of time on CSS for various browsers, taking 1/2 an hour to learn about Autoprefixer is worth it.
Thirdly, take time every quarter to learn something that will level you up. Instead of being one of those folks who says, “this is how I always do it,” become someone who can say, quarterly, this is something I'm learning that is speeding up my work. You can collect interesting things along the way, but take a couple days at the end or beginning of a quarter and dig into them to see if it will speed you up.
This way, you have a consistent approach to both efficiency and expertise.