Development tools are easy to come by these days. In fact, I think it’s harder to choose what to use than anything else. Never before have we had so many choices especially when it comes to the web.

Development Tools: Programming Languages

Just some of the popular programming languages, let alone tools.

Yesterday, I talked a bit about how there’s a particular breed of developers who love to get on their soapboxes and talk all about their superiority because of the development tools they use. If you haven’t read it, you can, but it’s not necessary for this post.

However, I will state that this is Part 2 of what I wrote yesterday. I even said:

Originally, I had this written as a single post, but it got a little long, so I’ve opted to split it into two pieces.

And I know: Yesterday was less about development and more of a critique of the nature of our industry. I try not to write too much about that, but there are times for exceptions. That was a time.

This one is not.

Why Do We Use These Development Tools

If there are so many great development tools that are available to us, then why do some people opt to use some packages while others choose to use other packages?

It’s a good question because they all offer their sets of advantages and disadvantages, right? I mean, what software doesn’t? But here’s the thing:

When you insult or look down upon the development tools a person is using, you’re making assumptions about why they’ve chosen the particular set of software with which they want to work.

If a person is a hobbyist and all they need is something simple to help them get going with building simple on sites on their machine, then using virtualization is overkill.

MAMP 4: Free

A basic instance of MAMP. This is all some people need. And it works great.

If a person is working from the small-to-mid-size range in business and they aren’t using the latest and greatest enterprise development tools, then that’s fine. If what they are using helps to mirror the environment to which they are trying to deliver, they are on point.

If a person is using what might be considered a heavy-handed solution to build out a complex multi-site solution that seems to be way overkill for your needs, that’s not your problem nor is it your place to make an assertion. They are using the tools that help align them with their customers’ needs.

And that’s what it comes down to, isn’t it? We need to be using with what best aligns with the needs of the business. And I don’t mean just the business for whom we’re working, but the business in which we’re working, as well.

How We Work

By that, I mean that I want to make sure that the people I’m working with are using the same setup as me (I don’t know too much about the operating system), but when doing work for Pressware, I want to be able to share images and configuration with the team.

Using Tower with Git

I prefer to use Tower for Git but that’s not the point of this post.

This ensures we’re all working off of the same foundation. But I’ll go as far as to say I don’t care how they have the environment set up as long as it offers the following:

  • Apache or Nginx (depending on the client),
  • PHP (from 5.6.25 up to 7.0.0),
  • The latest version of WordPress,
  • A way to enforce the WordPress Coding Standards with their editor or IDE of choice,
  • A way to transpile Sass files into CSS,
  • A JSHint tool,
  • A way to transpile JSHinted JavaScript files into a single JavaScript file.

This might sound like a lot, but it’s not that complicated of a setup. For example, if you’re using macOS then you can use something like:

There are some Windows equivalents, as well but that’s the besides the point. No, this doesn’t take into account things such as version control or deployment tools, and I find that to beyond the point of this point.

Development Tools Are Your Foundation

Ultimately, this is about how we select the tools we use to create the foundation off of which we build our solutions.

Remember, we’re in the business of building solutions for others. To do that, we need to make sure that we’ve got a solid foundation that best matches their needs and allows us to have a pleasant experience writing our code.

Quality Code and Bloat

I really enjoy writing code and getting work done using Atom (along with certain packages).

Furthermore, our development environment should closely mirror the staging environment and the production environments in which our code is running. This streamlines the testing and deployment process and helps to avoid so many hurdles.

So when you end up talking endless – and possibly needlessly – about the tools a person as chosen to use, you may be implying that they haven’t evaluated all of the possibilities for their business. On top of that, you assume that they aren’t pragmatic developers because they aren’t using something that you use.

When it comes to the development tools that form the software foundation of our business, it’s important to recognize that developers select tools that set themselves up for success. Not for “is my set up as complicated as possible?”

Two Points For All Of Us

So, as mentioned in the last post, our industry as its ego problems. They extend far and wide beyond discussing development tools, but this isn’t the post to discuss that. Instead, it’s about two things:

  1. Be confident in the foundation of tools that you’ve opted to use. Evaluate others, learn and determine if they are a better fit. If so, use them; if not, don’t sweat it.
  2. Don’t look down or chastise others for not knowing what you believe to be “the latest and greatest development tools.” They may know it, they’ve just opted not to use it.

This isn’t only about you either. It’s just as much for me, too. So let’s all try to adhere to what’s mentioned in the previous post and this one.

I think it will make our conversations much more productive, meaningful, and less egotistical.

Series Posts

  1. Software Development Soapboxes: The Industry’s Ego
  2. Development Tools for WordPress: The Industry’s Ego