Programmer for Hire

Sometimes the greatest thing about being a programmer for hire is you have virtually unlimited access to a very useful class of service provider.

The employee discount is pretty nice, too.

The notion that software is eating the world is fast becoming a commonplace quotation and is well on it’s way to Cliché Town.

Correspondingly, it’s not that hard to think up any number of sexy and interesting (if not downright useful and/or profitable) projects that might be pursued.  This holds doubly true for those of us well immersed in the craft: we dabble in this stuff all the time, seeing countless examples of what the other smart monkeys are dreaming up this week which affords limitless opportunities for ideas to cross-pollinate.

If you love the programming craft, I think personal projects are pretty natural to pursue, bounded primarily by bandwidth¹.  Conversely if you’re only in it for a paycheck, personal projects are never going to be a priority because when free time comes about, well, fuck this programming stuff–I’m on break.

One of the highly instructive things about doing a personal project is that it allows a programmer to experience being completely at the source of a project.  By that I mean: completely in tune with the purpose and vision of why do the project at all, and thus able to effectively navigate the countless micro-decisions about how to create a fits-like-a-glove solution.  It is the complete absence of a Creator/User Gap, and, put into crude terms: it’s a matter of being keenly aware of when something sucks and when it is great.

Why is this instructive?  Because one of the key ways for a programmer for hire to be fantastic is to fully own whatever vision and purpose of the project they are hired for.  If you do, and then you create something you think is great, your client will likely agree.  Dabbling in personal projects gives you the experience of fully owning the vision, and cultivates your ability to do that with other people’s projects.

It’s also a unique opportunity to create and showcase something that you’re really proud of.  Assuming you can muster the whole “doing a substantial chunk of work without a tidy paycheck as reward”, a personal project can be the shining beacon of your ability, with nothing external to detract from it.  Often as servants to the vision of others, our proud work is sometimes blended into projects based on problems which are uninteresting, design which is unflattering, or direction which is lackluster.

By contrast, a personal project need not be compromised any such excuse.  It’s the ultimate act of putting your money where your mouth is insomuch as “Well, if it were up to me…” speak is concerned: it’s all up to you.

All of these properties of personal projects suggest they’re a really good predictor of talent that is worth hiring.  Though this approach may suffer from the occasional false negative (even the greats now and again bang out quick-and-dirty personal projects don’t necessarily impress), a false positive probably never does: you’ll probably never find someone with a great personal project who also turns out to be rubbish.

There’s something great about the notion of personal projects serving as resume pieces: as far as credentials go, they have a much stronger connection to reality than more abstract indicators like, say, certifications or a 4-year degree.  I don’t mean to imply some need to create personal projects as yet another barrier to entry of the field, but when trying to discern talent they make a really nice basis on which to differentiate.

Note:

A few weeks ago I had the opportunity to have a spirited discussion via email with a fellow just about to graduate with a CS degree, centered around a few themes here on Programmer for Hire.  Here are excerpts from the email that got us started:

Hey John

I’ve read nine or ten of your essays in about an hour or so time frame, and I find myself wondering “Hmm.. I’m about to graduate college, and this fellow’s got it in his pocket. Seems to do well for himself, et cetera…” but then after I finished reading the last two, “The Free Day” and “What Happens if I Get Hit by a Bus?“, something bothers me, and I can’t really put it into the most perfect set of words, but I’ll try to communicate/ask-about my thought(s). It may read like an “attack” on you… and that might be a fair assessment, but that is not the intention. My goal was to show how your actions perpetuate a mentality that would be difficult to break out of, not to mention degrade the field as it is already.

I’ve noticed that in the field, there are what appears to be hidden .. guidelines (rules, codes, mores?, not sure what word to put here).. that revolve around the ego. Is this true, or is it more an attribute most seen in the “lone programmer” types? I recall reading you “walked out on air” [The Free Day] as though you ‘saved the day’ or something, as if you were the man of the hour, or day, as it were. Then, in the second essay discussing ideas for your hypothetical replacement, the new person should be able to understand your work, because “my code is quite beautiful and well organized, with perfectly uniform indentation and formatting, completely consistent conventions, and immaculately well factored” in the space of just one day.

First off, from my perspective, I don’t even need to synthesize anything from the preceding paragraph. I think it speaks with enough volume to make its own point. Maybe I missed a day in class that covered ego and “why it’s important to have to succeed in this field” because if so, man, a) I’m fucked, but more importantly b) the industry is fucked. If you can think about it [don’t want your ego to get in the way here], consider this: you are a tool. It sucks not being on top. Even Zuckerburg isn’t on top. Sure, he’s got numbers to play with and spout around, but in reality. he is a tool. His job is to make other people richer. Sure, you’re probably not at his level in the field, but the idea of you make other people richer still applies. A tool has to be bought, so there is the initial investment [see that key word here?], but its price is paid off [usually] by using it to create things that cost more for those the tool’s services are required, in order for it to be sold for a profit. [hammer -> house -> homeowner]. Your job as a tool is no different. Maybe that’s why you and others in similar environments look to other ways of measuring success, ie: “I had 40 clients last year!” or “My app was downloaded 3400 times last night!”, et cetera.

…  I am not saying you will cause a war to occur… but then again, aren’t you already in one? You purport yourself to be a one-man army, capable of reducing the vision into reality. You may very well be able to do such things [it seems so], but does that mean everyone should then become a one-man army?  …

Alas, I think soon it won’t matter. As I wrap up my studies, I keep finding evidence that I don’t like the field I’ve chosen, even though I’ve been told I’m pretty good. I subsequently tell those who tell me that, that they are incorrect; they are comparing me to their skill in the art, not the greats. Of course the greats don’t become great by staying behind the scenes. They need their name out there, in front of people, part of some discussion or controversy, et cetera. As the days go by, the counter measuring my disgust increments too.

…

PS: I don’t want you to stop cold-turkey. In fact, continue what you do. This is just some new guy to the real-world trying to understand it [even if from a more… aggressive and accusatory standpoint]. If you read it all, and want to kill me.. or whatever… I do apologize. I am a new-born programmer… but that doesn’t mean I don’t have convictions.

This gave me real pause for thought.  If my tales of programming are leaving members of the next generation of programmers with misgivings and distaste about the field, I’m both surprised and keen to make amends.

Here was my reply:

Hey ____!

First off to be clear: I don’t want to kill you.  On the contrary, I give you serious props and respect for thinking deep on all this enough to question my words and raise some real valid points of contention.  I appreciate your earnest curiosity and willingness to call (what I would label) tentative bullshit on some of the ideas I share on the blog.

So what I’m hearing in your words is a healthy concern that programming (or at least the freelance market of it) is being purported as a massive bout of egos: with both constructive elements (e.g. how bolstered sense of self importance fosters serious productivity) and destructive elements (e.g. if you’re not good enough to follow MY code, you’re fired).

If you’re open to it, I’d like to offer you a different perspective which may help to decrement your disgust counter about your contemplated field as you round out the current phase of your education.

Consider programming as a craft, and you and I as craftsmen.

As craftsmen we may choose to take serious pride in our art and commit ourselves to deepening our practice and grow, learn, and improve in an ongoing basis.  We may also choose to resist our craft while staying in it: complain about it, insist that the other guy’s code is shit, and maintain a tendency to make excuses for difficulties encountered, lack of results, broken promises, etc.  (Since it is pretty well agreed upon that programming is a rich, complicated, and on the whole difficult practice, we have a lot to draw from when making excuses.)

My ethos in my craft is to be the best darn programmer for hire I can be, and to hold myself to a very high standard so that I’m worth every penny to the people who hire me (that entails making big promises, following through with high integrity, and completely owning my fuck ups when the occur).  My aim in blogging is to spread that sort of pride (and the attendant benefit, i.e. charging a lot and doing folks a lot of good for it) to my fellow programmer, and at the same time advise the hiring world that you don’t have to settle for shitty development talent, which the business world by and large seems to think it must (just ask a typical project manager about the frequency of excuses, lack of results, and broken promises they’ve encountered).

Where ego gets nasty (and is apt to rightly increment your disgust) is when it is applied with hypocrisy: when I’m a bumbler but should be tolerated ‘cuz I’ve got lots of really great excuses, while everyone else who missteps is shit and should be fired.

That, I agree, just fucks the industry with a warped terrain of self-deluded talent and hapless hire-ers who don’t know who to trust.

The world in general works better when people (meaning ourselves and the folks around us) take responsibility for results happening, pursue excellence, have pride in doing great work, honor promises, and decline to indulge in excuses, blaming others, and complaints.  (Please look for yourself to see if the preceding sentence sounds about right to you.)  Consider that our craft is no exception.

Side note about being a tool: no one needs to be bummed about being one.  With a deliberate choice of language you can flip the notion of “being a tool” into “being of service to something or someone, which gives purpose”.  Most everyone who earns a living is a tool by the definition you invoke.  Consider that it’s actually not a problem, especially if you enjoy and have pride in what you’re doing.  Success is in the eye of the beholder, and what works well for me in gauging success is the quality of life that my craft affords me to live.

So you’ve got the opportunity to play in this craft.  If you focus your attention on all the prick waving and caustic competitiveness, I reckon it doesn’t look that appealing, especially since you’re apt to fall into that game by the mere act of focusing on it.  (It’s analogous to “keeping up with the Jones’s”: obsess over whatever’s parked in their driveway and you’ve got a problem, ignore the Jones’s and you’re free to do your own thing.)

There is an alternative, and that is to transcend the whole darn thing.  I’m actually not at war with anyone, and you don’t need to be either.  I learn a lot from the greats (my heroes who contribute massively to our craft), pay it forward by contributing to others, and otherwise just do my own thing in a personal pursuit of what to me is excellence.

There’s one last thing I want to leave you with about the field you’ve chosen but are having second thoughts about: it’s actually pretty sweet.  My wife and I are–no joke–moving out of our apartment in two weeks to go on a roughly 15 month world tour.  Everyone says how lucky we are, and though I resist that a little because it’s more a deliberate choice and creation (we didn’t win the lottery), there is truth in how blessed I am to have a job where I can work anywhere in the world with just a laptop and wi-fi.  To me that’s awesome, that’s that quality of life thing I mentioned.  No one’s stats are a threat to that.

I hope at least some of the above is useful to you, and know that I appreciate you sharing your perspective.  As you might guess from the tagline of my blog I’m fascinated by the culture of programmers and how we view and act in the field–the good, bad, and ugly.  So if you’d like I’d be happy to continue this spirited conversation with you on the phone some time–my number is (720) 621-0600.  In any event, all the best as you finish your undergrad studies, and in whatever path you pick for your career.

He and I had one more email volley, and to his follow up remark,

“…you do bring up some food for thought. I’ve thought about the craftsmanship aspect, but I can see a little ego in there still — however, I think with good practice, it can be useful, but held in check.”

I had this to say, which I think sums it up for all of us programmers:

When it comes to ego: it’s up to you to manage it in whatever manner works well for you.  At the end of the day you’ll either come of as an insufferable cock-jockey, a complete delight to work with, or somewhere in between.  Since that reality holds true for you and everyone else, there’s a lot of great incentive and room for folks keeping their egos in check and having our craft be more of a peaceful playground.  It’s the notion that I get to control my part of the equation which makes me pretty optimistic about the state of our field–your mileage may vary, but try that on.

The other day I got to chatting with a lovely woman who reached out after reading my blog.  She was interested in talking about an idea she had, how she might get it off the ground, and if I might be a good fit into the process in some capacity or another.

“I saw what you did with Spotlight Denver, and I’ve got an idea that could revolutionize the whole deal-of-the-day industry.” is how she broached the subject.

It’s always a treat to chat with folks who have taken a shine to me from my online persona alone, and taking 20 minutes to offer up whatever perspective and insight I can is a welcome break from programming.  I was happy to lend an ear and wax entrepreneurial.

It wasn’t long into the conversation when she mentioned she would soon have a lawyer draw up a Non-Disclosure Agreement regarding the project, at which point I had to interject.

“Ah, let me stop you right there for a sec and let you know this up front: I will almost never sign an NDA.”

She was curious as to why.  This is the explanation I gave her, spread over a couple of distinct but interrelated concepts.

There’s Nothing New Under the Sun

Between a first-time web entrepreneur and one who’s been for years working on many ventures, there is a huge gap in perspective regarding the importance, rarity, and uniqueness of ideas.  Namely if you have this one great idea and that’s your ticket into entrepreneurship, you’re apt to overlook (or simply be unaware of) how interconnected and overlapping innovations are, and correspondingly unable (or unwilling) to see traces of your idea in and around stuff that’s already out there.

This perspective gap is most easy to recognize when someone alludes to their confidential idea as being like [existing web thing] for [some other niche].

“It’s like twitter, but for construction field workers”, “It’s like Yelp, but you only see reviews of people you know, like your Facebook friends”¹, “It’s like AirBNB, but for wife-swapping.”

Even a revolutionary take on the deal-of-the-day industry as alluded to by my new friend has, by virtue of being rooted in an established business model, an upper bound on its originality (to say nothing of the likelihood that the million-dollar marketing or biz-dev teams of Groupon, Living Social, etc. have already had and/or explored similar ones).

Ideas are Plentiful, Good Execution is Scarce

It’s a well documented phenomenon how idea-havin’ first timers just need a programmer to bring their vision to life, as though the idea is somehow half the battle (or 90%, as folks like me often get offered sweat equity deals–10% seems to be a popular number).  But if you’ve ever tried to bring even one venture to market, you know perhaps all too well that ideas are just the starting point, and take by far the least work, time, and capital.

Gary Vaynerchuk said it perhaps best in his talk at the 2011 Big Omaha: “ideas are shit, execution’s the game”.  Watch it².

It’s Not a Good Sign

Say I’m just first meeting you to discuss your idea.  If you prize your idea so much (in relation to everything else it will take in order to make it succeed) that you feel the need to put in legal protections from me, it’s a tell that you don’t have much going for you in this endeavor.

How do I know this?  Because if confidentiality matters to you when talking high-level particulars (meaning anything shy of at least a 10 page business plan), either one of two scenarios apply.

Either (A) you’ll be blown out of the water in the open market soon after you release (this is the case in which the idea really is all it takes, which implies stronger incumbents will easily be able to catch up), or (B) you are vastly underestimating what it takes to execute successfully.

Scenario A rarely ever happens (if ever), but is understandably often feared by those with the newcomer’s perspective described above.  Scenario B is much more common, and should make the thought of tethering oneself to broad and vague legal obligations even less desirable.

Your NDA Treads Heavily Upon My Right to Work

Overlap in innovations and concepts found among disparate parts of the web is ubiquitous.  Any agreement that I sign to not disclose or use information shared with me in a casual engagement opens up a whole world of potentially contentious confusion about what is or isn’t okay for me to do in the future.

In an ecosystem where ideas are borrowed and remixed constantly, an NDA is a poor man’s patent that can be levied only against the signer.  Never mind the existence of clear competitors: the confusion of whether or not any “secret sauce” information was shared is enough to entertain lengthy and costly litigation.

I had a fellow make a bid to buy my CoachAccountable business not long ago.  Great guy, but when I ultimately decided to decline his offer he resorted to legal threats that I better not use any of the ideas we talked about, and expressed regret that he hadn’t had me sign an NDA.

In reality, if had he offered one up I simply would’ve declined.³  Signing one could have compromised my ability to build upon my business or sell it to the next suitor, and by corollary, compromised my negotiating position in the sale.  It would have been the poor man’s patent in action.

NDAs Have Their Place

Are there some situations where NDAs are appropriate?  You betcha.  They are appropriate when there exists something both significant and tangible to disclose, representing more than just whatever popped into your head in the shower.  The 10 page business plan alluded to above makes a reasonable cutoff, necessary but probably not sufficient.

The importance of having something significant and tangible is that it’s something you can point to and say “there, THAT’S what is confidential”.  Without it, the reach of an NDA is too vague and undefinable. An NDA that is not highly specific nor describes boundaries to what it applies is not worth signing: sloppy legalese at best, a malicious trap at worst.

An NDA should also be dependent upon the signer being compensated in some non-trivial way, as in a condition of being hired or part of terms of a sale.  Requiring one prior to that is highly suspect, and signing one, I say, is highly inappropriate.

So that’s why I won’t sign your NDA.  It’s not because I don’t like you, it’s not because I want to steal your ideas, it’s not because what you’re up to isn’t important.

It’s because the ideas you are likely to share with me over coffee or in a phone conversation are otherwise plentiful, worthless in isolation, and, to some degree, completely unoriginal and already known to the world.

View the discussion on Hacker News

Notes:

I’m tickled by the good that can come of the noble act of releasing an open source project.

Two months ago I released trueDAT, a web-based GUI for MySQL databases and the first real project I’ve ever taken the time to open source.  While I always figured good things eventually came to open source contributors¹, I didn’t have expectations for myself while showing off trueDAT for the first time at a Meetup group back in mid-January.

While demoing my baby, I made the acquaintance of two folks eagerly looking to birth their web vision: a user generated content site focused on promoting the best with prize-laden contests.  They were then working on learning PHP and MySQL, and so trueDAT, a tool which makes a really novice-friendly way to interact with databases, made a nice topic of conversation.  (They were also a bit displeased with the progress on their site with their current provider, so we had plenty to talk about.)

The instant good karma of open sourcing trueDAT is summed up in the following 2 snippets from emails from them to me over the two days that followed:

…  I’d like to talk over potentially hiring you to build Masspire. I’m not that enthused about my current menu of options, and I’d like to explore a bit more. …

and

… Basically, if we can think up a mutually agreeable version of the site that you’d be willing to build for $… I’d be happy to work with you. I’ve got a bit more faith in someone who makes something like trueDAT for fun than an Indian firm.  …

These words simply tickle me:

I’ve got a bit more faith in someone who makes something like trueDAT for fun than an Indian firm.

I share them not to brag on what a great open source guy I am (I’m not, I’m new to this game–trueDAT hasn’t even been downloaded 100 times since I released it two months ago), nor to revive the notion that I’m anti-India (I’m just anti-cheap slop).  Rather I wish to share that experience with my fellow programmer: that open sourcing can make such a powerful and immediate impression on the type of person who could/would/should hire you.

In hindsight?  Makes total sense.

Beforehand, I only knew open sourcing as more of an ideologically good thing.

Today, about 2 months later, we have high fived over the successful build of their site, which can be seen now at www.masspire.com.  I had a solid February as a contractor, and they’re pleased with the value and end result of their work.

Our connecting professionally was a tidy win-win, and a direct result of chops effectively demonstrated through an open source project.

Doing well by doing good, illustrated.  Viva open source.

Notes:

There’s a delightful phenomenon that happens with clients after the first contract is executed and fulfilled on, and that I call “Drive-Thru Programming”.

The way I am most often engaged professionally is like this: a client needs me to build a web application, we sketch out the relevant particulars, I write up the resultant scope of work contact (which details features, price, and payment schedule).  It’s signed and we’re off to the races.

Once that contact has been fulfilled, all the money has been paid and everything outlined has been built and delivered to my client’s satisfaction (and I’m not done until they love it).  By this point we’ve invariably established a really good rapport: we know how we work together, trust is there, quality, value and workability have been demonstrated.

This situation makes possible Drive-Thru Programming.

What is it?  It’s a style of handling requests for development work on a rolling basis that is tuned for speed and ease.

It’s quite common for clients to want to evolve and expand upon the applications I have built them.  After the first contract, the formalities of said contract are far less important.  So I’m free to operate as a fluid, on-demand programmer for needs as they arise.  So we get to have email volleys that look like this:

9:41am, Client: Hey John, can you add to the system this, that, and the other thing, and how much would it cost?
9:48am, Me:  Sure thing, can do this for $A, that for $B, and the other thing for $C, so $X total.  Can have it done by then end of tomorrow if you want me to proceed.
9:57am, Client:  Sounds good, please proceed.
9:59am, Me:  On it, will drop you an email when it’s done.  Please pull through!

The analogy is crude, but the feeling is dead on: I get the experience of being a drive-thru coding house, ready to take your order and deliver ultra-quick turnaround times.  Of course I request a phone call to clarify in case this, that, or the other thing aren’t entirely clear, and I maintain my promise that I’m not done until they love it.  These two practices ensure that with speed we are not sacrificing clarity and quality of the end result.

For clients with whom I’ve completed a major contract, I have no problem putting on-demand programming tasks and mini-projects on a tab, and billing whenever it makes sense to do so.  My trust is their convenience.  In return, my clients get ultra-responsive service which helps them mold and evolve the application that runs critical (or all) aspects of their business without the hassle of formalities.

I wrote about programming at the speed of trust over a year ago, and Drive-Thru Programming is yet another gem that arises from it.

I passed through my early days of entrepreneurship with plenty of rookie insecurity.  One vestige of that era was how in my public-facing prose (such as in contracts and on my website) I’d write things like “We’re committed to the success of our clients’ business ventures.”, “we’ll get back to you within 24 hours”, and references to “our development team”.

I was using the word “we” when the word “I” was far more appropriate, as if the fact that it was just me was some dirty little secret to be guarded.  I had it in my head that, in order to be taken seriously, I better project the air that my company was bigger than it was.

In other words, I was in the “We” trap.

Nowadays, I’m super content and proud to be the product of JPL Consulting: I’m it, it’s just me.  I’m not trying to sell an ethos, a corporate culture, a team backed by a method for finding/growing/retaining talent, or anything else that larger development shops pride themselves on.

It’s just me.  You either dig me as a partner who can do your project or you don’t.

The other week a prospective client was hitting me with all kinds of great questions about how I work, and one of them was “Do you have anyone else that would be working on our project?”  Despite the intuition that they might like to hear that their baby would be in more pairs of capable hands than just mine, I replied proudly that it’s just me, that I’m able to handle elaborate projects from start to finish all by myself, and that things go massively faster for it.

To my surprise she was distinctly happy to learn as much, and cited how she and her partner have worked with consulting firms where they liked their initial contact, but once they signed a contract their project was handed off someone else who, in their estimation, wasn’t nearly as good.

That I was their agent for the project, period, was good news.

This makes sense: with any consulting firm that’s organized sensibly, the person you talk with up front to get your project rolling is going to be the strongest person that the firm can offer you.  They are the closer.  If, when you’ve signed on the dotted line (effectively saying yes to that company with confidence that they can handle your project), it’s someone else who actually executes your project, chances are good you won’t be as impressed.

By contrast, in a one-man shop, the one who sells you on their ability is the one you get.

If you have a good impression of me as I take you through the upfront consulting/sales process, then it’s good news that I’m the one who will be actually living up to my words¹.  Accountability is in a nice tidy little package, and there’s no one else that the buck can get passed to.  Sure it sucks if I get hit by a bus, but even that has a workable plan to it.

To solo operations everywhere, I say this: you can either put on the facade of being bigger than you are, ashamed to have not yet built your empire with hoards of underlings, or you can grow yourself to the specific reason people are excited to work with you, and proudly tout as much in your conversations and prose.

Your call.

Notes:

Like everyone in my profession I get approached by folks who are interested (or at least potentially interested) in hiring me to turn their business vision into a live, working web application.

If all of the maxims of self promotion (the vital importance of networking, having strong references, keeping clients happy so they’ll continue to hire you, etc.) are true (they pretty much are), it is of course in my best interest to say yes to any project that (a) I’m qualified to do, (b) I’m available to do in the called-for time frame, and (c) my price is acceptable for.

Saying “no” based on any of these criteria isn’t terribly interesting as most everyone holds to those three prerequisites for accepting work (though based on the regularity of client horror stories with their past vendors, it would appear that a lot of folks in my profession relax a little on point (a), but that’s for another essay).

What’s more interesting is saying “no” to a project when, by all conventional measures, it amounts to good, gainful employment while providing a client with what they know they want.  I do this now and then, and I do it specifically when deep down I don’t believe in the project.  When yes, they’ve got the money and yes, they’ve got the drive and vision enough to pull the trigger, yet I can’t wrap my mind around how this is ever going to work in the envisioned capacity.  This is when my conscience pipes in, objecting to thought of taking money for a project that I don’t believe will ever bear fruit for the individual or organization willing to pay me.

Am I fallible in my estimations?  Absolutely.  I don’t pretend to know for certain how things will turn out.  But I have done enough projects that had a lot of heart and a compelling vision which turned out to be ultimately a poor idea (and in hindsight could have been recognized as such with knowledge available at the start).  For it I can recognize hints of blind optimism when I see them.  Red flags of assumptions or impending obstacles that are unaccounted for jump right out and insist upon careful consideration before I can dismiss them.

This, while perhaps annoying as rain on someone’s parade, I believe is to everyone’s benefit.  My being unwilling to take a client’s money and diligently complete the work when I can’t get behind a project might be the most generous bit of consulting I can give when confronted with a flop¹  If I send you back to the drawing board because I think the project has major weaknesses², I might well be viewed as insolent and unworthy of hiring in the first place.  But deeper than that, I might well be doing you a huge favor, helping you to either (or both) save a lot of money & time, and refine your ideas so that they do ultimately succeed once a guy like me is brought in to bring it to life.

Though it breaks my heart to turn down good gainful employment, I do not hesitate to render this favor when appropriate.

By corollary, if I’m excited by your project and think it has legs, I’ll tell you as much and (if you care to hear it, most people do) explain exactly what specific merits I see it having and why.

There’s probably a good litmus test in all of this.  Useless flattery to lobby for getting a contract is bankrupt.  If you wanna sense for how much your success matters to your developer, throw a deliberately terrible idea their way and see what they think.  Whether they they greet it enthusiastically or balk at it, ask follow up questions and you’ll really learn something about who you’re talking to as a service provider.

If I say “no” to your project, take it as a sincere gesture of commitment to its success.  My doing so might either help you dodge a bullet, or prompt you to retool your vision in a massively useful way.

Notes:

My earlier essay about cheap overseas programming (with the observation that it’s not all it’s cracked up to be) ended up sparking long comment threads in places like Hacker News, Slashdot, and Reddit.  Thanks everyone for weighing in on this one–this turned out to be a topic that touched a nerve with folks much more than I had imagined.

There are a number of themes that kept coming up in the threads, and from them I see a few ideas worth exploring.

A number of comments were to the tune of “What did they expect at $12/hour?  This is not news.”  I take it as a positive sign that disaster in cheap outsourcing of software is self-evident for some, yet based on the multitude of folks weighing in with similar stories of cleaning up outsourced messes, it’s clear not everyone has gotten the memo (most programmers I reckon have, hiring managers less so).

A number of comparisons were made comparing the attitude of the essay to the hubris of the US auto industry back in the 60s and 70s: the local talent giving themselves a pat on the back, celebrating their infallibility, while competitors abroad were gaining ground, the implication being that local talent would one day eat their words and regret their complacency.

I think this quite insightful, but it misses the alternate dynamic which I think is at play.  Back when I was in grad school for computer science (2001-2003), the talk among our soon-to-be-graduating ranks was that the job market is tough, and usually close behind was that the US programmer was a dying breed, fast losing jobs to overseas markets.  This we heard peddled without apology or qualification, it was just a sort of accepted reality as described by the “experts”.

So in regards to the 60s/70s auto industry comparison, I say the scenario more resembles this: the local talent has been told “you’re fucked, don’t even try”, and after a decade of experience we are now witnessing that it ain’t necessarily so.

This is not so much a tale of complacency so much as reclaiming a sense of relevance in industry.

As many commentators rightly pointed out, my limited experiences do not constitute any statistically valid conclusions.  Quite true, but those experiences (and the many similar stories shared) are enough to counter the sweeping narrative of the impending death of the US programmer from years back.  The death of the US based programmer was like the sensational story that breaks on page one in huge type face, only to eventually be followed up by a redaction tucked away on page 13 in a much smaller font.

(Tangentially, I suspect the talk of US programmers being unable to compete on a global market caused an untold number of students to veer away from computer science degrees, and by corollary a counter narrative might serve to veer students towards computer science.  A useful re-balancing, I think.)

In the end I think the most well-reasoned comments came in the flavor that is well summarized by @dylanized‘s words:

I’ve got programmers and designers I work with in India, Pakistan, the Philippines. The guys I’ve found are badasses, very professional and teaching me stuff all the time. If and when I become successful, it will be due in large part to my overseas team.

I’ve also attempted to recruit horrible programmers and designers before. Sometimes they come from these non-western places, other times they come from America or even from my hometown.

There’s jokers everywhere. It’s up to us as technical project managers to screen them out and only hire good contractors and firms.

To me, that is really at the heart of it: it takes real talent to do this work efficiently and economically, good talent can be found anywhere (as can terrible talent), and that good talent should be sought after and prized above all else for businesses with projects that matter.  Though it runs counter to hopes of scoring a real bargain at $12/hour, programmer types can probably all agree there is a lot of depth to the art of being a great on-demand programmer.  The notion that it’s grunt work which can be given without care to the lowest bidder is a farce.

Long live the truly talented programmer: this conversation reveals perhaps above all else that they are in short supply the world over.  To those who choose to continuously deepen their mastery over the craft, I say let us take to filling that need.

[UPDATE: To all those who got here by clicking a link entitled “Why I Will Never Feel Threatened by Programmers in India”, that title has been retired as an unfortunate misfire on my part: much of the conversation was lead astray as though I meant to single out India in particular, and it landed for some as having racist connotations.

It is now titled “Why I Will Never Feel Threatened by Cheap Overseas Programming”, which much more aptly captures the meat and message of this essay.  And now without further ado…]

I got a call from a friend of a friend the other night. It was a fellow with whom I’d talked 11 months ago about a project he and his partner were looking to start. We established then that I wasn’t the guy for him, that I was likely too expensive for their big-dreams, small-means budget.

Fast forward to present day: their project is still not launched, it’s still not right. They’ve paid for something between 600-700 hours of development with a firm in India, and they should have launched 6 weeks ago.

Sure they’re only being charged $14/hour for that work, but I think the Indian firm is, as the saying goes, making up for it in volume.  And that’s to say nothing of the time our heroes have spent proctoring the whole process: in his words, they’ve got to be constantly super explicit in their instructions, or it comes back wrong–then then have to spend more hours getting it fixed (this is but one instance of why I am suspect of the hourly model in my industry).

“I’m wondering if you’re available–my partner says we just need an American programmer to get in their and clean up a few things to get us out the door, we figure it would take the right person 10 hours, instead of 50 or more with these guys.”

Outsourcing programming came in to vogue as a cost-effective strategy, what, 10 years ago?

For a number of years in my industry there’s been a sense of not-necessarily impending doom, but something akin to that due to the rise in outsourcing programming work abroad, most prominently to India.  Hoards of smart people, as the alarmist vision goes, willing and able to do highly talented technical work for a fraction of the going rate for US programmers.  The labor force here in the states can’t possibly compete, and what savvy, responsible company could possibly pass up the opportunity of such cost-effective globalization?

The thing is: I have yet to see a project done overseas at that sort of hourly rate that has actually gone well.  Version 1 of MonsterMarketplace was first done overseas–took 4 months, billed for gobs of hours including a lot of testing and QA, and crashed predictably under the strain of campaign traffic.  (By contrast, my complete rewrite of the front end was done in 4 weeks–at peak times it produced about 4% server CPU utilization, never crashed, and had correspondingly faster page loads.)   This was my first inkling that the “outsourcing problem” wasn’t all it was cracked up to be.

My second close look at the outsource phenomenon was the code base for Zowzee.  As I discussed in the tale of building and launching SpotlightDenver.com, rebuilding it made more sense than trying to extend the $12/hour piece of work (to this day I’ve been too polite to ask how many of those $12 hours it took–I do know that my work was vastly cheaper, faster, and smoother).

And now this.  That makes three out of three instances in which outsourcing abroad turned not that great, if not outright regrettable¹.  This is a small sample, to be sure, but still serves to bolster my confidence as a US-based programmer.

Reclaiming our Competitiveness

So how is it that we can compete with programming talent overseas, with figures like $12/hour stacked against $125/hour?  My experience leads me to believe that US-based programmers can be the sound and “right” choice for development projects, and we don’t even need to resort to protectionist arguments for supporting our local economy & talent.

I think we can observe a few generalizations which, while they may not give due credit to the exceptional firms overseas, serve to counter the equally general notions that hiring offshore talent is an economical no-brainer.

Consider the idea that the rock-bottom hourly rates creates a certain cognitive dissonance in decision makers.  If I tell you that your job is going to take 500 hours, but don’t worry, it’s only $14/hour, you might think it a god send that such a rate is even possible–you might even think it not worthwhile it to consider US based options at $50+ per hour.  Sure, the quote from India might be a little inflated, but it couldn’t be that inflated… right?  Turns out it was in my 3 examples.

But even if multiplying hours times rate gives you a real bargain, there’s a very good chance the hours term will balloon.  If they get something wrong, they can fix it with 20 more hours of work.  But don’t worry, it’s only $14/hour.  Again, impaired judgment based on what a great deal you’re getting makes this palatable and thus probable: you wouldn’t tolerate it if you were paying a substantial hourly, and besides, you’re already in 500 hours, so what’s a few more?  I think it’s safe to presume that overseas firms understand this reasoning and mindset very well, and at very least appear to exploit it accordingly.

Our heroes’ need to be super explicit in order to get what they want reveals another major advantage that local programmers have: nobody wants to have to babysit their programmer with constant direction and correction.  Communicate the overall vision of what you’re trying to create for your customers, and any programmer worth their salt will bring their A-game to solve it from that shared understanding.  The net result is a project that is completed faster, racks up far fewer billable hours, and saves you headaches and time.

I’ve noticed a number of other reasons to think twice about off-shoring:

• real-time communication made inconvenient and response times made long by the time zone difference,
• a reduced sense of accountability, commitment and partnership inherent in the long distance relationship,
• and text like “Link will be sent to your mail for to update your Password.” sprinkled throughout public facing parts of the website, which just doesn’t give your customers the best impression of you and your business.

These all come with the turf but seem seldom considered: the allure of cheap labor seems to trump these potential problems, or they are unimagined all together.

The good news is that each of these reasons constitute a means by which US programmers can justify their value as a worthwhile and economically sound alternative to outsourcing.

There’s fruit to all of this on more idyllic grounds, too: just as the threat of overseas outsourcing would tend to discourage mastery of programming here in the US (what’s the point when you’re told that someone else is going to eat your lunch?), the notion that the fight is more fair than typically envisioned may as well encourage it.

I believe when the myth of cheap, abundant programming abroad is shattered, there is a lot more reason for the next generation of talent to take on and excel at a craft that creates real value.

[UPDATE: There has been a lot of comments and conversation on this topic here and elsewhere.  See the response to many of the consistently raised issues in the follow up post, Cheap Overseas Programming Revisited.]

View the discussion on Hacker News or Slashdot or Reddit.

Notes:

This is project that was a long time in coming, and in a short time in doing.

I first became acquainted with the Zowzee team back in January when I went in to pitch on their then new project, DealNation.  Frustrated with the progress and process of working with a firm in India, they wanted to know if, in addition to building DealNation, I could expand their Zowzee application (built specially as a deal-of-the-day site) to be more of a general purpose marketplace of deals: let deals run for longer than a day, enable visitors to peruse and purchase from a collection of deals, and so on.

Tempting as it would be to pick up the extra bit of work, after poking around the code I had no interest: it was buggy, carelessly architected, and loaded with code duplication (meaning if you wanted to change something, you better be sure you found and updated every instance of it, or face new bugs and inconsistencies).  I couldn’t responsibly quote prices or time frames for any non-trivial work, to me it would all be subject to pitfalls and gotchas.

I said to Paul with earnest sympathy and apology (because I know it sucks to get the kind of news I had to give) that it would need to rebuilt if I were to make any substantial changes on it (I mean, who wants to hear that 3 months after you launch?).  I scoped it out and wrote it up, and estimated a solid two weeks to do everything and add in the big new features.  “But at that point” I told him, “you’ll have a super solid foundation from which point I’ll be able to make it do whatever you want, easily and without concern of introducing obscure bugs.”

Paul was open to it (a real testament, I think, to how it was going with the firm in India) but it was not in the budget at the time, thus Zowzee would trudge along in its current state for a while longer.

This month, with me now in house as CTO of DealNation, we found gap enough in my usual duties to direct our attention back to the Zowzee redesign: our sights were now to reincarnate it as SpotlightDenver.  Paul took the initiative to mock up some fab wire frames that really gave a clear vision, hired some design help to give me some pretty pixels to work with, and we were off.

Centered around the concept of a marketplace of deals, I built an e-commerce application nearly from scratch that was perfectly tailored to the needs in just over two weeks amidst usual DealNation duties.  The end result is www.spotlightdenver.com, launched Monday, November 21th.

My team tells me that the whole thing went smoother for them than launching some of the deals on Zowzee, let alone the whole Zowzee site.  And the best part for my team is me delivering on my original promise of the rebuild: we’ve now got a super solid foundation that is easy to extend upon, and since launch I’ve been taking requests and building out new features that make everyone’s life easier and better.

The whole experience has reaffirmed for me that yes: though generally unpleasant news upfront, sometimes you gotta rebuild.  The good news is the other side can be quite gorgeous, workable, and profitable.