Category Archives: Opinion

Thoughts on computers and the IT industry.

Recruitment Tests

Over the years I’ve been asked to do a lot of programming aptitude tests. I’ve had to do some in the last couple of months and I’m deliberately writing this now before I get the results back of the most recent one so you won’t think that this post is just sour grapes…

I’m not going to get into the details of the tests because it doesn’t really matter what they are or who administered them for the purposes of this post.

I don’t like these tests. I don’t think they work well for either the candidate or even the company that is using them.

An obvious complaint is that the tests bare little resemblance to Real Life. On Twitter I cynically suggested that a more realistic test would involve trying it write a program based on an ambiguous and constantly changing specification. The test would end when you quit in frustration.

A bigger issue, I think, is the amount of time it takes and when they take place.

Let’s tackle the latter point first. Every time I’ve been asked to take a test it has been before I’ve spoken to anyone. All they’ve seen of me is my CV/resume. All I know about the company and job is what I see on their website and a brief job description. Am I a nice person? What is it like to work there? Neither party has any idea.

My objection to this is that we both have a lot to lose if the recruitment process goes wrong. I always consider an interview to be a two way process — they need to learn about me and I need to understand more about them — yet the very first stage in the recruitment process is them demanding a couple of hours or a days commitment of my time but only a couple of minutes of their time.

To be clear, I have sat on the other side of the table. I do know that far too many candidates have no real hope of filling the position. But, equally, you don’t want to push away the most qualified candidates.

Two hours is a good a chunk of time. A day is a lot of time. If I already have a full time job and am just looking to move to something better how are those requests going to fit into my schedule? Badly I’d hazard. A full day is half my weekend. Two hours is an evening. (At least! Finding two contiguous hours at home these days is a challenge.)

Sure, the least qualified candidates will fail it but the very best candidates probably won’t even take it. They’ll just say “no” and move on to an opportunity that requires less upfront effort.

I came across this quote earlier today: “Never allow someone to be your priority while allowing yourself to be their option” (either Mark Twain or Maya Angelou, not sure who said it first). That seems very appropriate here. Should I really prioritise these companies over others? Are these companies that special? (A possible exception would be really big names like Google or Apple but I think it’s fair to say that none of the companies that have asked me to do tests have been in that class.)

So, what’s the answer? Certainly there’s no silver bullet that pleases everyone and finds only the very best matches. Having thought about this I think the best compromise would be asking candidates to do something as basic as FizzBuzz (but probably not exactly that as it would be very easy to Google the answer).

To people who have never done any recruitment this probably sounds incredibly patronising. All I can say is that I wish that were true.

And if you really want to administer a test that takes more than thirty minutes, I think they’d be more acceptable much later in the recruitment process. Or failing that, offering to pay isn’t a ridiculous suggestion, though I suspect most employers would argue otherwise.

Afterword: After writing all this, why am I even taking the tests? Mostly because I’m currently between jobs so it’s difficult to argue that I don’t have the time.

After-afterword: I passed the test. I still don’t like them.

Swift Hate

I’m seeing a surprising amount of vitriol aimed at Swift, Apple’s new programming language for iOS and Mac development. I understand that there can be reasoned debate around the features (or lack thereof), syntax and even the necessity of it but there can be little doubt about the outcome: if you want to consider yourself an iOS developer, it’s a language that you will need to learn.

The only variable I can think of is when you learn it.

I think it’s perfectly reasonable to delay learning it as you have code to deliver now and because Swift is, well, very beta currently.

But asking what the point of Swift is not constructive. Asking what problems can be solved exclusively by Swift makes no sense at all you can do almost anything in most programming languages. Just because Intercal is Turing complete doesn’t mean that you’d want to use it for any real work. What varies between languages is what’s easy and what’s hard.

Objective-C undoubtedly makes some things easier than Swift. It’s a more dynamic language and its C foundations open up a lot of low-level optimisations that probably are not there in higher level languages.

But that same flexibility comes with a price: segmentation faults and memory leaks; pointers; easy-to-get-wrong switch statement; a lack of bounds checking. It also inherits a lot of ambiguity from original C language specification which makes certain automatic optimisations impossible.

How many applications require low-level optimisations more than safety? (And that’s ignoring that the biggest optimisations are usually found in designing a better algorithm or architecture.) How often is it better to have five lines of code instead of one? Every line is a liability, something that can go wrong, something that needs to be understood, tested and maintained.

Whatever its failings, it’s already clear that Swift is more concise and safer than Objective C.

There are absolutely applications where Objective C, C or C++ would be a better choice than Swift. It’s the old 80-20 rule applied to a programming language. And, for those resistant to learning a new language, the 80% is not on “your” side.

Right now, some of this requires a bit of a leap of faith. Swift clearly isn’t finished. You can either learn it now and potentially have some say on what the “final” version looks like, or you can learn it afterwards and just have to accept what’s there. But, either way, you’ll probably using it next year. Get used to it.

Failure is an option

My first project out of university was a disaster.

The client was unhappy, technically it was a mess, no one knew what it was supposed to do despite the volume of requirements and functional specification documents and the quality of what was there was terrible. People were working hard but it wasn’t really going anywhere.

All of this, I should note, was happening before I joined. I didn’t realise how bad it really was at the time. The Real World was so different and new from university that I was blinded the problems and just did what I thought was best.

Of course, despite the title of the piece, this isn’t a good option. But that’s not to say that no good came out of the whole process.

Six months, maybe a year, into my time on the project somebody realised that something needed to change. They replaced the project manager with one known inside the company as a “trouble shooter.” And it’s no exaggeration to say that within a few months the project as a whole had been turned around. Indeed, the relationship with the client changed so much we won new business. And a senior manager, after a few drinks, happily sang the praises of this new manager. With the old manager pretty much any discussion by the client would be unquotable on a family website.

The details of what happened are too numerous and it happened far too long ago for me to remember them all anyway. Instead, what I take away from this is (at least) two things.

Firstly, even when things are badly wrong it is possible to turn them around. It can take effort and time that you maybe unwilling or unable to invest, but deliberate change is always possible; just waiting for a miracle or someone to stop paying the invoices is not productive.

Secondly, it has made me try to keep my eyes open, to try to understand what’s going on on the whole project rather than just in my little corner. On that first project, there were talented people doing good work but it wasn’t coordinated and it wasn’t being prioritised correctly. On other projects you see a few bad eggs who (deliberately or not) manage to sour the whole team. And on others there is so much bureaucracy, so much overhead that good people can’t do good work because of all the meetings and paperwork.

Of course, as a small cog in a big machine it is often not possible to actually fix these problems, but an awareness of what’s going on can make it easier to anticipate problems and try to work around the worst aspects. You alone may not be able to make the project a success but you can at least complete your tasks as well as possible.

Webcam

I’m not entirely sure what I was thinking. In about 2005 I bought an iSight, Apple’s relatively short-lived external webcam. It was a beautiful device. Sleek, easy to use and functional.

At least, I think it was functional.

For a device that cost me well over £100 I didn’t really think it through. No one else I knew at the time had a Mac with iChat. Or a webcam.

Before I finally gave in and sold it on eBay I did use it a few times with my then girlfriend (now wife). And it was really nice; like the future. Having grown up with old, slow computers the idea of playing video on them is still slightly magical to me. To have a computer simultaneously record, compress, transmit, receive, decode and display high resolution videos still strikes me as pretty amazing.

Even now, web chatting once a week, I think it’s neat. My son, before he was two, thought nothing of having long, detailed “conversations” with his grandparents. What’s high-tech to me is entirely normal to him.

And all this leads me to my latest technology purchase: a webcam. I got it for two reasons: firstly, I’ve been using my laptop with the lid closed a lot, which means I can’t use its builtin webcam. The second reason: it only cost £5.

I’ve probably already used it more than I ever used the iSight.

Is it as pretty as the iSight? Is it as well made? No and no. But it’s amazing what £5 can get you these days. I added the following as a review:

Considering the cost it’s remarkably well put together, comes with a decent length USB cable, has a flexible stand and works straight out of the box. The LEDs are a bit of a gimmick and the picture quality is a little muddy compared with the built-in camera on my MacBook, but it’s totally usable and easily forgiven given the price.

Webcams have moved from an expensive toy that I wanted to like but couldn’t actually use to a practically disposable tool — I’m sure there are drinks in your favourite coffee chain that cost more — that I use almost daily in less than ten years. I don’t mind being a foolish early adopter if it helps get genuinely useful technology into the hands of more people. If only all my other toys prove to be quite to useful.

Not so smart phones

The flood of new so-called smart watches continues. Some people seem to love theirs, others remain to be convinced.

Count me in with the unconvinced, though only because the current ones seem to be poorly conceived.

Marco Arment says:

Portability is critical to modern device usefulness, and there are only two classes that matter anymore: always with you, and not… Smartphones dominate always with you.

I think this gets to the heart of why the current range of devices — both those for sale and also those just announced at CES — just are not very compelling.

Let’s ignore for the moment the fact that most of them look awful.

Actually, no. Let’s not. You can’t sell a device for hundreds of pounds, one designed to sit on your wrist, replacing the only jewellery that many men wear, and make it look like a digital watch from 1981. I half expect the next smart watch to have a calculator keyboard on like the old Casios.

(For what it’s worth, I think new Pebbles are a big step forward over the original version. Unfortunately I like my super-thin Skagen so I’d still consider it a long way from acceptable.)

But yes, let’s assume the form-factor was more pleasing. Then it still doesn’t work. They’re not replacing anything. They’re accessories for an already expensive and always-with-you device. Sure, looking at your wrist is easier than getting your phone out of your pocket, but is it really that much easier? Is it several hundred pounds better? Is it worth the hit on you phones battery life and the inconvenience of yet another device to charge? I think most people will conclude, no.

So in summary, I think that smart watches have two main problems:

  1. Aesthetics
  2. They’re companion devices

The first is solvable with advancing technology and a degree of taste. The latter means that not every manufacturer will solve it but once the components become small enough putting them in an attractive case becomes possible.

Moore’s Law can partly solve the second point, too, but it’s not enough on its own. You’d also need changes in the way you interact with the device if it’s to be a full replacement for a smartphone.

I don’t think the answer to that is speech. Sure, Siri will get better, but there are places where you can’t or wouldn’t want to talk to your devices. And it would be hard to do an Android and get bigger and bigger screens — at least until we evolve to have bigger fore-arms.

Instead, I wonder if smart-watches are really a bit of a technological dead-end. If over time components tend smaller and smaller, then why stop at wrist watch size?

The other side of the equation is the smart phone. Is it really the best form-factor that we can possibly imagine? Do we use smart phones because they are the best place to put small computers, radios and piles of sensors?

Or put another way: if you could have the same functionality that’s currently in your smart phone in the form of a watch, would you take it? If you could take all that functionality and not even have to wear a watch, would you take it?

The smart phone is a great compromise. It’s small and with you most of the time. But you still have to carry it. You can still easily lose or drop it and break it.

Smart watches and Google Glass try to solve these problems but, as Marco says, they do so with some pretty serious draw-backs. The smartphone is better for most people right now but that won’t always be the case.

CameraGPS debrief

As happy as I am with the way that my new app, CameraGPS, a GPS logger application for people who want to geotag their photographs, came out I can’t say that it’s exactly as I envisioned it at the start of the process.

The idea was something like this: many of the GPS logger apps in the App Store require you to either use iTunes file sharing (who connects their iPhone’s to iTunes any more?) or mail yourself the exported document or sign up to some third party fitness or trekking website. Mailing yourself stuff just didn’t feel very slick and I didn’t want to record my trails for fitness purposes.

I felt that there must be a better way. The better way, I thought, was to use iCloud to share the files between iOS and a Mac. This would require writing a recorder app for iPhone and an “exporter” app for the Mac.

It didn’t work out that way in the end. Here’s why.

You see all kinds of horror stories from people who have had to deal with iCloud. Most of those stories come from people who used the Core Data syncing, while there are a few apps that successfully use the document syncing model, not least some of Apple’s own. Using the document storage I figured that, worst case, if something gets screwed up it would only affect a single trail. Using Core Data syncing, an error could mean corrupting the whole database.

So this became the plan: record each GPS trail into a separate document. Because I wanted to “random access” parts of each trail and because I didn’t want to have to load the whole trail into memory all the time, I decided to use Core Data to manage the document. On iOS this is called UIManagedDocument.

The first and most obvious fail here is with UIManagedDocument’s cross platform capabilities. Or rather the lack of them. Unless you count iPhone to iPad as cross platform it just doesn’t work. There is a class on the Mac called NSPersistentDocument that is also a Core Data store and looks on the surface to do exactly the same thing… but it’s in a different format. On iOS it’s a “package” which includes a Core Data store. On the Mac it’s just the store. Mike Abdullah has written an open source component that attempts to be bridge the gap but — as we’ll see shorty — I didn’t get to the point where I was able to test it in anger.

But let’s take a step backwards. Let’s assume that all we need is to move data between iPhone and iPad. Then what?

Well, technically it works — in the sense that documents transfer between machines — just not in a way that would make sense to ship.

To make sense of why it doesn’t work let’s take a quick diversion to look at the format of a UIManagedDocument. As hinted above, it’s not a file. Rather it’s a “package” which a number of files within.

An important file is called DocumentMetadata.plist. This tells you about the rest of the package and is created when the document is. There’s little in here that needs to be changed after document creation. The interesting stuff is all stored in a SQLite file, which is stored in a folder.

When files are stored in iCloud you can’t just use NSFileManager to poke around and see what’s there. Instead you create a query using NSMetadataQuery — which supports both a predicate and a sort descriptor — and listen for updates. Updates come in two parts, the initial state and then changes to that state.

After a few false starts I ended up using KVO to populate a table view showing the current list of documents. This worked nicely, showing the full list, updating automatically when changes arrived over the network.

But, and it’s a big but, what if you want to sort the list. Pretty basic requirement, no?

One of the fun things about NSMetadataQuery is that it can only look for files. Folders are “invisible.”

Most of Apple’s documentation — where there is any — suggests searching for the DocumentMetadata.plist. Which makes sense but with two significant drawbacks: every file that you’re looking for now has exactly the same name; and the modification date is the creation date of the document rather than the time of the last update.

This means that you can’t sort the documents alphabetically or by modification date using only the metadata predicate. To get the names you need to listen for updates, copy them elsewhere and then butcher the file name, that is removing the last component and possibly the file extension.

To get the last modification date you probably need to open the document and do a Core Data query. This sounds pretty straight-forward but, again, there are difficulties. Remember that NSMetadataQuery tells us what’s available in iCloud rather than what has been downloaded onto the current device. Just because the query tells us the file is in iCloud doesn’t mean that you can open it immediately.

UIDocument helps us a bit here: if you ask to open a document it will download it if necessary. However there’s a big difference between opening a local file and downloading one over the network and then opening it. Also remember, at this point we’re not opening it as the result of a user request. We’re just trying to find the last modification date so that we can sort the list of documents conveniently.

None of this, of course, is impossible. It’s just a lot of faff for something that pretty much every app that wants to use UIDocument must have to go through.

Okay, so we get all that done. We’re good to go now, right? Not quite.

Part of the idea of using a UIDocument was that it would appear as a, well, document. But that whole thing about what NSMetatadataQuery “sees” comes back to haunt us.

The short, weird version is that if you configure the application to look for DocumentMetadata.plist, then that’s what is seen in the Settings app. Not very helpful as all the documents will all have the same name.

On the other hand you can configure the app to “know” about the document type. This means that the Settings app understands that they’re document and displays them with the correct “file” name. Unfortunately then the app can’t see the documents properly. Specifically, you can search for the document by name — which is nice — but you can’t actually open it. It’s odd and I’m not entirely sure what goes wrong, but when you call openWithCompletionHandler: it never actually calls the completion handler and the document never becomes available for use. (I initially thought that I just wasn’t being patient enough. I later accidentally left the app running for over two hours and the completion handler still never ran. That convinced me that it wasn’t a patience thing.)

I convinced myself that this couldn’t possibly be how it was supposed to work. My question on Stack Overflow didn’t get any answers and a reply to another, similar question said that the behaviour was “by design.”

I think it’s just broken and that no one is really using it. Either that or there’s a secret handshake that you have to give to the right person at WWDC.

So what’s shipping? Pretty much none of the above. I read about the new iOS 7 methods of Core Data – iCloud syncing and liked what I saw. Additionally iOS 7 comes with a few more APIs with better error handling hooks. This made me happier shipping with Core Data syncing. Just using “raw” Core Data meant that I could simplify a lot of code, use NSFetchedResultController and remove a bunch of the more fragile iCloud code (mostly NSMetadataQuery). While I was quite pleased with the KVO code I wrote, having far less code overall is a much bigger win.

And, in case you were wondering, I also de-scoped the Mac app and integrated Dropbox support instead.

But the bottom line is that this is all a lot harder than it should be. My concerns originally were around error conditions — something that has been very weak in iCloud since it’s introduction in iOS 5 — but it quickly morphed into questions about how it’s all supposed to work at all.

I once quipped on Twitter that you can tell which APIs are the ones Apple uses themselves as they’re the well designed ones. I think it’s pretty clear that Apple don’t use UIManagedDocument.