3 Strategies for Better Communication with International Freelancers
One of the biggest advantages of services like oDesk is that you get to tap…
As a marketing consultant, I am frequently in the position of recommending web developers.
This article is an open letter to all present, past, and future web developers that I work with. By reading this article, you will learn how I think and avoid friction with me. (I’m actually a very pleasant person, but I get a little annoyed when I see developers making the same mistakes.)
This is a public service announcement to web developers.
Many developers have the opinion that all problems can be solved by some type of plug-in. Although plug-ins can be tremendously helpful, they can also act as a crutch for laziness.
Here’s a perfect example: As a marketer, I always want client websites to load extremely fast. Some developers might say, “Hey! We need to install a caching plug-in as the first priority. That will help us speed up the site.” Although this may be true, I prefer to address the problem – not just the symptom. For example, does the site have a gigantic video embedded on the homepage? Or, is there some clunky code that could easily be fixed first?
Here’s my point: Before we implement additional complexity to a website, let’s be certain there’s not a more obvious solution.
We live in an age where unbelievable web themes cost less than $50. Granted, there may be things that you or I may not like about a given theme. However, in my experience, it’s best to avoid major customizations when possible. Let’s try to make the template work!
There are a couple of reasons why I feel this way. First, if I ever have to change web developers, it makes it harder for the new developer to know exactly what you’ve customized. Second, if we ever have to update the theme, there’s a greater likelihood that something is going to break.
I’m not completely against customizations, but they should be a last resort.
In situations where we must customize the code, it’s best to maintain a shared document of your CSS and other code changes. It not only helps me understand what you’re doing, but it also helps us scale our marketing operation in the future. It’s also handy for your own record-keeping purposes, especially when you need to roll back changes.
Most content management systems allow you to load things as “drafts” for approval.
Unless I specifically tell you to do so, please save items in draft format for my review. (There may be some circumstances where I tell you to publish something as “no index, no follow” or “password protected,” but I’ll provide specific instructions when I want you to do so.) In particular, blog posts should never be published without my prior approval.
If you want to stay busy, your best bet is to check in daily while I’m online. I prefer to chat with web developers in the morning my time, which is usually evening or late afternoon for developers in eastern countries. This works out very well for everyone. During my workday, I can delegate tasks to you. Then, while I’m sleeping, you could be doing the work. The next morning, when I wake up, I’ll review your completed projects. The project repeats itself over and over again.
Final note: Missing a meeting (without letting me know in advance) is a big warning sign. If you do that more than occasionally, I’ll have no choice but to look for a new developer. You can avoid mix-ups like this by reading my book about virtual work (download Chapter 1 for free).