Many of you know one of my passions is entrepreneurship. This is part of the reason I became a web developer and one of the reasons I love building Buink.

Part of entrepreneurship is hiring the right people. Hiring is hard and it can make or break your project and company. Hiring developers is even harder because of the lack of supply, the difficulty in assessing skills, and the long-term consequences the wrong hire can have.

This is why I enjoyed reading Fletcher’s recent post this morning, “The hacker’s guide to hiring software engineers.” He included tons of great resources and ideas. It is definitely worth a read.

Inspired by his post I thought I’d add two additions, from my point of view, relating to hiring contractors vs employees and testing potential developer hires.

Contractor vs. Employee

I agree with his section on contractors vs. employees in many instances, but being that I’m a contractor and not interested in being an employee (and probably never will again) I’ve put a lot of thought into the question and summarized several good reasons startups and other companies may want to consider contractors as part of their technical strategy.

Testing Potential Developers

Fletcher has some great recommendations on testing potential developers and in many instances, a test can be helpful. However, I’ve never seen this done well and I have been asked to take these kinds of tests many times. I’m not saying it can’t be done, but I would love to see it improved in the following ways:

1.  Only send people a test if you’re serious about moving forward with that person. Vet them quickly over the phone first.
   • I see companies all the time that ask 10 or 15 developers to take an hour test (unpaid) when they’re only planning on hiring one. I think everyone could agree that is a waste and, some might say, even disrespectful to other people’s time.
2. Make the test relevant to the type of work you’ll be asking of the developer. This seems obvious, but trust me, it is not.
   • Decide on the first task you’d ask the developer to do and make that the test question. If it is database work you need, ask them to setup a model. If it is css work, ask them to create a list of items that is responsive. If it is Angular work, ask them to create a directive that has an api.
   • Too many times people get these questions that have nothing to do with day-to-day coding but have too much to do with nuances of a language that are rarely used in practice.
   • So, they end up hiring book smart developers that sometimes have little experience in practice. The questions you choose should be geared to the types of coders you want to hire, street smart, or book smart.
   • That is not to say that some theoretical questions aren’t good, but in my experience, the biggest driver of projects coming in under budget and on time is street smarts.
3. This leads me to my #1 recommendation for hiring developers. It is related to Fletcher’s tip on a contract-to-hire relationship but a little more specific. Send them a small paid task, maybe 8 hours of work. Have them track their time and see the quality they send back. If they do well, send them more work. If they keep doing well, make them an offer. I’ve had ton’s of success with this strategy.

I recently finished an IOS app using the Ionic framework. I really enjoyed the experience. Ionic has tons of time saving features, and it is based on Apache Cordova, so you can use Cordova plugins to make apps that feel quite native.

My project comps required a button that would allow the user to choose a picture from their library or take a picture. As I searched the web for the easiest way to do this, most of the articles talked about using two plugins ( cordova-plugin-camera and cordova-imagePicker). This made me cringe. Wasn’t there a plugin powerful enough to do both? Not only that, but I got down the road a little bit and couldn’t get cordova-imagePicker to work on my project.

Hopefully this article will save you some time. 🙂

Some caveats:

• I’ve only tested this on IOS, but in theory it should work on Android too.
• I have the following dependencies in my package.json:

{  
  "dependencies"   {    
    "ionic": "^1.7.14",    
    "cordova": "^6.1.1",   
  } 
}

Install Cordova Camera Plugin

You need to install the Cordova Camera Plugin (e.g. I’ve installed [email protected])

ionic plugin add [email protected]

Using the Ionic CLI is important here (as opposed to the cordova CLI) because the ionic automatically adds the following line to your package.json

{
 "cordovaPlugins": [
  "[email protected]",
 ],
}

Make sure your package.json updates. An updated package.json file is helpful because then you can run `ionic state restore` and instantly have the same exact plugins as required by your code. 

Install ngCordova

You can install inCordova with bower:

bower install ngCordova --save

Then include the new file in your index.html file:

<script src="lib/ngCordova/dist/ng-cordova.min.js"></script>

Now you can inject it into Angular:

angular.module('myApp', ['ngCordova']);

See the official ngCordova install directions here.

Start Using The Camera

Here is were the magic happens! Like I mentioned, other articles were saying that you needed both cordova-plugin-camera and cordova-imagePicker, but the latter isn’t necessary.

The most important part of what I’m going to show you is…

$cordovaCamera.getPicture(uploadPhotoOptions).then(takePictureSuccess,takePictureError);

A full list of options (uploadPhotoOptions) can be found at the cordova camera plugin github repo.

The most important option for our purposes is…

uploadPhotoOptions.sourceType = Camera.PictureSourceType.CAMERA;
OR
uploadPhotoOptions.sourceType = Camera.PictureSourceType.PHOTOLIBRARY

It should be pretty self explanitory. Just call $cordovaCamera with the sourceType = Camera.PictureSourceType.PHOTOLIBRARY for photolibrary and Camera.PictureSourceType.CAMERA for camera.

One gotcha…

Camera.PictureSourceType.CAMERA only works on an actual device, unfortunately you can’t test in the Ionic emulator (i.e. `ionic run emulate`).

Full Code Example

I’ve included a full working sample below.

$ionicActionSheet.show({
 buttons: [
  { text: 'Take Photo' },
  { text: 'Choose Photo' },
 ],
 cancelText: 'Cancel',
 titleText: 'Take or Choose a Photo',
 buttonClicked: buttonClicked,
});
function buttonClicked(index){
 var uploadPhotoOptions = {
   quality: 50,
   destinationType: Camera.DestinationType.DATA_URL, //FILE_URI, NATIVE_URI, or DATA_URL. DATA_URL could produce memory issues.
   sourceType: Camera.PictureSourceType.PHOTOLIBRARY,
   encodingType: Camera.EncodingType.JPEG,
   allowEdit: true,
   targetWidth: 300,
   targetHeight: 300,
   saveToPhotoAlbum: false,
 };
 if (index == 0) { // Take photo
   uploadPhotoOptions.sourceType = Camera.PictureSourceType.CAMERA;
 } else if (index == 1) { //Choose Photo
   uploadPhotoOptions.sourceType = Camera.PictureSourceType.PHOTOLIBRARY;
 }
 $cordovaCamera.getPicture(uploadPhotoOptions).then(takePictureSuccess,takePictureError);
 function takePictureSuccess(success) { 
   vm.userProfile.image = "data:image/jpeg;base64,"+success; //this is how I store the image to firebase
 };
 function takePictureError(error) {
   $ionicPopup.alert({
     title: 'Photo Error',
     template: error,
   });
 };
 return true;
}

I’m happy to answer any questions you may have, just post a comment below.

The purpose of this post is to outline some of the guiding principles of code we use at Buink. These principles inform how we review  and write code and we ask all our contractors and employees use these as well.

Summary:

• Cost Effective Technology (efficient, maintainable)
• Responsive and Transparent Communication
• Quick Turn-Around
• Eloquent, Simple, Maintainable Code
  • Organized Code
  • Readability vs. Performance
  • Self Documenting
  • Collapsible
• Less Code, Less Problems
  • Code Reuse
  • Code Refactoring
• Intelligent Solutions
• Test Driven Development

Cost Effective Technology (efficient, maintainable)

One of the things you’ll notice as you read these principles is that almost all of them relate directly to making your code cost effective. I’m a developer, but I also call myself a business technologist because I’m constantly looking for ways to make:

1. technology affordable for business
2. business better with technology.

Focusing on cost effective code seems like a no-brainer, but you must realize that this isn’t the norm. Every day I see articles written about this or that best practice which may be bad for business.

I’ll give you an example: test driven development. I’m a huge fan! I love the benefits that tests can provide your code, but you have to understand that testing has trade-offs. Tests add about 30% to 40% of time to your project. This means your end-product costs more. So, if your project is a minimum viable product, then adding tests may be overkill. Also, tests can be done poorly. The big takeaway here is that testing is important but not for all projects.

Another example is WordPress. A big portion of my colleagues hate WordPress and actually mock WordPress developers. Why? Because they are threatened by the fact that WordPress comes out-of-the-box with tons of features they usually get paid to add. On the other hand, I look at WordPress as a tool perfectly suited for some jobs. If you’re looking for a simple site, I often call them brochure sites, then there is no need to code it from scratch. WordPress is a time-tested piece of software perfectly suited for the job.

This principle really sets us apart at Buink. I was an entrepreneur before I was a coder, so I see the trade-offs and try to educate my clients about them. I’m also constantly on the look-out for technologies (frameworks, platforms, etc.) that give more bang for the buck.

Responsive and Transparent Communication

Many of my clients are surprised when I add them to our internal project management software or give them access to the code during production. They’re also surprised how quickly I respond to email and how easy it is to reach me via phone, “call anytime” I say, and I mean it.

I find that being as transparent as possible with clients reduces misunderstandings and improves relationships.

I take communication to the next level by sending weekly invoices so clients know exactly how much of their budget is being spent. I also include a detailed breakdown of every minute of work in each invoice.

Quick Turn-Around

If you have a deadline, we’ll do everything we can to hit it. We’re not like other developers who try to manage their own schedule at the detriment of their clients. We’ll come up with a plan that works for your timeline and we’ll focus on hitting it.

Eloquent, Simple, Maintainable Code

Reading code can be a exercise in patience, particularly code that is not your own. Stringing functions together with intertwined dependencies increases the complexity of the code. Some people think complexity is just the nature of code. We don’t! The more complex the code is, the less readable, maintainable, and manageable. We strive to make our code simple and readable in the following ways.

Organized Code

There is a reason that organization is a synonym for business. Organization systematically reduces cost and increases benefit. With code there is no difference. Organized code is readable code, organized code is easy to maintain, and organized code makes us happy! 🙂

There is nothing worse than opening a file only to find a jumbled pile of mess (spaghetti anyone?). You have no idea which variables are used throughout the file and which are used only once. You have no idea where features start and stop. You have no idea which functions have which dependencies.

Our goal at Buink is to write code that you can get a feel for quickly. This is why we put the most important variables/functions/apis/references near the top of the file. We use setup functions to dispatch other important functions and to organize important variables. We use cutting edge technologies to separate components and make them reusable and updateable. We do all this so that your code lest costly in the long run.

Readability vs. Performance

At Buink, we operate under one simple rule: people are more expensive than servers. Hopefully this is self-evident, but if not, just look up the average price for a developer per year vs. the average price of a server. You’ll quickly find that it is much cheaper to throw more computing power at a problem than it is to throw another developer at it. This becomes less true when your site is getting billions of page views a year, but most projects won’t and don’t need to.

This doesn’t mean we throw best practices out the window. No! But when we need to decide between simple, readable, maintainable code vs. performance, we lean towards readable.

If performance does become an issue, we circle back and attack the bottlenecks that are hit by the end users most often.

Self Documenting

One problem with documentation is that it is constantly outdated. You make a quick change to line 300 and your documentation on line 1 is now misleading. I can’t tell you how many times I’ve tried to understand code and wasted money trusting the documentation. Things are constantly added, moved, changed, removed, and documentation is very poor at keeping up.

The only surefire way to keep your documentation up-to-date is to make it part of your code. With this, you cannot change the code without changing the documentation. Rather than spend time updating the documents, you spend time updating the variable names and function names. Then, when future developers take over the project, they find it easy to read and update.

I cannot stress how valuable a principle this is; this principle alone has saved our clients tens of thousands of dollars. This mindset isn’t easy to attain. It takes a little extra thought about what could be confusing for future developers and how can I write the code to make the intent clear, but this extra effort is well worth it.

Collapsible

One aspect of code that is often overlooked is proper indentation and closures. Most modern code editors allow developers to collapse code based on indentation. Writing code using closures and uniform indentation can allow a thousand line file to collapse into 6 or 7. Then you can drill down to the parts of the code most important to you. This speeds up development and reduces the overall cost of software.

Less Code, Less Problems

There are many ways to skin a potato. 🙂 There are tools and techniques you could use. Code is similar; there are always many options to accomplish the same task. Often, the first solution you think up/find is not the best. We’re constantly pushing to find the best, most intelligent, and simplest solutions to client’s problems. Reducing the lines of code is one technique we’ve found that skins our code potato well.

Building features with the least amount of code has many benefits including less bugs, less problems adding or updating features, and more clairty when reviewing code. We use the following strategies to reduce the number of lines in our code.

Code Reuse

The most important principle here is we NEVER copy and paste code. Ok, I’m exaggerating a little, but for the most part, the rule is to avoid copying. Whenever we’re tempted to copy and paste, we catch ourselves and start thinking about how we could make this into a reusable component or function.

This doesn’t mean that we just create reusable components for every little feature. A re-usable component costs a little bit more than a functional component and there is no reason to incur this cost if the code may never be reused. Also, making re-usable components reduces the readability and clarity of the code. For this reason, we wait to make re-usable components until we need them (i.e. until we’re tempted to copy and paste).

When reusing code, we strive to make it independent of its environment. In other words, we want it to plug-and-play in multiple areas of the website. We pay attention to adding default options to the code so it requires almost no setup and can be extremely customizable.

Code Refactoring

After building complex features/functions, we generally review the code to see if there is any ways we can make it more eloquent. Goal #1 is to get the feature working. Goal #2 is to reduce its size and make it more efficient.

Intelligent Solutions

Again, there are many ways to skin a potato. Some are more wise then others and the truth is most of the easy to find solutions are not good. Many of the previous principles can help us arrive at the smartest code, but there is still something to be said for thoughtful code. We don’t just find the first thing that works and throw it in. We have to consider the impact of our design on the whole system. How well does each solution address the overall business need? Is a solution forward thinking; in other words, will it set us up for success in the future or will it introduce technical debt?

Given the complexity of code, it is rare that future developers praise the code they inherit from us, and yet, that is our goal. To solve problems in such a way that enlightens those who read it.

Test Driven Development

Yes, tests are important and we push all of our clients to let us implement them. We’re constantly trying to improve our mindset around tests. Test driven development (TDD) is a buzz word these days, but 80% of the tests we see written by outside developers are useless clutter, and many time detrimental bloat. At Buink, we push our developers to think deeply about the type of tests that are valuable and the best ways to write them.

I’d love this post to spark a conversation because I’m still formulating this opinion.

In building Buink Web Development, I’ve worked with over 15 clients all over the country and close to home. The interesting thing is that I’ve met very few of them face-to-face. This is true of both my clients in San Francisco/LA/Utah as well as my clients right here in Denver. In fact, 3 clients come to mind that operate nearby and whom I’ve never met.

One good example is a client that I worked with last year for about 6 months, I’ll call them GameChanger. They operate probably no more than 20 minutes from my house. They were referred to me by someone I’d met at the grand opening of Confluence, a co-working space in Lafayette. They had an existing code base and I cleaned it up, re-designed the UI, added pages, and added some really complex features. We’d use phone, email, and Jira to communicate and if there was something really complex, we’d use Google Hangout.

I share my experience with GameChanger because we could have met in person if we wanted to, but why? Most of our communication didn’t require a time-consuming meeting. Ninety percent of it could be done via email and Jira, and for the couple times we needed to meet, a quick chat via Google Hangout saved close to an hour of drive time.

Today, face-to-face meetings are an expensive nice-to-have.

Despite the fact that face-to-face meetings are just an expensive nice-to-have, I find myself constantly trying to avoid them (I think it is my obsessive focus on efficiency :)). Many people have it set in their mind that they have to sit across from someone to work with them.

I’ll admit, in-person meetings are more memorable. Their face is more indelibly imprinted on your mind, their mannerisms are more noticeable (or more distracting), the things they carry with them tell part of their story, but I’m not sure that these niceties are necessary. They are, however, costly.

I’m not sure that these niceties are necessary!

I went to a meeting last week to provide technical direction for an IOS app that I hope I get to build. I got a first impression of the company, where and how they work, who works with them, and a little about their background. It was pleasant. I like to meet with people, but it did take two hours of drive time for a two hour meeting. And, unfortunately, I don’t own a self-driving car (trust me, I will!).

Luckily, I did get paid for the time in the meeting, but the client wasn’t planning on paying for drive time. I don’t blame them, who pays for drive time? No one. No one, that is except for the person driving.

I guess I could just raise my hourly rate. That is probably the most common reaction to covering incidental costs, but I’d rather push the clients to realize the true cost of development. They may value in-person meetings more than I do, so I want to happily give them the option rather than avoiding it. 🙂

So, I’ve decided to charge for drive time. I have to admit, that it doesn’t always go over really well, but I think I just need to work on my delivery. Thoughts?

UPDATE 2018.05.11

So, I tried the charging for drive time thing and it didn’t work out so well. 🙁

I mentioned it to a couple potential clients and the reactions I got were as expected. “I totally understand where your coming from, but…we’ve always done things like this.” So, I made several exceptions and then just stopped mentioning it all together.

I keep experimenting with ways to get out of face-to-face meetings and a couple weeks ago I lost a potentially lucrative client related to this. I didn’t even mention drive time but I did say, “I’d don’t typically like to meet in person at this stage of the conversation, but because you’re a referral from ZZZZ, I’ll make an exception.” Referrals almost always become clients, so I’m ok bearing the cost.

She responded, “That is honestly one of the strangest responses I’ve ever received. . .Not sure that this will be the right fit.” Ouch.

Frankly, I’m not too hurt by her response because she probably would have expected me to waste a lot of time just to work with her, but it did cause me to pause.

I’ll continue to experiment but I find it interesting how adamant people are about meeting in-person and interesting how they bristle when I ask them to bear the cost.

I think part of the reason is that people don’t often look at the true cost of doing business. They have this nebulous “administration” expense that includes lots of wasted time by sales people, executives, and others.

At Buink, we understand our costs exactly! That is how we can deliver maintainable, intelligent, simple code and a price that competes with the best onshore and overseas teams. That is how I know every person on my team is delivering value that exceeds our competition, even if our competition is in-house talent. This is possibly why I can’t keep up with demand for our services.

I recently passed my 1 year mark building Buink Web Development and thought it is about time to address one of my biggest competitors: offshore development. 🙂

I say competitor, but I honestly don’t see it as that. Looking to the future, I hope that offshore development is my friend, not my enemy. In fact, I don’t think you’ll still be alive in this industry in 20 years if you don’t learn to leverage offshore resources (unless offshore is also made obsolete by artificial intelligence, mu ha ha ha!).

I hope that offshore development is my friend, not my enemy.

That said, offshore development is not for everyone. In this article, I’ll share some of my experiences, list the pros, list the cons (including some solutions to counter the cons), and make some recommendations to help you make the most of your development dollars.

Here is how this article is broken out:

• Pro: Come on Down, The Price is Right
• Con: Their Timezone is Sleeping On the Job
• Con: Lost in Translation
• Con: Spaghetti Code
• Con: Stolen Code
• Solution: Make Offshore Work

Pro: Come On Down, The Price Is Right

The low price of offshore development is the only “pro” that comes to mind. There may be more, but I can’t think of any.

I’ve met and interviewed lots of developers (offshore and on) and, its true, most offshore developer costs less than onshore developers. No surprises there, in fact, some charge quite a bit less; for example, the lowest hourly rate I’ve seen is $9. That is cheap! Imagine, a highly skilled developer in a distant land making less than we pay people at McDonalds. Nine dollars, however, is unusual, the range I’ve seen is from $9-$60 and the average is about $25.

“The only ‘pro’ that comes to mind is low price.”

These rates sound great, but are they too good to be true? They can be if you’re not careful.

Con: Their Timezone is Sleeping On the Job

When you’re trying to move at the speed of business, you’ll quickly realize that having a 5-12 hour delay in communication can really slow a project and even waste money. When you’re asleep, your developer is awake and vice versa.

I’ve seen the following two scenarios many times. You wake up, rub your eyes open, grab your mobile phone, and review the developers work from the night before. You realize they spent the whole day going down a “rabbit hole” of misunderstanding. You send an email clarifying something they did wrong. They wake up 12 hours later and respond with a question, which you don’t see for another 12 hours. The cycle continues! Work stops for multiple days and time is lost. Or, worse yet, they don’t clarify and spend another 8 hours going down another rabbit hole.

This cycle isn’t a product of the distance between lands. The internet and new technologies like Google Hangout, Slack, Trello, Basecamp, and others have virtually eliminated the distance between two points on planet earth, but the timezone barrier is still a serious issue.

I experienced this problem first hand with a developer not long ago, I’ll call him Victor. Our relationship was already on the rocks because he was hard to communicate with and he missed a small deadline. I gave him a second chance with a small project. I expected him to return the code in two hours, but when I woke up the next morning I found that he had billed 8 hours and still hadn’t delivered the code. He had all kinds of questions and I quickly realized he was trying to make changes on the wrong code base. No wonder he was confused about my instructions. Had we been on the same timezone, he could have easily reached out and I could have followed up. Instead, he spent all night spinning his wheels.

“The timezone barrier is still a serious issue”

The only solution I’ve found to fix this con is to require the offshore developer to work in my timezone. They won’t always do that and sometimes they’ll make promises they don’t keep, but if they do, it will save you a lot of time and money. If they don’t, just consider your true cost of offshore development at something like $40/hr and not the sticker price of $25/hr.

Con: Lost in Translation

As I’ve said in previous articles, development specifications are hard to communicate EVEN to native English typers and readers. When you add in the language barrier, you may find it impossible to communicate.

Notice, I specified typing and not speaking. Speaking English is important, but if a developer can’t type quickly, they can’t code quickly. It sounds simple, but it is often overlooked. Coding is typing; and typing in English will always be harder for non-native speakers.

Reading is also critical. Your developer needs to be able to easily comprehend the project specifications. In addition, they’ll need good reading skills to find help with bugs and features. When a developer hits a snag, a quick search of the internet often results in a solution. Most of the time, someone has written an article about a feature you’re trying to implement. If a developer can’t read and understand quickly, they’ll likely be re-inventing the wheel with every new feature.

The truth is, I’ve never met an offshore developer that types and reads as well as a native English developer, and even some native developers struggle. 🙂 You just have to understand that this is going to be an issue. The question is, how much of an issue. Are they twice as slow? If so, the true cost of offshore development is looking to be closer to $80/hr.

“Coding is typing; and typing in English will always be harder for non-native speakers.”

The best you can do is try to asses their English skills and avoid those who have trouble. You’ll realize really quickly if a developer is avoiding email communication and opting for conversations via Skype instead. This is a red flag. I try to force them to communicate everything via email and chat. If I notice some big grammar errors, the kind where you can’t even understand what they’re saying, then I usually don’t move forward.

In addition to screening their typing and reading skills, you must also realize that they’re going to misunderstand some things and they’ll waste money in the first or second rabbit hole. As you can imagine, things get out of hand very quickly.

Con: Spaghetti Code

I have yet to work with an offshore developer whose deliverables were significantly more valuable than that of an onshore developer. I’m not saying they aren’t out there, but I’m still on the lookout. In my experience (which isn’t trivial) they aren’t much cheaper.

For example, I’ve talked about the first project I sent offshore in earlier posts, but I’ll summarize it here again. It was a custom WordPress site. When I took over the code it was filled with all types of security flaws, they had hacked the WordPress core (making it impossible to update), and there was almost no structure/organization/architecture to the code. I’ve heard other people talk about “spaghetti code” and that is exactly what this looked like. From a user perspective, the site looked great, but from a developer perspective, it was a mess.

Even Victor, who I mentioned previously, delivered code (albeit late) that on the surface looked good but had to be re-coded in some aspects. Did his code add value to the project? Yes, but not without exception. Even though his rate was lower than my other onshore developers, his code ended up costing about the same or more.

“From a developer perspective, it was a mess.”

The only solution to this con is that you have to have an experienced developer review all offshore code. Just because it looks like it is working, doesn’t mean it is.

I’m sure I’ll mention this again, but I highly recommend you track code changes (via Git) and require all code changes to be packaged into small, feature related groups (called pull requests).  These pull requests should be reviewed by an experienced developer you trust (like an onshore developer you hire as a lead).

Con: Stolen Code

This con is only hearsay, in other words, I haven’t experienced it myself. I include it here because I could totally see this being an issue.

I was out to lunch with a client recently, we’ll call him Zuck. He had me act as a developer lead on a project with a short timeline. I brought in several contractors to speed up the process. I mentioned to him that one of the developers was from Kiev, Ukraine and he said he was glad that I wasn’t working with anyone from India. He told me how he’d worked with several in the past and questions their ethics. “Sometimes,” he said, “they’ll just hack someone else’s code and package it up for you instead of developing it themselves.”

I didn’t dig into Zuck’s claim, but I take his word for it. I’m not saying that India is somehow worse than anywhere else, but the rule of law isn’t the same in many other countries. The risk of getting sued by a client is drastically less for offshore developers than for us onshore. Offshore developers don’t operate under the same rules we do, and as a result, I can imagine there is less incentive to write honest code.

Luckily, the solution that prevents spaghetti code will also solve this con. Hire a developer lead like Zuck! I can’t stress it enough; you should require developers to track code changes (via Git) and package code changes into small, feature related groups (called pull requests). Then, have each pull request reviewed by an experienced developer.

Solution: Make Offshore Work

So, with only one pro and several cons, you may be wondering why I started this article hoping that offshore development would be my friend in the future. Well, you have to admit the price is very nice, if you can figure out how to prevent the cons.

Some of the cons are easier to solve than others. Timezone and communication issues are difficult, but through some trial and error with different offshore developers, most businesses can overcome these cons. Just be prepared to loose some time and money in the trial and error process.

It is, however, much harder to asses coding skills, both before hiring and while on the job, unless you are a developer yourself. For this reason, I don’t recommend overseas development for anyone who is not a developer. There are just too many phonies. There are too many overseas developers charging high rates and delivering substandard results.

If you’re not a developer, the only way I’d recommend you use overseas developers is if you hire an onshore lead developer you trust. This lead developer will review all code changes, review progress based on the number of hours worked, and make decisions about the effectiveness of overseas resources.

“Hire a developer lead like Zuck!”

I have several clients, including Zuck, who use my services to lead a team of developers. Some have existing developers they’ve worked with for a while and they want me to take over and make sure things are going as planned. Others want me use developers I’ve worked with in the past. Either way, you’re better off letting me worry about timezone, communication, and skills assessment.

What do you think? I’m sure I missed something, so please share your comments below!