Perhaps one of the most tiring things of working in development in staying up to date with all of the various tools and processes available to us for helping us get our work done.
As soon as one comes out we even come close to mastering (and I use that term loosely), there’s a new dependency manager, process, server configuration, whatever, to learn and to see if it fits into our workflow.
All the while, many of us want to find the most streamlined process available for us to efficiently do our work and build our projects with as much optimization as possible.
So it’s like we’re faced with this dilemma:
Stay up to date with all of the new tools that are available or stick with what we know and hope that we don’t become irrelevant?
It sounds a bit like hyperbole, but you know the feeling I’m talking about, right?
Simplifying Our Tools
To be a little clear, it’s not so much I think we’d become irrelevant, but it does leave us wondering if we’re using the best tools possible for our work.
And in order to evaluate, we have to try the tools out in the context of a project. If it works out, great! We’ve found something new.
- If not, then are we losing time? Maybe.
- Are we losing billable hours? Maybe. (I guess that depends on how your structured the project.)
- Are we completely wasting time? I guess it depends on if you think learning something you’ll never use again is a valuable use of your time. That isn’t sarcasm, either. I legitimately mean that.
Then again, is it worth doing when you have something you know works, does the job well?
My Case in Point
I’ve written about CodeKit before. I know there are a lot of popular build tools are out there specifically tailored for Sass, JavaScript linting, package management, dependency management, minification, combination, and on and on.
Things like Grunt, Gulp, etc. They are all great (and yes, I’ve used them for various projects), but I personally find myself coming back to CodeKit for the majority of my projects.
The reason I mention this is sometimes it’s frowned upon. Some people – as is true in a variety of areas of development – tend to view the tools they use as the epitome of what the rest of us should use.
You know how it goes.
You don’t use X, Y, and Z? You use CodeKit?
Yep – I do. And here’s why: When it comes to productivity and trying to get my workflow to be as efficient as possible while also optimizing the development work I do each day, CodeKit fits the bill.
For me.
It’s Not For You (Or Maybe It Is)
The purpose of saying this isn’t to try to convince you to use it. I’ve no stake in the game. It’s to remind you – and me, if I’m being honest – you need to explore and stick with the tools that streamline our workflow as much as possible.
We need to stay focused on simplifying our tools to the point where we’re efficient, practical, and optimal and completing projects.
When something new comes out, sure, consider using it, but don’t do it at the expense of using it for the sake of using it. Use it if it helps you do what you’re doing better.
Will I always stick with CodeKit? I don’t know. For now, I am but that’s because it helps me simplify my workflow while also maintaining the levels of control I need for the things I’m building.
But it’s a good thing we have choices, right? Ultimately, I may need something different.
This really hits home for me because of how often I hear people discussing what tools to use for local development and how they should be using tool X and not tool Y.
I think it is a huge cause of imposter syndrome because people feel like they aren’t smart for being able to understand or fully utilize something even if it wouldn’t ever fully benefit them and a lot of times they’d rather continue using what works for them instead of using whatever might be second or third best.
Just like your example of using CodeKit, we should use what allows us to implement newer technology in the easiest way, even if it isn’t the most streamlined.
More people need to be open minded and realize that we all work differently and just because some new shiny thing comes out that does all this awesome stuff, it doesn’t mean someone is wrong for choosing a different tool. Thank you so much for writing this.
For sure. Right now, VVV is a popular package among WordPress developers. And rightly so – it’s a great setup and offers a lot of fantastic features.
But I don’t use it.
The reason being is I want my local development environment to mirror that of staging as production as much as possible and the VVV stack doesn’t do that for me right now.
It might later, but not now.
Sometimes I think people interpret the lack of someone using something as a sign of ignorance or a slight against the software when it may be a deliberate choice for what works best for them.
The imposter syndrome discussion is one I generally avoid, but I think the point you’ve made here is spot on in that people continue to use what works for them not just because it’s what they like but because it benefits them more than the alternative.
Right! CodeKit, for my projects, does help streamline my workflow.
But I’ve worked with other teams and on projects where I had to use Grunt, Bower, etc. Does that mean I dislike those tools? No. Does that mean I would rather use my own tools? No.
It means that the project that I’m working on called for them so I used them. Nothing more.
But given the choice and given how I want to run my own shop, I’ve got the stack of tools I’d like.
+1. Well-stated.
It’s a struggle for designers too honestly. I see a new prototyping tool out just about everyday. Most of them are just iterations on each other. I usually give a lot of them a try just to have the knowledge of what it is and what it does but I usually fall back to a core set of tools that I use on a daily basis.
I believe it. I’m not even a designer and I see things showing up in blogs, posts, app stores, shops, etc. and I think “how could someone abandon what they’ve used for years for this?”
To me, it has to reach a point where the current tool is not doing a good enough job than a new tool and the new tool has to be able to accommodate what a person was doing and what they need to do.
I’m the exact same way.
Actually, this is probably a bit controversial, but I would be more likely to see someone that picks up every new tool that comes out as being less experienced…
Someone who’s been programming for a few has seen quite a few tools come and go. An experienced programmer releases that a tool is a tool, not something to show off with and they release that by picking up every new one that comes along your not actually saving time at all.
I think you bring up a good point (that is, the idea of someone being more experienced using a set of consistent tools).
I’m a fan of that, for sure, and it’s something that I find myself doing. This is probably evident in this posts and in others I’ve written. I don’t want to stay completely out of the loop with what’s out there, so I still experiment with new things but if I can’t fit it into my workflow I don’t change my workflow to fit that tool.
That seems backwards to me. And like you said, “you’re not actually saving time at all.”