The Accidental Internship

In truth, I was planning to post this last Frivolous Friday.  Because, when it comes right down to it, the joke's really on me.

You see a lot of the same faces at various Moncton technology-related events.  However, they're rarely the same faces.  But as with middle- and high-school cliques, you'll find a scant handful of individuals who can comfortably exist in multiple contexts.  In this case, one of those individuals is a student shortly due to graduate from one of the local colleges.

Said college does not require (but will give credit for) what amounts to internships.  Mind you, those are not plentiful even in a booming economy (into which category New Brunswick emphatically does NOT fall). Now, it's stupefying to conceive of a situation in which businesses have abused the system egregiously enough to (gasp!) force a change in requirements--under a Conservative government, no less!.  But that, in fact, has actually happened in Canada.  Thus, we can count on several months of a reality in which unpaid grunt-work is not, in fact, the norm for certain career-tracks.  At least not until the lawyers find all the loopholes and labour conditions disintegrate even further into the stuff of Ayn Rand pr0n, anyway.

For all that, I (as a freelancer) seriously doubt that the dearth of internship opportunities can be blamed on the same oppressive regime which tyrannically imposes a lower corporate tax rate than that of the United States.  No.  The reality is that "branching off" tasks is actually pretty darned complex.  There's the up-front cognitive investment, certainly.  One has to define tasks and metrics, for starters.  Also, to be prepared to do it all oneself in cases of extreme failure.  And Dread Cthulu help anyone who has employees.   Because the same ones who are perpetually "swamped" are inevitably the same ones who "don't have time" to train anyone else to take the load off.  (Yeah, people are awesome, amirite?)

But there's a third barrier to the wide availability of internships, and I'll get to that in a bit.

In the meantime, I have the luxury of not having the second problem.  So when a local college student (an older gentleman with an amiable disposition and ridiculous amounts of hustle) informed me that (despite all his networking) he didn't have an internship lined up, I airily suggested that he make his own with a local non-profit.  Then I (very) briefly outlined a project that's about three or four rungs down on my personal pro-bono "To Do" list.  And followed up with the vague, "Oh, well, if nothing else turns up, you know where to find me..."

That was last Tuesday night.

By last Thursday, he and his partner had decided that they liked my idea better than what they had been working on, and would I care to take a look at the project draft they'd hammered out in the interim? And, oh, by the way, the app. has to be turned in by April 15th...

Colour me wryly amused. But also colour me a bit wiser.  Not about making airy, open-ended suggestions (when I should darned well know better) to ambitious college students.  Pffffft--that's just paying it forward after making my own (second) internship all those years ago.  (Plus, knowing me, I'll always be that kind of stupid anyway.)

Uh-uh.  The take-away for me is if interns don't scare the ever-loving beejeebers out of you, you're in serious trouble.  Because, as it turns out, these two aspiring programmers aren't too shabby.  The UI specs that landed in my Inbox this evening had use cases I wouldn't have thought of until the second (maybe third?) draft.  That's not to say these folks are bound for the next Y-Combinator cohort, but daaaaaaaaaang.

And is that, I have to wonder, what prevents a lot of businesses from pipelining students into their ranks while the latter are still in school.  Make no mistake:  It's emphatically NOT FUN to be reminded of the fact that someone else has the luxury (yea, even requirement) of using the Cool Tools(TM) while you're being paid to maintain boring legacy code with infuriating pay-per-seat software that long-gone manager once scored a sweet discount on.

Sure, you can pooh-pooh their naivité ("Erhmehgerhd--where is your validation code!?!?!?"). But chances are, they'll internalise that lesson faster than even a seasoned coder will absorb how Android configuration files are laid out.   In a world where coders halfway around the globe sell their time/expertise at dime-store rates, it's the ability to, well, triage knowledge that's the key to survival.  Oh, and having some hustle certainly doesn't hurt either.

Be afraid--be very afraid.  And for love of Mammon, on-board some of these people if you know what's good for you.

The evolution of a contract

Just about a year ago, I contacted a lawyer about overhauling the contract I've been using with clients.  What I was then using was essentially split into two parts:

1. The "legalese" that defined terms, spelled out the conditions under which a Party could "fire" the other, etc.  Basically what contracts are expected to do.  Much of it has been borrowed from contracts I've signed in the past, and translated (as far as possible) into The Queen's English.
2. The "Statement of Work," which was specific to the client project at hand.  It described the work to be done, and then itemised it with the amount of fee allocated to each line-item of the overall deliverable.

The first and main criticism the lawyer brought was that the two documents should be streamlined into one atomic unit.  Fair enough, I suppose.  Problem was, the new version was likewise partitioned into a "legalese" part and a "technical" part.  Without, I might add, any attempt to ameliorate the legalese for the benefit of anyone whose writing skills haven't been demolished by Law School.  No attempt, that is, besides wholesale cutting and pasting of my original verbiage into what looked for all the world like the bolted-together results of a LexisNexis search.

In short, it was a Frankencontract, large swathes of which didn't even apply to what I, you know, actually do for my crust.  Grrrrrrrrrrr.

I made one wholesale revision myself, then made my dissatisfactions known when we reviewed the mark-ups over the phone.  The second draft wasn't as dreadful (or nearly as long).  But halfway through amending its sins, I gave up on a hopeless cause.  No point in paying someone to do their job for them.  Surprisingly  (or perhaps not) I never heard from the lawyer again. 

This week, I pulled out the standard contract I've been using since last year's debacle, and realised, "Aw, Grethor--I can't believe that we never even thought to mention Secure Sockets Layer (SSL)..."  So into the mix that went, and the end of the contract inched (or centimetered, for metric contracts) down on the page.  Sigh.

To re-purpose an old adage, good contracts come from experience, which come from bad contracts.  Or, much worse, no contract at all.  For a freelancer or small business, paying a lawyer for a standard contract makes it tempting to treat it like Holy Writ.  Or The Necronomicon, depending on your view of the legal profession.

But, to me, a contract is more like DNA.  As it should be.  Because a contract is a living document that can, and should, evolve with its business.

Now, I prefer to think that successful business-to-client or business-to-business relationships are the default.  (Because the vast majority of us mean well...riiiiiiiight???)  Failure, then, is what designers and programmers call "an edge-case."  And, while there typically are multiple paths to success (even with detours and construction), the paths to failure are legion.   (Pretty much the opposite of Stairway to Heaven vs. Highway to Hell, when you think about it...)  And so contracts mostly exist to head off edge-cases (or at least to define what happens when a business relationship goes off the proverbial rails).

What's interesting to me, however, is when a business has survived enough mutations of its revenue model to acquire what in biology is known as "junk DNA."  (It's also known as "Non-coding DNA," but the programmer in me takes no small exception to that, y'understand...)  At one point, up to eighty percent of human DNA had no "explainable" purpose.  Later science has emphatically questioned that.  (Not surprisingly, I might add.  Not only does Nature abhor a vacuum, she is also an incorrigible pack-rat.  Honeybees being a case in point.  But don't get me started on that.  No, really.  You don't have that kind of time...) But a certain percentage of it nevertheless is purely vestigial.  (And thus the analogy holds.)

And, of course, the role of parasites in evolution is not to be underestimated.  For good and ill, by the bye.  As it turns out, the absence of nemeses for our immune systems may actually correlate to other problems.  (Because, after all, what's a comic-book superhero/ine without a monologuing super-villain, I ask you?)  Alas, it takes all of one bad actor to trigger a Cambrian Explosion of clauses in the contract of the party acting in good faith.

Yes, I realise that the "Lawyers are why we can't have nice things" meme has been fashionable since at least 1591.  But I would encourage my fellow software developers (particularly the freelancers) to re-think their opinion of contracts.  I've already mentioned edge-cases, which is certainly something that any dev. can wrap their think-meat around. 

But, far more importantly, the entire process of negotiating and signing a contract is an invaluable preview of how the project will likely run.   Just a handful of possible scenarios:

• Client signs your contract without question:  Woo-hoo!  You and your lawyer did a bang-up job with that contract, yes?  Nope.  This signals zero attention to detail on the part of your client.  And it's going to bite you in the butt--possibly both cheeks.  Unless you have a P12+ Telepath on your team, you're screwed.  Get written sign-off on every deliverable, grow a thick skin, and have your lawyer's burner phone on speed-dial.
• Client sends you a contract that they obviously didn't (or didn't want to) read:  Pretty much the same problem as above.  This tends to happen with larger, institutional clients.  Tip-offs included (but are not limited to) references to obsolete technologies.  Tactically, consider it a cry for help and negotiate.  (And, for pity's sake, work your otherwise billable time and that of your lawyer's into the project cost.  You are emphatically not in business to compensate for their flabby Legal Dept.!)  Strategically, consider it an orange flag; bill them incrementally--that place has clearly been infested by bean-counters, martinets, and gold-brickers.  Collect your fee ASAP and don't hand over the IP until the cheque clears.
• Client won't discuss the project with you before you sign an NDA:  Not necessarily a red flag; it depends on how bleeding-edge the idea turns out to be.  You've been around long enough (or at least hang around with people smart enough) to know that ideas mean bupkis without execution.  Unless your spider-senses--by which I mean your personal network--tell you that these folks are working on something very close to your pet projects (or the projects of your existing/potential clients), you're probably safe.  However, you will not be able to use them as a references for rain-making.  Factor that into your pricing accordingly.
• Client pushes back on item/project cost:  Groovy.  They're doing their job.  If they're funded by VC or public money, this goes double.  (If they're funded by VC or public money and they don't push back, write them off for future business...and referrals.  Also, make a note of their names for when they invariably attach themselves to another startup.)  You are ready for this, because you've already crunched the cost-benefit numbers.  (Riiiight???)  One caveat:  If you've already been through a few projects with the client and the push-back isn't a formality, you have a trust issue that needed to be resolved a long time ago.
• Client pushes back on Intellectual Property (IP) ownership:  Also not a bad sign.  Again, you've crunched the numbers enough to know what you're giving up, and you know what they're willing to pay for that.  So it should be an easy call.  Also, you know better than to hand over the work until the cheque has cleared.  So you're not going to budge on that point.
• Client insists on a handshake agreement:  Nope.  Seriously.  Just nope.  Get the heck out of there.  Now.  There are other clients waiting for your help. 

In short, put on your "Sherlock" hat and make a game of it, if that's what it takes to keep your analytical skills engaged on the business side of freelancing.  Because your business exists to survive, not to provide an interesting fossil.

Frivolous Friday, 2016.03.04: "darwin.config"