Programmer for Hire

Last month a good friend of mine, Chris Kissner of ProCntr, invited me to give video blogging a whirl.

Chris has all the stuff for a video session: lights, cameras, backdrops, reflectors, you name it.  He even gave me a little foundation makeup to look my best on camera.

We riffed for about 2 hours on camera about freelancing, web development, client relations, coaching, projects, nerd culture, my craft, and more.  Chris played the interviewer and efficiently probed my brain on the very kinds of thoughts usually featured in written form here on Programmer for Hire, and for the first time ever captured them on video.

The end result is quite nice.  Chris has done a good job of tidying up, editing down, and slicing the footage up into self-contained nuggets.

The first clip is below, in which we talk about transcending the role of web technician and getting into the realm of massive gains realized by strong communication between contractor and client.

Enjoy!

The other day I got this email:

Hi John,

I just finished reading your post regarding not signing NDAs and I was wondering if you might be willing to share your insight as to how I might want to proceed in something similar (in other words, what is the appropriate way to develop an idea when one does not have the programming skills)?  Everyone wants to protect their ideas, but how do we do so and see them through to fruition rather than be a simple pipe dream?

 

Just like in your post, I have an idea which I can not implement and it is rooted in a couple of ideas/websites.  I do not necessarily consider it original, but I do see an opportunity for it as it has not been executed yet.  I actually want to approach a specific website with this idea as I believe they would be the best fit for this project/expansion.  I believe I fit into your A category; I know they would blow me out of the water if I were to develop my idea independently of them.  My problem is that I am not really sure how to get my foot in the door and be taken seriously, while at the same time protect myself from them just saying “thanks for the idea, the door is over there.”

 

I did appreciate your point on the “90/10” split.  I have always thought that I would love to get 10% for my idea, but my assumption has been even that would be extremely high considering the web site would be putting up the money and doing all the work (and “the door is over there”).

 

I would greatly appreciate it if you might be able to give me some feedback and pointers as to what I should actually do.

 

Thank you for your time,

…

After meticulously detailing the ins and outs of NDAs for developers, it’s super interesting to consider things from the other side of the table.  What is a good way for someone in that position to see their idea become something?

I mulled it over a while, and this was my reply:

Hi ______,

Your situation is a tricky one to make work in the way that I think I’m hearing you want it to: getting 10% for putting up the idea and little else.  To folks like me and people running already off-the-ground companies, there is virtually zero appeal to what you are describing, and as you surmise they are apt to indicate to you where the door is.

 

Why?  It’s not that a good idea might not be a net win to execute fully for 90% of the market reward, that could happen.  Though a long shot, it conceivably might make economic sense to do.  The thing is that that premise is predicated upon “they’re all out of ideas, and would love to jump on the chance to do something new”.  That is almost NEVER the case: most businesses, (especially in the web world with its ever evolving and innovating nature), have no shortage whatsoever of ideas and initiatives that they could be pursuing to further and better their business.  Everything they do is a trade off against other conceivably great things they could do, which makes picking something that entails a dormant idea partner highly unattractive.

 

I think the thing is for you then that you’ve gotta bring something more to the table than the idea.  Something about how you are the best person in the world to lead its execution and willing to come on board as part of the team to make you baby fly, or how much secret sauce and tangible development you’ve already done and our willing to share, or the resources or connections you can bring to the party.  Any of these constitute a tremendous boost to the desirability of your offer.

 

If you’re not prepared to do so, there may be to confront the bitter truth that the idea, though great, might not fetch by itself what you think it should fetch in the market.  At which point you can either offer it up gratis and see what happens (and perhaps see what credit and esteem as an innovator it fetches you), or keep it to yourself (either forever and let it die with you, or until the someone else thinks of it independently, or until things shift where you have an stronger opportunity to get it going either solo or in partnership).

 

Whew, I think I just wrote out a flow chart in that last paragraph!  I hope this, while probably not an ideal assessment of your situation, is useful food for thought, and of course it’s just my opinion–certainly not the final say on how things will necessarily go in the real world.

 

Thanks for the shout out, and good luck!

John

Like I said to her, this probably isn’t an ideal assessment: it’s kind of a downer, and I’m stumped to offer up a more constructive take¹.

I’m also completely open to being wrong on this one: I’m just one dude, and come from a vantage point that is certainly sensitive to and biased against overvaluation of ideas.

Can anyone help me with this?  What would you offer up as advice to this situation?

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.

As posted on Craigslist:

I’m an independent web application developer (see www.jpl-consulting.com plus my blog to learn everything about me).

Bottom line: I want someone able to handle my client’s typical 0-10 maintenance issues for $300+/month.

Here’s the setup: I have several active web application projects out there which I built and am responsible for supporting and maintaining. Starting in May my wife and I are going on World Tour: three months road tripping about in the US, and then we leave the country for about a year. From experience I know how much it sucks to land in another country with a technical problem to fix, having to frantically search for an internet cafe, and hop online to save the day.

What I’m looking for is an apprentice: someone reliable whom I can trust, get up to speed on the projects I am responsible for, and have them be able and competent to handle any issues as they arise when I’m offline and unreachable. For all the projects I have out there with clients, I generally see between 0 to 3 issues that crop up in a given week. Questions, general tweaks, bugs to fix.

If you are able to handle that sort of thing and be my first line of support while I’m off in the world it’s a huge win for me: my clients get great service and support, and I don’t have to stress over things trying to fix a problem on some internet cafe machine which only has IE6 installed.

Paying someone $300 a month to handle something between 0-3 hours of work/0-12 brain farts is so very worth it to me. If more things come up than the norm in a given month, I’ll pay you more. If less things come up, awesome: enjoy the $300 and I thank you for the peace of mind.

My preference is a fellow freelancer, someone who can respond to the occasional email or phone call that comes up quickly. The applications are in PHP (vanilla, no heavy framework), MySQL, CSS, HTML, and MooTools JavaScript (if you know JQuery, you should be fine). Ah, and a few fringe projects are in WordPress.

Other perk: I don’t know how much you care to learn and grow as a freelancer, but if it’s important/interesting to you, this will entail learning how I do large scale/highly paid projects as a one man team, and I’ll be happy to teach you whatever I know to get you up to snuff to support my projects.

To determine if you’re experienced enough to be fit what I’m looking for, check out www.truedat.us, it’s an open source project of mine. If you can comfortably read through and follow that code base, you should be fine. (If you want to make a bang up impression, add a feature to it that you think is cool and show it to me!)

I’m excited to meet whomever I’ll meet who replies to this ad, fellow hackers are so cool. If you feel good about your understanding of the trueDAT code and would like to be my support apprentice and earn some extra cash for the next year, please give me a shout out!

Update

Talk about “ask and ye shall receive”: the day I posted this I had lunch with a friend with whom I’ve done some work before. I told him of the ad and he, to my surprise and delight, said casually “I’ll take on your people for you.” Though I am bummed to have the opportunity to meet other hackers, how nice to have this handled!

I’ve been invited to join the team of DealNation as their CTO.

This is a very good fit in a lot of ways, most of all because it has me doing my magic in a way that lends rocket fuel to a big venture that’s already got a lot going for it.

In retrospect there are 3 things I would say I did very right to precipitate this opportunity:

1. I set the bar for my performance very high from the very beginning.  The first impression I made on the DealNation team was an act of remarkable ability, and I, with confidence bordering on arrogance, stated plainly then that that’s just how it goes with me.  I’ve been delivering on that tall promise ever since.
2. I gave them a taste of what it’s like to have me in house.  When I offered the free day of me working with them side by side on my laptop, they got to experience the luxury of immediate communication to bounce around ideas, and the velocity at which development can get done when you sidestep the spec’ing/bidding/approving cycle of contract work¹
3. I shared with them a single-sheet write up of the value of me being their CTO. Drawing heavily from the coursework of Ramit Sethi’s Earn1K, I took the time to really articulate the how and why I could be of most value to DealNation in the CTO capacity.  Then I unabashedly shared as much.  Two months later, when the time was right, they came around to taking me up on that offer.

The path that we’ve taken together since January has us both clear that we’re a fantastic fit, and thus I’ve accepted the position and begin on July 11th.  Exciting times ahead, I can hardly wait to weave more web dev magic into everything they (soon to be we) are doing.

Notes:

I stood in the office of my clients having just wrapped up a successful quick visit, and gave a strategic, pensive pause.

“So… you guys get a free day.” I said plainly, as though what I meant was perfectly clear and well established.

It wasn’t of course, and immediately aroused the earnest curiosity that I was aiming for.  “What’s that mean?” asked one of my clients, as if right on cue.

“A free day.  Meaning I’ll come into the office at 9am prompt, laptop in hand, and be at your disposal to bang out whatever new features, tweaks, enhancements, or anything else you’d like to add to your system.  My super powers are yours to wield for a full day, no charge.  I totally dig working with you guys, and this is my way of saying thanks for the opportunity.”

(As an aside, let me point out that our working relationship had thus far been 100% based on me assigning dollar amounts to chunks of work (projects, features, enhancements, etc).  Hourly availability was never on the table, as I don’t really believe in that model for the kind of work that I do.  So to have me in the office to perform whatever work I could in a solid 8 hour day was quite the novelty, and a rather valuable one at that.)

“It’s a chance for you to get whatever enhancements or tweaks made to have you really love the system without worrying about the cost.” I went on to explain.  “Having me in house will enable me to quickly identify how you’re using things and what’ll make them even better for you.”  Eyes lit up at the prospect, they were just about to go live with the system for the first time, and having me after a few days of really using things was in their estimation perfect and fortuitous timing.  We picked a day during the following week.

“It’s good form to buy me lunch, during that day.” I said with a smile as I walked out, “Keeps me at my desk working on stuff for longer.  Oh, and for best results I also recommend having a spare monitor available… I can get more done when rockin’ the dual screen.”

The day itself was a hit.  My second monitor as well a USB keyboard (“in case you prefer it to your laptop keyboard) were there and waiting in my conference room setup when I arrived, and the whiteboard was loaded up with a huge list of check box-adorned to-dos.  A spirit of “yay, John’s in the house!” was palpably in the air.  I was well taken care of and lunch ordered in was delicious.

I say this all not to boast, but to point out how the human element can massively work in everyone’s favor in programming.  I’m human, so the excitement that I’m in the house pumps me up, which gives me massive focus and determination to have a rockin’ day, which creates superb results.  Programming at its purpose-filled, invigorated best.

And when 5pm rolled around, what was the net result of this 8-hour generosity?  My client loves their system even more, have gotten massive value out of the programming I did, and appreciates the heck out of me for it.  I walk on air as I leave the office after having the sensation of being a hero for a day, I’m better related to what my clients are trying to accomplish which henceforth makes me a better consultant to them, I’ve got a bunch more billable work to perform to wrap up and extend upon various bits that got done, and I got free lunch.

A day in the life of a programmer well spent.

I recently had a good sense to add this new boilerplate section to my standard project contracts:

3.5 RIGHT TO DEMAND SATISFACTION

Acceptance of this agreement includes the right to demand satisfaction for all described features, no more, no less.  I’m on the hook to complete all the described features to the point that you love it, and you get to demand satisfaction to that extent.  So do it.  If you’re not happy, and you haven’t exercised this clause, you’re technically in breach of this agreement.  Just sayin’.

In my years of experience I have never been burned putting myself on the hook called “my work is not done until you love it” , so I realized that I may as well get the benefit of advertising as much up front.

I don’t know that this sort of clause exists anywhere else in my industry.  Flippant language aside (which in my estimation is rad: if that sort of playfulness backed up solid performance turns you off, you’re not my client anyway), I think there’s a general fear about having to appease some fictional, nightmare client who is endlessly demanding.  In my experience, when it comes to my world of web programming, they don’t exist¹.  Oh sure, there’s always room to want more features, or a cheaper price, but that’s not what what’s on the table here.

This here is a promise to do great with all of the [meticulously outlined] features within the scope of work at hand.  Software development is generally a complex endeavor so I think the average bear understandably shies away from such a tall promise.  Fair enough.  I embrace it.  It keeps me honest and fosters a healthy pride in my craft, and if I just bring my art to it using my full facility with leading edge technologies and tricks, I don’t have to worry about falling short.

So I don’t fall short.  If my first attempt isn’t loved by my client, they tell me and I tweak accordingly.  No fuss, no muss².

That’s the second beauty of stating up front the right to demand satisfaction: it creates a conversational dynamic between my client and I that deliberately CALLS FOR that kind of feedback.  We become partners in the endeavor to create software that perfectly suits, and they have a role to play called “speak up if you don’t love it.”  When the invitation to do that is clear and on the table it is easy and fun to exercise, and moreover doesn’t get compromised by a desire to be polite.

Notes:

A fair question indeed.

I bill myself as an ultra effective development team of one, citing of course virtues like eliminated communication overhead, a shorter route from business vision to application design and implementation, nimble ability to adapt the application to changing business needs when they come up, and 100% accountability when it comes to turning out quality.

Oh, and it’s cheap to hire one person instead of six.

So naturally it has occurred to my clients on more than one occasion to ask me “what happens if you get hit by a bus?”  If I’m the guy who’s doing it all, naturally I represent a sizable single point of failure.

Here’s my answer.

You replace me.  Though I do have a publicly documented love affair with Classic ASP, Classic ASP developers are a dying breed, so it would be irresponsible to start any new substantial project for a client in that language. No, anything that’s built to last I would start in PHP or perhaps Ruby on Rails, languages that boast thriving communities of developer talent from which you could draw to replace poor old mangled (or dead) me.

Now then, when you replace me my successor will need to be trained on how to work on the code base I’ve laid down.  If I’m NOT dead I can guide them through to get them up to speed quickly.  I if AM dead the good news is that my code is quite beautiful and well organized, with perfectly uniform indentation and formatting, completely consistent conventions, and immaculately well factored.  Any developer who is worth their salt in the language I have laid down will be able to understand, trace, and build upon my code within one day of poring over it.  (If not, fire them.  Trust me.)

Furthermore, whatever I did manage to complete before carelessly failing to look the other way while crossing that hypothetical street will constitute a massive leg up on your project.  Remember, typical development projects tend to be heavily loaded on the front end with meetings, spec docs, planning, project management, and other such things that don’t get you closer to a usable piece of software.  Before that Greyhound sent me to a better place even a half-completed prototype done by me will have enabled you to shortcut through all of that, leaving you with a sensible solution strategy and design foundation already in existence.

So in conclusion: if I get hit by a bus, you replace me.  You’ll miss me as you move forward at not as smooth or fast a clip as before, but your project will have gotten the benefit of my precious last remaining pre-bus-hit days.

It’s kinda like getting Frank Lloyd Wright to draw up the plans for your house and then he can’t finish it.  It’s still gonna be a pretty snazzy house even if some junior architect needs to rough in details like which tiles to use in the bathroom.

Michael Gerber, in his treatise on entrepreneurship The E-Myth [1], makes a firm point of the dangers of working in your business when you yourself are the entrepreneur trying to run and grow it (i.e. working on your business).  He makes a compelling case that the activities of one and the other are not only completely distinct, but that they are also virtually mutually exclusive.

I completely agree.

It was a watershed moment for me when I acknowledged for myself that am far more interested in being a consultant than building and running a consultancy, even though the the latter carries with it much more prestige.  I love the kind of consulting and application development that I do, and at the same time I have no interest in building a team of me-clones to do contract consulting work.   So when it comes to me as a free agent consultant, I am much more about working in my business than on my business, and Michael Gerber is right to say that I haven’t created a business so much as a job.

The reason this is interesting at all is because of the fun twist on the in-the-business/on-the-business dichotomy that I love to play with: for an application developer who is not afraid to get his/her hands dirty with the daily roles and work of a given business, there is opportunity to make massive improvements to how that work is done.  An example will make this clear.

During my one straight job out of school at MonsterCommerce I held a number of roles and one of them was manager of the custom programming department.  We were an e-commerce company selling an already spiffy, feature-loaded shopping cart software package, but that didn’t stop loads of our customers from wanting it to do more new and novel things.  So we had a custom programming department that would take feature requests, offer quotes for the work, and execute the jobs when opted for.  About 2-4 requests would come in per day.

The system I inherited for managing these leads and projects was a drawer of a few hanging folders, my predecessor’s email in-box, and a notebook or two of notes.  The notebook system, it turns out, scaled maybe for two weeks’ worth of leads before becoming cumbersome and impossible to manage without jobs and tasks slipping through the cracks.  By this firsthand experience of working in the business I knew things could be better, and with programming skills, a desire to learn web programming (new to me then), and a dash of confidence (arrogance? ) I set out to create the solution I knew I wanted.

It was fueled by a simple vision: whenever so-and-so called, I wanted to type their name in, see their job on my screen with the complete lowdown (what they wanted, the status of the job, and even when we last talked and what was said), and be able to talk intelligibly about their project within 10 seconds as if getting it done was the only thing on my mind.  (I think a lot of visions are fueled by frustration of doing something a few times when you know it could be so much better.)

Taking inspiration (and the design aesthetic) from our own shopping cart software, I learned how to program web applications[2] and design databases, and built my dream system one weekend at a time.  It sat there, hosted humbly on the floor within the computer in my bedroom, during a time when each subsequent week a little more of my job was managed or automated by it.

After six weekends of development (and the interim six weeks of real-world use, testing, and tweaking), I was ready to show off my baby to the rest of the company.  It was well received by all the parties it touched upon: billing, sales, management, and my team of programmers, and getting adoption was quick and painless.  (The greatest honor was when the Design and SEO department heads both requested a similar system: I quickly forked off versions to suit both.  The second greatest honor was hearing that it wasn’t until 2009 until these systems were retired, fully 3 years after I left the company.)

Building something that good was made easy (almost trivial, it felt) because I was making it for me to solve my own day-to-day problems.  When my day-to-day usage revealed something that sucked I would simply fix it that night at home, and have a better system the next day.  I had bridged the creator/user gap.

Not only were the systems nice and made a manager’s job easier, it made the departments better.  Communication, coordination, follow through, professionalism and the bottom line all benefited.  It was the stuff of systematizing things that Micheal Gerber would classify as working on the business, and doing so happened because I was steeped a little while working in the business.

This is completely unconventional.  Software development talent seldom experiences the day-to-day work of the people for whom they create software for, yet what if that experience is a shortcut to making a really great system?  Though unorthodox, time spent by a developer actually doing a job for which he/she is to make a software system for may pay out overall in time saved trying to otherwise imagine, describe and communicate the software needs.   Any additional unimagined solutions/shortcuts/innovations devised by the developer-turned-worker are a pleasant bonus.  Furthermore it makes nice protection from rough or ugly spots in an application: if a developer is saddled with using his/her own creation (even if for a little while), they will be apt to smooth over and tidy up such unflattering features.

It may be a loophole to the notion that if you’re working in the business you can’t possibly working on it: insofar as software systems are concerned, at least, a person working the job who is able to design systems to make it easier is leveraging the former to help the latter.

Notes:

[1] It’s been 4 years since I read it, so please pardon any haziness in my recollection of it.

[2] This is the root of my [still persistent] fondness for Classic ASP, an arguably terrible and woefully outdated server side web language.  There’s always something special about your first.

There are some services for which I think the model of charging based on an hourly rate is appropriate.  Software development is not one of them.

Consider: some services fit the hourly model to a T.  These are jobs where the hours spent are directly proportional to the value realized by the hirer.  It makes sense that getting the hour long massage costs roughly double what the 30 minute session does.  Or manning a reception desk.  When somebody needs to be there, every hour that a body is there that creates value and fulfills a need of the hirer.

But software development runs counter to this notion.  We programmers are pretty much always hired to solve a real problem stemming from a real need, not to provide hours of coverage hunched over a keyboard, and certainly not to provide extended enjoyment for the client by virtue of working longer hours (the massage therapist might hear the phrase “hey, that’s nice, why don’t you do that a little longer?”, I don’t think a programmer ever has).

No, in software development it’s virtually always the opposite: the longer a project drones on, the more painful it is.  Just ask any stressed-out looking project manager who keeps getting excuses and pushed back deadlines from her development team.

But doesn’t more hours mean more quality?

Maybe, but that correlation is sketchy at best.  To realize a given set of features, a pro can often do it both better & faster: the number of hours spent becomes an argument against quality, not for.  (I’m much more apt to trust that a WordPress install got done right by someone else if it took them 15 minutes rather than 3 hours.)

Programmers can (and should) be hired on the overall demonstrable quality of their work, and a review of their portfolio plus a mutual understanding of the level of thoroughness/quality that is called for (throw-away prototype or enterprise level masterpiece?) keeps the fixed price model honest.  (Because yes, without that mutual understanding a developer could hack the fixed-price model by racing through a project and cutting corners, to say nothing of whether or not he’ll be hired again).

Alignment of Priorities

If we can assume that a contractor is guaranteeing satisfaction (and we probably should, right?), then a faster execution of a fixed-price project is in the best interests of both parties.  The client gets what they need sooner, and the effective hourly rate of the contractor is higher.  When an accurate sense of the quality to be expected and a correlate price tag are established, the fixed price model creates this nice alignment of priorities between contractor and client.

By contrast, hourly creates a misalignment of priorities of client and contractor: the contractor gets rewarded for dragging their feet and making problems out to be more complex.  Not a huge amount of course, because in the logical extreme they’d get dumped sooner or later.  But it’s just too easy to milk the clock and divert energy from actually solving the problem, to instead convincing ones self and others that it’s more difficult than not.

Effective software development is all about fewer smart hours as opposed to longer hard hours.  Pricing for it should probably then reflect that, and by the  same token programmers should probably strive to avoid the curse of the hourly wage.