Month: March 2014

Putting a value on desired skills

I have an eye on the jobs market on an ongoing basis and this morning, a temporary vacancy dropped into my inbox for a data analyst role, requiring fluent French.

I tick these boxes. I speak fluent French; lived in France for one year, Belgium for 2. Added to that I have very good German as well. I’ve never felt, however, that language skills have been particularly valued. They are nice to haves but the jobs they are considered for are often low paid jobs. In 1999 – which is a long time ago – I laughed at a recruitment agent who told me that I was on to a good thing with two fluent languages and recent experience living in countries with both language, that oooh, I could be earning up to £14000 pounds as I would get two language premia.

That was ten thousand pounds a year less than I had been earning as a secretary in Belgium before I came back to Ireland. It was also less than I was learning as a contract secretary in jobs where all they cared about was my ability to answer the phone and type at more than 65wpm.

So, I rocked up in a job in IT that didn’t involve much of a need to speak languages. I’m now interested in data analytics anyway – more possibly interested in numeracy as well – and am following a university course which features analytics as a core skill.

This ad had an hourly rate attached. It also talked about a possibility of earning up to a particular level for very hard work.

The level was not very high. Being frank, there are a lot of secretarial roles out there which have higher salaries.

This suggests to me that language skills are not particularly valued in Ireland, and nor are data analytical roles; or at least a lot of people looking for data analysts don’t value skills enough.

I don’t have a lot of free time at the moment, but I’m inclined to see if I can possibly figure out a way of identifying the economic premium paid for perceived desirable skills. I’m inclined to wonder if we hear skills are desired simply because people don’t want to pay for them sometimes.

Coding comments again

I saw something mythical yesterday; something I hadn’t actually seen before. I saw self documenting code. This is unique in my experience.

I have seen on many occasions, code described as self documenting but which was anything but. I suspect a big contribution to the self documenting nature of the code is that it mapped a relatively simple process. The logic was straightforward. The objects were straightforward and non-complex. The code ran to 300 lines which is not a lot for a full application, and the application was culturally common. It was written in Python. It was a thing of absolute beauty.

I’m a fan – in general – of providing code comments, particularly in the zone of Why rather than How. My experience is that the why tends to get forgotten, that current knowledge gets taken for granted and that if the code base is still in use in 10 years time, you probably can’t rely on current knowledge.

In particular I am a fan of assuming that you should make your code as easy to read for the next person as possible. Ultimately, you shouldn’t assume – as a lot of programmers seem to do – that because you approach a problem in a specific way, that everyone will, and that everyone will immediately understand your approach.

And especially, if you’re not writing a clone of a well loved arcade game, it’s probably a good idea not to assume that your code will self document. What’s rare is wonderful and seriously, I have never – before yesterday – seen a piece of code longer than about 5 lines that could justifiably be called self documenting.

What’s rare is wonderful.