This is a series of posts wherein I share the dev mistakes that I used to make, and hopefully help others in doing so! Also, I reserve the right to publish these either on Tuesdays or Thursdays. As long as the title is cheesy and alliterative, I’m happy.

Back when I was a young developer just learning the ropes, I did some silly things. One of them, as you can probably guess, was developing live (making changes on a live server) instead of locally (on my computer). I was full of excuses:

“But this site barely gets any traffic! If I make a few changes live, who will notice?”

“If I code this site right on a staging server, I don’t have to migrate the site from my computer to the server because it’s already there!”

“Setting up a local server sounds hard and I’m lazy!”

I’ve heard it all, because at some point I’ve said it all. First, let me walk you through the three main ways one can code a site:

Worst: Developing on a live/production site

In my defence, even back in the old days, I didn’t do this too often. After all, it would be ridiculous to develop a full new site from scratch in a public location where everyone could see it. But, not gonna lie, sometimes when I was asked to add new features to an existing site, I found myself being both lazy and overly optimistic and just quickly doing it live on the server.

Overly optimistic? Yep! I was assuming that I wouldn’t make a mistake that would mess up the live site and even potentially ruin my reputation as a developer. And when it’s easy to take out a whole site with a single missing semicolon, this was actually a pretty real risk.

Sub-Worst: Making changes to a WordPress theme using the built-in editor

noooooooooooooo

If you are going to go ahead and make changes to a production WordPress site right on the live server, please never do it in the built-in editor. While HTML and CSS are pretty forgiving, one can royally screw up stuff in PHP (see above about missing semicolons taking out whole sites), and if you make a mistake in the online editor, you risk taking out your entire site with a White Screen Of Death™ and not even knowing why. Usually you’ll only take out the front end of your site, but in some cases, you can even lock yourself out of the admin pages. Know what’s super fun? Trying to restore your website when you can’t even access your website. Don’t do it, kids!

Don’t let this happen to you!

Better: Developing on a staging site

So, you’ve decided instead that you’re going to develop your site on a staging server or a test site that only you and the client have access to. That’s obviously way better than making changes on a production server, because at least it’s private and if you mess something up, the public doesn’t have to know! Yay!

That being said, here’s what I don’t like about this method:

1. Working off the server means that you’re at your server’s (and your Internet connection’s) mercy. All servers have outages at some point, and because the universe totally hates you, it’ll obviously happen when you need it the most.
2. FTP is slow, dudes. There’s a lot of waiting and reloading with this method, and I’m impatient.
3. Your super secret site might not be so super secret. I’ve found other developers’ “secret” “staging” sites in Google before when I wasn’t even looking for them. Oh noes!
4. Once you’ve given out the secret address for your client to see, they can/will see all the further changes you make, and might see some mistakes that you make (or wonder what happened to the site when it’s taken out by the missing semicolon of doom). When I’m troubleshooting code or trying new features, I’ll often do strange things like outline elements in weird colours, use cats and Samuel L Ipsum as placeholders, and will occasionally console.log(‘some very profane things’). I don’t necessarily need my clients seeing all of that (though, to be honest, I’m pretty shameless about the cats).

Best: Developing locally alongside a staging site

Naturally, my favourite solution is to always develop sites locally (on my computer) so that the only people who can see the site in its incomplete state are me, myself, and I. Then, when I’ve finished, I upload the site to a super secret staging server (which I’ve made sure is hidden from search engines) for the client to see. Any time I have changes to make or bugs to fix, I go back to my local server to make the changes, and then push the changes to the staging site when I’m good and ready. This might sound tedious, but trust me, it’s saved me a lot of grief.

This method is awesome because:

1. Developing locally is crazy fast! No need to wait for changes to upload or for pages to reload. There are various apps that’ll refresh your browser automatically every time you save a file, and let me assure you, this is a magical experience from which there is no turning back.
2. I can screw up as much as I want in the comfort of my very own computer. Clients and the public only ever see the site when it’s in good shape. Life is much less embarrassing this way.
3. Client-facing sites will never succumb to the White Screen of Death™ due to a missing semicolon.
4. During development, I always have an up-to-date version of the website on my computer in case anything happens to the server.

Coming up next: How I develop locally!

Are you intrigued about the idea of developing locally? If so, stay tuned! My next post in this series will go into detail about how I develop locally, which programs I use, and other fun tips and tricks. And if you disagree with any of this, that’s cool too! Feel free to share your perspective in the comments below or reach out on Twitter.