Tuesday, June 26, 2012

LinkedIn: the de facto standard for CVs

Intrigued by some recent commentary casting doubt on the value of Mother LinkedIn, and recognising that the best questions are often the simplest and most fundamental, I got to thinking about ol' LinkedIn - what's the point of it?

I've been a member of LinkedIn since October 7, 2009. 3 Mobile, where I was working, was merging with Vodafone, and there was no room left for our little IT department, so we were out. They weren't in any hurry about it though, and we had 4 or so months to get our affairs in order. HR offered us the services of some "outbridging" company, or some term like that, to help us make the adjustment back to the job market.

Around that time we become aware of LinkedIn, and we all set up accounts. Then Jade hit on a great idea. A couple of days before that, no less than the Queensland Regional Director for 3 Mobile, Tim Gallagher, had come to wish us well, thank us for the last few years, and offer to help us in any way he could. Well, how about a LinkedIn reference? He only had to write it once, and copy and paste it to each of our profiles with minor variations. Which he duly did. Bang! 4 recommendations. We weren't sure how much they were really worth, but there they were on our profiles, with his imprimatur. In contrast, the outbridging guy hadn't heard of LinkedIn, as I recall.

Flickr photo
FlickrLinkedin, by Socialmediamx

Now some might say that that recommendation is not worth a jot. Maybe no-one who has the power to hire and fire looks at that stuff. All I know is that before LinkedIn existed that offer from Tim would probably have petered out in a fug of nah, unlikely as any of us were to cite him as a reference 6 months or a year later. I also know that my current boss values those recommendations to the extent that he requested one from me recently, and I in return got him to reciprocate. Ditto with my erstwhile Team Leader at the Dept. of Communities, John Wilson. I'm figuring that much like any currency, if influential people behave as if something is valuable then that makes it valuable.

Around the time of being retrenched from 3 Mobile I was using StackOverflow quite a bit so I signed up for a 3-year SO Careers 2.0 profile for $29. I loved the idea that my job prospects should be associated with the hard evidence of my performance on a Q&A site. Not that I was some SO heavy hitter or anything like that, or that even if you have a decent enough score, I mean reputation, that it means that you're better than someone else. It's simply that a career profile site where one claims some expertise in things like jQuery or MVC3 by linking to answers one has contributed to is an irresistible idea. It is also sadly true - at least in Brisbane - that Careers 2.0 isn't on anyone's radar, that I know of anyway. But considering all the value that StackOverflow has given me over the years, I've never begrudged that $29 for a second.


When you're tasting the cold steel of unemployment you end up dealing with recruitment agents. You speak to them on the phone. They ask you to send them an updated copy of your CV. That's the stage at which I ask them "Are you on LinkedIn?" That's a bit disingenuous of me, because of course they are. It's like asking a gamer if they've heard of Steam. Naughty me. They respond "Of course." "Ok, in that case, my CV is my LinkedIn public profile." If we aren't connected, I can friend them up. It's all there at www.linkedln.com/in/ralphlavelle - everything you need to know about me. This is the single most valuable service LinkedIn provides me - this universal CV format. But for some reason recruiters seem reluctant to move away from the "send me the latest copy of your CV" model. Why?

I asked the excellent Michael Cant of Source Code Recruitment about this curious affection for Word documents, and he wrote: "I think it is difficult to tell in some cases what someone has done through Linkedin as not everyone completes their profiles. With a CV you get a detailed history...". Leisa from Zenus said more or less the same thing: "The reason is that most people don't put full CVs on to Linkedin...and we like to make sure we have all the details."

It goes without saying that nowadays if you're back out there on the mean streets, then you should tend to your profile (on all relevant job-seeking sites), give it a haircut and a shave. Why would anyone who's gone to the bother of setting up a LinkedIn account, and who's now looking for a job, faff around with a half-assed profile?

One Resume to Rule Them All

But notwithstanding the reluctance of agents to relinquish the file-based CV model, it's still pretty handy to keep a canonical CV on LinkedIn, from where one can clone a Word-based one. In Dialog, we had to prepare a bespoke CV, in Dialog's preferred format. Painful. And frequently I've been asked to tailor my CV for specific job applications. One ends up with a folder of CVs, of all different stripes, but with essentially the same information on each of them. And all periodically having to be updated with the same information. Which I did by loading up my LinkedIn one and seeding the others from that.

This to me is the very definition of efficiency - only one copy, publicly available, with all the latest information (or at least it's my job (pun!) to make sure it does), obviating the need for dino-nonsense like Word. I don't have Word on my computer, nor do I want to. It doesn't do anything I need. It's like a fat kid staring in your window. If we can all agree to modernise, we can trade in URLs, in addressable resources. LinkedIn's de facto monopoly means we don't have to shlep Word documents around anymore. Maybe.

All this, by the way, is to ignore the rather obvious fact that keyword-based searching resulting in your profile appearing on the radar of agents looking to fill roles is probably the best single service that LinkedIn provides. I just wish you could import it into your Seek or CareerOne profiles. Bu things are possibly about to change: Tom McGruther (Hays Information Technology) wrote to me: "(LinkedIn) has great value, especially to a recruiter, for sourcing people - but not necessarily for marketing them to clients. I heard they are planning to release their own recruitment software. It’d be insanely good if it comes out, it will change the whole ballgame."

My First Law of Conservation of Social Media Energy

In the end, I think it all boils down to my 1st Law of Conservation of Social Media Energy: if you don't contribute to a social network, to nobody's great surprise you will think it's crap. I know some people who complain about Google+ for instance. They barely post anything, and the people they have circled don't either. And to nobody's great surprise they dont see much value there. LinkedIn is obviously a good way to advertise yourself to recruitment agents -the fact that they find and contact you on the site shows this. So let's advance to the next step and use our profile as the commodity rather than as an ad, a teaser for our "real" CV.

Wednesday, June 13, 2012

How do you save a datetime?

The indeterminacy of local time, given UTC time, is a tricky problem to solve if you have not given yourself enough information to work with. Use datetimeoffsets.

Somewhere along the line on the MVC3 project I'm currently working on, we decided that datetimes should be stored in UTC format. I hadn't seen that practice before, but the other guys thought it was a good idea - the idea being that an absolute time reference is better than a local one. It's not parochial, it's universal, and it's based on Atomic time which makes it cool. And when we want to display the date anywhere to the user, we would simply convert back to local time. Best practice, all good, keep going.

And then I never thought about that again until I had to convert back to local time and I realised I couldn't. Not given a simple datetime, albeit in UTC format, I couldn't. Because of course how could I know what time it had been locally at the time of saving the original event's datetime? You can work it out easily enough in somewhere like Brisbane, where I am, because we don't have daylight saving time. Same with China, India, and Japan. But it had been a fluke, the fact that the app will be mainly based somewhere where DST doesn't apply.

I guess I had thought to myself: "My datetime values are easily expressible in local time; their meaning is perfectly clear to me". But then I read this, on Bart Duncan's SQL Weblog:
Of course, you might be thinking, My datetime values are all local server time; their meaning is perfectly clear to me. Well, one day your company may expand and your little homegrown system might need to handle data from more than one region. Or you might need to import the data into a new system when your solution is thrown out for being too provincial :). Or the data in your local database might turn out to be needed in some central data warehouse that consolidates data from a variety of sources. You can save yourself and your successors some grief by using the more robust datetimeoffset data type from the start.

If in doubt, read a book: that's my advice

This seemingly innocuous problem led me to re-read "The Quark and the Jaguar" by Murray Gell-Mann, whose curious title comes from the fact that quarks are simple and jaguars complex. If you haven't heard of MG-M, he's a physicist, one of the co-discoverers of the quark. In fact he gave the particle its name (with inspiration from James Joyce).

In the book he talks about the difficulty of quantifying complexity. The Algorithmic Information Content (AIC) of a piece of information is an important concept, one that you're aware of at a deep level, if only implicitly, if you're a programmer. In terms of a 'message string' it's the shortest program that will produce that message. In my case, I guess it's the most efficient way of getting the local time to the user. Another way of measuring complexity is to measure the length of the description of the problem. Look at this StackOverflow answer to get a rough feel for how complex this problem can get.

['Daylight saving time and Timezone best practices' StackOverflow question]

But maybe you're thinking "What's the big deal, like? It all fits on one StackOverflow page. That's not much of a description, ergo it can't be that complex." Well, consider Einstein's equation for general relativity - not the E=mc2 one, but it's similar. From Quark:
"It is a remarkably powerful schema, which has compressed into a brief message the general properties of gravitation everywhere...the schema is remarkably short, its complexity low. Hence, Einstein's general-relativistic theory of gravitation is simple."
I doubt if most people would call it simple, but they'd be wrong. And I doubt if most people would imagine it's quite so complex to deal with dates in a scalable and reliable way. Also wrong.

Complexity isn't intrinsic

If complexity is measured by the length of a description of a system, then local time determination (from UTC alone) turned out to be twice as hard as we (in our team) originally thought, because you need two pieces of information rather than the single piece we were storing. By the way, I'm not considering here how much actual information is required to store a datetime, or a timezone, etc. at a bit level. Rather, I'm taking a more coarse grained view, where each piece of information - local time, timezone, UTC time - is treated equally as a 'piece'.

But one vital thing to realise about complexity is that it's not an intrinsic property of a system - it depends on who's describing it, how much they already know, what assumptions they're allowed to make, etc. In other words, complexity is context-dependent. What is the smallest amount of information you need to save the time of an event? Could you just save one piece of information - UTC time - and reconstruct the local time from that?

Of course, you could just save events as local time and resign yourself to the fact that the very rare cases that happen outside your preferred timezone will have a wrong time associated with any event they trigger. In that case you would not even be trying to solve this problem: maybe you have that luxury.

Or, if you think you're smart enough, save the event time as UTC, but compute what the local time must have been at that time, using some sort of look up service. But how can you do that without knowing which timezone the user was in in the first place? You can't. Which is the problem in the first place.

Everything is obvious, once you know the answer

Or, to paraphrase Duncan J. Watts, some solutions are straightforward, but only when you recognise there's a problem in the first place. That's the hard part. So this may all seem really obvious - it certainly feels like that, writing it out like this. Each step on its own is easy to understand, but the overall problem at hand is a really thorny one, and if you don't see the inherent difficulty, you haven't taken the time (adjusted for daylight saving, of course) to pay attention. It crept up on us unexpectedly, so my assumption is that it might just creep up on at least some other teams out there too.

Steps to create a datetimeoffset

So, avoid saving only local time because you simply cannot determine the absolute time, and vice versa. But in using UTC make sure to include the local offset. Or, the other way round, it doesn't matter. You need those two bits of information, and datetimeoffset gives them to you in one field. The good news if you use Entity Framework is that it couldn't be easier. Note the "+10:00". That's because I'm in Brisbane, which is 10 hours ahead of UTC.