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"

When Empathy > Technology

Dennis's shirts hang on the left side of our shared closet, mine on the right.  The closet doors are the typical sliding ones, so that when one side is open, the other side is occluded by door.  When the doors are open to my side, light from the window is largely eclipsed by anyone standing in front of it, leaving the job of illumination to anything coming from the left.  On the opposite side, it's the opposite story.

Thus, Dennis hangs up his shirts so that they face the right; I hang up mine so they face the left.  In a logical Universe, we would respect this light-optimised orientation when hanging up each other's shirts.  But even a dual-programmer household falls well short of the Spock/Sherlock ideal.  Alack.

The mayhem and havoc wreaked by misaligned clothing can be quantified in terms of extra fractions of a second required to select the t-shirt whose snark and/or geek culture in-joke best matches our mood-of-the-moment.  A #firstworldproblem if there ever was one, in other words.  But it illustrates the power of personal norms to trump logic (and the instinct to use it).  And, in a way, it makes me despair for human progress as driven by first world technology...or even most first world technologists (in whose number I count myself, btw).

Silicon Valley has been panned by folks as diverse as Valleywag and Startup L. Jackson for burning so many calories turning paper millionaires into paper billionaires while infantilising the twenty-something dudebros who are the face of its culture/ethos.  The first is just what shareholder capitalism is optimised to do.  (The second is just plain pathetic.)  Neither of them can be considered truly "disruptive"--at least not in the net positive sense their apologists would have you believe.  Sure, it's taking bites out of the taxi and hotel industry by socialising the costs of industries formerly held more accountable via regulation.  But, hey, you can't make a creative destruction omelette without breaking a few social contracts, amirite?

It's not even a private sector ailment.  NGOs can (and do) squander resources applying first world thinking outside the first world.  Case in point:  The first attempts to convince Cambodian families to add a lotus-shaped chunk of iron to their cook-pots to reduce/eliminate anaemia fell short.  Follow-up visits discovered the iron being used for other purposes, notably doorstops.  But casting the iron in the shape of a fish considered "lucky" by locals changed the game.  Anaemia has been eliminated in 43% of trial subjects, and a sustainable business model was spawned in the process. 

Moral of the story:  Sometimes it's the users, not the technologies, that have to be "hacked."  The catch is that those of us who are paid to be problem solvers have the instinct to hack technology first.  Don't get me wrong--I'm a huge proponent of usability.  The bigger a technology's side effects, the more incumbent it is upon its designers to make it as impossible as possible to misuse.  I get it.

But the slickest, most bulletproof interface in the 'verse means bupkis if it is A.) Not solving a worthwhile problem, and/or B.) Is too expensive (in terms of cost, infrastructure support, externalised costs, etc.) to use by those who would most benefit from it.

So, to recap, to successfully "disrupt" anything, the designers/developers need to:

1. Allow people to benefit their lives/families/communities in a way that was previously impossible
2. Allow them to do it in a way that doesn't require huge (for them!) investments or later remediation
3. Ensure that misuse is darned near impossible without anything beyond rudimentary training

Put together, that's a very tall order.  To pull all that off that takes great wads of empathy--which starts with the proverbial exercise of putting oneself in someone else's head-space.  (But we geeks are supposed to be the "smart" people, right?)  Alas, empathy (or even self-awareness) is not something I expect to find thick on the ground in a place where more than one techbro has very publicly hated on the problems his very own Galt-couture has created.  If that's a representative sample of the "thought leadership" in the culture of disruption, that culture is bankrupt.  Part of me thinks that, in this case, this latest tech. bubble can't burst soon enough.  Except that it won't move the needle on the culture.  At best, that offers the cold comfort that it won't be so lionised by press and pundit.  With February winding down, I've had enough cold for one winter, thanks.

Exceptional madness

Doubtless, my Gentle Reader has heard some form of the adage, "The definition of insanity is doing the same thing over and over while expecting different results."  It's not a bad rule for nearly all situations, actually.

Problem is, it doesn't necessarily work that way in Software Development, particularly during debugging.

See, when you're trying to reproduce a problem, you want to see the same results after doing the same thing over and over.  Anything else spells extra time and resources.  Second-to-worst case scenario is you'll end up essentially creating a VirtualBox-type simulacrum of the production environment so you can replicate the live conditions as closely as possible.  Maybe you'll end up dorking with the system date, or writing custom scripts to roll back test data to a specific point in time...repeatedly.  For sure, you'll be spelunking in the database, likely scribbling down ID numbers and combing through matrices of data.

Worst-case scenario, though, is that you're never able to reproduce the error, EVER.  Nope, no matter how faithfully you re-create the conditions from the bug report, the gremlin never reappears.  That, mes amis, is The Short Road to Crazytown.

So if you've ever wondered why some programmers (and other I/T folks) have a slightly skewed perspective on the world, this is one of the reasons.  For us, madness lies in the exception, not the rule.  In more than one way.

A.B.H.

As with many rants, the thing at which I'm yelling is not actually the thing that cheesed me off in the first place.  For that reason, I'm keeping names out of this.

The Moncton tech. community, like any community, has what's known as "super-hubs" in its network.  These are the folks who pretty much know everybody (sometimes even before being introduced), and whose job--officially or not--is to connect people.  It would be difficult to overstate the time/resources/opportunities that would be wasted if not for these folks, and I look for ways in which I can repay what they've done for me over the last few years.

But with any community resource, its value is cheapened when any-old-body assumes that they can short-cut their way to clients, employees, etc. by basically asking a super-hub to spam her/his network.

As these requests go, today's email was comparatively defensible, and I'm honestly quite happy to note how tight-knit the Moncton and Fredericton tech. startup community is.  No silo-ing or turf wars in sight, and thank the FSM for that.

Alas, something that's been simmering for awhile boiled over.

For anyone who doesn't know me, I'm a freelancer building a fairly niche business and, frankly, I'm still in over my head on where I fit into the local economy...if indeed I fit at all.  And so I've been to a whack of after-hours mixers and lunch-n-learns and business-over-breakfast thingies lately.  And I'm afraid that in the context of such events, I've too often heard the lament that business "can't find" the programming talent it needs in Moncton.

Yet, strangely, the only people I see at the user group meetings are other programmers.  Ditto the classes sponsored by the Cybersocial.  Same deal at the MPL Makerspace/FabLab.  It's like all these non-technical managers/executives are afraid of programmers in packs.  Like there will be a West Side Story-esque suits-vs.-geeks rumble.  Or something.

There are a few notable exceptions.  I know of at least one Moncton tech. company that practically works hand-in-glove with a private college.  Frankly, such pipelining doesn't skeeve me out.  Far better that than the business that expects the government to provide a corporation-coddling tax climate and educated college grads.  And--bless his heart--Dan Martell's advice to would-be tech. entrepreneurs was to (gasp!) figure out where geeks hang out and go look for a technical co-founder in those places.  (Yes, I know I said I wasn't going to mention names, but credit's due where credit's due, yo.)

Clearly, some suits get it.  It's the ones who send out the emails that contain phrases like "We have an immediate need for _n_ developers..." that burn my bacon.

No.

You had that need as soon as you knew that you were opening a branch office.  Or as soon as you put together the project proposal you knew your current staff couldn't support.  Or as soon as you started lunching with VCs.  Basically, as soon as you were fantasising about how you were going to spend your share of the new profits, you, my friend, had that need.  If you now have an "immediate" need, it's loonies to Timbits that you chose to do other things until you absolutely couldn't ignore the most fundamental job a business has.  You're basically the kid who waits until 8:30 the night before the project is due to tell Mom that you have to go to CraftWorld for the supplies.

And so I frankly don't want to hear about the dearth of programmers that you could be standing knee-deep in if you'd bother to get to know them.  Best of all, the programmers who show up to places like Makerspaces and user groups are the motivated ones.  Sure, I've known plenty of very bright developers who prefer to pick up a new technology/framework by reading code and tinkering on their own.  Nothing wrong with that.  But the advantage of mixing with programmers among their own tribe is that you meet the ones who aren't embarrassed to ask questions in front of their peers. 

Look.  Most suits are inherently salespeople.  So I'm going to assume that part of their self-education involved the film Glengarry Glen Ross.  As such, they'll immediately recognise that I'm referring to that scene:  Alec Baldwin's profanity-laden verbal beat-down that includes the acronym "ABC," for "Always Be Closing."  That maps nicely--and without all the F-bombs--to "ABH" for "Always Be Hiring."

Hiring the best of the best means having a the pick of the market.  Which means that you have to know the market in the first place.  Oh, you had your heart set on that 10X full-stack unicorn, but now s/he can't be poached from the once-in-lifetime start-up opportunity?  Womp-womp on you for not seeing if there were any more at home like her/him.  Maybe next time you'll create a job around a person you know will take you to the next level...before it's time to scramble up that hockey-stick curve.  Or, better yet, you'll actually have met all your potential hires face-to-face long before their phone screen.

Start-ups have the mantra, "Get out of the building," which means validating their ideas before they build.  "Get out of the building" also applies to hiring.  Because you can't say that your employees are your most valuable resource if you expect them to magically drop into your org. chart with the right skills at the right time.

Always.  Be.  Hiring.

And, if we happen to meet at any number of these mixers, bee-bop on over and say "Hi."  Now that I have this rant off my chest, I probably won't be too bitey.  Unless, of course, you ask me if I know anyone who's looking for a developer job.  :~/

Trading the creeper for the stalker

I'm on the "admin." email list for a volunteer group that organises monthly tech. talks.  I'm not the volunteer who orders the pizza, so normally I don't fuss too much over how many registrations have landed.  But I recruited this month's speaker, and wanted to give him a rough head-count (especially since it was a higher than usual, which is always good to report).

One downside to flipping through all those EventBrite notifications, however, was the huuuuuuge and depressing preponderance of "anonymous" email accounts used to register for the talk.  Clearly, someone--well, pretty much everyone in our almost-big-enough-to-be-statistically-valid sample--has had their workaday email address trammeled by someone before.  And (more to the point) that's not news or even remarkable.  It's merely evolution in action, really.  In the sense that arms races can be considered "evolutionary," anyway.

Until now, I'd failed to see the extra irony in that response.  GMail and Hotmail (and the odd Yahoo) accounts are, of course, a prophylactic against having one's attention-stream repeatedly crashed by spammers and scammers.  Not unlike how single women will wear fake wedding/engagement rings as a prophylactic against being creeped-on.  (Needless to say, its deterrent effect is never 100%, but on balance it's worth the clunky el-cheapo jewelry.  Pro tip, ladies:  A layer of clear nail polish over the metal of a dime-store ring will extend its lifespan by months.  Trust me on this.)

So, in an attempt to preserve the online equivalent of personal space, people choose to trade their privacy and a certain amount of attention-span.  Because of course Google, Microsoft, and Yahoo are monetising both.  Behind the scenes, naturally.  Which apparently makes all the difference.  It's difference between the creeper at the pub who won't take "go away" for an answer and the stalker who rifles through your garbage and eavesdrops at your window.  But the latter is at least discreet about it--incredibly polite, in fact--and (best of all) you're not its only target.  So it's not even personal, which almost makes it not-creepy, hey?

Please understand that I'm actually not slagging Google or Microsoft or Yahoo here.  Blocking all the spam and worse spawned in the underbelly of the internet is itself an arms-race.  Just handling the sheer amount of illicit email traffic chews up resources that your average I/T department can't afford.  Bayesian filters require constant "training" and updates to the code to keep up with the latest scams, viruses, and desperately incompetent marketing hacks.  Only huge corporations have the resources to A.) Scale up to the challenges, and B.) Pay for it all with targeted advertising revenue.  "Targeted," naturally, implies sniffing email for keywords and (more importantly) patterns and embedding compatible ads in the user experience.

Within the confines of the free market, we're left with an imperfect system.  In essence, we're allowing the stalkers to protect us from (most of) the creepers.  To imagine any other outcome is reading History backward without remembering that it is lived forward.  And also to forget that people people--perhaps as much as the corporate people of which Mitt Romney famously spoke--have zero conscience when it comes to externalising costs for things you can't actually touch.  Maybe even negative conscience, given some of the rationalisations I've heard.  Internet security, naturally, ranks high on that list.  Which is precisely what criminals and griefers are banking on.  And, as if we could forget, Marketing's sins are both legion and legendary--regardless of medium.

If it weren't for those inconvenient truths, I'd feel less futile in wishing for a do-over on email at this late date.  Namely, a do-over that doesn't require the ghetto-isation of personal email.  Because a tool that's so critical to modern life (on the clock and off) doesn't fit well into any of those flows on or off the clock.  To say that I'm fussy about my tools (in software development as well as elsewhere) is a massive understatement.  You take care of your tools, and they'll take care of you.  I believe that.

Predictions of email's demise are over a decade old.  (Just like predictions of the demise of many things.  Particularly when made by people too busy penning tech. articles to read any Geoffrey Moore.)  But let's imagine that the street-corner nut-job with the doomsday sign is correct and that The End is, in fact, Near.  That would be our last, best hope for owning up to how much #FAIL is baked into the current system and keeping it out of the Next Big Next Big Thing, yes?  Effectively, means that it's time to (finally!) put a price-the on "free" email that reflects all its costs:  The internalised costs of our own context-switching as well as externalised costs of subsidising crime, giving viruses a vector for spreading, etc.

When the internet first went mainstream, we were treated to starry-eyed predictions of democratisation and broadened horizons and geysers of previously untapped human potential.  To some extent that's happened...along with other things less laudable or savoury.  But there's no excuse for not learning the lessons of the past two decades, and far less excuse for perpetuating its sins.  I'm at an age where I don't have soaring hopes for the future--after that whole flying cars and Mars vacations thing didn't pan out and all.  But I'm all-in for "not-creepy internet"  Can we get it right next time?